Skip to content

🚨 [security] [ruby] Update rails 7.2.2.2 → 8.1.1 (major)#2625

Closed
depfu[bot] wants to merge 1 commit intodevelopfrom
depfu/update/group/rails-8.1.1
Closed

🚨 [security] [ruby] Update rails 7.2.2.2 → 8.1.1 (major)#2625
depfu[bot] wants to merge 1 commit intodevelopfrom
depfu/update/group/rails-8.1.1

Conversation

@depfu
Copy link
Contributor

@depfu depfu bot commented Nov 5, 2025 •
edited
Loading

🚨 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?

✳️ rails (7.2.2.2 → 8.1.1) · Repo

Release Notes

8.1.1

More info than we can show here.

8.1.0

More info than we can show here.

8.0.4

More info than we can show here.

8.0.3

More info than we can show here.

8.0.2.1

More info than we can show here.

8.0.2

More info than we can show here.

8.0.1

More info than we can show here.

8.0.0.1

More info than we can show here.

8.0.0

More info than we can show here.

7.2.3

More info than we can show here.

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.

↗️ actioncable (indirect, 7.2.2.2 → 8.1.1) · Repo · Changelog

Release Notes

8.0.1 (from changelog)

More info than we can show here.

8.0.0.1 (from changelog)

More info than we can show here.

8.0.0 (from changelog)

More info than we can show here.

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.

↗️ actionmailbox (indirect, 7.2.2.2 → 8.1.1) · Repo · Changelog

↗️ actionmailer (indirect, 7.2.2.2 → 8.1.1) · Repo · Changelog

Release Notes

8.0.1 (from changelog)

More info than we can show here.

8.0.0.1 (from changelog)

More info than we can show here.

8.0.0 (from changelog)

More info than we can show here.

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.

↗️ actionpack (indirect, 7.2.2.2 → 8.1.1) · Repo · Changelog

Security Advisories 🚨

🚨 Possible Content Security Policy bypass in Action Dispatch

There is a possible Cross Site Scripting (XSS) vulnerability in the content_security_policy helper in Action Pack.

Impact

Applications which set Content-Security-Policy (CSP) headers dynamically from untrusted user input may be vulnerable to carefully crafted inputs being able to inject new directives into the CSP. This could lead to a bypass of the CSP and its protection against XSS and other attacks.

Releases

The fixed releases are available at the normal locations.

Workarounds

Applications can avoid setting CSP headers dynamically from untrusted input, or can validate/sanitize that input.

Credits

Thanks to ryotak for the report!

Release Notes

8.0.1 (from changelog)

More info than we can show here.

8.0.0.1 (from changelog)

More info than we can show here.

8.0.0 (from changelog)

More info than we can show here.

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.

↗️ actiontext (indirect, 7.2.2.2 → 8.1.1) · Repo · Changelog

Release Notes

8.0.1 (from changelog)

More info than we can show here.

8.0.0.1 (from changelog)

More info than we can show here.

8.0.0 (from changelog)

More info than we can show here.

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.

↗️ actionview (indirect, 7.2.2.2 → 8.1.1) · Repo · Changelog

Release Notes

8.0.1 (from changelog)

More info than we can show here.

8.0.0.1 (from changelog)

More info than we can show here.

8.0.0 (from changelog)

More info than we can show here.

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.

↗️ activejob (indirect, 7.2.2.2 → 8.1.1) · Repo · Changelog

Release Notes

8.0.1 (from changelog)

More info than we can show here.

8.0.0.1 (from changelog)

More info than we can show here.

8.0.0 (from changelog)

More info than we can show here.

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.

↗️ activemodel (indirect, 7.2.2.2 → 8.1.1) · Repo · Changelog

Release Notes

8.0.1 (from changelog)

More info than we can show here.

8.0.0.1 (from changelog)

More info than we can show here.

8.0.0 (from changelog)

More info than we can show here.

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.

↗️ activerecord (indirect, 7.2.2.2 → 8.1.1) · Repo · Changelog

Security Advisories 🚨

🚨 Active Record logging vulnerable to ANSI escape injection

This vulnerability has been assigned the CVE identifier CVE-2025-55193

Impact

The ID passed to find or similar methods may be logged without escaping. If this is directly to the terminal it may include unescaped ANSI sequences.

Releases

The fixed releases are available at the normal locations.

Credits

Thanks to lio346 from Unit 515 of OPSWAT for reporting this vulnerability

Release Notes

8.0.1 (from changelog)

More info than we can show here.

8.0.0.1 (from changelog)

More info than we can show here.

8.0.0 (from changelog)

More info than we can show here.

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.

↗️ activestorage (indirect, 7.2.2.2 → 8.1.1) · Repo · Changelog

Security Advisories 🚨

🚨 Active Storage allowed transformation methods that were potentially unsafe

Active Storage attempts to prevent the use of potentially unsafe image transformation methods and parameters by default.

The default allowed list contains three methods allowing for the circumvention of the safe defaults which enables potential command injection vulnerabilities in cases where arbitrary user supplied input is accepted as valid transformation methods or parameters.

This has been assigned the CVE identifier CVE-2025-24293.

Versions Affected: >= 5.2.0
Not affected: < 5.2.0
Fixed Versions: 7.1.5.2, 7.2.2.2, 8.0.2.1

Impact

This vulnerability impacts applications that use Active Storage with the image_processing processing gem in addition to mini_magick as the image processor.

Vulnerable code will look something similar to this:

<%= image_tag blob.variant(params[:t] => params[:v]) %>

Where the transformation method or its arguments are untrusted arbitrary input.

All users running an affected release should either upgrade or use one of the workarounds immediately.

Releases

The fixed releases are available at the normal locations.

Workarounds

Consuming user supplied input for image transformation methods or their parameters is unsupported behavior and should be considered dangerous.

Strict validation of user supplied methods and parameters should be performed as well as having a strong ImageMagick security policy deployed.

Credits

Thank you lio346 from Unit 515 of OPSWAT for reporting this!

Release Notes

8.0.1 (from changelog)

More info than we can show here.

8.0.0.1 (from changelog)

More info than we can show here.

8.0.0 (from changelog)

More info than we can show here.

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.

↗️ activesupport (indirect, 7.2.2.2 → 8.1.1) · Repo · Changelog

Release Notes

8.0.1 (from changelog)

More info than we can show here.

8.0.0.1 (from changelog)

More info than we can show here.

8.0.0 (from changelog)

More info than we can show here.

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.

↗️ connection_pool (indirect, 2.5.5 → 3.0.2) · Repo · Changelog

Release Notes

3.0.2 (from changelog)

More info than we can show here.

3.0.1 (from changelog)

More info than we can show here.

3.0.0 (from changelog)

More info than we can show here.

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.

↗️ date (indirect, 3.4.1 → 3.5.0) · Repo

Commits

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

↗️ erb (indirect, 5.0.2 → 6.0.0) · Repo · Changelog

Release Notes

6.0.0

More info than we can show here.

5.1.3

More info than we can show here.

5.1.2

More info than we can show here.

5.1.1 (from changelog)

More info than we can show here.

5.1.0 (from changelog)

More info than we can show here.

5.0.3 (from changelog)

More info than we can show here.

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.

↗️ globalid (indirect, 1.2.1 → 1.3.0) · Repo · Changelog

Release Notes

1.3.0

More info than we can show here.

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.

↗️ irb (indirect, 1.15.2 → 1.15.3) · Repo

Release Notes

1.15.3

More info than we can show here.

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.

↗️ mail (indirect, 2.8.1 → 2.9.0) · Repo · Changelog

Release Notes

2.9.0

More info than we can show here.

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.

↗️ marcel (indirect, 1.0.4 → 1.1.0) · Repo

Release Notes

1.1.0

More info than we can show here.

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.

↗️ net-imap (indirect, 0.5.9 → 0.5.12) · Repo

Release Notes

0.5.12

More info than we can show here.

0.5.11

More info than we can show here.

0.5.10

More info than we can show here.

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.

↗️ nio4r (indirect, 2.7.4 → 2.7.5) · Repo · Changelog

Commits

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

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

Release Notes

1.18.10

More info than we can show here.

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.

↗️ pp (indirect, 0.6.2 → 0.6.3) · Repo

Release Notes

0.6.3

More info than we can show here.

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, 3.1.19 → 3.2.4) · 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'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: 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 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).
Release Notes

3.2.4 (from changelog)

More info than we can show here.

3.2.2 (from changelog)

More info than we can show here.

3.2.0 (from changelog)

More info than we can show here.

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.

↗️ rackup (indirect, 2.2.1 → 2.3.1) · Repo · Changelog

Commits

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

↗️ railties (indirect, 7.2.2.2 → 8.1.1) · Repo · Changelog

Release Notes

8.0.1 (from changelog)

More info than we can show here.

8.0.0.1 (from changelog)

More info than we can show here.

8.0.0 (from changelog)

More info than we can show here.

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.

↗️ rdoc (indirect, 6.14.2 → 6.17.0) · Repo · Changelog

Release Notes

6.17.0

More info than we can show here.

6.16.1

More info than we can show here.

6.16.0

More info than we can show here.

6.15.1

More info than we can show here.

6.15.0

More info than we can show here.

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.

↗️ reline (indirect, 0.6.2 → 0.6.3) · Repo

Release Notes

0.6.3

More info than we can show here.

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.

↗️ stringio (indirect, 3.1.7 → 3.1.9) · Repo · Changelog

Release Notes

3.1.9

More info than we can show here.

3.1.8

More info than we can show here.

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.

↗️ timeout (indirect, 0.4.3 → 0.5.0) · Repo

Release Notes

0.4.4

More info than we can show here.

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.

🆕 action_text-trix (added, 2.1.15)

🆕 tsort (added, 0.2.0)

🆕 uri (added, 1.1.1)

🗑️ benchmark (removed)

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 dependencies Pull requests that update a dependency file label Nov 5, 2025
@depfu depfu bot force-pushed the depfu/update/group/rails-8.1.1 branch from 7528f87 to 8fe1cf6 Compare December 8, 2025 19:15
@depfu
Copy link
Contributor Author

depfu bot commented Jan 15, 2026

Closed in favor of #2670.

@depfu depfu bot closed this Jan 15, 2026
@depfu depfu bot deleted the depfu/update/group/rails-8.1.1 branch January 15, 2026 20:47
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

dependencies Pull requests that update a dependency file

Projects

None yet

Milestone

No milestone

Development

Successfully merging this pull request may close these issues.

0 participants