Skip to content

🚨 [security] Update omniauth-rails_csrf_protection 1.0.1 → 2.0.1 (major) #60

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom
Open
depfu wants to merge 1 commit into
base: master
Choose a base branch
from
Open

🚨 [security] Update omniauth-rails_csrf_protection 1.0.1 → 2.0.1 (major) #60

depfu wants to merge 1 commit into from
+10 −9

Conversation

@depfu
Copy link
Contributor

@depfu depfu bot commented Dec 11, 2025

🚨 Your current dependencies have known security vulnerabilities 🚨

This dependency update fixes known security vulnerabilities. Please see the details below and assess their impact carefully. We recommend to merge and deploy this as soon as possible!

Here is everything you need to know about this update. Please take a good look at what changed and the test results before merging this pull request.

What changed?

✳️ omniauth-rails_csrf_protection (1.0.1 → 2.0.1) · Repo

Release Notes

2.0.1

  • Fix an issue with configuration delegation in Rails < 8.1 (#26)

    For more details, please see 1a0d390.

2.0.0

  • Stop using deprecated ActiveSupport::Configurable when this gem is running against Action Pack version 8.1 and later (#23, #24)

1.0.2

  • Update supported Ruby and Rails versions.
  • Ensure the library is working correctly in a multi-threaded environment.

Does any of this look wrong? Please let us know.

Commits

See the full diff on Github. The new version differs by more commits than we can show here.

✳️ omniauth (2.1.3 → 2.1.4) · Repo

Release Notes

2.1.4

What's Changed

Full Changelog: v2.1.3...v2.1.4

You may now configure an after_request_phase callback on your omniauth builder instance. This callback will be run after the request phase before returning the request result.

Does any of this look wrong? Please let us know.

Commits

See the full diff on Github. The new version differs by more commits than we can show here.

↗️ base64 (indirect, 0.2.0 → 0.3.0) · Repo

Release Notes

0.3.0

What's Changed

New Contributors

Full Changelog: v0.2.0...v0.3.0

Does any of this look wrong? Please let us know.

Commits

See the full diff on Github. The new version differs by more commits than we can show here.

↗️ loofah (indirect, 2.24.0 → 2.24.1) · Repo · Changelog

Release Notes

2.24.1

2.24.1 / 2025-05-12

Ruby support

  • Import only what's needed from cgi for support for Ruby 3.5 #296 @Earlopain

Does any of this look wrong? Please let us know.

Commits

See the full diff on Github. The new version differs by more commits than we can show here.

↗️ mini_portile2 (indirect, 2.8.8 → 2.8.9) · Repo · Changelog

Release Notes

2.8.9

2.8.9 / 2025-05-12

Ruby support

  • Import only what's needed from cgi, for supporting Ruby 3.5. #160 @Earlopain

New Contributors

Full Changelog: v2.8.8...v2.8.9

Does any of this look wrong? Please let us know.

Commits

See the full diff on Github. The new version differs by more commits than we can show here.

↗️ minitest (indirect, 5.25.5 → 5.26.2) · Repo · Changelog

Release Notes

5.26.2 (from changelog)

  • 5 bug fixes:

    • Bumped minimum ruby to 3.1.

    • Alias Spec#name to #inspect for cleaner output in repls.

    • Fix pathing for Hoe::Minitest initialization to be more generic.

    • Fixed refute_in_epsilon to use min of abs values. (wtn)

    • Improved options processing and usage output to be more clear.

5.26.1 (from changelog)

The Ocean Shores, Slightly Less Tipsy Edition!

  • 3 bug fixes:

    • Add links to API doco in README.

    • Add missing require thread.

    • Bumped ruby version to include 4.0 (trunk). (hsbt) (see also 5.14.2)

5.26.0 (from changelog)

The Seattle.rb Nerd Party, Slightly Tipsy Edition!

  • 2 minor enhancements:

    • Added extra documentation to Minitest::TestTask options.

    • Make parallelize_me! a no-op when n_threads=1.

  • 9 bug fixes:

    • Bypass parallel_executor entirely when n_threads=1.

    • Don’t require rubygems in Rakefile… it is 2025.

    • Ensure that minitest exits non-zero on Interrupt. (tavianator)

    • Fix Minitest.run sequence rdoc to include loop vars and read consistently.

    • Fix call to parallel_executor.shutdown when it isn’t defined.

    • Removed some 1.8/1.9-based code from the assertions and expectations.

    • Still fighting with rdoc? Yup. Still fighting with rdoc…

    • Switched assert_equal’s diff from Tempfile.open to Tempfile.create.

    • Use Regexp.escape for BASE_RE in case pwd has special chars. (astra_1993)

Does any of this look wrong? Please let us know.

Commits

See the full diff on Github. The new version differs by more commits than we can show here.

↗️ nokogiri (indirect, 1.18.5 → 1.18.10) · Repo · Changelog

Security Advisories 🚨

🚨 Nokogiri patches vendored libxml2 to resolve multiple CVEs

Summary

Nokogiri v1.18.9 patches the vendored libxml2 to address CVE-2025-6021, CVE-2025-6170, CVE-2025-49794, CVE-2025-49795, and CVE-2025-49796.

Impact and severity

CVE-2025-6021

A flaw was found in libxml2's xmlBuildQName function, where integer overflows in buffer size calculations can lead to a stack-based buffer overflow. This issue can result in memory corruption or a denial of service when processing crafted input.

NVD claims a severity of 7.5 High (CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H)

Fixed by applying https://gitlab.gnome.org/GNOME/libxml2/-/commit/17d950ae

CVE-2025-6170

A flaw was found in the interactive shell of the xmllint command-line tool, used for parsing XML files. When a user inputs an overly long command, the program does not check the input size properly, which can cause it to crash. This issue might allow attackers to run harmful code in rare configurations without modern protections.

NVD claims a severity of 2.5 Low (CVSS:3.1/AV:L/AC:H/PR:N/UI:R/S:U/C:N/I:N/A:L)

Fixed by applying https://gitlab.gnome.org/GNOME/libxml2/-/commit/5e9ec5c1

CVE-2025-49794

A use-after-free vulnerability was found in libxml2. This issue occurs when parsing XPath elements under certain circumstances when the XML schematron has the <sch:name path="..."/> schema elements. This flaw allows a malicious actor to craft a malicious XML document used as input for libxml, resulting in the program's crash using libxml or other possible undefined behaviors.

NVD claims a severity of 9.1 Critical (CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:H/A:H)

Fixed by applying https://gitlab.gnome.org/GNOME/libxml2/-/commit/81cef8c5

CVE-2025-49795

A NULL pointer dereference vulnerability was found in libxml2 when processing XPath XML expressions. This flaw allows an attacker to craft a malicious XML input to libxml2, leading to a denial of service.

NVD claims a severity of 7.5 High (CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H)

Fixed by applying https://gitlab.gnome.org/GNOME/libxml2/-/commit/62048278

CVE-2025-49796

A vulnerability was found in libxml2. Processing certain sch:name elements from the input XML file can trigger a memory corruption issue. This flaw allows an attacker to craft a malicious XML input file that can lead libxml to crash, resulting in a denial of service or other possible undefined behavior due to sensitive data being corrupted in memory.

NVD claims a severity of 9.1 Critical (CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:H/A:H)

Fixed by applying https://gitlab.gnome.org/GNOME/libxml2/-/commit/81cef8c5

Affected Versions

  • Nokogiri < 1.18.9 when using CRuby (MRI) with vendored libxml2

Patched Versions

  • Nokogiri >= 1.18.9

Mitigation

Upgrade to Nokogiri v1.18.9 or later.

Users who are unable to upgrade Nokogiri may also choose a more complicated mitigation: compile and link Nokogiri against patched external libxml2 libraries which will also address these same issues.

References

🚨 Nokogiri updates packaged libxml2 to v2.13.8 to resolve CVE-2025-32414 and CVE-2025-32415

Summary

Nokogiri v1.18.8 upgrades its dependency libxml2 to v2.13.8.

libxml2 v2.13.8 addresses:

Impact

CVE-2025-32414: No impact

In libxml2 before 2.13.8 and 2.14.x before 2.14.2, out-of-bounds memory access can occur in the Python API (Python bindings) because of an incorrect return value. This occurs in xmlPythonFileRead and xmlPythonFileReadRaw because of a difference between bytes and characters.

There is no impact from this CVE for Nokogiri users.

CVE-2025-32415: Low impact

In libxml2 before 2.13.8 and 2.14.x before 2.14.2, xmlSchemaIDCFillNodeTables in xmlschemas.c has a heap-based buffer under-read. To exploit this, a crafted XML document must be validated against an XML schema with certain identity constraints, or a crafted XML schema must be used.

In the upstream issue, further context is provided by the maintainer:

The bug affects validation against untrusted XML Schemas (.xsd) and validation of untrusted
documents against trusted Schemas if they make use of xsd:keyref in combination with recursively
defined types that have additional identity constraints.

MITRE has published a severity score of 2.9 LOW (CVSS:3.1/AV:L/AC:H/PR:N/UI:N/S:U/C:N/I:N/A:L) for this CVE.

Release Notes

1.18.10

v1.18.10 / 2025-09-15

Dependencies

  • [CRuby] Vendored libxml2 is updated to v2.13.9. Note that the security fixes published in v2.13.9 were already present in Nokogiri v1.18.9.
  • [CRuby] [Windows and MacOS] Vendored libiconv is updated to v1.18

sha256 checksums

 
7fb87235d729c74a2be635376d82b1d459230cc17c50300f8e4fcaabc6195344  nokogiri-1.18.10-aarch64-linux-gnu.gem
7e74e58314297cc8a8f1b533f7212d1999dbe2639a9ee6d97b483ea2acc18944  nokogiri-1.18.10-aarch64-linux-musl.gem
51f4f25ab5d5ba1012d6b16aad96b840a10b067b93f35af6a55a2c104a7ee322  nokogiri-1.18.10-arm-linux-gnu.gem
1c6ea754e51cecc85c30ee8ab1e6aa4ce6b6e134d01717e9290e79374a9e00aa  nokogiri-1.18.10-arm-linux-musl.gem
c2b0de30770f50b92c9323fa34a4e1cf5a0af322afcacd239cd66ee1c1b22c85  nokogiri-1.18.10-arm64-darwin.gem
cd431a09c45d84a2f870ba0b7e8f571199b3727d530f2b4888a73639f76510b5  nokogiri-1.18.10-java.gem
64f40d4a41af9f7f83a4e236ad0cf8cca621b97e31f727b1bebdae565a653104  nokogiri-1.18.10-x64-mingw-ucrt.gem
536e74bed6db2b5076769cab5e5f5af0cd1dccbbd75f1b3e1fa69d1f5c2d79e2  nokogiri-1.18.10-x86_64-darwin.gem
ff5ba26ba2dbce5c04b9ea200777fd225061d7a3930548806f31db907e500f72  nokogiri-1.18.10-x86_64-linux-gnu.gem
0651fccf8c2ebbc2475c8b1dfd7ccac3a0a6d09f8a41b72db8c21808cb483385  nokogiri-1.18.10-x86_64-linux-musl.gem
d5cc0731008aa3b3a87b361203ea3d19b2069628cb55e46ac7d84a0445e69cc1  nokogiri-1.18.10.gem

1.18.9

v1.18.9 / 2025-07-20

Security

sha256 checksums

 
5bcfdf7aa8d1056a7ad5e52e1adffc64ef53d12d0724fbc6f458a3af1a4b9e32  nokogiri-1.18.9-aarch64-linux-gnu.gem
55e9e6ca46c4ad1715e313f407d8481d15be1e3b65d9f8e52ba1c124d01676a7  nokogiri-1.18.9-aarch64-linux-musl.gem
eea3f1f06463ff6309d3ff5b88033c4948d0da1ab3cc0a3a24f63c4d4a763979  nokogiri-1.18.9-arm64-darwin.gem
fe611ae65880e445a9c0f650d52327db239f3488626df4173c05beafd161d46e  nokogiri-1.18.9-arm-linux-gnu.gem
935605e14c0ba17da18d203922440bf6c0676c602659278d855d4622d756a324  nokogiri-1.18.9-arm-linux-musl.gem
ac5a7d93fd0e3cef388800b037407890882413feccca79eb0272a2715a82fa33  nokogiri-1.18.9.gem
1fe5b7aa4a054eda689a969bb4e03999960a6ea806582d327207d687168bceb5  nokogiri-1.18.9-java.gem
6b4fc1523aa0370c78653e38c94cb50e7f3ab786425de66ba7ad24222c1164a3  nokogiri-1.18.9-x64-mingw-ucrt.gem
e0d2deb03d3d7af8016e8c9df5ff4a7d692159cefb135cbb6a4109f265652348  nokogiri-1.18.9-x86_64-darwin.gem
b52f5defedc53d14f71eeaaf990da66b077e1918a2e13088b6a96d0230f44360  nokogiri-1.18.9-x86_64-linux-gnu.gem
e69359d6240c17e64cc9f43970d54f13bfc7b8cc516b819228f687e953425e69  nokogiri-1.18.9-x86_64-linux-musl.gem

1.18.8

v1.18.8 / 2025-04-21

Security

sha256 checksums

 
36badd2eb281fca6214a5188e24a34399b15d89730639a068d12931e2adc210e  nokogiri-1.18.8-aarch64-linux-gnu.gem
664e0f9a77a7122a66d6c03abba7641ca610769a4728db55ee1706a0838b78a2  nokogiri-1.18.8-aarch64-linux-musl.gem
483b5b9fb33653f6f05cbe00d09ea315f268f0e707cfc809aa39b62993008212  nokogiri-1.18.8-arm64-darwin.gem
17de01ca3adf9f8e187883ed73c672344d3dbb3c260f88ffa1008e8dc255a28e  nokogiri-1.18.8-arm-linux-gnu.gem
6e6d7e71fc39572bd613a82d528cf54392c3de1ba5ce974f05c832b8187a040b  nokogiri-1.18.8-arm-linux-musl.gem
8c7464875d9ca7f71080c24c0db7bcaa3940e8be3c6fc4bcebccf8b9a0016365  nokogiri-1.18.8.gem
41002596960ff854198a20aaeb34cff0d445406d5ad85ba7ca9c3fd0c8f03de0  nokogiri-1.18.8-java.gem
11ab0f76772c5f2d718fb253fca5b74c6ef7628b72bbf8deba6ab1ffc93344cf  nokogiri-1.18.8-x64-mingw-ucrt.gem
024cdfe7d9ae3466bba6c06f348fb2a8395d9426b66a3c82f1961b907945cc0c  nokogiri-1.18.8-x86_64-darwin.gem
4a747875db873d18a2985ee2c320a6070c4a414ad629da625fbc58d1a20e5ecc  nokogiri-1.18.8-x86_64-linux-gnu.gem
ddd735fba49475a395b9ea793bb6474e3a3125b89960339604d08a5397de1165  nokogiri-1.18.8-x86_64-linux-musl.gem

1.18.7

v1.18.7 / 2025-03-31

Dependencies

  • [CRuby] Vendored libxml2 is updated to v2.13.7, which is a bugfix release.

sha256 checksums

 
57a064ab5440814a69a0e040817bd8154adea68a30d2ff2b3aa515a6a06dbb5f  nokogiri-1.18.7-aarch64-linux-gnu.gem
3e442dc5b69376e84288295fe37cbb890a21ad816a7e571e5e9967b3c1e30cd3  nokogiri-1.18.7-aarch64-linux-musl.gem
083abb2e9ed2646860f6b481a981485a658c6064caafaa81bf1cda1bada2e9d5  nokogiri-1.18.7-arm64-darwin.gem
337d9149deb5ae01022dff7c90f97bed81715fd586aacab0c5809ef933994c5e  nokogiri-1.18.7-arm-linux-gnu.gem
97a26edcc975f780a0822aaf7f7d7427c561067c1c9ee56bd3542960f0c28a6e  nokogiri-1.18.7-arm-linux-musl.gem
6b63ff5defe48f30d1d3b3122f65255ca91df2caf5378c6e0482ce73ff46fb31  nokogiri-1.18.7.gem
2cb83666f35619ec59d24d831bf492e49cfe27b112c222330ee929737f42f2eb  nokogiri-1.18.7-java.gem
681148fbc918aa5d54933d8b48aeb9462ab708d23409797ed750af961107f72b  nokogiri-1.18.7-x64-mingw-ucrt.gem
081d1aa517454ba3415304e2ea51fe411d6a3a809490d0c4aa42799cada417b7  nokogiri-1.18.7-x86_64-darwin.gem
3a0bf946eb2defde13d760f869b61bc8b0c18875afdd3cffa96543cfa3a18005  nokogiri-1.18.7-x86_64-linux-gnu.gem
9d83f8ec1fc37a305fa835d7ee61a4f37899e6ccc6dcb05be6645fa9797605af  nokogiri-1.18.7-x86_64-linux-musl.gem

1.18.6

v1.18.6 / 2025-03-24

Fixed

  • [JRuby] In HTML documents, Node#attribute now returns the correct attribute. This has been broken, and returning nil, since v1.17.0. (#3487) @flavorjones

sha256 checksums

 
1b11f9a814068282cc2b47ebe61395b2a69d1918092d2ca3bd664074f72540e9  nokogiri-1.18.6-aarch64-linux-gnu.gem
797662f201c37a8feac3bd5b0c0e3447053bc71e6633d273fefd4c68b03e6a54  nokogiri-1.18.6-aarch64-linux-musl.gem
727a441d179d934b4b7c73e0e28e6723ee46463d96bb0cc6e2e33a13540962c4  nokogiri-1.18.6-arm64-darwin.gem
2da07a07ef4c9d9e9da809b3dc0937ed90b031e32c2c658d9918941b85d68b95  nokogiri-1.18.6-arm-linux-gnu.gem
e8ae1c9a4d8cfa7a92d632a6f596a88235ebe66d4b70418543378ba16c601f70  nokogiri-1.18.6-arm-linux-musl.gem
4d283431d7829719ea1287ca388f24c6ce343af736bbcbd1365cbdb83bce41a4  nokogiri-1.18.6.gem
bf16c53446987007ff3e1deb29d65d20444073ba112cb5bddbd2671135ba293c  nokogiri-1.18.6-java.gem
134f6d54f56edd46cb6db77c9d9de1704b3f83b3981a6763671e3cfbeba221f5  nokogiri-1.18.6-x64-mingw-ucrt.gem
fb72568c97ccd90a8d68cb765b0ff0720b109bd62e3babbf372e854ef8fef995  nokogiri-1.18.6-x86_64-darwin.gem
df065db6ba6e1e80f76ef04f860fcf260cc24685125fe33cdc3d1572a1c66b71  nokogiri-1.18.6-x86_64-linux-gnu.gem
75ec7a93cec54687aa63b2eaf830dc4ac5b4f3d8c969f20c035e67c9e6a30cef  nokogiri-1.18.6-x86_64-linux-musl.gem

Does any of this look wrong? Please let us know.

Commits

See the full diff on Github. The new version differs by more commits than we can show here.

↗️ rack (indirect, 2.2.13 → 2.2.21) · Repo · Changelog

Security Advisories 🚨

🚨 Rack has a Possible Information Disclosure Vulnerability

Summary

A possible information disclosure vulnerability existed in Rack::Sendfile when running behind a proxy that supports x-sendfile headers (such as Nginx). Specially crafted headers could cause Rack::Sendfile to miscommunicate with the proxy and trigger unintended internal requests, potentially bypassing proxy-level access restrictions.

Details

When Rack::Sendfile received untrusted x-sendfile-type or x-accel-mapping headers from a client, it would interpret them as proxy configuration directives. This could cause the middleware to send a "redirect" response to the proxy, prompting it to reissue a new internal request that was not subject to the proxy's access controls.

An attacker could exploit this by:

  1. Setting a crafted x-sendfile-type: x-accel-redirect header.
  2. Setting a crafted x-accel-mapping header.
  3. Requesting a path that qualifies for proxy-based acceleration.

Impact

Attackers could bypass proxy-enforced restrictions and access internal endpoints intended to be protected (such as administrative pages). The vulnerability did not allow arbitrary file reads but could expose sensitive application routes.

This issue only affected systems meeting all of the following conditions:

  • The application used Rack::Sendfile with a proxy that supports x-accel-redirect (e.g., Nginx).
  • The proxy did not always set or remove the x-sendfile-type and x-accel-mapping headers.
  • The application exposed an endpoint that returned a body responding to .to_path.

Mitigation

  • Upgrade to a fixed version of Rack which requires explicit configuration to enable x-accel-redirect:

    use Rack::Sendfile, "x-accel-redirect"

  • Alternatively, configure the proxy to always set or strip the headers (you should be doing this!):

    proxy_set_header x-sendfile-type x-accel-redirect;
proxy_set_header x-accel-mapping /var/www/=/files/;

  • Or in Rails applications, disable sendfile completely:

    config.action_dispatch.x_sendfile_header = nil

🚨 Rack is vulnerable to a memory-exhaustion DoS through unbounded URL-encoded body parsing

Summary

Rack::Request#POST reads the entire request body into memory for Content-Type: application/x-www-form-urlencoded, calling rack.input.read(nil) without enforcing a length or cap. Large request bodies can therefore be buffered completely into process memory before parsing, leading to denial of service (DoS) through memory exhaustion.

Details

When handling non-multipart form submissions, Rack’s request parser performs:

form_vars = get_header(RACK_INPUT).read

Since read is called with no argument, the entire request body is loaded into a Ruby String. This occurs before query parameter parsing or enforcement of any params_limit. As a result, Rack applications without an upstream body-size limit can experience unbounded memory allocation proportional to request size.

Impact

Attackers can send large application/x-www-form-urlencoded bodies to consume process memory, causing slowdowns or termination by the operating system (OOM). The effect scales linearly with request size and concurrency. Even with parsing limits configured, the issue occurs before those limits are enforced.

Mitigation

  • Update to a patched version of Rack that enforces form parameter limits using query_parser.bytesize_limit, preventing unbounded reads of application/x-www-form-urlencoded bodies.
  • Enforce strict maximum body size at the proxy or web server layer (e.g., Nginx client_max_body_size, Apache LimitRequestBody).

🚨 Rack: Multipart parser buffers large non‑file fields entirely in memory, enabling DoS (memory exhaustion)

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.

🚨 Rack's unbounded multipart preamble buffering enables DoS (memory exhaustion)

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.
  • Workarounds:
    • Limit total request body size at the proxy or web server level.
    • Monitor memory and set per-process limits to prevent OOM conditions.

🚨 Rack's multipart parser buffers unbounded per-part headers, enabling DoS (memory exhaustion)

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

🚨 Rack has an unsafe default in Rack::QueryParser allows params_limit bypass via semicolon-separated parameters

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.

🚨 Rack has an Unbounded-Parameter DoS in Rack::QueryParser

Summary

Rack::QueryParser parses query strings and application/x-www-form-urlencoded bodies into Ruby data structures without imposing any limit on the number of parameters, allowing attackers to send requests with extremely large numbers of parameters.

Details

The vulnerability arises because Rack::QueryParser iterates over each &-separated key-value pair and adds it to a Hash without enforcing an upper bound on the total number of parameters. This allows an attacker to send a single request containing hundreds of thousands (or more) of parameters, which consumes excessive memory and CPU during parsing.

Impact

An attacker can trigger denial of service by sending specifically crafted HTTP requests, which can cause memory exhaustion or pin CPU resources, stalling or crashing the Rack server. This results in full service disruption until the affected worker is restarted.

Mitigation

  • Update to a version of Rack that limits the number of parameters parsed, or
  • Use middleware to enforce a maximum query string size or parameter count, or
  • Employ a reverse proxy (such as Nginx) to limit request sizes and reject oversized query strings or bodies.

Limiting request body sizes and query string lengths at the web server or CDN level is an effective mitigation.

🚨 Rack session gets restored after deletion

Summary

When using the Rack::Session::Pool middleware, simultaneous rack requests can restore a deleted rack session, which allows the unauthenticated user to occupy that session.

Details

Rack session middleware prepares the session at the beginning of request, then saves is back to the store with possible changes applied by host rack application. This way the session becomes to be a subject of race conditions in general sense over concurrent rack requests.

Impact

When using the Rack::Session::Pool middleware, and provided the attacker can acquire a session cookie (already a major issue), the session may be restored if the attacker can trigger a long running request (within that same session) adjacent to the user logging out, in order to retain illicit access even after a user has attempted to logout.

Mitigation

  • Update to the latest version of rack, or
  • Ensure your application invalidates sessions atomically by marking them as logged out e.g., using a logged_out flag, instead of deleting them, and check this flag on every request to prevent reuse, or
  • Implement a custom session store that tracks session invalidation timestamps and refuses to accept session data if the session was invalidated after the request began.

Related

As this code was moved to rack-session in Rack 3+, see GHSA-9j94-67jr-4cqj for the equivalent advisory in rack-session (affecting Rack 3+ only).

Release Notes

2.2.21 (from changelog)

Fixed

  • Multipart parser: limit MIME header size check to the unread buffer region to avoid false multipart mime part header too large errors when previously read data accumulates in the scan buffer. (#2392, @alpaca-tc, @willnet, @krororo)

2.2.19 (from changelog)

Security

  • CVE-2025-61772 Multipart parser buffers unbounded per-part headers, enabling DoS (memory exhaustion)
  • CVE-2025-61771 Multipart parser buffers large non‑file fields entirely in memory, enabling DoS (memory exhaustion)
  • CVE-2025-61770 Unbounded multipart preamble buffering enables DoS (memory exhaustion)

2.2.16 (from changelog)

2.2.15 (from changelog)

2.2.14 (from changelog)

Security

  • CVE-2025-46727 Unbounded parameter parsing in Rack::QueryParser can lead to memory exhaustion.

Does any of this look wrong? Please let us know.

Commits

See the full diff on Github. The new version differs by more commits than we can show here.

↗️ rails-dom-testing (indirect, 2.2.0 → 2.3.0) · Repo · Changelog

Release Notes

2.3.0

What's Changed

  • Add assert_not_dom, refute_dom, assert_not_select, refute_select & refute_dom_equal by @joshuay03 in #113
  • Raise an error when given a block with a 0 element assertion by @joshuay03 in #116
  • Raise an error when provided an invalid Range, or invalid :minimum and :maximum by @joshuay03 in #115
  • assert_dom :text collapses whitespace by @jyeharry in #123

New Contributors

Full Changelog: v2.2.0...v2.3.0

Does any of this look wrong? Please let us know.

Commits

See the full diff on Github. The new version differs by more commits than we can show here.

Depfu Status

Depfu will automatically keep this PR conflict-free, as long as you don't add any commits to this branch yourself. You can also trigger a rebase manually by commenting with @depfu rebase.

All Depfu comment commands
@​depfu rebase
Rebases against your default branch and redoes this update
@​depfu recreate
Recreates this PR, overwriting any edits that you've made to it
@​depfu merge
Merges this PR once your tests are passing and conflicts are resolved
@​depfu cancel merge
Cancels automatic merging of this PR
@​depfu close
Closes this PR and deletes the branch
@​depfu reopen
Restores the branch and reopens this PR (if it's closed)
@​depfu pause
Ignores all future updates for this dependency and closes this PR
@​depfu pause [minor|major]
Ignores all future minor/major updates for this dependency and closes this PR
@​depfu resume
Future versions of this dependency will create PRs again (leaves this PR as is)

@depfu depfu bot added the depfu label Dec 11, 2025
@depfu depfu bot mentioned this pull request Dec 11, 2025
Closed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Reviewers

No reviews

Assignees

No one assigned

Labels

depfu

Projects

None yet

Milestone

No milestone

Development

Successfully merging this pull request may close these issues.

1 participant