CVE-2026-66066 (Rails Active Storage) — the withheld attack chain is public four weeks early, and Rails has shipped forensic tooling to answer 'was I exploited?'
UPDATE · originally covered CVE-2026-66066 — Ruby on Rails Active Storage: an unauthenticated image upload reaches arbitrary file read through libvips' unfuzzed loaders, exposing every application secret (CVSS 4.0 9.5) (2026-07-31)
The disclosure timetable this entry's predecessor described has collapsed. Rails shipped the CVE-2026-66066 fixes on 2026-07-29 while deliberately withholding the exploitation mechanics — the security team "held back details about the attack vector to allow applications to be upgraded before malicious attackers could take advantage of the vulnerability" — and intended to publish them no later than 2026-08-28. On 2026-07-31 it abandoned that plan, stating that "several researchers quickly reverse-engineered the attack and have already published proofs-of-concept" (Ruby on Rails security team, 2026-07-31). The four-week grace period the prior coverage described as the defender's buffer no longer exists.
Rather than publish prose alone, the team released a repository — rails/rails-forensics-CVE-2026-66066 — containing four things a responder can use directly: a step-by-step walkthrough of the attack from the incoming request to the file being read, a guide to what evidence the attack leaves in the application database and object store, and, explicitly, what that evidence does and does not prove; plus two artifacts the team calls "agent skill"s rather than scripts, one that "works out whether your application was ever vulnerable, and if it was, over what period of time" and one that "searches your Active Storage data for the crafted files, and works out what was read if it finds any" (Ruby on Rails security team, 2026-07-31). The distinction matters operationally: these are skills intended to be driven by an AI coding agent, not standalone command-line tools. The post's author, writing as a member of the Rails security team, states the material was "extracted from work I did at 37signals to perform a forensic analysis on our own apps" — that is, it comes out of one company's real incident response rather than being written for the advisory. Nothing about the vulnerable versions or the preconditions changed: activestorage below 7.2.3.2, 8.0.5.1 and 8.1.3.1 remain affected where the application uses the libvips variant processor and accepts image uploads from untrusted users, and the fix is only effective on libvips 8.13 or newer (Ruby on Rails GHSA, 2026-07-29).
One in-window operational signal accompanies the announcement, and it should be read carefully. A maintainer of the Discourse forum platform replied in the same thread on 2026-08-01 that Discourse has "noticed an increase in this style of attack" and described the defence-in-depth work it shipped that week — moving image processing out of high-privilege processes using Linux Landlock sandboxing, with the stated design goal that an image-resizing process should be able to write to one location rather than hold write access to the whole filesystem (Discourse maintainer reply on Ruby on Rails Discussions, 2026-08-01). That observation is about the class of attack against image-processing libraries, not about CVE-2026-66066 specifically — the same reply states Discourse currently uses ImageMagick with an allowed-coder list and is only now porting to libvips, so it is not describing exploitation of this Rails flaw (Discourse maintainer reply on Ruby on Rails Discussions, 2026-08-01).
we held back details about the attack vector to allow applications to be upgraded before malicious attackers could take advantage of the vulnerability.
We originally intended to publish these details no later than 2026-08-28, but several researchers quickly reverse-engineered the attack and have already published proofs-of-concept.
Defender actions
- Run the kr2s-was-i-vulnerable and kr2s-was-i-exploited agent skills from the rails/rails-forensics-CVE-2026-66066 repository against every Rails application configured with the libvips variant processor that accepted untrusted image uploads before it reached activestorage 7.2.3.2 / 8.0.5.1 / 8.1.3.1 on libvips >= 8.13, and for any application the exploited skill flags rotate secret_key_base, the master key and every credential reachable through credentials.yml.enc — storage and database credentials and third-party tokens included — because the patch does not invalidate a secret that was already read.
ATT&CK mapping
3 techniques mapped from the cited reporting · MITRE ATT&CK v19.1
Initial Access TA0001
T1190Exploit Public-Facing Application
Adversaries may attempt to exploit a weakness in an Internet-facing host or system to initially access a network. The weakness in the system can be a software bug, a temporary glitch, or a misconfiguration.
Credential Access TA0006
T1552.001Unsecured Credentials: Credentials In Files
Adversaries may search local file systems and remote file shares for files containing insecurely stored credentials. These can be files created by users to store their own credentials, shared credential stores for a group of individuals, configuration files containing passwords for a system or service, or source code/binary files containing embedded passwords.
Collection TA0009
T1005Data from Local System
Adversaries may search local system sources, such as file systems, configuration files, local databases, virtual machine files, or process memory, to find files of interest and sensitive data prior to Exfiltration.
Update chain
AI-generated · no human review · this permalink is the shareable record for the finding · verify operationally critical claims against the linked primary source.