KindaRails2Shell abuses a file that tells two different libraries two different lies to read anything your Rails app can read — including the keys that sign its cookies.
Upload a picture to a Rails app and, behind the scenes, Active Storage almost always resizes it — that's the whole point of the feature, and it runs by default in every Rails 7 and 8 app that handles image uploads. Researchers just showed that a single crafted file can turn that resizing step into a way to read any file the Rails process has access to, including the master key that signs every cookie and session token the app issues. The bug is CVE-2026-66066, nicknamed KindaRails2Shell, and Ethiack estimates more than 500,000 sites are running an exposed version right now.
The trick: a file that lies to two libraries at once
The name of the game is format confusion. Active Storage's default image processor is libvips, and libvips will happily try to open a file that identifies itself as a MATLAB Level 5 data file — a scientific-computing format, not something you'd expect from a profile picture upload. But the same bytes, read by a different library called libmatio, identify as something else entirely: MAT 7.3, which is really just HDF5 underneath. HDF5 has a legitimate feature called External File List, meant for splitting large datasets across multiple files. A crafted MAT 7.3 file can point that External File List at any path on the server's filesystem — and libvips, trusting the chain, fetches and returns the contents.
Active Storage was supposed to stop this before it started. libvips itself flags certain operations, including this one, as unsafe for untrusted input, and the fix requires the application to explicitly disable them. Active Storage never did. Every upload endpoint using the Vips processor accepted the risky operations by default, which as of Rails 7.0 is nearly every Rails app doing image uploads at all.
Why 'file read' becomes 'remote code execution'
On its own, arbitrary file read is bad but bounded — an attacker sees what your server can see. The escalation path here is that Rails apps store some genuinely dangerous material in plain files: config/master.key, encrypted credentials, and ultimately the secret_key_base value that signs cookies, session data, and Rails' own MessageVerifier and MessageEncryptor tokens. Get that value, and an attacker can forge signed data the app will trust and deserialize — a well-documented route to remote code execution once you control what gets deserialized. Rapid7's assessment, published July 30, hadn't confirmed in-the-wild exploitation at that point, but a working proof-of-concept was already public, which is exactly why Rails moved its own disclosure timeline up.
Rails joins a growing 2026 pattern where the danger wasn't the headline software itself but a dependency several layers underneath it — see Fastjson's RCE that went unpatched for months or the network driver bug hiding inside Windows Server. The common thread: teams patch the framework they know they're running and forget the native library three layers down that the framework quietly depends on.
KindaRails2Shell at a glance
CVSS (v4)
Metric
9.5 — Critical
Sites estimated exposed
Metric
500,000+ (Ethiack estimate)
Publicly disclosed
Metric
July 29, 2026
Fixed in
Metric
Active Storage 7.2.3.2 / 8.0.5.1 / 8.1.3.1
Metric
Value
CVSS (v4)
9.5 — Critical
Sites estimated exposed
500,000+ (Ethiack estimate)
Publicly disclosed
July 29, 2026
Fixed in
Active Storage 7.2.3.2 / 8.0.5.1 / 8.1.3.1
Fixing it — and why patching Rails alone isn't enough
Upgrade Active Storage to 7.2.3.2, 8.0.5.1, or 8.1.3.1 — check your Gemfile.lock, not just your Rails version, since Active Storage ships as its own gem.
2
Update libvips itself to 8.13 or later, and ruby-vips to 2.2.1 or later — the Rails patch does nothing if the underlying libvips binary is still old.
3
Can't upgrade libvips immediately? Set the VIPS_BLOCK_UNTRUSTED environment variable, or call Vips.block_untrusted(true) in an initializer, as a stopgap.
4
Rotate secret_key_base, the Rails master key, and any credentials.yml.enc contents — assume they were read if you were running a vulnerable version with public uploads.
5
Run Rails' forensic tooling, released alongside the July 31 advisory, against your logs to check for exploitation artifacts before assuming you're clean.
The blast radius here is unusually wide because Active Storage's Vips pipeline is the default image handler for nearly every Rails 7 and 8 app. · Unsplash
Rails KindaRails2Shell: quick answers
Do I need to accept file uploads for this to affect me?
Yes, specifically image uploads processed through Active Storage's Vips variant pipeline, which is the default as of Rails 7.0. If you don't use Active Storage, or you use the MiniMagick processor instead of Vips, this specific chain doesn't apply to you.
Is Rails 6 safe?
Mostly — Rails 6.0 through 6.1.7.10 are only affected if Active Storage was explicitly configured to use Vips, which wasn't the default processor for that generation. Check your config before assuming you're clear.
Has this been exploited in the wild yet?
Rapid7 reported no confirmed in-the-wild exploitation as of its July 30 assessment, but proof-of-concept code was already circulating — which is exactly why Rails moved its full disclosure up from the planned August 28 date.
What's the single most important step if I only have time for one?
Rotate secret_key_base and your master key after patching. Even an app that's patched now but was previously vulnerable should treat those secrets as potentially burned.
My honest take: forget the CVSS number for a second. The genuinely interesting part of KindaRails2Shell is the format-confusion trick — a file simultaneously telling two different C libraries two different lies, and getting away with it because nobody told libvips to refuse unsafe operations by default. That's worth remembering past this specific patch: any pipeline that hands untrusted uploads to a native image library is worth an afternoon of checking whether 'unsafe operations' are actually disabled, not just assumed to be. If you're keeping score, that puts Rails in the same 2026 pile as vBulletin's pre-auth RCE and SharePoint's latest critical hole — different stacks, same lesson: patch the thing you didn't know was there.
