Export limit exceeded: 54609 CVEs match your query. Please refine your search to export 10,000 CVEs or fewer.
Search
Search Results (54609 CVEs found)
| CVE | Vendors | Products | Updated | CVSS v3.1 |
|---|---|---|---|---|
| CVE-2024-5535 | 5 Debian, Netapp, Openssl and 2 more | 72 Debian Linux, 500f, 500f Firmware and 69 more | 2026-11-10 | 9.1 Critical |
| Issue summary: Calling the OpenSSL API function SSL_select_next_proto with an empty supported client protocols buffer may cause a crash or memory contents to be sent to the peer. Impact summary: A buffer overread can have a range of potential consequences such as unexpected application beahviour or a crash. In particular this issue could result in up to 255 bytes of arbitrary private data from memory being sent to the peer leading to a loss of confidentiality. However, only applications that directly call the SSL_select_next_proto function with a 0 length list of supported client protocols are affected by this issue. This would normally never be a valid scenario and is typically not under attacker control but may occur by accident in the case of a configuration or programming error in the calling application. The OpenSSL API function SSL_select_next_proto is typically used by TLS applications that support ALPN (Application Layer Protocol Negotiation) or NPN (Next Protocol Negotiation). NPN is older, was never standardised and is deprecated in favour of ALPN. We believe that ALPN is significantly more widely deployed than NPN. The SSL_select_next_proto function accepts a list of protocols from the server and a list of protocols from the client and returns the first protocol that appears in the server list that also appears in the client list. In the case of no overlap between the two lists it returns the first item in the client list. In either case it will signal whether an overlap between the two lists was found. In the case where SSL_select_next_proto is called with a zero length client list it fails to notice this condition and returns the memory immediately following the client list pointer (and reports that there was no overlap in the lists). This function is typically called from a server side application callback for ALPN or a client side application callback for NPN. In the case of ALPN the list of protocols supplied by the client is guaranteed by libssl to never be zero in length. The list of server protocols comes from the application and should never normally be expected to be of zero length. In this case if the SSL_select_next_proto function has been called as expected (with the list supplied by the client passed in the client/client_len parameters), then the application will not be vulnerable to this issue. If the application has accidentally been configured with a zero length server list, and has accidentally passed that zero length server list in the client/client_len parameters, and has additionally failed to correctly handle a "no overlap" response (which would normally result in a handshake failure in ALPN) then it will be vulnerable to this problem. In the case of NPN, the protocol permits the client to opportunistically select a protocol when there is no overlap. OpenSSL returns the first client protocol in the no overlap case in support of this. The list of client protocols comes from the application and should never normally be expected to be of zero length. However if the SSL_select_next_proto function is accidentally called with a client_len of 0 then an invalid memory pointer will be returned instead. If the application uses this output as the opportunistic protocol then the loss of confidentiality will occur. This issue has been assessed as Low severity because applications are most likely to be vulnerable if they are using NPN instead of ALPN - but NPN is not widely used. It also requires an application configuration or programming error. Finally, this issue would not typically be under attacker control making active exploitation unlikely. The FIPS modules in 3.3, 3.2, 3.1 and 3.0 are not affected by this issue. Due to the low severity of this issue we are not issuing new releases of OpenSSL at this time. The fix will be included in the next releases when they become available. | ||||
| CVE-2026-69005 | 1 Samsung Semiconductor | 6 Exynos 1480, Exynos 1580, Exynos 1680 and 3 more | 2026-11-10 | 7.3 High |
| Integer overflow in NPU driver parameter processing due to insufficient bounds checking. | ||||
| CVE-2026-68984 | 1 Samsung Semiconductor | 10 Exynos 1280, Exynos 1380, Exynos 1480 and 7 more | 2026-11-10 | 8.1 High |
| In the Samsung Exynos NPU kernel driver, an integer overflow allows an unprivileged application to trigger memory corruption. | ||||
| CVE-2026-48179 | 1 Samsung Semiconductor | 5 Exynos 1080, Exynos 9110, Exynos Modem 5123 and 2 more | 2026-11-10 | 7.5 High |
| In the Exynos modem's IMS stack, improper handling of SDP payload leads to a Denial of Service | ||||
| CVE-2026-48176 | 1 Samsung Semiconductor | 5 Exynos 1080, Exynos 9110, Exynos Modem 5123 and 2 more | 2026-11-10 | 7.5 High |
| A memory corruption vulnerability caused by improper validation of messages | ||||
| CVE-2026-48173 | 1 Samsung Semiconductor | 19 Exynos 1280, Exynos 1330, Exynos 1380 and 16 more | 2026-11-10 | 9.8 Critical |
| In the NAS message handler, improper validation of the length field in NAS message causes memory corruption | ||||
| CVE-2026-33972 | 1 Samsung Semiconductor | 5 Exynos 1080, Exynos 9110, Exynos Modem 5123 and 2 more | 2026-11-10 | 9.8 Critical |
| In the Exynos modem's IMS stack, Out of Bound access occurs due to improper validation. | ||||
| CVE-2026-33958 | 1 Samsung Semiconductor | 15 Exynos 1080, Exynos 1280, Exynos 1330 and 12 more | 2026-11-10 | 7.5 High |
| Processing a malformed RRC Reconfiguration message leads to an out-of-bounds (OOB) access, resulting in a denial-of-service (DoS) condition. | ||||
| CVE-2026-123776 | 2026-11-10 | 9.8 Critical | ||
| RRD::CGI::Image versions through 0.01 for Perl pass CGI query parameters containting "tz" to tzset(), , so a FIFO or device path blocks the CGI process. The normalize_params method sends any query key matching /tz/i to tz(), which sets $ENV{TZ} to that value, with no validation. It then calls tzset(). glibc treats a TZ value starting with / or : as a file path and opens it, so a value naming a FIFO or a blocking device stalls the process inside tzset(). | ||||
| CVE-2025-66367 | 1 Samsung Semiconductor | 18 Exynos 1280, Exynos 1330, Exynos 1380 and 15 more | 2026-11-10 | 7.5 High |
| Improper handling of NAS DLTransport messages may lead to a baseband crash. | ||||
| CVE-2025-66366 | 1 Samsung Semiconductor | 10 Exynos 1280, Exynos 1330, Exynos 1380 and 7 more | 2026-11-10 | 7.5 High |
| Incorrect handling of unauthenticated downlink RRC Setup messages can cause the baseband to crash | ||||
| CVE-2026-120399 | 1 Redhat | 1 Edge Manager | 2026-11-10 | 7.5 High |
| A flaw was found in flightctl. A TLS handshake is performed synchronously in the HTTP server’s connection-context callback without a deadline. A network-reachable unauthenticated client can stall the handshake and prevent the affected listener from accepting new connections. | ||||
| CVE-2026-9669 | 1 Python | 1 Cpython | 2026-11-10 | 5.9 Medium |
| bz2.BZ2Decompressor objects could be reused after a decompression error. If an application caught the resulting OSError and retried with the same decompressor, crafted input could cause the decompressor to resume from an invalid internal state and perform out-of-bounds writes to a stack buffer. This could crash the process when processing untrusted data. | ||||
| CVE-2026-93990 | 2 Libexpat, Libexpat Project | 2 Expat, Libexpat | 2026-11-10 | 7.5 High |
| Expat before 2.8.5 fails to validate that a high surrogate in UTF-16 input is followed by a low surrogate, allowing malformed UTF-16 sequences to be accepted. Attackers can supply UTF-16 encoded XML containing lone high surrogates that consume the following code unit, causing Expat to pass unpaired surrogates to applications built with XML_UNICODE and to silently replace input characters in other builds. | ||||
| CVE-2026-84782 | 2 Openssl, Redhat | 2 Openssl, Hummingbird | 2026-11-10 | 8.2 High |
| Issue summary: The DTLS retransmission logic does not correctly handle a handshake message write that is suspended part-way through. The retransmitted message can be read past the message buffer and the retransmission overwrites the internal state the suspended write needs to resume correctly. Impact summary: The retransmitted message can disclose a heap memory to the peer as plaintext handshake data or cause a crash and a Denial of Service when the read reaches an unmapped memory region. CWE: CWE-125: Out-of-bounds Read Description: DTLS handshake messages can be written out in multiple fragments, and a write can suspend mid-message (returning WANT_WRITE) if the underlying transport temporarily cannot accept more data. While such a write is suspended, the DTLS retransmission timer may independently fire and ask the retransmission logic to resend an earlier, already-acknowledged-as-sent message from its retransmit queue. The retransmission logic reused the same internal buffer and position tracking as the message that was still being written, without resetting the position back to the start of the message being retransmitted. As a result the retransmission was read starting from wherever the suspended write had left off, producing a mislabelled message whose body was leftover bytes from the other, larger message still in flight - content that was never meant to be sent at that point, and which could run past the end of the allocated buffer. Separately, even when the retransmission is positioned correctly, allowing it to run to completion while another write is suspended overwrites the same shared bookkeeping that the suspended write depends on to resume. When the application later resumes the suspended write (via a subsequent SSL_read(), SSL_write(), SSL_accept(), or SSL_connect() call), it finds that bookkeeping in a state inconsistent with the message and aborts the process in a debugging build. The fix resets the retransmission's read position to the start of the message before resending, and skips retransmission entirely whenever a handshake write is still suspended, deferring to the next call that resumes it instead. FIPS impact: no The affected code is outside the FIPS module boundary. | ||||
| CVE-2026-7598 | 1 Libssh2 | 1 Libssh2 | 2026-11-10 | 7.3 High |
| A security vulnerability has been detected in libssh2 up to 1.11.1. The impacted element is the function userauth_password of the file src/userauth.c. Such manipulation of the argument username_len/password_len leads to integer overflow. The attack may be launched remotely. The name of the patch is 256d04b60d80bf1190e96b0ad1e91b2174d744b1. A patch should be applied to remediate this issue. | ||||
| CVE-2026-7010 | 1 Haarg | 1 Http::tiny | 2026-11-10 | 6.5 Medium |
| HTTP::Tiny versions before 0.093 for Perl do not validate CRLF in HTTP request lines or control field header values. The unvalidated inputs are the method and URI in the request line, the URL host that becomes the `Host:` header, and HTTP/1.1 control data field values. An attacker who controls one of these inputs, for example a user supplied URL passed to a webhook or URL fetch endpoint, can inject additional headers and smuggle requests to the upstream server. | ||||
| CVE-2026-77214 | 2 Libexpat, Libexpat Project | 2 Expat, Libexpat | 2026-11-10 | 8.2 High |
| libexpat before commit 13c5f63 contains a heap buffer over-read vulnerability in xmlparse.c. XML_ParseBuffer advances the parse buffer end with parser->m_bufferEnd += len using a caller-supplied length that is not validated against the allocated buffer size, so repeated XML_ParseBuffer calls move m_bufferEnd past the end of the heap allocation and subsequent parsing reads out of bounds. Reaching this path requires a parse buffer to already be present; otherwise XML_ParseBuffer returns XML_ERROR_NO_BUFFER. A buffer is present after a prior call to XML_GetBuffer, either directly (the common case) or indirectly through a prior XML_Parse call that allocates the buffer internally. The over-read discloses adjacent heap memory to the calling application, recovering heap pointers, libc function pointers, and code pointers sufficient to defeat ASLR and build further exploitation primitives. | ||||
| CVE-2026-75806 | 1 Openssl | 1 Openssl | 2026-11-10 | 5.3 Medium |
| Issue summary: An established DTLS 1.2 association using an AEAD cipher suite can be terminated by a single unauthenticated datagram whose encrypted fragment is shorter than the mandatory explicit IV and authentication tag overhead. Impact summary: An attacker who can send a datagram that is routed to an existing DTLS 1.2 association can tear that association down without knowing any key material. This is a Denial of Service limited to the targeted association. There is no memory safety or confidentiality impact. CWE: CWE-1284: Improper Validation of Specified Quantity in Input Description: In TLS 1.2 and DTLS 1.2 every record protected by an AEAD cipher suite carries an explicit IV followed by the ciphertext and an authentication tag. When decrypting such a record the record layer passed the record length to the cipher implementation before checking that the record was long enough to contain the explicit IV and the tag. For a record shorter than that overhead the cipher implementation rejected the impossible length, and the record layer treated this as an internal failure and raised a fatal internal_error alert instead of treating the record as one that failed authentication. In TLS 1.2 the same record causes a fatal internal_error alert instead of the expected bad_record_mac alert. Since any undecryptable record already terminates a TLS connection, this is a protocol conformance issue rather than a security issue in TLS. The fix validates the record length against the explicit IV and tag length before any AEAD processing, so that TLS reports bad_record_mac and DTLS silently discards the record. FIPS impact: no The affected code is outside the FIPS module boundary. | ||||
| CVE-2026-72522 | 1 Libexpat Project | 1 Libexpat | 2026-11-10 | 6.2 Medium |
| libexpat before 2.8.3 has an out-of-bounds read and resultant infinite loop because low surrogates are treated the same as high surrogates during Unicode processing in the *_toUtf16 functions. | ||||