Rails Active Storage RCE: CVE-2026-66066 Explained

An image upload should not be able to read your database password. A newly disclosed vulnerability in Ruby on Rails means that, for a wide range of applications, it could. Tracked as CVE-2026-66066 and rated CVSS 9.5, the flaw sits in Active Storage — the built-in Rails subsystem that handles file uploads and image processing — when it is paired with the popular libvips image library. Dubbed “KindaRails2Shell” by the researchers who dug into it, the bug lets an unauthenticated attacker upload a crafted image and read arbitrary files from the server, with a plausible path to full remote code execution.

The Rails team published the advisory and patched releases on July 29, 2026. For anyone running a Rails app that accepts image uploads, this is a patch-now item.

What the flaw is

Active Storage generates variants of uploaded images — thumbnails, resized versions, format conversions — by handing the file to an image-processing backend. Rails supports two: the older MiniMagick (ImageMagick) and the faster, increasingly default libvips. The vulnerability is specific to the libvips path.

The root cause is an insecure default (formally, CWE-1188, “initialization of a resource with an insecure default”). When Active Storage invokes libvips to build a variant, it does not disable the libvips operations that are marked unsafe for untrusted content. libvips can do far more than resize a picture — some of its loaders and operators can read external files, follow references embedded in an image, or execute functionality that was never meant to run on attacker-supplied input. Because Active Storage left those operations enabled, a specially crafted upload can invoke one of them.

The immediate consequence is arbitrary file read. An attacker who can upload an image to a vulnerable app may be able to coax the server into reading files off its own filesystem — including the process environment. In a typical Rails deployment, that environment holds secret_key_base (which underpins session integrity and signed cookies) along with credentials for the database, cloud storage, and third-party services. Leak secret_key_base and an attacker can forge signed and encrypted data; leak database and cloud credentials and the blast radius expands to everything those keys unlock. From there, the researchers note, a path to remote code execution opens up — which is why the “shell” in KindaRails2Shell is not hyperbole.

Crucially, no authentication is required. Any endpoint that accepts an image upload from the public — an avatar, a profile photo, a document attachment, a support-ticket screenshot — is a candidate entry point. That combination of unauthenticated access, a ubiquitous framework, and secrets exposure is what earns the 9.5 score.

What’s affected

The vulnerability affects Active Storage in applications that use libvips for image processing. Per the advisory, the impacted version ranges are:

• Active Storage before 7.2.3.2
• 8.0.x before 8.0.5.1
• 8.1.x before 8.1.3.1

If your app processes image variants through MiniMagick/ImageMagick instead of libvips, this particular flaw does not apply — though that backend has its own long history of image-parsing issues and is not a security recommendation in itself.

How to fix it

Upgrade. The fix that matters is moving to a patched release: Rails 7.2.3.2, 8.0.5.1, or 8.1.3.1 (or later). The patched Active Storage disables the unsafe libvips operations by default, closing the crafted-upload path.

There is an important dependency wrinkle. The fix relies on libvips being version 8.13 or later — earlier libvips builds simply cannot disable the unsafe operations involved. To avoid running in a state that only looks patched, the updated Active Storage will raise an exception on boot if it detects a libvips version too old to enforce the protection. That fail-loud behavior is deliberate: a security fix that silently no-ops on old dependencies is worse than no fix at all, because it hands operators false confidence. Check both your Rails version and your system libvips version.

If you cannot upgrade immediately, the pragmatic interim mitigations are the usual defense-in-depth measures: restrict or validate the file types your upload endpoints accept, consider processing images in an isolated or sandboxed worker rather than the app process, and rotate any secrets that may have been exposed if you find evidence of exploitation. None of these substitutes for the patch — they narrow the window.

How to tell if you’re exposed

Two checks settle most of the question. First, confirm your Rails version — bundle list rails or the lockfile tells you whether you are on a patched Active Storage release. Second, confirm your image backend and libvips version: apps that set config.active_storage.variant_processor = :vips (increasingly the default) are on the affected path, and the system vips --version must be 8.13 or later for the fix to take effect. If you process variants at all — avatars, thumbnails, previews — assume the endpoint is reachable until proven otherwise.

For detection after the fact, review upload-handling logs for malformed or unusual image files, unexpected errors from the variant processor, and any application error that references file paths outside the expected upload directory. Because successful exploitation reads files rather than crashing the app, it can be quiet — absence of obvious errors is not evidence of safety. If the app has been internet-facing and unpatched, treat exposed secrets as potentially compromised and rotate them regardless of whether you find a smoking gun.

Why this keeps happening

CVE-2026-66066 fits a pattern this year’s advisories keep repeating: a convenience feature meant for trusted input becomes a compromise path once it meets untrusted input. It is the same shape as the Adobe ColdFusion RDS flaw, where a developer-facing service exposed to the network turned into unauthenticated RCE, and the WordPress core RCE that turned a routine content-management path into code execution. In each case the dangerous capability was already present; the vulnerability was leaving it reachable by default.

Image processing is a particularly rich target because parsers are complex, formats are numerous, and libraries like libvips and ImageMagick expose powerful operators that predate today’s threat model. Feeding attacker-controlled bytes into that machinery has produced a long line of file-read and code-execution bugs. The lesson threat modelers keep drawing — see our guide to threat modeling — is that any place where external input crosses into a powerful subsystem deserves an explicit “assume hostile” boundary. An avatar uploader is not a benign feature; it is an untrusted-data pipeline into a native image library.

What it means

For the Rails ecosystem, CVE-2026-66066 is a high-priority, low-drama fix: the patch is available, the affected versions are clearly bounded, and the remediation is a version bump plus a dependency check. The urgency comes from how ordinary the vulnerable pattern is — image uploads through Active Storage and libvips describe an enormous number of production Rails apps, many run by small teams without a dedicated security function.

• Who’s exposed: any internet-facing Rails app on an unpatched Active Storage version that uses libvips and accepts image uploads. The more public upload endpoints an app has, the more reachable it is.
• The real danger is secrets, not just files. Arbitrary file read that reaches secret_key_base and service credentials is not a contained information leak — it is the seed of session forgery, lateral movement, and the RCE the nickname promises. Teams that patch should also rotate exposed secrets if they cannot rule out prior exploitation.
• What to watch next: public proof-of-concept exploits and scanning activity — the ColdFusion timeline showed attackers weaponizing a critical flaw within hours of disclosure, and a bug this reachable in a framework this common will draw the same attention. Expect opportunistic scanning for vulnerable upload endpoints to ramp quickly.

The action item is simple and short: confirm your Rails and libvips versions, upgrade to a patched Active Storage release, and rotate secrets if you have any doubt. An avatar uploader should never be able to read your environment file — CVE-2026-66066 is the reminder that, until you patch, it might.