<?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>Tue, 06 Oct 2026 12:30:54 +0000</lastBuildDate>
    <item>
      <title>EUVD-2026-340590</title>
      <link>https://cve.radiocsirt.org/vuln/euvd-2026-340590</link>
      <description>EUVD-2026-340590</description>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/euvd-2026-340590</guid>
    </item>
    <item>
      <title>fkie_cve-2026-47075</title>
      <link>https://cve.radiocsirt.org/vuln/fkie_cve-2026-47075</link>
      <description>&lt;p&gt;Improper Neutralization of CRLF Sequences vulnerability in benoitc hackney allows HTTP Request Splitting. hackney does not percent-encode carriage return (\r) or line feed (\n) characters in the URL query component before constructing the HTTP/1.1 request target. Characters outside the grammar defined in RFC 3986 Section 3.4 must be percent-encoded, but hackney_url:make_url/3 passes the query binary directly without validation or escaping. An attacker who can control all or part of a URL passed to hackney can inject raw CRLF sequences into the query string, which are then sent as HTTP line breaks in the request target. This enables injection of arbitrary HTTP headers or splitting of the HTTP request.&lt;/p&gt;
&lt;p&gt;This issue affects hackney: from 0.13.1 before 4.0.1.&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;Improper Neutralization of CRLF Sequences vulnerability in benoitc hackney allows HTTP Request Splitting. hackney does not percent-encode carriage return (\r) or line feed (\n) characters in the URL query component before constructing the HTTP/1.1 request target. Characters outside the grammar defined in RFC 3986 Section 3.4 must be percent-encoded, but hackney_url:make_url/3 passes the query binary directly without validation or escaping. An attacker who can control all or part of a URL passed to hackney can inject raw CRLF sequences into the query string, which are then sent as HTTP line breaks in the request target. This enables injection of arbitrary HTTP headers or splitting of the HTTP request.&lt;/p&gt;
&lt;p&gt;This issue affects hackney: from 0.13.1 before 4.0.1.&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/fkie_cve-2026-47075</guid>
    </item>
    <item>
      <title>GHSA-j9wq-vxxc-94wf — Hackney has CR/LF injection in query parameter</title>
      <link>https://cve.radiocsirt.org/vuln/ghsa-j9wq-vxxc-94wf</link>
      <description>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; Hex: hackney&lt;/p&gt;
&lt;p&gt;### Summary&lt;/p&gt;
&lt;p&gt;`hackney_url:make_url/3` passes the URL query component directly into the HTTP/1.1 request target without percent-encoding `\r` or `\n`. RFC 3986 §3.4 requires characters outside the query grammar to be percent-encoded, but no validation or escaping occurs. An attacker who controls any portion of the URL passed to hackney can inject raw CRLF sequences into the request line, enabling HTTP header injection or full request splitting.&lt;/p&gt;
&lt;p&gt;### Details&lt;/p&gt;
&lt;p&gt;`hackney_url:make_url/3` in `src/hackney_url.erl` builds the request target by concatenating the path and query binaries. The query string is used as-is — no character-class check, no percent-encoding of `\r` or `\n`. When hackney serializes the request, the query value lands verbatim in the `GET &amp;lt;path&amp;gt;?&amp;lt;query&amp;gt; HTTP/1.1\r\n` request line. A query value containing `\r\n` terminates the request line early; subsequent bytes are parsed by the server (or any intermediary proxy) as additional header lines or a second request.&lt;/p&gt;
&lt;p&gt;A concrete example: a URL with query `?q=x HTTP/1.1\r\nX-Injected: yes\r\nX:` produces the following on the wire:&lt;/p&gt;
&lt;p&gt;```
GET /?q=x HTTP/1.1
X-Injected: yes
X: HTTP/1.1
Host: ...
```&lt;/p&gt;
&lt;p&gt;The server sees `X-Injected: yes` as a legitimate request header that the client never intended to send.&lt;/p&gt;
&lt;p&gt;### PoC&lt;/p&gt;
&lt;p&gt;1. Listen on a raw TCP port: `nc -lvnp 8080`.
2. Issue: `:hackney.get(&amp;#34;http://127.0.0.1:8080/?q=x HTTP/1.1\r\nX-Injected: yes\r\nX:&amp;#34;)`.
3. Observe the listener receives `X-Injected: yes` as a standalone header line…&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; Hex: hackney&lt;/p&gt;
&lt;p&gt;### Summary&lt;/p&gt;
&lt;p&gt;`hackney_url:make_url/3` passes the URL query component directly into the HTTP/1.1 request target without percent-encoding `\r` or `\n`. RFC 3986 §3.4 requires characters outside the query grammar to be percent-encoded, but no validation or escaping occurs. An attacker who controls any portion of the URL passed to hackney can inject raw CRLF sequences into the request line, enabling HTTP header injection or full request splitting.&lt;/p&gt;
&lt;p&gt;### Details&lt;/p&gt;
&lt;p&gt;`hackney_url:make_url/3` in `src/hackney_url.erl` builds the request target by concatenating the path and query binaries. The query string is used as-is — no character-class check, no percent-encoding of `\r` or `\n`. When hackney serializes the request, the query value lands verbatim in the `GET &amp;lt;path&amp;gt;?&amp;lt;query&amp;gt; HTTP/1.1\r\n` request line. A query value containing `\r\n` terminates the request line early; subsequent bytes are parsed by the server (or any intermediary proxy) as additional header lines or a second request.&lt;/p&gt;
&lt;p&gt;A concrete example: a URL with query `?q=x HTTP/1.1\r\nX-Injected: yes\r\nX:` produces the following on the wire:&lt;/p&gt;
&lt;p&gt;```
GET /?q=x HTTP/1.1
X-Injected: yes
X: HTTP/1.1
Host: ...
```&lt;/p&gt;
&lt;p&gt;The server sees `X-Injected: yes` as a legitimate request header that the client never intended to send.&lt;/p&gt;
&lt;p&gt;### PoC&lt;/p&gt;
&lt;p&gt;1. Listen on a raw TCP port: `nc -lvnp 8080`.
2. Issue: `:hackney.get(&amp;#34;http://127.0.0.1:8080/?q=x HTTP/1.1\r\nX-Injected: yes\r\nX:&amp;#34;)`.
3. Observe the listener receives `X-Injected: yes` as a standalone header line…&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/ghsa-j9wq-vxxc-94wf</guid>
    </item>
  </channel>
</rss>
