<?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 17:48:37 +0000</lastBuildDate>
    <item>
      <title>bdu:2021-05079</title>
      <link>https://cve.radiocsirt.org/vuln/bdu:2021-05079</link>
      <description>bdu:2021-05079</description>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/bdu:2021-05079</guid>
    </item>
    <item>
      <title>EUVD-2026-26399</title>
      <link>https://cve.radiocsirt.org/vuln/euvd-2026-26399</link>
      <description>EUVD-2026-26399</description>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/euvd-2026-26399</guid>
    </item>
    <item>
      <title>fkie_cve-2021-29509</title>
      <link>https://cve.radiocsirt.org/vuln/fkie_cve-2021-29509</link>
      <description>&lt;p&gt;Puma is a concurrent HTTP 1.1 server for Ruby/Rack applications. The fix for CVE-2019-16770 was incomplete. The original fix only protected existing connections that had already been accepted from having their requests starved by greedy persistent-connections saturating all threads in the same process. However, new connections may still be starved by greedy persistent-connections saturating all threads in all processes in the cluster. A `puma` server which received more concurrent `keep-alive` connections than the server had threads in its threadpool would service only a subset of connections, denying service to the unserved connections. This problem has been fixed in `puma` 4.3.8 and 5.3.1. Setting `queue_requests false` also fixes the issue. This is not advised when using `puma` without a reverse proxy, such as `nginx` or `apache`, because you will open yourself to slow client attacks (e.g. slowloris). The fix is very small and a git patch is available for those using unsupported versions of Puma.&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;Puma is a concurrent HTTP 1.1 server for Ruby/Rack applications. The fix for CVE-2019-16770 was incomplete. The original fix only protected existing connections that had already been accepted from having their requests starved by greedy persistent-connections saturating all threads in the same process. However, new connections may still be starved by greedy persistent-connections saturating all threads in all processes in the cluster. A `puma` server which received more concurrent `keep-alive` connections than the server had threads in its threadpool would service only a subset of connections, denying service to the unserved connections. This problem has been fixed in `puma` 4.3.8 and 5.3.1. Setting `queue_requests false` also fixes the issue. This is not advised when using `puma` without a reverse proxy, such as `nginx` or `apache`, because you will open yourself to slow client attacks (e.g. slowloris). The fix is very small and a git patch is available for those using unsupported versions of Puma.&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/fkie_cve-2021-29509</guid>
    </item>
    <item>
      <title>GHSA-q28m-8xjw-8vr5 — Puma's Keepalive Connections Causing Denial Of Service</title>
      <link>https://cve.radiocsirt.org/vuln/ghsa-q28m-8xjw-8vr5</link>
      <description>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; RubyGems: puma&lt;/p&gt;
&lt;p&gt;This vulnerability is related to [CVE-2019-16770](https://github.com/puma/puma/security/advisories/GHSA-7xx3-m584-x994).&lt;/p&gt;
&lt;p&gt;### Impact&lt;/p&gt;
&lt;p&gt;The fix for CVE-2019-16770 was incomplete. The original fix only protected existing connections that had already been accepted from having their requests starved by greedy persistent-connections saturating all threads in the same process. However, new connections may still be starved by greedy persistent-connections saturating all threads in all processes in the cluster.&lt;/p&gt;
&lt;p&gt;A `puma` server which received more concurrent `keep-alive` connections than the server had threads in its threadpool would service only a subset of connections, denying service to the unserved connections.&lt;/p&gt;
&lt;p&gt;### Patches&lt;/p&gt;
&lt;p&gt;This problem has been fixed in `puma` 4.3.8 and 5.3.1.&lt;/p&gt;
&lt;p&gt;### Workarounds&lt;/p&gt;
&lt;p&gt;Setting `queue_requests false` also fixes the issue. This is not advised when using `puma` without a reverse proxy, such as `nginx` or `apache`, because you will open yourself to slow client attacks (e.g. [slowloris](https://en.wikipedia.org/wiki/Slowloris_(computer_security))).&lt;/p&gt;
&lt;p&gt;The fix is very small. [A git patch is available here](https://gist.github.com/nateberkopec/4b3ea5676c0d70cbb37c82d54be25837) for those using [unsupported versions](https://github.com/puma/puma/security/policy#supported-versions) of Puma.&lt;/p&gt;
&lt;p&gt;### For more information&lt;/p&gt;
&lt;p&gt;If you have any questions or comments about this advisory:&lt;/p&gt;
&lt;p&gt;* Open an issue in [Puma](https://github.com/puma/puma).
* To report problems with this f…&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; RubyGems: puma&lt;/p&gt;
&lt;p&gt;This vulnerability is related to [CVE-2019-16770](https://github.com/puma/puma/security/advisories/GHSA-7xx3-m584-x994).&lt;/p&gt;
&lt;p&gt;### Impact&lt;/p&gt;
&lt;p&gt;The fix for CVE-2019-16770 was incomplete. The original fix only protected existing connections that had already been accepted from having their requests starved by greedy persistent-connections saturating all threads in the same process. However, new connections may still be starved by greedy persistent-connections saturating all threads in all processes in the cluster.&lt;/p&gt;
&lt;p&gt;A `puma` server which received more concurrent `keep-alive` connections than the server had threads in its threadpool would service only a subset of connections, denying service to the unserved connections.&lt;/p&gt;
&lt;p&gt;### Patches&lt;/p&gt;
&lt;p&gt;This problem has been fixed in `puma` 4.3.8 and 5.3.1.&lt;/p&gt;
&lt;p&gt;### Workarounds&lt;/p&gt;
&lt;p&gt;Setting `queue_requests false` also fixes the issue. This is not advised when using `puma` without a reverse proxy, such as `nginx` or `apache`, because you will open yourself to slow client attacks (e.g. [slowloris](https://en.wikipedia.org/wiki/Slowloris_(computer_security))).&lt;/p&gt;
&lt;p&gt;The fix is very small. [A git patch is available here](https://gist.github.com/nateberkopec/4b3ea5676c0d70cbb37c82d54be25837) for those using [unsupported versions](https://github.com/puma/puma/security/policy#supported-versions) of Puma.&lt;/p&gt;
&lt;p&gt;### For more information&lt;/p&gt;
&lt;p&gt;If you have any questions or comments about this advisory:&lt;/p&gt;
&lt;p&gt;* Open an issue in [Puma](https://github.com/puma/puma).
* To report problems with this f…&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/ghsa-q28m-8xjw-8vr5</guid>
    </item>
    <item>
      <title>gsd-2021-29509</title>
      <link>https://cve.radiocsirt.org/vuln/gsd-2021-29509</link>
      <description>gsd-2021-29509</description>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/gsd-2021-29509</guid>
    </item>
    <item>
      <title>OESA-2021-1203 — rubygem-puma security update</title>
      <link>https://cve.radiocsirt.org/vuln/oesa-2021-1203</link>
      <description>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; openEuler:20.03-LTS-SP1: rubygem-puma&lt;/p&gt;
&lt;p&gt;A simple, fast, threaded, and highly concurrent HTTP 1.1 server for Ruby/Rack applications.&#13;
&#13;
Security Fix(es):&#13;
&#13;
Puma is a concurrent HTTP 1.1 server for Ruby/Rack applications. The fix for CVE-2019-16770 was incomplete. The original fix only protected existing connections that had already been accepted from having their requests starved by greedy persistent-connections saturating all threads in the same process. However, new connections may still be starved by greedy persistent-connections saturating all threads in all processes in the cluster. A `puma` server which received more concurrent `keep-alive` connections than the server had threads in its threadpool would service only a subset of connections, denying service to the unserved connections. This problem has been fixed in `puma` 4.3.8 and 5.3.1. Setting `queue_requests False` also fixes the issue. This is not advised when using `puma` without a reverse proxy, such as `nginx` or `apache`, because you will open yourself to slow client attacks (e.g. slowloris). The fix is very small and a git patch is available for those using unsupported versions of Puma.(CVE-2021-29509)&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; openEuler:20.03-LTS-SP1: rubygem-puma&lt;/p&gt;
&lt;p&gt;A simple, fast, threaded, and highly concurrent HTTP 1.1 server for Ruby/Rack applications.&#13;
&#13;
Security Fix(es):&#13;
&#13;
Puma is a concurrent HTTP 1.1 server for Ruby/Rack applications. The fix for CVE-2019-16770 was incomplete. The original fix only protected existing connections that had already been accepted from having their requests starved by greedy persistent-connections saturating all threads in the same process. However, new connections may still be starved by greedy persistent-connections saturating all threads in all processes in the cluster. A `puma` server which received more concurrent `keep-alive` connections than the server had threads in its threadpool would service only a subset of connections, denying service to the unserved connections. This problem has been fixed in `puma` 4.3.8 and 5.3.1. Setting `queue_requests False` also fixes the issue. This is not advised when using `puma` without a reverse proxy, such as `nginx` or `apache`, because you will open yourself to slow client attacks (e.g. slowloris). The fix is very small and a git patch is available for those using unsupported versions of Puma.(CVE-2021-29509)&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/oesa-2021-1203</guid>
    </item>
    <item>
      <title>openSUSE-SU-2024:12592-1 — ruby3.1-rubygem-puma-5-5.6.5-1.1 on GA media</title>
      <link>https://cve.radiocsirt.org/vuln/opensuse-su-2024:12592-1</link>
      <description>&lt;p&gt;ruby3.1-rubygem-puma-5-5.6.5-1.1 on GA media&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;ruby3.1-rubygem-puma-5-5.6.5-1.1 on GA media&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/opensuse-su-2024:12592-1</guid>
    </item>
    <item>
      <title>RHSA-2021:4702 — Red Hat Security Advisory: Satellite 6.10 Release</title>
      <link>https://cve.radiocsirt.org/vuln/rhsa-2021:4702</link>
      <description>&lt;p&gt;python-ecdsa: Unexpected and  undocumented exceptions during signature decoding python-ecdsa: DER encoding is not being verified in signatures rubygem-activerecord-session_store: hijack sessions by using timing attacks targeting the session id rake: OS Command Injection via egrep in Rake::FileList guava: local information disclosure via temporary directory created with unsafe permissions PyYAML: incomplete fix for CVE-2020-1747 rubygem-nokogiri: XML external entity injection via Nokogiri::XML::Schema Satellite: Azure compute resource secret_key leak to authenticated users foreman: possible man-in-the-middle in smart_proxy realm_freeipa Satellite: BMC controller credential leak via API python-aiohttp: Open redirect in aiohttp.web_middlewares.normalize_path_middleware rubygem-actionpack: Possible Information Disclosure / Unintended Method Execution in Action Pack rails: Possible Denial of Service vulnerability in Action Dispatch rails: Possible DoS Vulnerability in Action Controller Token Authentication django: potential directory-traversal via uploaded files rubygem-puma: incomplete fix for CVE-2019-16770 allows Denial of Service (DoS) django: Potential directory-traversal via uploaded files rubygem-addressable: ReDoS in templates django: Potential directory traversal via ``admindocs`` python-urllib3: ReDoS in the parsing of authority part of URL django: Possible indeterminate SSRF, RFI, and LFI attacks since validators accepted leading zeros in IPv4 addresses&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;python-ecdsa: Unexpected and  undocumented exceptions during signature decoding python-ecdsa: DER encoding is not being verified in signatures rubygem-activerecord-session_store: hijack sessions by using timing attacks targeting the session id rake: OS Command Injection via egrep in Rake::FileList guava: local information disclosure via temporary directory created with unsafe permissions PyYAML: incomplete fix for CVE-2020-1747 rubygem-nokogiri: XML external entity injection via Nokogiri::XML::Schema Satellite: Azure compute resource secret_key leak to authenticated users foreman: possible man-in-the-middle in smart_proxy realm_freeipa Satellite: BMC controller credential leak via API python-aiohttp: Open redirect in aiohttp.web_middlewares.normalize_path_middleware rubygem-actionpack: Possible Information Disclosure / Unintended Method Execution in Action Pack rails: Possible Denial of Service vulnerability in Action Dispatch rails: Possible DoS Vulnerability in Action Controller Token Authentication django: potential directory-traversal via uploaded files rubygem-puma: incomplete fix for CVE-2019-16770 allows Denial of Service (DoS) django: Potential directory-traversal via uploaded files rubygem-addressable: ReDoS in templates django: Potential directory traversal via ``admindocs`` python-urllib3: ReDoS in the parsing of authority part of URL django: Possible indeterminate SSRF, RFI, and LFI attacks since validators accepted leading zeros in IPv4 addresses&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/rhsa-2021:4702</guid>
    </item>
    <item>
      <title>SUSE-SU-2021:2761-1 — Security update for rubygem-puma</title>
      <link>https://cve.radiocsirt.org/vuln/suse-su-2021:2761-1</link>
      <description>&lt;p&gt;Security update for rubygem-puma&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;Security update for rubygem-puma&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/suse-su-2021:2761-1</guid>
    </item>
    <item>
      <title>Withdrawn: UBUNTU-CVE-2021-29509</title>
      <link>https://cve.radiocsirt.org/vuln/ubuntu-cve-2021-29509</link>
      <description>&lt;p&gt;&lt;strong&gt;Withdrawn by the publisher.&lt;/strong&gt;&lt;/p&gt;
&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; Ubuntu:20.04:LTS: puma, Ubuntu:22.04:LTS: puma&lt;/p&gt;
&lt;p&gt;Puma is a concurrent HTTP 1.1 server for Ruby/Rack applications. The fix for CVE-2019-16770 was incomplete. The original fix only protected existing connections that had already been accepted from having their requests starved by greedy persistent-connections saturating all threads in the same process. However, new connections may still be starved by greedy persistent-connections saturating all threads in all processes in the cluster. A `puma` server which received more concurrent `keep-alive` connections than the server had threads in its threadpool would service only a subset of connections, denying service to the unserved connections. This problem has been fixed in `puma` 4.3.8 and 5.3.1. Setting `queue_requests false` also fixes the issue. This is not advised when using `puma` without a reverse proxy, such as `nginx` or `apache`, because you will open yourself to slow client attacks (e.g. slowloris). The fix is very small and a git patch is available for those using unsupported versions of Puma.&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;&lt;strong&gt;Withdrawn by the publisher.&lt;/strong&gt;&lt;/p&gt;
&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; Ubuntu:20.04:LTS: puma, Ubuntu:22.04:LTS: puma&lt;/p&gt;
&lt;p&gt;Puma is a concurrent HTTP 1.1 server for Ruby/Rack applications. The fix for CVE-2019-16770 was incomplete. The original fix only protected existing connections that had already been accepted from having their requests starved by greedy persistent-connections saturating all threads in the same process. However, new connections may still be starved by greedy persistent-connections saturating all threads in all processes in the cluster. A `puma` server which received more concurrent `keep-alive` connections than the server had threads in its threadpool would service only a subset of connections, denying service to the unserved connections. This problem has been fixed in `puma` 4.3.8 and 5.3.1. Setting `queue_requests false` also fixes the issue. This is not advised when using `puma` without a reverse proxy, such as `nginx` or `apache`, because you will open yourself to slow client attacks (e.g. slowloris). The fix is very small and a git patch is available for those using unsupported versions of Puma.&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/ubuntu-cve-2021-29509</guid>
    </item>
  </channel>
</rss>
