Snailsploit

#2068of 56,329
120.4Total CVSS
Vulnerabilities · 18
Medium
11
High
5
Critical
2
PT-2026-50491
5.3
2026-06-17
Vllm · Vllm · CVE-2026-54236
**Name of the Vulnerable Software and Affected Versions** vLLM versions prior to 0.23.1rc0 **Description** An incomplete fix for a previous memory leak issue allows unauthenticated attackers to leak heap memory addresses. The system fails to properly sanitize error messages in several response paths, echoing the string representation of exceptions directly to clients. This occurs because certain routes catch exceptions internally and construct responses themselves, bypassing the global sanitizing exception handler, while WebSocket frames bypass the handler chain entirely. Technical details include: - **API Endpoints**: 'POST /v1/messages' and 'POST /v1/messages/count tokens' within the Anthropic API router. - **Vulnerable Components**: The Server-Sent Events streaming converter in `vllm/entrypoints/anthropic/serving.py` and the realtime speech-to-text WebSocket in `vllm/entrypoints/speech to text/realtime/connection.py`. An attacker can exploit this by sending malformed image bytes through the Anthropic Messages API image content parts. This causes the `PIL.Image.open()` function to raise an `UnidentifiedImageError`, which includes a `BytesIO` object representation containing a verbatim heap memory address in the `error.message` field of the response body. **Recommendations** Update to version 0.23.1rc0 or later. As a temporary workaround, restrict access to the 'POST /v1/messages' and 'POST /v1/messages/count tokens' endpoints and the realtime speech-to-text WebSocket to minimize the risk of exploitation.
PT-2026-50129
6.8
2026-06-16
Git · Pydantic-Ai · CVE-2026-48782
## Summary When an application using Pydantic AI opts a URL into `force download='allow-local'` (which disables the default block on private/internal IPs) **and runs on a network that routes the affected IPv6 transition forms (NAT64- or ISATAP-configured networks)**, the cloud-metadata blocklist could be bypassed by encoding the metadata IP in an IPv6 transition form that the previous fix did not decode — IPv4-compatible IPv6 (`::a.b.c.d`), the NAT64 RFC 8215 local-use prefix (`64:ff9b:1::/48`), operator-chosen NAT64 prefixes, or ISATAP. The IPv6 wrapper is then delivered to the underlying IPv4 metadata endpoint, exposing cloud IAM short-term credentials. **The bypass is exploitable only in environments whose network actually routes these forms** — NAT64-configured networks (IPv6-only or dual-stack-with-NAT64 deployments, including some Kubernetes setups) for the NAT64 variants, or networks with an ISATAP tunnel for ISATAP. A standard dual-stack cloud VM or container does not route them and is not affected in practice. The IPv4-compatible and Teredo variants are deprecated and addressed as defense-in-depth. This is an incomplete fix of [GHSA-cqp8-fcvh-x7r3](https://github.com/pydantic/pydantic-ai/security/advisories/GHSA-cqp8-fcvh-x7r3) / [CVE-2026-46678](https://nvd.nist.gov/vuln/detail/CVE-2026-46678) (itself a follow-up to [CVE-2026-25580](https://nvd.nist.gov/vuln/detail/CVE-2026-25580)). The prior remediation decoded only IPv4-mapped IPv6, 6to4, and the NAT64 well-known prefix; the metadata guarantee did not hold for the remaining transition forms. ## Severity **MEDIUM** — `CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:C/C:H/I:N/A:N` = **6.8** Same impact metrics and narrow attack surface as the parent advisory (AC:H): exploitation requires the application to have opted into `allow-local` on a URL influenced by untrusted input, and the NAT64/ISATAP variants additionally require the deployment network to route those forms. **CWE-918**: Server-Side Request Forgery (SSRF) ## Affected Versions | Package | Vulnerable | Patched | |---|---|---| | `pydantic-ai` | `>= 1.56.0, < 1.102.0`; `>= 2.0.0b1, < 2.0.0b3` | `1.102.0`; `2.0.0b3` | | `pydantic-ai-slim` | `>= 1.56.0, < 1.102.0`; `>= 2.0.0b1, < 2.0.0b3` | `1.102.0`; `2.0.0b3` | These transition forms have not been decoded since SSRF protection was introduced in `1.56.0`. ## Who Is Affected Users are affected **only if** their application explicitly opts a `FileUrl` (`ImageUrl`, `AudioUrl`, `VideoUrl`, `DocumentUrl`) into `force download='allow-local'` on a URL that is, or could be, influenced by untrusted input. Beyond that precondition, the affected encodings only reach a metadata endpoint in environments whose network actually routes them. The broadly-routable IPv4-mapped form was addressed in `1.99.0` (CVE-2026-46678); the additional forms addressed here require a **NAT64-configured network** (IPv6-only or dual-stack-with-NAT64 deployments, including some Kubernetes setups) for the NAT64 variants, or an **ISATAP tunnel** for the ISATAP variant. The IPv4-compatible and Teredo forms are deprecated and not routed by modern stacks; they are addressed as defense-in-depth. Most deployments on a standard dual-stack cloud VM or container are therefore not exploitable in practice, but the fix restores the "always blocked" guarantee for the environments that are. Users are **not** affected if they use any of the bundled integrations to ingest user input, because they do not propagate `force download` from external data: - `Agent.to web` / `clai web` - `VercelAIAdapter` - `AGUIAdapter` / `Agent.to ag ui` Applications that only download from developer-controlled URLs are not affected. ## Remediation Upgrade to `1.102.0` or later (or `2.0.0b3` or later on the 2.0 pre-release line). The cloud-metadata and private-IP blocklists now decode the embedded IPv4 of every standardized IPv6 transition form before evaluating it — IPv4-mapped, IPv4-compatible, 6to4, NAT64 across all prefix lengths (including the RFC 8215 local-use prefix and operator-chosen prefixes), ISATAP, and Teredo. The set of always-blocked cloud metadata/credential endpoints has also been expanded across providers. ## Workaround for Unpatched Versions Avoid passing `force download='allow-local'` on any URL that could be influenced by untrusted input. If developers must, resolve the hostname themselves and validate the result against their own metadata blocklist — including IPv6 transition forms — before constructing the `FileUrl`. ## Credits Reported by [@SnailSploit](https://snailsploit.com).
PT-2026-37300
7.7
2026-05-05
Avideo · Avideo · CVE-2026-43884
**Name of the Vulnerable Software and Affected Versions** AVideo versions prior to 29.0 **Description** Two endpoints, 'plugin/AI/receiveAsync.json.php' and 'objects/EpgParser.php', use the `isSSRFSafeURL()` function to validate user-supplied URLs but then fetch them using `file get contents()` without disabling automatic redirect following. This allows an attacker to provide a URL that redirects to an internal or cloud-metadata address (such as 'http://169.254.169.254/latest/meta-data/'), bypassing SSRF protections because only the initial URL is validated. This can lead to the exfiltration of IAM credentials, instance identity, or access to internal services and port scanning. Additionally, several callers of `isSSRFSafeURL()` discard the `$resolvedIP` parameter intended for DNS pinning, making them susceptible to DNS rebinding TOCTOU (Time-of-Check to Time-of-Use) attacks. This occurs when a domain's DNS record changes between the time of validation and the time of the actual request. Affected callers include: - 'objects/aVideoEncoderReceiveImage.json.php' - 'objects/aVideoEncoder.json.php' - 'plugin/BulkEmbed/save.json.php' - 'plugin/AI/receiveAsync.json.php' - 'objects/EpgParser.php' - 'plugin/Scheduler/Scheduler.php' **Recommendations** Update AVideo to a version later than 29.0. As a temporary workaround, restrict access to the 'plugin/AI/receiveAsync.json.php' and 'objects/EpgParser.php' endpoints to minimize the risk of redirect-based SSRF.