The Ruby on Rails core team disclosed CVE-2026-66066 on July 29, a critical vulnerability in Active Storage that lets an unauthenticated attacker read arbitrary files from the application server through nothing more than a crafted image upload. Researchers have nicknamed it “KindaRails2Shell.” The bug carries a CVSSv4 score of 9.5, and public write-ups and self-contained exploit labs are already circulating, even though Rapid7 says it has not yet observed exploitation in the wild as of July 30.

What happened

Active Storage, Rails’ built-in file-attachment framework, generates image variants — thumbnails, resized previews — by handing uploaded files to an image-processing backend. When an application sets config.active_storage.variant_processor = :vips, that backend is libvips, invoked through the ruby-vips bindings. The vulnerability is tracked as CWE-1188, Initialization of a Resource with an Insecure Default: Active Storage did not restrict libvips to its safe, sandboxed set of image operations before Rails 7.2.3.2/8.0.5.1/8.1.3.1, and did not require a libvips version new enough to enforce the “untrusted operation” block that vips added in 8.13.

libvips supports operations well beyond image decoding, including ones that can read arbitrary files from disk and embed their contents into the processed output (for example, via crafted image metadata or format-specific file-inclusion primitives). Because Active Storage fed attacker-controlled upload bytes straight into libvips without constraining which operations were reachable, a crafted “image” file could instruct libvips to read a file from the server’s filesystem and leak its contents back through the generated variant — no authentication, no valid session, just a public upload endpoint.

Affected versions

  • Rails 7.0.0 through 7.2.3.1
  • Rails 8.0.0 through 8.0.5
  • Rails 8.1.0 through 8.1.3
  • Rails 6.0 and 6.1 applications that explicitly configured variant_processor = :vips (not the default on those releases, but still exploitable where set)

Two conditions have to both be true for an app to be exposed: it uses libvips (rather than ImageMagick/MiniMagick) as the Active Storage variant processor, and it accepts image uploads from untrusted or unauthenticated users — a extremely common combination for avatar uploads, user-generated content, and public-facing forms.

Impact

Arbitrary file read against a Rails application process is rarely “just” a file read. The files an attacker can pull back typically include:

  • config/master.key or RAILS_MASTER_KEY, which decrypts config/credentials.yml.enc and any environment-specific encrypted credentials files
  • secret_key_base, which underlies session cookie signing/encryption and, depending on the app, can be leveraged toward deserialization-based remote code execution
  • Database connection strings and passwords, cloud storage keys (S3/GCS/Azure), third-party API tokens, and other environment variables readable by the Rails process

Rapid7’s and HeroDevs’ analyses both flag that exposing secret_key_base or the Rails master key creates a credible path to full RCE or lateral movement into connected systems — turning an information-disclosure bug into a server-takeover primitive once an attacker has the keys needed to forge signed cookies or decrypt stored secrets.

Mitigation

  1. Patch immediately. Upgrade to Active Storage-patched Rails releases 7.2.3.2, 8.0.5.1, or 8.1.3.1.
  2. Update libvips. The patch also depends on libvips 8.13 or later to enforce the untrusted-operation block; an old libvips binary undermines the Rails-side fix.
  3. Check your variant processor. If config.active_storage.variant_processor is not set to :vips, or you don’t accept untrusted image uploads, exposure is lower — but confirm rather than assume, since :vips has been the Rails default since load_defaults 7.0.
  4. Rotate secrets if you were exposed. If you ran an affected, internet-facing version with untrusted uploads enabled, treat secret_key_base, the Rails master key, database credentials, and any cloud storage keys readable by the app process as compromised and rotate them — you cannot retroactively verify whether the file-read primitive was used against you from application logs alone.
  5. Review upload-endpoint logs for anomalous or malformed image content types and unusually large or structurally unusual “image” uploads predating the patch.

References