Export limit exceeded: 423918 CVEs match your query. Please refine your search to export 10,000 CVEs or fewer.
Search
Search Results (423918 CVEs found)
| CVE | Vendors | Products | Updated | CVSS v3.1 |
|---|---|---|---|---|
| CVE-2026-105752 | 2 Vllm, Vllm-project | 2 Vllm, Vllm | 2026-10-08 | 3.1 Low |
| vLLM is an inference and serving engine for large language models. Prior to 0.30.0, Harmony tool continuations submitted through "POST /v1/responses" requests rebuild the next-turn engine input without preserving the cache_salt value, placing the continuation prefix in the global unsalted cache namespace even when the caller enabled salting. On deployments with prefix caching enabled, which is the default, an authenticated tenant who can reconstruct a victim's low-entropy post-tool history can submit the same continuation and use the cached_tokens_per_turn count to determine whether the prefix was previously processed, defeating the intended tenant isolation of salted prefix caching. This issue is fixed in version 0.30.0. | ||||
| CVE-2026-105753 | 2 Vllm, Vllm-project | 2 Vllm, Vllm | 2026-10-08 | 6.5 Medium |
| vLLM is an inference and serving engine for large language models. Prior to 0.28.0, the default mirrored multimodal LRU cache can commit a media hash in the frontend sender cache during multimodal rendering and before engine admission, while the engine receiver cache never receives the payload if that request is rejected. A later request reusing the same media hash causes MultiModalProcessorSenderCache to send no payload and MultiModalReceiverCache to reach an assertion with the message "Expected a cached item," producing a shared-service availability failure. This issue is fixed in version 0.28.0. | ||||
| CVE-2026-105755 | 2 Vllm, Vllm-project | 2 Vllm, Vllm | 2026-10-08 | 4.2 Medium |
| vLLM is an inference and serving engine for large language models. Prior to 0.30.0, flash late-interaction scoring at the /score and /rerank endpoints derives each worker's query_key value from the caller-controlled X-Request-Id header. A concurrent request that reuses a victim's identifier can overwrite the cached query embedding so the victim's documents are scored against the attacker's query, and shared use counters can also cause a late-interaction cache-miss error. This issue is fixed in version 0.30.0. | ||||
| CVE-2026-105756 | 2 Vllm, Vllm-project | 2 Vllm, Vllm | 2026-10-08 | 6.5 Medium |
| vLLM is an inference and serving engine for large language models. Prior to 0.30.0, OpenAI-compatible request models accept a non-empty cache_salt value without enforcing the character and length restrictions required by the IPCCacheServerKey consumer in LMCache-MP. On deployments using the LMCache-MP connector, a salt that contains a forbidden character or exceeds the permitted length can raise an uncaught ValueError during scheduler cache lookup, causing EngineCore to terminate and denying service to all concurrent users. This issue is fixed in version 0.30.0. | ||||
| CVE-2026-105757 | 2 Vllm, Vllm-project | 2 Vllm, Vllm | 2026-10-08 | 6.5 Medium |
| vLLM is an inference and serving engine for large language models. Prior to 0.30.0, structured-output request failures can escape request-scoped validation and reach the EngineCore fatal-error path. A per-request backend mismatch can re-raise a grammar compilation exception, padding produced by the ngram_gpu speculative-decoding mode can pass a negative token to guidance validation, and the Rust frontend can admit empty structured-output values that the Python frontend rejects, allowing ordinary constrained-generation requests to terminate the shared engine. This issue is fixed in version 0.30.0. | ||||
| CVE-2026-106220 | 1 Google | 1 Chrome | 2026-10-08 | 8.8 High |
| Information leak in Passwords in Google Chrome prior to 155.0.8059.39 allowed a remote attacker to obtain sensitive information via a crafted HTML page. (Chromium security severity: Low) | ||||
| CVE-2026-106222 | 1 Google | 1 Chrome | 2026-10-08 | 5.9 Medium |
| Incorrect authorization in Sync in Google Chrome prior to 155.0.8059.39 allowed a remote attacker to obtain sensitive information via crafted network traffic. (Chromium security severity: Medium) | ||||
| CVE-2026-93679 | 2 Ibm, Langflow | 2 Langflow Oss, Langflow | 2026-10-08 | 4.3 Medium |
| IBM Langflow OSS 1.0.0 through 1.12.2 could allow a remote authenticated attacker to cause a denial of service due to uncontrolled resource consumption during ZIP file extraction. | ||||
| CVE-2026-97671 | 2 Ibm, Langflow | 2 Langflow Oss, Langflow | 2026-10-08 | 6.5 Medium |
| IBM Langflow OSS 1.0.0 through 1.12.2 could allow a remote authenticated attacker to obtain sensitive information due to a path traversal vulnerability. | ||||
| CVE-2026-97673 | 2 Ibm, Langflow | 2 Langflow Oss, Langflow | 2026-10-08 | 8.8 High |
| IBM Langflow OSS 1.0.0 through 1.12.2 could allow a remote authenticated attacker to execute arbitrary code due to improper input validation. | ||||
| CVE-2026-97676 | 2 Ibm, Langflow | 2 Langflow Oss, Langflow | 2026-10-08 | 8.8 High |
| IBM Langflow OSS 1.0.0 through 1.12.2 could allow a remote authenticated attacker to execute arbitrary code due to improper neutralization of special elements used in code, resulting in a sandbox escape. | ||||
| CVE-2026-97680 | 2 Ibm, Langflow | 2 Langflow Oss, Langflow | 2026-10-08 | 8.3 High |
| IBM Langflow OSS 1.0.0 through 1.12.2 could allow a remote authenticated attacker to obtain sensitive information or inject malicious data due to improper access control in the vertex result caching subsystem. | ||||
| CVE-2026-106223 | 1 Google | 2 Android, Chrome | 2026-10-08 | 4.7 Medium |
| Uninitialized resource in GPU in Google Chrome on on Android prior to 155.0.8059.39 allowed a remote attacker to read memory outside the sandbox via a crafted HTML page. (Chromium security severity: Medium) | ||||
| CVE-2026-106224 | 1 Google | 1 Chrome | 2026-10-08 | 3.1 Low |
| Missing authorization in Google Lens in Google Chrome prior to 155.0.8059.39 allowed a remote attacker who had compromised the renderer process to obtain cross-origin data via a crafted HTML page. (Chromium security severity: Medium) | ||||
| CVE-2026-106225 | 1 Google | 1 Chrome | 2026-10-08 | 8.8 High |
| Missing authorization in Autofill in Google Chrome prior to 155.0.8059.39 allowed a remote attacker leveraging social engineering to obtain sensitive information via a crafted HTML page. (Chromium security severity: Medium) | ||||
| CVE-2026-84784 | 1 Openssl | 1 Openssl | 2026-10-08 | 7.5 High |
| Issue summary: A malicious remote peer may flood the local QUIC stack with NEW_CONNECTION_ID frames by avoiding a limit check on how many connection IDs the remote QUIC stack can use. Impact summary: The local QUIC stack sends a RETIRE_CONN_ID frame for every NEW_CONNECTION_ID frame it receives. The RETIRE_CONN_ID frame is dispatched via the Control Frame Queue (CFQ). If the remote peer also withholds ACKs, then it can force the local stack to allocate ~400MB (depending on ACK delay). CWE: CWE-770: Allocation of Resources Without Limits or Throttling Description: RFC 9000 sections 5.1.1 and 5.1.2 [1] describe the mechanism by which a remote peer can notify the local QUIC stack to change the destination connection ID (a.k.a. CID) the local stack uses to identify the connection at the remote peer. Each CID is associated with a sequence number. The sequence number is transmitted in NEW_CONNECTION_ID and RETIRE_CONNECTION_ID frames to identify the CID which is being either associated with a connection or retired. The remote peer sends a NEW_CONNECTION_ID frame to let the local stack know a new CID is being associated with an existing connection. The NEW_CONNECTION_ID frame carries the new CID, its sequence number, and the retire-prior-to number. The retire-prior-to identifies existing CIDs that are to be retired. The local QUIC stack must send a RETIRE_CONNECTION_ID for every destination CID whose sequence number is less than retire-prior-to. The CID becomes retired after the local stack receives an ACK for its RETIRE_CONNECTION_ID frame. Although the OpenSSL QUIC stack supports at most one destination CID for every connection, it can be tricked into processing more than one RETIRE_CONNECTION_ID frame per connection. The OpenSSL QUIC stack currently retires the destination CID as soon as it receives the NEW_CONNECTION_ID, while in fact the destination CID must be retired after an ACK for the RETIRE_CONNECTION_ID frame is received. Correcting the flawed logic also fixes the backlog growth. [1] https://datatracker.ietf.org/doc/html/rfc9000#name-issuing-connection-ids FIPS impact: no The FIPS module is not affected as the QUIC implementation is outside of the OpenSSL FIPS module boundary. | ||||
| CVE-2026-84783 | 2 Openssl, Redhat | 2 Openssl, Hummingbird | 2026-10-08 | 7.5 High |
| Issue summary: The first concurrent use of the same X.509 certificate by several threads may cause its cached extension data to be freed while another thread is still using it. Impact summary: A remote, unauthenticated peer could crash a multi-threaded TLS client, or a multi-threaded TLS server that requests client certificates, if the first certificate chains built to the same trusted CA certificate are built by several connections at the same time. This is a use-after-free read, which is likely to crash the process, resulting in a Denial of Service. CWE: CWE-416: Use After Free Description: OpenSSL caches the decoded values of a certificate's X.509v3 extensions inside the X509 object the first time they are needed. In OpenSSL 4.0 this cache is built in two phases: the extension values are computed while holding a read lock on the certificate, and the results are then installed into the certificate under a write lock. Because a read lock does not exclude other readers, several threads can compute the cache for the same certificate at the same time. Each thread that subsequently acquires the write lock installs its own results and frees the values installed by the thread before it, even though that earlier thread has already marked the cache as complete and may have returned pointers into it to its caller. A caller still using those pointers then reads freed memory. Any certificate shared between threads is exposed the first time its extensions are decoded. In TLS the certificates at risk are the trusted CA certificates supplied for chain verification, by whatever means, since these are shared by every connection and their extensions are decoded and cached the first time a chain is built to them. Certificates sent by the peer are decoded separately for each connection and are not shared, so they are not affected. In a TLS client verifying server certificates, or a TLS server that requests and verifies client certificates, the use-after-free could only occur if the first chains built to the same trusted CA are built by several connections at the same time. FIPS impact: no The FIPS module is not affected as X.509 certificate handling is outside of the OpenSSL FIPS module boundary. OpenSSL 4.0 is vulnerable to this issue. OpenSSL 3.6, 3.5, 3.4, 3.0, 1.1.1 and 1.0.2 are not affected by this issue. OpenSSL 4.0 users should upgrade to OpenSSL 4.0.3. This issue was reported on 27 August 2026 by Tim Becker (Xint.io) and independently in a public report on 31 August 2026 by aydinmercan. The fix has been developed by Bob Beck. -- cut (non-publishing metadata for internal use) -- Reported by: Tim Becker (Xint.io), aydinmercan Fixed by: Bob Beck | ||||
| CVE-2026-75804 | 1 Openssl | 1 Openssl | 2026-10-08 | 5.3 Medium |
| Issue summary: OpenSSL QUIC stack does not enforce connection level flow control for streams. Remote peers may send more bytes as long as they fit within the stream flow control limits. Impact summary: A malicious remote peer may exploit the lack of connection flow control for streams to make the QUIC stack receive ~100MB of memory instead of 768 KiB (default flow control window size). CWE: CWE-770: Allocation of Resources Without Limits or Throttling Description: The local QUIC stack advertises two flow control limits to its remote peer: stream flow control limit and connection flow control limit. The remote peer must follow both limits when transmitting stream data. Whenever the local QUIC stack receives a stream frame, it validates that the size of the received stream frame stays within flow control limits. If either limit is exceeded (stream level or connection level), then the QUIC stack must close the connection with a flow control error. The vulnerable OpenSSL QUIC stack enforces the stream-level but not the connection-level limit. To exploit the issue, three conditions must be met: - the remote peer opens several streams - each stream must stay within the stream-level flow control limit - there must be no zero-offset byte sent on any of the streams (to prevent the vulnerable QUIC stack from consuming data). By meeting the conditions above, the remote peer may make the local stack allocate 2 x MAX_STREAMS x (stream flow control limit) bytes of memory. MAX_STREAMS defaults to 100, and the limit applies to both bidirectional and unidirectional streams, making it 200 in total. The default flow control window for a stream is 512kB. The remote peer may force the vulnerable QUIC stack to allocate 100MB of heap per connection. FIPS impact: no The FIPS module is not affected as the QUIC implementation is outside of the OpenSSL FIPS module boundary. | ||||
| CVE-2026-72897 | 1 Openssl | 1 Openssl | 2026-10-08 | 7.5 High |
| Issue summary: A TLS server that calls SSL_set_SSL_CTX() to switch a connection to a different SSL_CTX part way through a handshake may access memory beyond the end of an internal array if the replacement context knows about more provider signature algorithms than the context the connection was created from. Applications which never call SSL_set_SSL_CTX() are not affected. Impact summary: A remote peer may be able to cause a small out-of-bounds read, and in some circumstances a fixed-value out-of-bounds write, on the server heap. This may lead to a Denial of Service. CWE: CWE-787: Out-of-bounds Write Description: A TLS connection records how many certificate slots it has when it is created, taken from the SSL_CTX that created it: the built-in certificate types plus one slot for each provider TLS-SIGALG entry that context was aware of. That count sizes an internal array of per-slot certificate validity flags. An application may replace a connection's SSL_CTX part way through the handshake by calling SSL_set_SSL_CTX(), most commonly from a servername callback in order to serve a different virtual host. Doing so did not refresh the recorded count. A provider signature algorithm's slot index is its position in the list of whichever context resolves it, so if the replacement context is aware of more of them than the original, an algorithm offered by the peer can resolve to an index beyond the end of the array. Processing the peer's signature algorithms then reads one four byte word past the end for each such algorithm and, where the word read is zero, writes a fixed value over it. A peer offering many of them can corrupt heap metadata and abort the process. Only provider signature algorithms which occupy one of the excess slots, and which the server also has configured, have this effect. Codepoints the replacement context does not recognise are discarded without being resolved to a slot, and provider signature algorithms are usable only from TLS 1.3. The two contexts must therefore be aware of different numbers of provider signature algorithms, which requires separate library contexts, a provider loaded between the two being created, or providers which differ in what they advertise - in 4.0, for example, the default provider advertises SM2 where the FIPS provider does not. A deployment meeting the condition is also unable to negotiate the affected algorithms with legitimate clients, since the same stale count hides the corresponding certificates, so the misconfiguration is likely to be noticed. For that reason, and because the configuration is not the default, this issue has been assessed as Low severity. FIPS impact: no No FIPS modules are affected by this issue as the affected code is outside the OpenSSL FIPS module boundary. | ||||
| CVE-2026-54875 | 1 Openssl | 1 Openssl | 2026-10-08 | 3.7 Low |
| Issue summary: A non-constant-time optimized implementation of scalar point multiplication is used for SM2 private key operations on ARM64 and RISC-V platforms. Impact summary: An attacker able to measure the time taken by, or to observe the cache-line access pattern of SM2 signing or decryption on an affected platform can learn information about the secret scalar. CWE: CWE-208: Observable Timing Discrepancy Description: On ARM64 and RISC-V processors, the SM2 curve uses an optimized scalar multiplication implementation whose conditional branches and table look ups are chosen according to the bits of the secret scalar. The execution time and the cache-access pattern therefore depend on the long-term private key (during SM2 decryption) or the per-signature nonce (during SM2 signature generation), forming a timing and cache side-channel. FIPS Impact: no SM2 is not a FIPS algorithm and the optimized SM2 implementation is not part of the FIPS module. OpenSSL 4.0, 3.6, 3.5 and 3.4 are vulnerable to this issue on AArch64 and RISC-V. OpenSSL 3.0, 1.1.1 and 1.0.2 are not affected by this issue. OpenSSL 4.0 users should upgrade to OpenSSL 4.0.3. OpenSSL 3.6 users should upgrade to OpenSSL 3.6.5. OpenSSL 3.5 users should upgrade to OpenSSL 3.5.9. OpenSSL 3.4 users should upgrade to OpenSSL 3.4.8. This issue was reported on 2 May 2026 by Abhinav Agarwal. It was independently reported on 6 June 2026 by Feng Xue. The fix was developed by Igor Ustinov. -- cut (non-publishing metadata for internal use) -- Reported by: Abhinav Agarwal, Feng Xue Fixed by: Igor Ustinov | ||||