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.

The remote Ubuntu 20.04 LTS / 22.04 LTS host has a package installed that is affected by multiple vulnerabilities as referenced in the USN-6682-1 advisory.

  - In Puma (RubyGem) before 4.3.4 and 3.12.5, an attacker could smuggle an HTTP response, by using an invalid     transfer-encoding header. The problem has been fixed in Puma 3.12.5 and Puma 4.3.4. (CVE-2020-11076)

  - In Puma (RubyGem) before 4.3.5 and 3.12.6, a client could smuggle a request through a proxy, causing the     proxy to send a response back to another unknown client. If the proxy uses persistent connections and the     client adds another request in via HTTP pipelining, the proxy may mistake it as the first request's body.
    Puma, however, would see it as two requests, and when processing the second request, send back a response     that the proxy does not expect. If the proxy has reused the persistent connection to Puma to send another     request for a different client, the second response from the first client will be sent to the second     client. This is a similar but different vulnerability from CVE-2020-11076. The problem has been fixed in     Puma 3.12.6 and Puma 4.3.5. (CVE-2020-11077)

  - Puma is a Ruby/Rack web server built for parallelism. Prior to `puma` version `5.6.2`, `puma` may not     always call `close` on the response body. Rails, prior to version `7.0.2.2`, depended on the response body     being closed in order for its `CurrentAttributes` implementation to work correctly. The combination of     these two behaviors (Puma not closing the body + Rails' Executor implementation) causes information     leakage. This problem is fixed in Puma versions 5.6.2 and 4.3.11. This problem is fixed in Rails versions     7.02.2, 6.1.4.6, 6.0.4.6, and 5.2.6.2. Upgrading to a patched Rails _or_ Puma version fixes the     vulnerability. (CVE-2022-23634)

  - 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.
    (CVE-2022-24790)

  - Puma is a Ruby/Rack web server built for parallelism. Prior to versions 6.3.1 and 5.6.7, puma exhibited     incorrect behavior when parsing chunked transfer encoding bodies and zero-length Content-Length headers in     a way that allowed HTTP request smuggling. Severity of this issue is highly dependent on the nature of the     web site using puma is. This could be caused by either incorrect parsing of trailing fields in chunked     transfer encoding bodies or by parsing of blank/zero-length Content-Length headers. Both issues have been     addressed and this vulnerability has been fixed in versions 6.3.1 and 5.6.7. Users are advised to upgrade.
    There are no known workarounds for this vulnerability. (CVE-2023-40175)

  - Puma is a web server for Ruby/Rack applications built for parallelism. Prior to version 6.4.2, puma     exhibited incorrect behavior when parsing chunked transfer encoding bodies in a way that allowed HTTP     request smuggling. Fixed versions limits the size of chunk extensions. Without this limit, an attacker     could cause unbounded resource (CPU, network bandwidth) consumption. This vulnerability has been fixed in     versions 6.4.2 and 5.6.8. (CVE-2024-21647)

Note that Nessus has not tested for these issues but has instead relied only on the application's self-reported version number.

The remote Redhat Enterprise Linux 7 host has packages installed that are affected by multiple vulnerabilities as referenced in the RHSA-2023:1486 advisory.

  - puma-5.6.4: http request smuggling vulnerabilities (CVE-2022-24790)

  - rubygem-rack: crafted multipart POST request may cause a DoS (CVE-2022-30122)

  - rubygem-rack: crafted requests can cause shell escape sequences (CVE-2022-30123)

  - moment: inefficient parsing algorithm resulting in DoS (CVE-2022-31129)

  - rubygem-tzinfo: arbitrary code execution (CVE-2022-31163)

Note that Nessus has not tested for these issues but has instead relied only on the application's self-reported version number.

The remote Redhat Enterprise Linux 7 host has a package installed that is affected by a vulnerability as referenced in the RHSA-2022:8532 advisory.

  - puma-5.6.4: http request smuggling vulnerabilities (CVE-2022-24790)

Note that Nessus has not tested for this issue but has instead relied only on the application's self-reported version number.

The remote SUSE Linux SLES15 / SLES_SAP15 host has a package installed that is affected by a vulnerability as referenced in the SUSE-SU-2022:3571-1 advisory.

  - 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.
    (CVE-2022-24790)

Note that Nessus has not tested for this issue but has instead relied only on the application's self-reported version number.

It is, therefore, affected by multiple vulnerabilities as referenced in the ALAS2022-2022-051 advisory.

  - 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)

  - Puma is a HTTP 1.1 server for Ruby/Rack applications. Prior to versions 5.5.1 and 4.3.9, using `puma` with     a proxy which forwards HTTP header values which contain the LF character could allow HTTP request     smugggling. A client could smuggle a request through a proxy, causing the proxy to send a response back to     another unknown client. The only proxy which has this behavior, as far as the Puma team is aware of, is     Apache Traffic Server. If the proxy uses persistent connections and the client adds another request in via     HTTP pipelining, the proxy may mistake it as the first request's body. Puma, however, would see it as two     requests, and when processing the second request, send back a response that the proxy does not expect. If     the proxy has reused the persistent connection to Puma to send another request for a different client, the     second response from the first client will be sent to the second client. This vulnerability was patched in     Puma 5.5.1 and 4.3.9. As a workaround, do not use Apache Traffic Server with `puma`. (CVE-2021-41136)

  - Puma is a Ruby/Rack web server built for parallelism. Prior to `puma` version `5.6.2`, `puma` may not     always call `close` on the response body. Rails, prior to version `7.0.2.2`, depended on the response body     being closed in order for its `CurrentAttributes` implementation to work correctly. The combination of     these two behaviors (Puma not closing the body + Rails' Executor implementation) causes information     leakage. This problem is fixed in Puma versions 5.6.2 and 4.3.11. This problem is fixed in Rails versions     7.02.2, 6.1.4.6, 6.0.4.6, and 5.2.6.2. Upgrading to a patched Rails _or_ Puma version fixes the     vulnerability. (CVE-2022-23634)

  - 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.
    (CVE-2022-24790)

Note that Nessus has not tested for these issues but has instead relied only on the application's self-reported version number.

The remote Debian 10 host has a package installed that is affected by multiple vulnerabilities as referenced in the dla-3083 advisory.

  - 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)

  - Puma is a HTTP 1.1 server for Ruby/Rack applications. Prior to versions 5.5.1 and 4.3.9, using `puma` with     a proxy which forwards HTTP header values which contain the LF character could allow HTTP request     smugggling. A client could smuggle a request through a proxy, causing the proxy to send a response back to     another unknown client. The only proxy which has this behavior, as far as the Puma team is aware of, is     Apache Traffic Server. If the proxy uses persistent connections and the client adds another request in via     HTTP pipelining, the proxy may mistake it as the first request's body. Puma, however, would see it as two     requests, and when processing the second request, send back a response that the proxy does not expect. If     the proxy has reused the persistent connection to Puma to send another request for a different client, the     second response from the first client will be sent to the second client. This vulnerability was patched in     Puma 5.5.1 and 4.3.9. As a workaround, do not use Apache Traffic Server with `puma`. (CVE-2021-41136)

  - Puma is a Ruby/Rack web server built for parallelism. Prior to `puma` version `5.6.2`, `puma` may not     always call `close` on the response body. Rails, prior to version `7.0.2.2`, depended on the response body     being closed in order for its `CurrentAttributes` implementation to work correctly. The combination of     these two behaviors (Puma not closing the body + Rails' Executor implementation) causes information     leakage. This problem is fixed in Puma versions 5.6.2 and 4.3.11. This problem is fixed in Rails versions     7.02.2, 6.1.4.6, 6.0.4.6, and 5.2.6.2. Upgrading to a patched Rails _or_ Puma version fixes the     vulnerability. (CVE-2022-23634)

  - 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.
    (CVE-2022-24790)

Note that Nessus has not tested for these issues but has instead relied only on the application's self-reported version number.

The remote host is affected by the vulnerability described in GLSA-202208-28 (Puma: Multiple Vulnerabilities)

  - 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)

  - Puma is a HTTP 1.1 server for Ruby/Rack applications. Prior to versions 5.5.1 and 4.3.9, using `puma` with     a proxy which forwards HTTP header values which contain the LF character could allow HTTP request     smugggling. A client could smuggle a request through a proxy, causing the proxy to send a response back to     another unknown client. The only proxy which has this behavior, as far as the Puma team is aware of, is     Apache Traffic Server. If the proxy uses persistent connections and the client adds another request in via     HTTP pipelining, the proxy may mistake it as the first request's body. Puma, however, would see it as two     requests, and when processing the second request, send back a response that the proxy does not expect. If     the proxy has reused the persistent connection to Puma to send another request for a different client, the     second response from the first client will be sent to the second client. This vulnerability was patched in     Puma 5.5.1 and 4.3.9. As a workaround, do not use Apache Traffic Server with `puma`. (CVE-2021-41136)

  - Puma is a Ruby/Rack web server built for parallelism. Prior to `puma` version `5.6.2`, `puma` may not     always call `close` on the response body. Rails, prior to version `7.0.2.2`, depended on the response body     being closed in order for its `CurrentAttributes` implementation to work correctly. The combination of     these two behaviors (Puma not closing the body + Rails' Executor implementation) causes information     leakage. This problem is fixed in Puma versions 5.6.2 and 4.3.11. This problem is fixed in Rails versions     7.02.2, 6.1.4.6, 6.0.4.6, and 5.2.6.2. Upgrading to a patched Rails _or_ Puma version fixes the     vulnerability. (CVE-2022-23634)

  - 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.
    (CVE-2022-24790)

Note that Nessus has not tested for these issues but has instead relied only on the application's self-reported version number.

The remote Debian 11 host has a package installed that is affected by multiple vulnerabilities as referenced in the dsa-5146 advisory.

  - Puma is a HTTP 1.1 server for Ruby/Rack applications. Prior to versions 5.5.1 and 4.3.9, using `puma` with     a proxy which forwards HTTP header values which contain the LF character could allow HTTP request     smugggling. A client could smuggle a request through a proxy, causing the proxy to send a response back to     another unknown client. The only proxy which has this behavior, as far as the Puma team is aware of, is     Apache Traffic Server. If the proxy uses persistent connections and the client adds another request in via     HTTP pipelining, the proxy may mistake it as the first request's body. Puma, however, would see it as two     requests, and when processing the second request, send back a response that the proxy does not expect. If     the proxy has reused the persistent connection to Puma to send another request for a different client, the     second response from the first client will be sent to the second client. This vulnerability was patched in     Puma 5.5.1 and 4.3.9. As a workaround, do not use Apache Traffic Server with `puma`. (CVE-2021-41136)

  - Puma is a Ruby/Rack web server built for parallelism. Prior to `puma` version `5.6.2`, `puma` may not     always call `close` on the response body. Rails, prior to version `7.0.2.2`, depended on the response body     being closed in order for its `CurrentAttributes` implementation to work correctly. The combination of     these two behaviors (Puma not closing the body + Rails' Executor implementation) causes information     leakage. This problem is fixed in Puma versions 5.6.2 and 4.3.11. This problem is fixed in Rails versions     7.02.2, 6.1.4.6, 6.0.4.6, and 5.2.6.2. Upgrading to a patched Rails _or_ Puma version fixes the     vulnerability. (CVE-2022-23634)

  - 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.
    (CVE-2022-24790)

Note that Nessus has not tested for these issues but has instead relied only on the application's self-reported version number.

ID	Name	Product	Family	Severity
191720	Ubuntu 20.04 LTS / 22.04 LTS : Puma vulnerabilities (USN-6682-1)	Nessus	Ubuntu Local Security Checks	critical
173453	RHEL 7 : Red Hat Gluster Storage web-admin-build (RHSA-2023:1486)	Nessus	Red Hat Local Security Checks	critical
167832	RHEL 7 : Satellite 6.9.10 Async Security Update (Important) (RHSA-2022:8532)	Nessus	Red Hat Local Security Checks	high
166105	SUSE SLES15 Security Update : rubygem-puma (SUSE-SU-2022:3571-1)	Nessus	SuSE Local Security Checks	high
164760	Amazon Linux 2022 : (ALAS2022-2022-051)	Nessus	Amazon Linux Local Security Checks	high
164646	Debian DLA-3083-1 : puma - LTS security update	Nessus	Debian Local Security Checks	high
164109	GLSA-202208-28 : Puma: Multiple Vulnerabilities	Nessus	Gentoo Local Security Checks	high
161493	Debian DSA-5146-1 : puma - security update	Nessus	Debian Local Security Checks	high

Detections

Analytics

CVE-2022-24790

high

Tenable Plugins

critical

critical

high

high

high

high

high

high