<?xml version='1.0' encoding='UTF-8'?>
<?xml-stylesheet href="/static/style.xsl" type="text/xsl"?>
<rss xmlns:atom="http://www.w3.org/2005/Atom" xmlns:content="http://purl.org/rss/1.0/modules/content/" version="2.0">
  <channel>
    <title>Most recent entries from all</title>
    <link>https://cve.radiocsirt.org</link>
    <description>Contains only the most 10 recent entries.</description>
    <docs>http://www.rssboard.org/rss-specification</docs>
    <generator>python-feedgen</generator>
    <language>en</language>
    <lastBuildDate>Sat, 03 Oct 2026 09:03:01 +0000</lastBuildDate>
    <item>
      <title>bdu:2026-06585</title>
      <link>https://cve.radiocsirt.org/vuln/bdu:2026-06585</link>
      <description>bdu:2026-06585</description>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/bdu:2026-06585</guid>
    </item>
    <item>
      <title>EUVD-2026-339104</title>
      <link>https://cve.radiocsirt.org/vuln/euvd-2026-339104</link>
      <description>EUVD-2026-339104</description>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/euvd-2026-339104</guid>
    </item>
    <item>
      <title>fkie_cve-2026-25960</title>
      <link>https://cve.radiocsirt.org/vuln/fkie_cve-2026-25960</link>
      <description>&lt;p&gt;vLLM is an inference and serving engine for large language models (LLMs). The SSRF protection fix for CVE-2026-24779 add in 0.15.1 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. 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. This vulnerability in 0.17.0.&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;vLLM is an inference and serving engine for large language models (LLMs). The SSRF protection fix for CVE-2026-24779 add in 0.15.1 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. 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. This vulnerability in 0.17.0.&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/fkie_cve-2026-25960</guid>
    </item>
    <item>
      <title>GHSA-v359-jj2v-j536 — vLLM has SSRF Protection Bypass</title>
      <link>https://cve.radiocsirt.org/vuln/ghsa-v359-jj2v-j536</link>
      <description>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; PyPI: vllm&lt;/p&gt;
&lt;p&gt;## Summary&lt;/p&gt;
&lt;p&gt;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.&lt;/p&gt;
&lt;p&gt;## Affected Component&lt;/p&gt;
&lt;p&gt;- **File**: `vllm/connections.py`
- **Function**: `load_from_url_async`&lt;/p&gt;
&lt;p&gt;## Vulnerability Details&lt;/p&gt;
&lt;p&gt;### Root Cause&lt;/p&gt;
&lt;p&gt;The SSRF [fix](https://github.com/vllm-project/vllm/pull/32746) 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.&lt;/p&gt;
&lt;p&gt;These two URL parsers handle backslash characters (`\`) differently:&lt;/p&gt;
&lt;p&gt;| 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 |&lt;/p&gt;
&lt;p&gt;### Attack Scenario&lt;/p&gt;
&lt;p&gt;```python
# Attacker provides this URL
malicious_url = &amp;#34;https://httpbin.org\\@evil.com/&amp;#34;&lt;/p&gt;
&lt;p&gt;# 1. Validation layer (urllib3.parse_url)
parsed = urllib3.util.parse_url(malicious_url)
# parsed.host == &amp;#34;httpbin.org&amp;#34;  ✅ Passes vali…&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; PyPI: vllm&lt;/p&gt;
&lt;p&gt;## Summary&lt;/p&gt;
&lt;p&gt;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.&lt;/p&gt;
&lt;p&gt;## Affected Component&lt;/p&gt;
&lt;p&gt;- **File**: `vllm/connections.py`
- **Function**: `load_from_url_async`&lt;/p&gt;
&lt;p&gt;## Vulnerability Details&lt;/p&gt;
&lt;p&gt;### Root Cause&lt;/p&gt;
&lt;p&gt;The SSRF [fix](https://github.com/vllm-project/vllm/pull/32746) 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.&lt;/p&gt;
&lt;p&gt;These two URL parsers handle backslash characters (`\`) differently:&lt;/p&gt;
&lt;p&gt;| 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 |&lt;/p&gt;
&lt;p&gt;### Attack Scenario&lt;/p&gt;
&lt;p&gt;```python
# Attacker provides this URL
malicious_url = &amp;#34;https://httpbin.org\\@evil.com/&amp;#34;&lt;/p&gt;
&lt;p&gt;# 1. Validation layer (urllib3.parse_url)
parsed = urllib3.util.parse_url(malicious_url)
# parsed.host == &amp;#34;httpbin.org&amp;#34;  ✅ Passes vali…&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/ghsa-v359-jj2v-j536</guid>
    </item>
    <item>
      <title>PYSEC-2026-3411 — vLLM has SSRF Protection Bypass</title>
      <link>https://cve.radiocsirt.org/vuln/pysec-2026-3411</link>
      <description>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; PyPI: vllm&lt;/p&gt;
&lt;p&gt;## Summary&lt;/p&gt;
&lt;p&gt;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.&lt;/p&gt;
&lt;p&gt;## Affected Component&lt;/p&gt;
&lt;p&gt;- **File**: `vllm/connections.py`
- **Function**: `load_from_url_async`&lt;/p&gt;
&lt;p&gt;## Vulnerability Details&lt;/p&gt;
&lt;p&gt;### Root Cause&lt;/p&gt;
&lt;p&gt;The SSRF [fix](https://github.com/vllm-project/vllm/pull/32746) 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.&lt;/p&gt;
&lt;p&gt;These two URL parsers handle backslash characters (`\`) differently:&lt;/p&gt;
&lt;p&gt;| 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 |&lt;/p&gt;
&lt;p&gt;### Attack Scenario&lt;/p&gt;
&lt;p&gt;```python
# Attacker provides this URL
malicious_url = &amp;#34;https://httpbin.org\\@evil.com/&amp;#34;&lt;/p&gt;
&lt;p&gt;# 1. Validation layer (urllib3.parse_url)
parsed = urllib3.util.parse_url(malicious_url)
# parsed.host == &amp;#34;httpbin.org&amp;#34;  ✅ Passes vali…&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; PyPI: vllm&lt;/p&gt;
&lt;p&gt;## Summary&lt;/p&gt;
&lt;p&gt;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.&lt;/p&gt;
&lt;p&gt;## Affected Component&lt;/p&gt;
&lt;p&gt;- **File**: `vllm/connections.py`
- **Function**: `load_from_url_async`&lt;/p&gt;
&lt;p&gt;## Vulnerability Details&lt;/p&gt;
&lt;p&gt;### Root Cause&lt;/p&gt;
&lt;p&gt;The SSRF [fix](https://github.com/vllm-project/vllm/pull/32746) 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.&lt;/p&gt;
&lt;p&gt;These two URL parsers handle backslash characters (`\`) differently:&lt;/p&gt;
&lt;p&gt;| 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 |&lt;/p&gt;
&lt;p&gt;### Attack Scenario&lt;/p&gt;
&lt;p&gt;```python
# Attacker provides this URL
malicious_url = &amp;#34;https://httpbin.org\\@evil.com/&amp;#34;&lt;/p&gt;
&lt;p&gt;# 1. Validation layer (urllib3.parse_url)
parsed = urllib3.util.parse_url(malicious_url)
# parsed.host == &amp;#34;httpbin.org&amp;#34;  ✅ Passes vali…&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/pysec-2026-3411</guid>
    </item>
    <item>
      <title>RHSA-2026:24977 — Red Hat Security Advisory: RHOAI 2.25.7 - Red Hat OpenShift AI</title>
      <link>https://cve.radiocsirt.org/vuln/rhsa-2026:24977</link>
      <description>&lt;p&gt;bouncycastle: BC-JAVA: GOSTCTR implementation unable to process more than 255 blocks correctly vllm: HTTP header size limit not enforced allows Denial of Service from Unauthenticated requests golang: net/url: Memory exhaustion in query parameter parsing in net/url axios: Axios: Server-Side Request Forgery and proxy bypass due to improper hostname normalization aiohttp: aiohttp: Denial of Service via specially crafted POST request aiohttp: aiohttp: Denial of Service via memory exhaustion from crafted POST request keras: Keras: Arbitrary Code Execution Vulnerability Bypassing Safe Mode lodash: lodash: Arbitrary code execution via untrusted input in template imports fast-uri: fast-uri: Path traversal vulnerability allows bypass of security policies pyasn1: pyasn1: Denial of Service due to memory exhaustion from malformed RELATIVE-OID pytorch: PyTorch: Arbitrary code execution via malicious checkpoint file loading xgrammar: xgrammar: Denial of Service via multi-level nested syntax vLLM: vLLM: Server-Side Request Forgery bypass via inconsistent URL parsing onnx: ONNX: Information Disclosure via Path Traversal Vulnerability vllm: vLLM: Remote code execution due to hardcoded trust_remote_code setting onnx: ONNX: Untrusted Model Repository Warnings Suppressed python-dotenv: python-dotenv: Arbitrary file overwrite via symbolic link following immutable-js: Immutable.js: Arbitrary code execution via Prototype Pollution svgo: SVGO: Denial of Service via XML entity expansion tornado-pyth…&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;bouncycastle: BC-JAVA: GOSTCTR implementation unable to process more than 255 blocks correctly vllm: HTTP header size limit not enforced allows Denial of Service from Unauthenticated requests golang: net/url: Memory exhaustion in query parameter parsing in net/url axios: Axios: Server-Side Request Forgery and proxy bypass due to improper hostname normalization aiohttp: aiohttp: Denial of Service via specially crafted POST request aiohttp: aiohttp: Denial of Service via memory exhaustion from crafted POST request keras: Keras: Arbitrary Code Execution Vulnerability Bypassing Safe Mode lodash: lodash: Arbitrary code execution via untrusted input in template imports fast-uri: fast-uri: Path traversal vulnerability allows bypass of security policies pyasn1: pyasn1: Denial of Service due to memory exhaustion from malformed RELATIVE-OID pytorch: PyTorch: Arbitrary code execution via malicious checkpoint file loading xgrammar: xgrammar: Denial of Service via multi-level nested syntax vLLM: vLLM: Server-Side Request Forgery bypass via inconsistent URL parsing onnx: ONNX: Information Disclosure via Path Traversal Vulnerability vllm: vLLM: Remote code execution due to hardcoded trust_remote_code setting onnx: ONNX: Untrusted Model Repository Warnings Suppressed python-dotenv: python-dotenv: Arbitrary file overwrite via symbolic link following immutable-js: Immutable.js: Arbitrary code execution via Prototype Pollution svgo: SVGO: Denial of Service via XML entity expansion tornado-pyth…&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/rhsa-2026:24977</guid>
    </item>
    <item>
      <title>WID-SEC-W-2026-0648 — vllm: Schwachstelle ermöglicht Umgehen von Sicherheitsvorkehrungen</title>
      <link>https://cve.radiocsirt.org/vuln/wid-sec-w-2026-0648</link>
      <description>&lt;p&gt;Ein entfernter, authentisierter Angreifer kann eine Schwachstelle in vllm ausnutzen, um Sicherheitsvorkehrungen zu umgehen.&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;Ein entfernter, authentisierter Angreifer kann eine Schwachstelle in vllm ausnutzen, um Sicherheitsvorkehrungen zu umgehen.&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/wid-sec-w-2026-0648</guid>
    </item>
  </channel>
</rss>
