Rails Patches Critical Active Storage Flaw That Lets Unauthenticated Attackers Read Secrets and Escalate to RCE
CVE-2026-66066 lets attackers upload a crafted image to steal a Rails app's secret_key_base and escalate to remote code execution.
Overview
Rails maintainers have patched a critical vulnerability in Active Storage, the framework’s built-in file-attachment component, that can let an unauthenticated attacker read arbitrary files from a vulnerable application — including secrets that can be used to escalate to full remote code execution. The flaw, tracked as CVE-2026-66066, was published as a critical-severity GitHub Security Advisory by Rails maintainer byroot on July 29, 2026, and covered the following weekend by BleepingComputer.
What We Know
Active Storage is the built-in Rails component for handling file uploads and attachments, and it can generate image thumbnails using processing libraries such as libvips or ImageMagick, according to BleepingComputer. The vulnerability is exploitable specifically when libvips is used: according to the GitHub Security Advisory, libvips reads and writes file formats through operations it internally marks as “unfuzzed,” meaning they are unsafe for untrusted content, and Active Storage did not disable those operations. An attacker who can upload a crafted file and cause a variant to be generated from it may be able to invoke one of them and read arbitrary files on the server.
Two conditions have to be met for an application to be exposed. According to the advisory, an app must use libvips for Active Storage image processing — the default since Rails set load_defaults 7.0 — and it must allow image uploads from untrusted users. If both hold, BleepingComputer reports an attacker may access app files including the process environment, “which typically contains ‘secret_key_base’ and credentials for databases, cloud storage, and other services.” Akamai’s Security Intelligence Group, which has also published research on the flaw, put it similarly: the exposure reaches “the secret_key_base, cloud storage credentials, and database passwords,” according to Akamai.
The secret_key_base is what turns a file-read bug into remote code execution. “With the secret_key_base compromised, the attacker holds the master cryptographic key to the application,” Akamai explains. “They can forge session cookies, sign global IDs, and manipulate serialized data, which directly translates into full RCE on the underlying server,” according to Akamai.
CVE-2026-66066 affects Active Storage before 7.2.3.2, versions 8.0.x before 8.0.5.1, and 8.1.x before 8.1.3.1, according to the GitHub Security Advisory, which also lists a CVSS 4.0 vector of AV:N/AC:L/AT:P/PR:N/UI:N/VC:H/VI:H/VA:H/SC:H/SI:H/SA:H and classifies the underlying weakness as CWE-1188, initialization of a resource with an insecure default. Rails 6.x is affected only if Active Storage has been configured outside its defaults, BleepingComputer reports. Applications using ImageMagick instead of libvips are not affected by this attack vector, but libvips is the default processor in the official Rails Docker images as well as on Debian and Ubuntu, according to BleepingComputer.
The flaw was independently discovered twice. Ethiack’s research team — André Baptista, Bruno Mendes, and Rafael Castilho — first found and reported it, and RyotaK of GMO Flatt Security’s research team reported it separately a few days later; the two teams then coordinated disclosure and fixes with Rails maintainers, according to Ethiack. Ethiack named the bug “KindaRails2Shell,” writing that “we found a rails2shell… kinda,” according to Ethiack. Akamai adopted the same name in its own advisory, “CVE-2026-66066: Defending Against the ‘KindaRails2Shell’ Pre-Auth RCE,” and rated the flaw a CVSS score of 9.5, critical.
Rails maintainers initially withheld full technical details, planning to disclose them on the Rails forums on August 28, but moved up the release after public proof-of-concept exploits appeared quickly, publishing full details along with forensic investigation tooling, according to BleepingComputer. Ethiack cautioned that even without a public write-up, “assume attackers with AI tooling can reconstruct one quickly once patches ship and diffs go public,” according to Ethiack.
Remediation
The Rails team’s core recommendation is to upgrade to a patched activestorage version and separately ensure libvips is at version 8.13 or later, then rotate secret_key_base along with database, cloud-storage, and any other credentials accessible to the application process, according to the GitHub Security Advisory. For systems already on libvips 8.13 or newer, administrators can disable the vulnerable functionality without a full upgrade by setting the VIPS_BLOCK_UNTRUSTED environment variable, or by calling Vips.block_untrusted(true) when using ruby-vips 2.2.1 or newer, BleepingComputer reports. No workaround exists for applications still running libvips older than 8.13, according to BleepingComputer and the advisory.
Akamai says it coordinated with Ethiack ahead of public disclosure and, on July 29, 2026, deployed a new web application firewall rule — “3000989 v1 — Rails2Shell Exploit Attempt Detected (CVE-2026-66066)” — for its App & API Protector customers, according to Akamai. Ethiack, however, cautioned that a WAF “might buy admins some time” but is not a substitute for patching, since attackers can likely reconstruct the exploit chain from the published patch diffs, according to BleepingComputer.
What We Don’t Know
Neither the advisory nor the researchers who disclosed the flaw have published a count of how many production applications remain unpatched or whether the vulnerability has been exploited in the wild beyond the proof-of-concept exploits that circulated publicly. Rails maintainers had planned to hold back full technical detail until August 28 specifically to give administrators time to patch before a chain was public; that timeline was compressed once PoC code appeared, but the sources reviewed do not specify how quickly the PoCs surfaced after the July 29 advisory.