🚨 CVE-2026-84784
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.
🎖@cveNotify
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.
🎖@cveNotify
GitHub
CVE-2026-84784 QUIC: unbounded RETIRE_CONNECTION_ID backlog (memory DoS) · openssl/openssl@4685c91
Currently the cur_retire_prior_to counter is updated when RETIRE_CONNECTION_ID
is dispatched to control frame queue. However to follow protocol state
at both connection ends the counter must be upd...
is dispatched to control frame queue. However to follow protocol state
at both connection ends the counter must be upd...
🚨 CVE-2026-105752
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.
🎖@cveNotify
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.
🎖@cveNotify
GitHub
[Frontend] Add stateless /v1/responses/render endpoint (#50195) · vllm-project/vllm@6a2a2bb
Signed-off-by: Francisco Javier Arceo <farceo@redhat.com>
Co-authored-by: OpenAI Codex <codex@openai.com>
Co-authored-by: OpenAI Codex <codex@openai.com>
🚨 CVE-2026-105753
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.
🎖@cveNotify
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.
🎖@cveNotify
GitHub
[Bugfix][V1][Multimodal] Recover from P0/P1 processor cache drift (#4… · vllm-project/vllm@3962042
…6747) (#46747)
Signed-off-by: William Zhao <williamzh@meta.com>
Signed-off-by: WillZZZy <93454470+WillZZZy@users.noreply.github.com>
Co-authored-by: Cyrus Leung &l...
Signed-off-by: William Zhao <williamzh@meta.com>
Signed-off-by: WillZZZy <93454470+WillZZZy@users.noreply.github.com>
Co-authored-by: Cyrus Leung &l...
🚨 CVE-2026-105754
vLLM is an inference and serving engine for large language models. Prior to 0.30.0, the /inference/v1/generate endpoint in the disaggregated scale-out path accepts caller-supplied tensors in the features.kwargs_data field, cache identifiers in the features.mm_hashes field, ranges in the features.mm_placeholders field, and wire-selected multimodal field processors without rebinding them to the active model renderer contract. Forged grid geometry, field types, or non-positive placeholder lengths can terminate the shared EngineCore; when an attacker knows or can induce a victim's content hash, forged cache hashes can poison or retrieve cross-request encoder-cache state; and dropped sparse placeholder masks can alter replayed transport semantics. This issue is fixed in version 0.30.0.
🎖@cveNotify
vLLM is an inference and serving engine for large language models. Prior to 0.30.0, the /inference/v1/generate endpoint in the disaggregated scale-out path accepts caller-supplied tensors in the features.kwargs_data field, cache identifiers in the features.mm_hashes field, ranges in the features.mm_placeholders field, and wire-selected multimodal field processors without rebinding them to the active model renderer contract. Forged grid geometry, field types, or non-positive placeholder lengths can terminate the shared EngineCore; when an attacker knows or can induce a victim's content hash, forged cache hashes can poison or retrieve cross-request encoder-cache state; and dropped sparse placeholder masks can alter replayed transport semantics. This issue is fixed in version 0.30.0.
🎖@cveNotify
GitHub
Validate scale-out multimodal data before engine handoff (#51898) · vllm-project/vllm@1970f3e
Signed-off-by: Clinton Thomas <1033162+KernelClint@users.noreply.github.com>
Co-authored-by: Lucas Bourtoule <35483370+dhalf@users.noreply.github.com>
Co-authored-by: Lucas Bourtoule <35483370+dhalf@users.noreply.github.com>
🚨 CVE-2026-105755
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.
🎖@cveNotify
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.
🎖@cveNotify
GitHub
Use server-generated keys for late-interaction query caches (#51445) · vllm-project/vllm@ee17d0d
Co-authored-by: Lucas Bourtoule <35483370+dhalf@users.noreply.github.com>
🚨 CVE-2026-105756
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.
🎖@cveNotify
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.
🎖@cveNotify
GitHub
[Security] Validate cache salts before they reach LMCache (#51444) · vllm-project/vllm@e962733
Signed-off-by: Clinton Thomas <1033162+KernelClint@users.noreply.github.com>
Co-authored-by: Lucas Bourtoule <35483370+dhalf@users.noreply.github.com>
Co-authored-by: Cy...
Co-authored-by: Lucas Bourtoule <35483370+dhalf@users.noreply.github.com>
Co-authored-by: Cy...
🚨 CVE-2026-105757
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.
🎖@cveNotify
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.
🎖@cveNotify
GitHub
[Structured Output] Keep invalid structured-output requests from stop… · vllm-project/vllm@c55e15a
…ping the engine (#51450)
Co-authored-by: Lucas Bourtoule <35483370+dhalf@users.noreply.github.com>
Co-authored-by: Vadim Gimpelson <156319763+vadiklyutiy@users.noreply.github.com>
Co-authored-by: Lucas Bourtoule <35483370+dhalf@users.noreply.github.com>
Co-authored-by: Vadim Gimpelson <156319763+vadiklyutiy@users.noreply.github.com>
🚨 CVE-2026-105758
vLLM is an inference and serving engine for large language models. From 0.24.0 until 0.30.0, the Qwen2VLVideoBackend and Qwen3VLVideoBackend classes accept request-level values for the media_io_kwargs.video.max_frames and media_io_kwargs.video.fps fields without enforcing server-side ceilings. An unauthenticated caller can submit these values to the /tokenize endpoint, causing the sampler to decode every frame selected from attacker-controlled video input, consume disproportionate frontend memory, and potentially terminate the API process before scheduling or admission control. The Rust frontend is not affected because it rejects the media_io_kwargs field. This issue is fixed in version 0.30.0.
🎖@cveNotify
vLLM is an inference and serving engine for large language models. From 0.24.0 until 0.30.0, the Qwen2VLVideoBackend and Qwen3VLVideoBackend classes accept request-level values for the media_io_kwargs.video.max_frames and media_io_kwargs.video.fps fields without enforcing server-side ceilings. An unauthenticated caller can submit these values to the /tokenize endpoint, causing the sampler to decode every frame selected from attacker-controlled video input, consume disproportionate frontend memory, and potentially terminate the API process before scheduling or admission control. The Rust frontend is not affected because it rejects the media_io_kwargs field. This issue is fixed in version 0.30.0.
🎖@cveNotify
GitHub
[Security] Cap Qwen-VL video sampling knobs (#56729) · vllm-project/vllm@ea723c8
Signed-off-by: Juan Pérez de Algaba <jperezde@redhat.com>
Co-authored-by: Cursor <cursoragent@cursor.com>
Co-authored-by: Cursor <cursoragent@cursor.com>
🚨 CVE-2026-106221
Confused deputy in WebAPKs in Google Chrome on on Android prior to 155.0.8059.39 allowed a remote attacker leveraging social engineering to bypass web origin policy via a crafted HTML page. (Chromium security severity: Low)
🎖@cveNotify
Confused deputy in WebAPKs in Google Chrome on on Android prior to 155.0.8059.39 allowed a remote attacker leveraging social engineering to bypass web origin policy via a crafted HTML page. (Chromium security severity: Low)
🎖@cveNotify
Chrome Releases
Stable Channel Update for Desktop
The Stable channel has been updated to 155.0.8059.39/.40 for Windows and Mac and 155.0.8059.39 to Linux which will roll out over the coming...
🚨 CVE-2026-106222
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)
🎖@cveNotify
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)
🎖@cveNotify
Chrome Releases
Stable Channel Update for Desktop
The Stable channel has been updated to 155.0.8059.39/.40 for Windows and Mac and 155.0.8059.39 to Linux which will roll out over the coming...
🚨 CVE-2026-106223
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)
🎖@cveNotify
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)
🎖@cveNotify
Chrome Releases
Stable Channel Update for Desktop
The Stable channel has been updated to 155.0.8059.39/.40 for Windows and Mac and 155.0.8059.39 to Linux which will roll out over the coming...
🚨 CVE-2026-106224
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)
🎖@cveNotify
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)
🎖@cveNotify
Chrome Releases
Stable Channel Update for Desktop
The Stable channel has been updated to 155.0.8059.39/.40 for Windows and Mac and 155.0.8059.39 to Linux which will roll out over the coming...
🚨 CVE-2026-106225
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)
🎖@cveNotify
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)
🎖@cveNotify
Chrome Releases
Stable Channel Update for Desktop
The Stable channel has been updated to 155.0.8059.39/.40 for Windows and Mac and 155.0.8059.39 to Linux which will roll out over the coming...
🚨 CVE-2026-93678
IBM Langflow OSS 1.0.0 through 1.12.2 could allow a remote authenticated attacker to obtain sensitive information due to improper authorization.
🎖@cveNotify
IBM Langflow OSS 1.0.0 through 1.12.2 could allow a remote authenticated attacker to obtain sensitive information due to improper authorization.
🎖@cveNotify
Ibm
Security Bulletin: Langflow OSS is affected by multiple vulnerabilities
Langflow OSS is affected by multiple vulnerabilities involving code-execution restrictions, access controls, sensitive-data handling, file access, and archive processing. Depending on deployment configuration, an attacker could execute code, read or modify…
🚨 CVE-2026-93679
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.
🎖@cveNotify
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.
🎖@cveNotify
Ibm
Security Bulletin: Langflow OSS is affected by multiple vulnerabilities
Langflow OSS is affected by multiple vulnerabilities involving code-execution restrictions, access controls, sensitive-data handling, file access, and archive processing. Depending on deployment configuration, an attacker could execute code, read or modify…
🚨 CVE-2026-97655
IBM Langflow OSS 1.0.0 through 1.12.2 could allow a remote attacker to execute arbitrary code due to an incomplete blocklist in the code security scanner.
🎖@cveNotify
IBM Langflow OSS 1.0.0 through 1.12.2 could allow a remote attacker to execute arbitrary code due to an incomplete blocklist in the code security scanner.
🎖@cveNotify
Ibm
Security Bulletin: Langflow OSS is affected by multiple vulnerabilities
Langflow OSS is affected by multiple vulnerabilities involving code-execution restrictions, access controls, sensitive-data handling, file access, and archive processing. Depending on deployment configuration, an attacker could execute code, read or modify…
🚨 CVE-2026-97671
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.
🎖@cveNotify
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.
🎖@cveNotify
Ibm
Security Bulletin: Langflow OSS is affected by multiple vulnerabilities
Langflow OSS is affected by multiple vulnerabilities involving code-execution restrictions, access controls, sensitive-data handling, file access, and archive processing. Depending on deployment configuration, an attacker could execute code, read or modify…
🚨 CVE-2026-97673
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.
🎖@cveNotify
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.
🎖@cveNotify
Ibm
Security Bulletin: Langflow OSS is affected by multiple vulnerabilities
Langflow OSS is affected by multiple vulnerabilities involving code-execution restrictions, access controls, sensitive-data handling, file access, and archive processing. Depending on deployment configuration, an attacker could execute code, read or modify…
🚨 CVE-2026-97674
IBM Langflow OSS 1.0.0 through 1.12.2 could allow a remote authenticated attacker to execute arbitrary OS commands due to improper neutralization of special elements used in an OS command ('Code Injection'), aka improper control of code generation.
🎖@cveNotify
IBM Langflow OSS 1.0.0 through 1.12.2 could allow a remote authenticated attacker to execute arbitrary OS commands due to improper neutralization of special elements used in an OS command ('Code Injection'), aka improper control of code generation.
🎖@cveNotify
Ibm
Security Bulletin: Langflow OSS is affected by multiple vulnerabilities
Langflow OSS is affected by multiple vulnerabilities involving code-execution restrictions, access controls, sensitive-data handling, file access, and archive processing. Depending on deployment configuration, an attacker could execute code, read or modify…
🚨 CVE-2026-97676
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.
🎖@cveNotify
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.
🎖@cveNotify
Ibm
Security Bulletin: Langflow OSS is affected by multiple vulnerabilities
Langflow OSS is affected by multiple vulnerabilities involving code-execution restrictions, access controls, sensitive-data handling, file access, and archive processing. Depending on deployment configuration, an attacker could execute code, read or modify…
🚨 CVE-2026-97678
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.
🎖@cveNotify
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.
🎖@cveNotify
Ibm
Security Bulletin: Langflow OSS is affected by multiple vulnerabilities
Langflow OSS is affected by multiple vulnerabilities involving code-execution restrictions, access controls, sensitive-data handling, file access, and archive processing. Depending on deployment configuration, an attacker could execute code, read or modify…