CRITICAL: Ruby on Rails CVE-2026-66066 Exploited in the Wild

There is a particular flavor of dread that arrives when a vulnerability graduates from proof of concept on GitHub to something your customers are getting hit with right now. Ruby on Rails made that jump over the weekend.

VulnCheck logged more than fifty exploitation attempts against CVE-2026-66066 in the space of a few hours on August 30, 2026. By Monday morning the count had climbed to 360 and was still going. The flaw, which the researchers who published the full chain named KindaRails2Shell, carries a CVSS v4 score of 9.5 and hands an unauthenticated attacker the ability to read arbitrary files from the server running your Rails application. Read the right files and that file read becomes remote code execution. This is squarely in drop everything and patch it now territory, and the calm, well planned maintenance window option expired somewhere around Sunday afternoon.

What actually broke

The bug lives in Active Storage, in the seam between Rails and libvips. Rails published its advisory on July 29, 2026 and shipped fixes in 7.2.3.2, 8.0.5.1, and 8.1.3.1. Anything in Active Storage below 7.2.3.2, anything in the 8.0 line below 8.0.5.1, and anything in the 8.1 line below 8.1.3.1 is exposed. MITRE files it under CWE-1188, initialization of a resource with an insecure default, which is the standards body way of saying a library happily did something dangerous because nobody ever told it not to.

What makes this one genuinely clever, and worth understanding rather than just patching blindly, is that it is not really a single bug. It is four libraries disagreeing about what a file is.

libvips decides what kind of file it has by sniffing the first ten bytes. Start a file with the ASCII string MATLAB 5.0 and libvips is satisfied, so it passes the file along to libmatio. libmatio, though, does not care about the first ten bytes. It reads bytes 124 and 125 to determine which MAT format version it is dealing with. Set those two bytes to 0x0200 and libmatio concludes it is holding a MAT 7.3 file, which under the hood is an HDF5 container wearing a MATLAB costume. HDF5, in turn, supports external datasets, a feature that lets a dataset declare that its actual bytes live in some other file, at a path and offset written inside the container.

You can see where this goes. Point that external dataset at /proc/self/environ, or at config/master.key, or at anything else the application process can read, and HDF5 obligingly fetches the bytes, hands them back up the chain, and Rails renders them as pixels in a generated image variant. The attacker then downloads their own thumbnail and reads your environment variables out of the picture. It is an arbitrary file read dressed up as a profile photo.

Getting the file processed in the first place is depressingly easy. Rails direct upload lets a client declare a blob's content type, and by default nothing verifies that the bytes actually match the claim, so a file can announce itself as image/png without being remotely close. From there the attacker reuses a legitimate variation key harvested from the same application, applies it to their own malicious blob, and Rails does the rest.

From file read to shell

The escalation path is the part that should make you move quickly. Once an attacker can read /proc/self/environ they have your SECRET_KEY_BASE, and with SECRET_KEY_BASE they can forge signed variation parameters that Rails will trust without hesitation. The published chain forges a variation containing a JSON structure along the lines of a send instruction invoking spawn with /bin/sh and a command string, which the ImageProcessing chain builder then dutifully executes. That is unauthenticated remote code execution against a web application from nothing more than an image upload endpoint.

The same file read also gives up the Rails master key, database passwords, cloud storage credentials, and any API tokens sitting in the process environment. Even if you patch before anyone bothers to build the second stage, everything that lived in that environment during the exposure window should be treated as burned.

Who is actually vulnerable

Two conditions have to hold. The application has to use libvips as its Active Storage image processor, and it has to accept image uploads from users you do not fully trust. The catch is that vips became the default variant processor in Rails 7, so a very large number of applications satisfy the first condition without anyone having made a conscious decision about it. Researchers counted roughly 7,100 exposed and vulnerable Rails instances in early August, and that is only the population facing the public internet in a way that is easy to fingerprint. The real number is larger, and a good chunk of it is sitting behind your clients' login pages.

Rails also cannot fix this alone. The patch works by disabling untrusted libvips operations during initialization, and that mechanism requires libvips 8.13 or newer along with ruby-vips 2.2.1 or newer. Older libvips builds simply cannot turn those operations off. That means a Rails upgrade layered on top of a stale base image can leave you patched on paper and thoroughly vulnerable in practice. Check the native library version, not just the gem version.

What exploitation looks like right now

VulnCheck's canary infrastructure caught the initial wave on August 30, with source traffic arriving primarily from Russia and France and landing on canaries in the United Kingdom, Singapore, and Israel. The activity is a blend of reconnaissance and straightforward credential theft rather than anything especially subtle. Nobody is being careful, because nobody needs to be.

The same wave is also hitting Langflow through CVE-2026-0768, a CVSS 9.8 input validation failure that allows arbitrary Python execution as the root user, which tells you the operators behind this are simply working a list of high value pre authentication bugs. Attacker requests have been observed querying environment variables including LANGFLOW_SUPERUSER, anything matching OPENAI_API, and anything matching AWS_ACCESS or AWS_SECRET. They read the cached Langflow secret key, check whether the SSH directory is accessible, and measure the size of bash history files, which is a useful reminder that your shell history is reconnaissance material for somebody.

Post exploitation activity has included Python credential harvesters, proxy agents that quietly turn victim hosts into someone else's infrastructure, SimpleHelp remote access software installed for durable access, and the inevitable Monero miners. At least one incident involved the attacker disabling auditd before doing anything else, which is a detection opportunity in itself. An audit daemon stopping on a production application server at three in the morning is not routine maintenance.

Patching and detection

Upgrade Active Storage to 7.2.3.2, 8.0.5.1, or 8.1.3.1 depending on your branch, and verify that libvips is at 8.13 or newer with ruby-vips at 2.2.1 or newer on every host and container image that touches uploads. If you cannot patch immediately, the practical stopgap is to stop handing untrusted uploads to vips at all, either by switching the variant processor or by validating uploaded bytes server side against real magic numbers instead of trusting a client declared content type.

Assume compromise if you were exposed and internet reachable during the past several days. Rotate secret_key_base, the Rails master key, database credentials, object storage keys, and every API token that lived in the application environment. Rotating secret_key_base invalidates existing sessions and signed cookies, which is an inconvenience worth approximately nothing compared to leaving a forgeable signing key in the hands of someone who already has a copy.

For detection, look for blobs uploaded with an image content type whose bytes do not parse as that image type, variation keys appearing against blob identifiers they were never issued for, and variant generation requests that produce oddly shaped output. On the host side, watch for outbound connections from application servers to destinations that have no business receiving traffic, new SimpleHelp or similar remote access installations, logging services stopping unexpectedly, and reads of /proc/self/environ by the application user. Web application firewall rules matching the MATLAB 5.0 magic string in upload bodies will catch the unimaginative attempts, though signature matching on a file format this flexible is a speed bump rather than a wall.

If you run Langflow anywhere, and a surprising number of organizations do without their security team knowing about it, treat that as a parallel emergency. It has been a favorite target for well over a year now, with attackers exploiting at least a dozen distinct Langflow vulnerabilities since 2025.

The MSP angle

Every client running a Rails application with user uploads is a conversation this week, and it is a conversation that sells itself, because the exploitation counts are public and climbing. Lead with a rapid dependency and native library audit as a fixed fee engagement, since the libvips version gap is precisely the sort of thing internal teams miss when they bump the gem, watch the tests pass, and declare victory. The follow on work is where the recurring revenue lives. Credential rotation runbooks, egress monitoring on application servers, and continuous external attack surface discovery are all far easier to justify while a customer is still absorbing the fact that an image upload form can hand a stranger their AWS keys.