bundle-audit-results/bundle-audit.json

{"version":"0.9.2","created_at":"2025-10-09 08:31:10 +0200","results":[{"type":"unpatched_gem","gem":{"name":"rack","version":"3.2.0"},"advisory":{"path":"/home/wiseadvice/.local/share/ruby-advisory-db/gems/rack/CVE-2025-61770.yml","id":"CVE-2025-61770","url":"https://github.com/rack/rack/security/advisories/GHSA-p543-xpfm-54cp","title":"Rack's unbounded multipart preamble buffering enables DoS (memory exhaustion)","date":"2025-10-07","description":"## Summary\n\n`Rack::Multipart::Parser` buffers the entire multipart **preamble**\n(bytes before the first boundary) in memory without any size limit.\nA client can send a large preamble followed by a valid boundary,\ncausing significant memory use and potential process termination\ndue to out-of-memory (OOM) conditions.\n\n## Details\n\nWhile searching for the first boundary, the parser appends incoming\ndata into a shared buffer (`@sbuf.concat(content)`) and scans for\nthe boundary pattern:\n\n```ruby\n@sbuf.scan_until(@body_regex)\n```\n\nIf the boundary is not yet found, the parser continues buffering\ndata indefinitely. There is no trimming or size cap on the preamble,\nallowing attackers to send arbitrary amounts of data before the\nfirst boundary.\n\n## Impact\n\nRemote attackers can trigger large transient memory spikes by\nincluding a long preamble in multipart/form-data requests. The\nimpact scales with allowed request sizes and concurrency, potentially\ncausing worker crashes or severe slowdown due to garbage collection.\n\n## Mitigation\n\n* **Upgrade:** Use a patched version of Rack that enforces a preamble\nsize limit (e.g., 16 KiB) or discards preamble data entirely per\n[RFC 2046 § 5.1.1](https://www.rfc-editor.org/rfc/rfc2046.html#section-5.1.1).\n\n* **Workarounds:**\n  * Limit total request body size at the proxy or web server level.\n  * Monitor memory and set per-process limits to prevent OOM conditions.\n","cvss_v2":null,"cvss_v3":7.5,"cve":"2025-61770","osvdb":null,"ghsa":"p543-xpfm-54cp","unaffected_versions":[],"patched_versions":["~> 2.2.19","~> 3.1.17",">= 3.2.2"],"criticality":"high"}},{"type":"unpatched_gem","gem":{"name":"rack","version":"3.2.0"},"advisory":{"path":"/home/wiseadvice/.local/share/ruby-advisory-db/gems/rack/CVE-2025-61771.yml","id":"CVE-2025-61771","url":"https://github.com/rack/rack/security/advisories/GHSA-w9pc-fmgc-vxvw","title":"Multipart parser buffers large non‑file fields entirely in memory, enabling DoS (memory exhaustion)","date":"2025-10-07","description":"## Summary\n\n`Rack::Multipart::Parser` stores non-file form fields (parts without\na `filename`) entirely in memory as Ruby `String` objects. A single\nlarge text field in a multipart/form-data request (hundreds of\nmegabytes or more) can consume equivalent process memory, potentially\nleading to out-of-memory (OOM) conditions and denial of service (DoS).\n\n## Details\n\nDuring multipart parsing, file parts are streamed to temporary files,\nbut non-file parts are buffered into memory:\n\n```ruby\nbody = String.new  # non-file → in-RAM buffer\n@mime_parts[mime_index].body << content\n```\n\nThere is no size limit on these in-memory buffers. As a result, any\nlarge text field—while technically valid—will be loaded fully into\nprocess memory before being added to `params`.\n\n## Impact\n\nAttackers can send large non-file fields to trigger excessive memory\nusage. Impact scales with request size and concurrency, potentially\nleading to worker crashes or severe garbage-collection overhead. All\nRack applications processing multipart form submissions are affected.\n\n## Mitigation\n\n* **Upgrade:** Use a patched version of Rack that enforces a\n  reasonable size cap for non-file fields (e.g., 2 MiB).\n\n* **Workarounds:**\n  * Restrict maximum request body size at the web-server or proxy\n    layer (e.g., Nginx `client_max_body_size`).\n  * Validate and reject unusually large form fields at the application level.\n","cvss_v2":null,"cvss_v3":7.5,"cve":"2025-61771","osvdb":null,"ghsa":"w9pc-fmgc-vxvw","unaffected_versions":[],"patched_versions":["~> 2.2.19","~> 3.1.17",">= 3.2.2"],"criticality":"high"}},{"type":"unpatched_gem","gem":{"name":"rack","version":"3.2.0"},"advisory":{"path":"/home/wiseadvice/.local/share/ruby-advisory-db/gems/rack/CVE-2025-61772.yml","id":"CVE-2025-61772","url":"https://github.com/rack/rack/security/advisories/GHSA-wpv5-97wm-hp9c","title":"Rack's multipart parser buffers unbounded per-part headers, enabling DoS (memory exhaustion)","date":"2025-10-07","description":"## Summary\n\n`Rack::Multipart::Parser` can accumulate unbounded data when a\nmultipart part’s header block never terminates with the required\nblank line (`CRLFCRLF`). The parser keeps appending incoming bytes\nto memory without a size cap, allowing a remote attacker to exhaust\nmemory and cause a denial of service (DoS).\n\n## Details\n\nWhile reading multipart headers, the parser waits for `CRLFCRLF` using:\n\n```ruby\n@sbuf.scan_until(/(.*?\\r\n)\\r\n/m)\n```\n\nIf the terminator never appears, it continues appending data\n(`@sbuf.concat(content)`) indefinitely. There is no limit on\naccumulated header bytes, so a single malformed part can consume\nmemory proportional to the request body size.\n\n## Impact\n\nAttackers can send incomplete multipart headers to trigger high memory\nuse, leading to process termination (OOM) or severe slowdown. The\neffect scales with request size limits and concurrency. All\napplications handling multipart uploads may be affected.\n\n## Mitigation\n\n* Upgrade to a patched Rack version that caps per-part header size\n  (e.g., 64 KiB).\n\n* Until then, restrict maximum request sizes at the proxy or web\n  server layer (e.g., Nginx `client_max_body_size`).\n","cvss_v2":null,"cvss_v3":7.5,"cve":"2025-61772","osvdb":null,"ghsa":"wpv5-97wm-hp9c","unaffected_versions":[],"patched_versions":["~> 2.2.19","~> 3.1.17",">= 3.2.2"],"criticality":"high"}},{"type":"unpatched_gem","gem":{"name":"uri","version":"1.0.3"},"advisory":{"path":"/home/wiseadvice/.local/share/ruby-advisory-db/gems/uri/CVE-2025-61594.yml","id":"CVE-2025-61594","url":"https://www.ruby-lang.org/en/news/2025/10/07/uri-cve-2025-61594","title":"CVE-2025-61594 - URI Credential Leakage Bypass over CVE-2025-27221","date":"2025-10-07","description":"\nIn affected URI version, a bypass exists for the fix to CVE-2025-27221\nthat can expose user credentials.\n\nThis vulnerability has been assigned the CVE identifier CVE-2025-61594.\nWe recommend upgrading the uri gem.\n\n## Details\n\nWhen using the + operator to combine URIs, sensitive information\nlike passwords from the original URI can be leaked, violating\nRFC3986 and making applications vulnerable to credential exposure.\n\nPlease update URI gem to version 0.12.5, 0.13.3, 1.0.4 or later.\n\n## Affected versions\n\nuri gem versions < 0.12.5, 0.13.0 to 0.13.2 and 1.0.0 to 1.0.3.\n\n## Credits\n\nThanks to junfuchong (chongfujun) for discovering this issue.\nAlso thanks to nobu for additional fixes of this vulnerability.\n","cvss_v2":null,"cvss_v3":null,"cve":"2025-61594","osvdb":null,"ghsa":null,"unaffected_versions":[],"patched_versions":["~> 0.12.5","~> 0.13.3",">= 1.0.4"],"criticality":null}}]}