<?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-07T08:49:00.571911+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-2022-24790</id>
    <title>CVE-2022-24790 — HTTP Request Smuggling in puma</title>
    <updated>2026-10-07T08:49:00.605943+00:00</updated>
    <content type="xhtml">
      <div xmlns="http://www.w3.org/1999/xhtml"><p><strong>Affected:</strong> puma</p>
<p>Puma is a simple, fast, multi-threaded, parallel HTTP 1.1 server for Ruby/Rack applications. When using Puma behind a proxy that does not properly validate that the incoming HTTP request matches the RFC7230 standard, Puma and the frontend proxy may disagree on where a request starts and ends. This would allow requests to be smuggled via the front-end proxy to Puma. The vulnerability has been fixed in 5.6.4 and 4.3.12. Users are advised to upgrade as soon as possible. Workaround: when deploying a proxy in front of Puma, turning on any and all functionality to make sure that the request matches the RFC7230 standard.</p></div>
    </content>
    <link href="https://cve.radiocsirt.org/vuln/cve-2022-24790"/>
  </entry>
  <entry>
    <id>https://cve.radiocsirt.org/vuln/ghsa-h99w-9q5r-gjq9</id>
    <title>GHSA-h99w-9q5r-gjq9 — Puma vulnerable to HTTP Request Smuggling</title>
    <updated>2026-10-07T08:49:00.606005+00:00</updated>
    <content type="xhtml">
      <div xmlns="http://www.w3.org/1999/xhtml"><p><strong>Affected:</strong> RubyGems: puma</p>
<p>When using Puma behind a proxy that does not properly validate that the incoming HTTP request matches the RFC7230 standard, Puma and the frontend proxy may disagree on where a request starts and ends. This would allow requests to be smuggled via the front-end proxy to Puma.</p>
<p>The following vulnerabilities are addressed by this advisory:
- Lenient parsing of `Transfer-Encoding` headers, when unsupported encodings should be rejected and the final encoding must be `chunked`.
- Lenient parsing of malformed `Content-Length` headers and chunk sizes, when only digits and hex digits should be allowed.
- Lenient parsing of duplicate `Content-Length` headers, when they should be rejected.
- Lenient parsing of the ending of chunked segments, when they should end with `\r\n`.</p>
<p>The vulnerability has been fixed in 5.6.4 and 4.3.12. When deploying a proxy in front of Puma, turning on any and all functionality to make sure that the request matches the RFC7230 standard.</p>
<p>These proxy servers are known to have "good" behavior re: this standard and upgrading Puma may not be necessary. Users are encouraged to validate for themselves.</p>
<p>- Nginx (latest)
- Apache (latest)
- Haproxy 2.5+
- Caddy (latest)
- Traefik (latest)</p></div>
    </content>
    <link href="https://cve.radiocsirt.org/vuln/ghsa-h99w-9q5r-gjq9"/>
  </entry>
</feed>
