Ruby on Rails runs a significant share of the modern web, and Active Storage, Rails’ built-in file attachment and image-processing framework, is enabled by default in a large number of production applications.

A critical vulnerability has been found in those components that can lead to remote code execution (RCE). For more info check, the Ruby on Rails official advisory: https://github.com/rails/rails/security/advisories/GHSA-xr9x-r78c-5hrm

The vulnerability was first independently discovered and reported by André Baptista (0xacb), Bruno Mendes (S3np41k1r1t0) and Rafael Castilho (Castilho) of the Ethiack research team, and it was also reported a few days later by RyotaK of GMO Flatt Security’s research team. We then worked together to coordinate the disclosure and fixes.

Summary

• Active Storage + the default vips processor is necessary but not sufficient on its own. You're exposed if your app also accepts image uploads from untrusted users, on default Rails 7.x/8.x; 6.x only if you've customized Active Storage and accept untrusted image uploads.
• No PoC or technical chain details from us yet, but assume attackers with AI tooling can reconstruct one quickly once patches ship and diffs go public, so don't wait to upgrade.
• Patching Rails alone isn't sufficient if your libvips is older than 8.13, that's a separate upgrade.
• A WAF might buy you some time in specific setups, but it's not a fix.

Introduction

Inspired by wp2shell, our research team followed up on some prior leads and found an arbitrary file read and remote code execution chain affecting default Rails applications that use Active Storage with the vips image processor, which is the processor that ships by default in the official Rails Docker images and on Debian/Ubuntu.

We named it KindaRails2Shell, because we found a rails2shell… kinda. There are several requirements involved: some are default behavior, some are just very common configurations, and in certain scenarios no authentication is required at all. This article aims at providing an initial limited overview of the vulnerability and how to mitigate it.

Affected

Rails 6.0.0 through 6.1.7.10 may be affected only if Active Storage has been set up outside its defaults, so a normal 6.x install isn't exposed to this vulnerability. Rails 7.0.0 through 7.2.3.1 and 8.0.0 through 8.1.3 don't have that requirement.

Only the Vips image processor is affected. Applications using Magick are not affected by this vector.

An application is affected only if it meets all of the following:

• Uses libvips for Active Storage image processing
• Allows image uploads from untrusted users via features or direct uploads
• Runs a libvips build linked against certain third-party libraries

Please note that any user-facing feature that accepts an image upload and later serves back a processed version (avatars, thumbnails, profile pictures) may also be affected by this vulnerability. Multiple projects and 3rd party software that use Ruby on Rails may also be affected.

Impact

• Arbitrary file read as the user running the worker or process
• Remote code execution and lateral movement to other systems

We are holding further technical details about the chain at this moment to allow users more time to patch.

Remediation

Upgrading is the fix that actually matters here: move to Rails 7.2.3.2, 8.0.5.1, or 8.1.3.1 (or later). If you're on an affected version, patch as soon as you can, this holds regardless of how your specific setup is configured.

Note that the fix depends on libvips itself being version 8.13 or later, earlier libvips builds can't disable the unsafe operations involved at all, and Active Storage will raise an exception on boot in that case. If you're on libvips < 8.13, upgrading active storage alone won't be enough, you'll need to upgrade libvips too, or remove the dependency if your application only used it for image analysis.

A WAF can help in some deployments, but its usefulness varies a lot depending on where your app stores Active Storage files and how uploads reach it. Don't treat it as a patch.

There's also a stopgap if you can't upgrade immediately: on libvips 8.13+, setting the VIPS_BLOCK_UNTRUSTED environment variable will block the exploitation of this vulnerability. If you're instead pinned to ruby-vips 2.2.1 or newer, calling Vips.block_untrusted(true) from an initializer also prevents this.

Disclosure Timeline

We are withholding technical details, PoC, and the RCE details at the moment to give users a reasonable window to patch. We are coordinating with the affected upstream projects, and a write-up will follow once patches are broadly available and applied.

Acknowledgments

Thanks to RyotaK from GMO Flatt Security for their independent discovery and close collaboration on this disclosure(you also can check their post here), and to the Rails maintainers, especially Mike Dalessio (flavorjones), and the Libvips maintainers, for their help and quick response in getting a fix shipped.