Export limit exceeded: 36397 CVEs match your query. Please refine your search to export 10,000 CVEs or fewer.
Search
Search Results (36397 CVEs found)
| CVE | Vendors | Products | Updated | CVSS v3.1 |
|---|---|---|---|---|
| CVE-2020-15871 | 1 Sonatype | 1 Nexus Repository Manager | 2026-09-22 | 8.8 High |
| Sonatype Nexus Repository Manager OSS/Pro version before 3.25.1 allows Remote Code Execution. | ||||
| CVE-2026-53266 | 1 Linux | 1 Linux Kernel | 2026-09-21 | 8.8 High |
| In the Linux kernel, the following vulnerability has been resolved: netfilter: bridge: make ebt_snat ARP rewrite writable The ebtables SNAT target keeps the Ethernet source address rewrite behind skb_ensure_writable(skb, 0). This is intentional: at the bridge ebtables hooks the Ethernet header is addressed through skb_mac_header()/eth_hdr(), while skb->data points at the Ethernet payload. Asking skb_ensure_writable() for ETH_HLEN bytes would check the payload, not the Ethernet header, and would reintroduce the small packet regression fixed by commit 63137bc5882a. However, the optional ARP sender hardware address rewrite is different. It writes through skb_store_bits() at an offset relative to skb->data: skb_store_bits(skb, sizeof(struct arphdr), info->mac, ETH_ALEN) skb_header_pointer() only safely reads the ARP header; it does not make the later sender hardware address range writable. If that range is still held in a nonlinear skb fragment backed by a splice-imported file page, skb_store_bits() maps the frag page and copies the new MAC address directly into it. Ensure the ARP SHA range is writable before reading the ARP header and before calling skb_store_bits(). | ||||
| CVE-2026-84556 | 1 Apple | 1 Macos | 2026-09-20 | 5.5 Medium |
| An authorization issue was addressed with improved access control. This issue is fixed in macOS Golden Gate 27, macOS Sequoia 15.8, macOS Tahoe 26.7. An app may be able to access sensitive user data. | ||||
| CVE-2026-84552 | 1 Apple | 4 Ios And Ipados, Ipados, Iphone Os and 1 more | 2026-09-20 | 5.5 Medium |
| The issue was addressed with improved memory handling. This issue is fixed in iOS 26.7 and iPadOS 26.7, iOS 27 and iPadOS 27, macOS Golden Gate 27, macOS Sequoia 15.8, macOS Tahoe 26.7. An app may be able to cause unexpected system termination. | ||||
| CVE-2026-84533 | 1 Apple | 6 Ios And Ipados, Ipados, Iphone Os and 3 more | 2026-09-20 | 5.3 Medium |
| A cryptographic issue was addressed with improved integrity checks. This issue is fixed in iOS 27 and iPadOS 27, macOS Golden Gate 27, tvOS 27, watchOS 27. An attacker in a privileged network position may be able to modify network traffic. | ||||
| CVE-2026-65383 | 1 Apple | 1 Macos | 2026-09-20 | 4.4 Medium |
| This issue was addressed with improved checks. This issue is fixed in macOS Golden Gate 27. An app may bypass Gatekeeper checks. | ||||
| CVE-2024-21262 | 2 Netapp, Oracle | 2 Oncommand Insight, Mysql Connector\/odbc | 2026-09-18 | 6.5 Medium |
| Vulnerability in the MySQL Connectors product of Oracle MySQL (component: Connector/ODBC). Supported versions that are affected are 9.0.0 and prior. Easily exploitable vulnerability allows unauthenticated attacker with network access via multiple protocols to compromise MySQL Connectors. Successful attacks of this vulnerability can result in unauthorized update, insert or delete access to some of MySQL Connectors accessible data and unauthorized ability to cause a partial denial of service (partial DOS) of MySQL Connectors. CVSS 3.1 Base Score 6.5 (Integrity and Availability impacts). CVSS Vector: (CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:L/A:L). | ||||
| CVE-2025-23367 | 1 Redhat | 8 Build Keycloak, Jboss Data Grid, Jboss Enterprise Application Platform and 5 more | 2026-09-17 | 6.5 Medium |
| A flaw was found in the Wildfly Server Role Based Access Control (RBAC) provider. When authorization to control management operations is secured using the Role Based Access Control provider, a user without the required privileges can suspend or resume the server. A user with a Monitor or Auditor role is supposed to have only read access permissions and should not be able to suspend the server. The vulnerability is caused by the Suspend and Resume handlers not performing authorization checks to validate whether the current user has the required permissions to proceed with the action. | ||||
| CVE-2026-3203 | 1 Wireshark | 1 Wireshark | 2026-09-17 | 5.5 Medium |
| RF4CE Profile protocol dissector crash in Wireshark 4.6.0 to 4.6.3 and 4.4.0 to 4.4.13 allows denial of service | ||||
| CVE-2026-42499 | 2 Go Standard Library, Golang | 2 Net\/mail, Go | 2026-09-17 | 7.5 High |
| Pathological inputs could cause DoS through consumePhrase when parsing an email address according to RFC 5322. | ||||
| CVE-2026-9546 | 2 Curl, Haxx | 2 Curl, Curl | 2026-09-15 | 7.5 High |
| A vulnerability in libcurl caused the HTTP `Referer:` header to persist even when explicitly cleared. While the documentation states that passing NULL to `CURLOPT_REFERER` suppresses the header, the option failed to clear the internal state. As a result, the previous referrer string was erroneously reused and sent in subsequent requests, potentially leaking sensitive information to unintended servers. | ||||
| CVE-2026-9545 | 2 Curl, Haxx | 2 Curl, Curl | 2026-09-15 | 7.5 High |
| In this scenario, libcurl first uses a proper HTTP/3 server for the initial transfers, and when it makes a second transfer to the same site it has been replaced by the attacker's impostor machine - without a valid certificate. When libcurl returns to the hostname the second time with a cached SSL session (`CURLOPT_SSL_SESSIONID_CACHE` is not disabled) and early data enabled (the `CURLSSLOPT_EARLYDATA` bit is set in `CURLOPT_SSL_OPTIONS`), libcurl might send off the second request's bytes on that new connection *before* enforcing the certificate verification failure. Potentially leaking sensitive information. | ||||
| CVE-2026-8924 | 2 Curl, Haxx | 2 Curl, Curl | 2026-09-15 | 9.1 Critical |
| A flaw in curl’s cookie parsing logic allows a malicious HTTP server to set "super cookies" that bypass the Public Suffix List check. This enables an attacker-controlled origin to inject cookies that curl subsequently scopes and transmits to unrelated third-party domains. | ||||
| CVE-2026-8458 | 2 Curl, Haxx | 2 Curl, Curl | 2026-09-15 | 6.5 Medium |
| libcurl might in some circumstances reuse the wrong connection when asked to do Negotiate-authenticated ones, even when they are set to use different "services". libcurl features a pool of recent connections so that subsequent requests can reuse an existing connection to avoid overhead. When reusing a connection a range of criteria must be met. Due to a logical error in the code, a request that was issued by an application could wrongfully reuse an existing connection to the same server that was authenticated using different services. | ||||
| CVE-2026-6429 | 2 Curl, Haxx | 2 Libcurl, Curl | 2026-09-15 | 5.3 Medium |
| When asked to both use a `.netrc` file for credentials and to follow HTTP redirects, libcurl could leak the password used for the first host to the followed-to host under certain circumstances. | ||||
| CVE-2025-10148 | 2 Curl, Haxx | 2 Curl, Curl | 2026-09-15 | 5.3 Medium |
| curl's WebSocket code did not update the 32-bit mask pattern for each new outgoing frame as the specification says. Instead it used a fixed mask that persisted and was used throughout the entire connection. A predictable mask pattern allows for a malicious server to induce traffic between the two communicating parties that could be interpreted by an involved proxy (configured or transparent) as genuine, real, HTTP traffic with content and thereby poison its cache. That cached poisoned content could then be served to all users of that proxy. | ||||
| CVE-2024-21400 | 1 Microsoft | 1 Confcom | 2026-09-14 | 9 Critical |
| Microsoft Azure Kubernetes Service Confidential Container Elevation of Privilege Vulnerability | ||||
| CVE-2026-52944 | 1 Linux | 1 Linux Kernel | 2026-09-14 | 5.5 Medium |
| In the Linux kernel, the following vulnerability has been resolved: ksmbd: fix FSCTL permission bypass by adding a permission check for FSCTL_SET_SPARSE FSCTL_SET_SPARSE in fsctl_set_sparse() modifies the file's sparse attribute and saves it through xattr without any permission checks. This exposes two issues: 1) A client on a read-only share can change the sparse attribute on files it opened, even though the share is read-only. Other FSCTL write operations already check test_tree_conn_flag(work->tcon, KSMBD_TREE_CONN_FLAG_WRITABLE), but FSCTL_SET_SPARSE does not. 2) Even on writable shares, clients without FILE_WRITE_DATA or FILE_WRITE_ATTRIBUTES access should not modify the sparse attribute. Similar handle-level checks exist in other functions but are missing here. Add both share-level writable check and per-handle access check. Use goto out on error to avoid leaking file references. | ||||
| CVE-2026-46170 | 1 Linux | 1 Linux Kernel | 2026-09-14 | 5.5 Medium |
| In the Linux kernel, the following vulnerability has been resolved: mptcp: pm: ADD_ADDR rtx: free sk if last When an ADD_ADDR is retransmitted, the sk is held in sk_reset_timer(), and released at the end. If at that moment, it was the last reference being held, the sk would not be freed. sock_put() should then be called instead of __sock_put(). But that's not enough: if it is the last reference, sock_put() will call sk_free(), which will end up calling sk_stop_timer_sync() on the same timer, and waiting indefinitely to finish. So it is needed to mark that the timer is done at the end of the timer handler when it has not been rescheduled, not to call sk_stop_timer_sync() on "itself". | ||||
| CVE-2026-46158 | 1 Linux | 1 Linux Kernel | 2026-09-14 | 5.5 Medium |
| In the Linux kernel, the following vulnerability has been resolved: mptcp: pm: ADD_ADDR rtx: always decrease sk refcount When an ADD_ADDR is retransmitted, the sk is held in sk_reset_timer(). It should then be released in all cases at the end. Some (unlikely) checks were returning directly instead of calling sock_put() to decrease the refcount. Jump to a new 'exit' label to call __sock_put() (which will become sock_put() in the next commit) to fix this potential leak. While at it, drop the '!msk' check which cannot happen because it is never reset, and explicitly mark the remaining one as "unlikely". | ||||