<?xml version='1.0' encoding='UTF-8'?>
<?xml-stylesheet href="/static/style.xsl" type="text/xsl"?>
<feed xmlns="http://www.w3.org/2005/Atom" xml:lang="en">
  <id>https://cve.radiocsirt.org/rss/recent/all/10</id>
  <title>Most recent entries from all</title>
  <updated>2026-10-05T12:38:15.634042+00:00</updated>
  <author>
    <name>Vulnerability-Lookup</name>
    <email>csirt@opendfir.org</email>
  </author>
  <link href="https://cve.radiocsirt.org" rel="alternate"/>
  <generator uri="https://lkiesow.github.io/python-feedgen" version="1.0.0">python-feedgen</generator>
  <subtitle>Contains only the most 10 recent entries.</subtitle>
  <entry>
    <id>https://cve.radiocsirt.org/vuln/cve-2026-1605</id>
    <title>CVE-2026-1605</title>
    <updated>2026-10-05T12:38:15.886112+00:00</updated>
    <content type="xhtml">
      <div xmlns="http://www.w3.org/1999/xhtml"><p><strong>Affected:</strong> Eclipse Foundation Eclipse Jetty, Red Hat HawtIO HawtIO 4.4.0, Red Hat AMQ Broker 7.14.0, Red Hat JBoss Enterprise Application Platform 8.1, Red Hat JBoss Enterprise Application Platform 8.1 for RHEL 8, Red Hat JBoss Enterprise Application Platform 8.1 for RHEL 9, Red Hat OpenShift Developer Tools and Services 4.12, Red Hat OpenShift Developer Tools and Services 4.13, Red Hat OpenShift Developer Tools and Services 4.14, Red Hat OpenShift Developer Tools and Services 4.15 and 28 more</p>
<p>In Eclipse Jetty, versions 12.0.0-12.0.31 and 12.1.0-12.0.5, class GzipHandler exposes a vulnerability when a compressed HTTP request, with Content-Encoding: gzip, is processed and the corresponding response is not compressed.</p>
<p>This happens because the JDK Inflater is allocated for decompressing the request, but it is not released because the release mechanism is tied to the compressed response.
In this case, since the response is not compressed, the release mechanism does not trigger, causing the leak.</p></div>
    </content>
    <link href="https://cve.radiocsirt.org/vuln/cve-2026-1605"/>
  </entry>
  <entry>
    <id>https://cve.radiocsirt.org/vuln/ghsa-355h-qmc2-wpwf</id>
    <title>GHSA-355h-qmc2-wpwf — Jetty has HTTP Request Smuggling via Chunked Extension Quoted-String Parsing</title>
    <updated>2026-10-05T12:38:15.886317+00:00</updated>
    <content type="xhtml">
      <div xmlns="http://www.w3.org/1999/xhtml"><p><strong>Affected:</strong> Maven: org.eclipse.jetty:jetty-http</p>
<p>### Description (as reported)</p>
<p>Jetty incorrectly parses quoted strings in HTTP/1.1 chunked transfer encoding extension values, enabling request smuggling attacks.</p>
<p>### Background</p>
<p>This vulnerability is a new variant discovered while researching the "Funky Chunks" HTTP request smuggling techniques:
- https://w4ke.info/2025/06/18/funky-chunks.html
- https://w4ke.info/2025/10/29/funky-chunks-2.html</p>
<p>The original research tested various chunk extension parsing differentials but did not test quoted-string handling within extension values.</p>
<p>### Technical Details</p>
<p>**RFC 9112 Section 7.1.1** defines chunked transfer encoding:
```
chunk = chunk-size [ chunk-ext ] CRLF chunk-data CRLF
chunk-ext = *( BWS ";" BWS chunk-ext-name [ BWS "=" BWS chunk-ext-val ] )
chunk-ext-val = token / quoted-string
```</p>
<p>**RFC 9110 Section 5.6.4** defines quoted-string:
```
quoted-string = DQUOTE *( qdtext / quoted-pair ) DQUOTE
```</p>
<p>A quoted-string continues until the closing DQUOTE, and `\r\n` sequences are not permitted within the quotes.</p>
<p>### Vulnerability</p>
<p>Jetty terminates chunk header parsing at `\r\n` inside quoted strings instead of treating this as an error.</p>
<p>**Expected (RFC compliant):**
```
Chunk: 1;a="value\r\nhere"\r\n
         ^^^^^^^^^^^^^^^^^^ extension value
Body: [1 byte after the real \r\n]
```</p>
<p>**Actual (jetty):**
```
Chunk: 1;a="value
            ^^^^^ terminates here (WRONG)
Body: here"... treated as body/next request
```</p>
<p>### Proof of Concept</p>
<p>```python
#!/usr/bin/env python3
import…</p></div>
    </content>
    <link href="https://cve.radiocsirt.org/vuln/ghsa-355h-qmc2-wpwf"/>
  </entry>
</feed>
