Ce mail provient de l'extérieur, restons vigilants ===================================================================== CERT-Renater Note d'Information No. 2025/VULN675 _____________________________________________________________________ DATE : 08/10/2025 HARDWARE PLATFORM(S): / OPERATING SYSTEM(S): Systems running Rack versions prior to 2.2.19, 3.1.17, 3.2.2. ===================================================================== https://github.com/rack/rack/security/advisories/GHSA-625h-95r8-8xpm https://github.com/rack/rack/security/advisories/GHSA-p543-xpfm-54cp https://github.com/rack/rack/security/advisories/GHSA-w9pc-fmgc-vxvw https://github.com/rack/rack/security/advisories/GHSA-wpv5-97wm-hp9c _____________________________________________________________________ Unsafe default in `Rack::QueryParser` allows params_limit bypass via semicolon-separated parameters. High ioquatix published GHSA-625h-95r8-8xpm Sep 25, 2025 Package rack (RubyGems) Affected versions < 2.2.18 Patched versions 2.2.18 Description Summary Rack::QueryParser in version < 2.2.18 enforces its params_limit only for parameters separated by &, while still splitting on both & and ;. As a result, attackers could use ; separators to bypass the parameter count limit and submit more parameters than intended. Details The issue arises because Rack::QueryParser#check_query_string counts only & characters when determining the number of parameters, but the default separator regex DEFAULT_SEP = /[&;] */n splits on both & and ;. This mismatch means that queries using ; separators were not included in the parameter count, allowing params_limit to be bypassed. Other safeguards (bytesize_limit and key_space_limit) still applied, but did not prevent this particular bypass. Impact Applications or middleware that directly invoke Rack::QueryParser with its default configuration (no explicit delimiter) could be exposed to increased CPU and memory consumption. This can be abused as a limited denial-of-service vector. Rack::Request, the primary entry point for typical Rack applications, uses QueryParser in a safe way and does not appear vulnerable by default. As such, the severity is considered low, with the impact limited to edge cases where QueryParser is used directly. Mitigation Upgrade to a patched version of Rack where both & and ; are counted consistently toward params_limit. If upgrading is not immediately possible, configure QueryParser with an explicit delimiter (e.g., &) to avoid the mismatch. As a general precaution, enforce query string and request size limits at the web server or proxy layer (e.g., Nginx, Apache, or a CDN) to mitigate excessive parsing overhead. Severity High 7.5/ 10 CVSS v3 base metrics Attack vector Network Attack complexity Low Privileges required None User interaction None Scope Unchanged Confidentiality None Integrity None Availability High CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H CVE ID CVE-2025-59830 Weaknesses Weakness CWE-400 Weakness CWE-770 Credits @kwkr kwkr Reporter @jeremyevans jeremyevans Remediation developer @ioquatix ioquatix Remediation reviewer _____________________________________________________________________ Unbounded multipart preamble buffering enables DoS (memory exhaustion) High ioquatix published GHSA-p543-xpfm-54cp Oct 7, 2025 Package rack (RubyGems) Affected versions < 2.2.19 >= 3.1, < 3.1.17 >= 3.2, < 3.2.2 Patched versions 2.2.19 3.1.17 3.2.2 Description Summary Rack::Multipart::Parser buffers the entire multipart preamble (bytes before the first boundary) in memory without any size limit. A client can send a large preamble followed by a valid boundary, causing significant memory use and potential process termination due to out-of-memory (OOM) conditions. Details While searching for the first boundary, the parser appends incoming data into a shared buffer (@sbuf.concat(content)) and scans for the boundary pattern: @sbuf.scan_until(@body_regex) If the boundary is not yet found, the parser continues buffering data indefinitely. There is no trimming or size cap on the preamble, allowing attackers to send arbitrary amounts of data before the first boundary. Impact Remote attackers can trigger large transient memory spikes by including a long preamble in multipart/form-data requests. The impact scales with allowed request sizes and concurrency, potentially causing worker crashes or severe slowdown due to garbage collection. Mitigation Upgrade: Use a patched version of Rack that enforces a preamble size limit (e.g., 16 KiB) or discards preamble data entirely per [RFC 2046 § 5.1.1](https://www.rfc-editor.org/rfc/rfc2046.html#section-5.1.1). Workarounds: Limit total request body size at the proxy or web server level. Monitor memory and set per-process limits to prevent OOM conditions. Severity High 7.5/ 10 CVSS v3 base metrics Attack vector Network Attack complexity Low Privileges required None User interaction None Scope Unchanged Confidentiality None Integrity None Availability High CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H CVE ID CVE-2025-61770 Weaknesses Weakness CWE-400 Credits @kwkr kwkr Reporter @ioquatix ioquatix Remediation reviewer @jeremyevans jeremyevans Remediation developer _____________________________________________________________________ Multipart parser buffers large non‑file fields entirely in memory, enabling DoS (memory exhaustion) High ioquatix published GHSA-w9pc-fmgc-vxvw Oct 7, 2025 Package rack (RubyGems) Affected versions < 2.2.19 >= 3.1, < 3.1.17 >= 3.2, < 3.2.2 Patched versions 2.2.19 3.1.17 3.2.2 Description Summary Rack::Multipart::Parser stores non-file form fields (parts without a filename) entirely in memory as Ruby String objects. A single large text field in a multipart/form-data request (hundreds of megabytes or more) can consume equivalent process memory, potentially leading to out-of-memory (OOM) conditions and denial of service (DoS). Details During multipart parsing, file parts are streamed to temporary files, but non-file parts are buffered into memory: body = String.new # non-file → in-RAM buffer @mime_parts[mime_index].body << content There is no size limit on these in-memory buffers. As a result, any large text field—while technically valid—will be loaded fully into process memory before being added to params. Impact Attackers can send large non-file fields to trigger excessive memory usage. Impact scales with request size and concurrency, potentially leading to worker crashes or severe garbage-collection overhead. All Rack applications processing multipart form submissions are affected. Mitigation Upgrade: Use a patched version of Rack that enforces a reasonable size cap for non-file fields (e.g., 2 MiB). Workarounds: Restrict maximum request body size at the web-server or proxy layer (e.g., Nginx client_max_body_size). Validate and reject unusually large form fields at the application level. Severity High 7.5/ 10 CVSS v3 base metrics Attack vector Network Attack complexity Low Privileges required None User interaction None Scope Unchanged Confidentiality None Integrity None Availability High CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H CVE ID CVE-2025-61771 Weaknesses Weakness CWE-400 Credits @kwkr kwkr Reporter @jeremyevans jeremyevans Remediation developer @ioquatix ioquatix Remediation reviewer _____________________________________________________________________ Multipart parser buffers unbounded per-part headers, enabling DoS (memory exhaustion) High ioquatix published GHSA-wpv5-97wm-hp9c Oct 7, 2025 Package rack (RubyGems) Affected versions < 2.2.19 >= 3.1, < 3.1.17 >= 3.2, < 3.2.2 Patched versions 2.2.19 3.1.17 3.2.2 Description Summary Rack::Multipart::Parser can accumulate unbounded data when a multipart part’s header block never terminates with the required blank line (CRLFCRLF). The parser keeps appending incoming bytes to memory without a size cap, allowing a remote attacker to exhaust memory and cause a denial of service (DoS). Details While reading multipart headers, the parser waits for CRLFCRLF using: @sbuf.scan_until(/(.*?\r\n)\r\n/m) If the terminator never appears, it continues appending data (@sbuf.concat(content)) indefinitely. There is no limit on accumulated header bytes, so a single malformed part can consume memory proportional to the request body size. Impact Attackers can send incomplete multipart headers to trigger high memory use, leading to process termination (OOM) or severe slowdown. The effect scales with request size limits and concurrency. All applications handling multipart uploads may be affected. Mitigation Upgrade to a patched Rack version that caps per-part header size (e.g., 64 KiB). Until then, restrict maximum request sizes at the proxy or web server layer (e.g., Nginx client_max_body_size). Severity High 7.5/ 10 CVSS v3 base metrics Attack vector Network Attack complexity Low Privileges required None User interaction None Scope Unchanged Confidentiality None Integrity None Availability High CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H CVE ID CVE-2025-61772 Weaknesses Weakness CWE-400 Credits @kwkr kwkr Reporter @jeremyevans jeremyevans Remediation developer @ioquatix ioquatix Remediation reviewer ========================================================= + CERT-RENATER | tel : 01-53-94-20-44 + + 23/25 Rue Daviel | fax : 01-53-94-20-41 + + 75013 Paris | email:cert@support.renater.fr + =========================================================