The remote Fedora 38 host has a package installed that is affected by multiple vulnerabilities as referenced in the FEDORA-2022-7bc0f14a13 advisory.

    Automatic update for rubygem-puma-5.6.5-1.fc38.

    ##### **Changelog**

    ```
    * Thu Aug 25 2022 Vt Ondruch <vondruch@redhat.com> - 5.6.5-1
    - Update to Puma 5.6.5.
      Resolves: rhbz#2046576       Resolves: rhbz#2113697       Resolves: rhbz#2071625       Resovles: rhbz#2054212
    * Sat Jul 23 2022 Fedora Release Engineering <releng@fedoraproject.org> - 5.5.2-3
    - Rebuilt for https://fedoraproject.org/wiki/Fedora_37_Mass_Rebuild

    ```

Tenable has extracted the preceding description block directly from the Fedora security advisory.

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 Redhat Enterprise Linux 7 host has packages installed that are affected by multiple vulnerabilities as referenced in the RHSA-2023:1486 advisory.

    Grafana is an open source, feature rich metrics dashboard and graph editor for Graphite, InfluxDB &     OpenTSDB.

    Django is a high-level Python Web framework that encourages rapid development and a clean, pragmatic     design. It focuses on automating as much as possible and adhering to the DRY (Don't Repeat Yourself)     principle.

    Ruby is an extensible, interpreted, object-oriented, scripting language. It has features to process text     files and to perform system management tasks.

    Security Fix(es):

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

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

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

    For more details about the security issue(s), including the impact, a CVSS score, acknowledgments, and     other related information, refer to the CVE page(s) listed in the References section.

Tenable has extracted the preceding description block directly from the Red Hat Enterprise Linux security advisory.

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

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.

    Red Hat Satellite is a system management solution that allows organizations to configure and maintain     their systems without the necessity to provide public Internet access to their servers or other client     systems. It performs provisioning and configuration management of predefined standard operating     environments.

    Security Fix(es):
    * tfm-rubygem-puma: http request smuggling vulnerabilities (CVE-2022-24790)

    This update fixes the following bugs:
    * 2038995: When executing the content migration (pre-upgrade process), there is a PG query created by pulp     that will be sitting forever
    * 2074099: The errata migration continues to fail with pymongo.errors.DocumentTooLarge: BSON document too     large error even after upgrading to Satellite 6.9.8
    * 2081560: ForeignKeyViolation Error with docker_meta_tags
    * 2091438: Use of content.count() in app/models/repository.py seems to hit an error
    * 2093829: 'foreman-maintain content migration-stats' command stucks and consume all memory
    * 2098221: Pulp 3 migration stats timing is too low for very large deployments
    * 2141348: It appears that the egg is downloaded every time

    Users of Red Hat Satellite are advised to upgrade to these updated packages, which fix these bugs.

Tenable has extracted the preceding description block directly from the Red Hat Enterprise Linux security advisory.

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

    ZeddYu Lu discovered that Puma incorrectly handled parsing certain headers. A remote attacker could     possibly use this issue to perform an HTTP Request Smuggling attack. This issue only affected Ubuntu 20.04     LTS. (CVE-2020-11076)

    It was discovered that Puma incorrectly handled parsing certain headers. A remote attacker could possibly     use this issue to perform an HTTP Request Smuggling attack. This issue only affected Ubuntu 20.04 LTS.
    (CVE-2020-11077)

    Jean Boussier discovered that Puma might not always release resources properly after handling HTTP     requests. A remote attacker could possibly use this issue to read sensitive information. (CVE-2022-23634)

    It was discovered that Puma incorrectly handled certain malformed headers. A remote attacker could use     this issue to perform an HTTP Request Smuggling attack. (CVE-2022-24790)

    Ben Kallus discovered that Puma incorrectly handled parsing certain headers. A remote attacker could use     this issue to perform an HTTP Request Smuggling attack. (CVE-2023-40175)

    Bartek Nowotarski discovered that Puma incorrectly handled parsing certain encoded content. A remote     attacker could possibly use this to cause a denial of service. (CVE-2024-21647)

Tenable has extracted the preceding description block directly from the Ubuntu security advisory.

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	Published	Updated	Severity
211139	Fedora 38 : rubygem-puma (2022-7bc0f14a13)	Nessus	Fedora Local Security Checks	11/14/2024	11/14/2024	high
164109	GLSA-202208-28 : Puma: Multiple Vulnerabilities	Nessus	Gentoo Local Security Checks	8/15/2022	8/15/2022	high
173453	RHEL 7 : Red Hat Gluster Storage web-admin-build (RHSA-2023:1486)	Nessus	Red Hat Local Security Checks	3/28/2023	11/7/2024	critical
164646	Debian DLA-3083-1 : puma - LTS security update	Nessus	Debian Local Security Checks	9/2/2022	9/2/2022	high
166105	SUSE SLES15 Security Update : rubygem-puma (SUSE-SU-2022:3571-1)	Nessus	SuSE Local Security Checks	10/14/2022	7/13/2023	high
167832	RHEL 7 : Satellite 6.9.10 Async Security Update (Important) (RHSA-2022:8532)	Nessus	Red Hat Local Security Checks	11/17/2022	11/7/2024	high
164760	Amazon Linux 2022 : (ALAS2022-2022-051)	Nessus	Amazon Linux Local Security Checks	9/6/2022	9/6/2022	high
191720	Ubuntu 20.04 LTS / 22.04 LTS : Puma vulnerabilities (USN-6682-1)	Nessus	Ubuntu Local Security Checks	3/7/2024	8/27/2024	critical
161493	Debian DSA-5146-1 : puma - security update	Nessus	Debian Local Security Checks	5/24/2022	5/24/2022	high

Detections

Analytics

Plugins Search

high

high

critical

high

high

high

high

critical

high