Summary: CVE-2026-66066 is a critical (CVSS 9.5) arbitrary file-read
vulnerability in Ruby on Rails ActiveStorage. When an app processes untrusted
image uploads with libvips, an unauthenticated attacker can read arbitrary files
the Rails process can reach — including secret_key_base, which enables cookie
forgery and account takeover. It is fixed in Rails 7.2.3.2, 8.0.5.1, and 8.1.3.1.
Our lab reproduced a working exploit from the public advisory in 7m 29s for
$0.87.
What the vulnerability is
The vector is a crafted file upload. Rails ActiveStorage fails to disable libvips
operations marked unsafe for untrusted content, so a malicious upload can invoke
one. The impact is arbitrary local file read: environment variables,
secret_key_base, anything the Rails process can reach. With secret_key_base,
an attacker forges signed cookies and walks in as anyone. It is not SSRF — the
upload is the delivery, the file read is the payoff.
The exploit was public before the CVE
NVD published this on July 30. A working proof-of-concept had been on GitHub since July 29 — a day earlier. There are at least five public repos now, one an agent skill built to point an AI assistant at the flaw on command. For twenty-five years the gap between disclosure and a reliable exploit was where defenders lived. AI didn’t shrink that window; it inverted it. The exploit is now often older than the CVE.
“No AI-driven attacks yet” is a lagging indicator
The common objection: nobody has shown a confirmed breach driven by an AI-generated exploit, so this is hype. But an exploit carries no watermark. A crafted upload that reads your secrets looks identical whether a human or a model wrote it, so “no evidence” splits into two readings that look the same from outside: it hasn’t happened, or it has and the proof you want cannot exist. Waiting for an attributable example is waiting to be that example.
We reproduced it
We don’t hunt novel bugs. We take a published CVE and rebuild the exploit in a
clean room to answer one question with evidence instead of a severity score: does
it fire? For CVE-2026-66066 the AI harness found the path itself — ActiveStorage’s
SVG variant processing, abused with an XXE payload that points at a local file —
and read /etc/passwd back off the server:
[proof] XXE exfiltrated /etc/passwd via the ActiveStorage SVG variant
(17 passwd lines, 1122 bytes on the wire):
daemon:x:1:1:daemon:/usr/sbin:/usr/sbin/nologin
bin:x:2:2:bin:/bin:/usr/sbin/nologin
sys:x:3:3:sys:/dev:/usr/sbin/nologin
...
[+] benign evidence written: /tmp/poc-evidence/poc_marker_CVE-2026-66066
VULN_DETECTED CVE-2026-66066
[run-poc] PoC confirmed (marker written)/etc/passwd is the polite target. Swap that path for config/master.key and
the same primitive hands over your secret_key_base. The run cost 87 cents and
~81,000 tokens, in one attempt, with no human-written exploit code — against a
CVSS 9.5. That is the economics of 2026: the severity of a bug and the cost of
proving it are four orders of magnitude apart.
The fix
Upgrade Rails to 7.2.3.2, 8.0.5.1, or 8.1.3.1. If you can’t immediately, stop
routing untrusted uploads through libvips and rotate secret_key_base on the
assumption it may already have leaked.
How VRL can help
Knowing a CVE is critical is easy; knowing whether your estate has a reachable, exploitable version is the hard part. A free ai-recon scan points the agent at your domain, enumerates your exposed services and versions, then cross-references them against the Labs’ dataset of verified exploits — including this one. Not a longer findings list, a shorter one: the assets where a real exploit already exists, ranked ahead of the thousands where it doesn’t.
FAQ
Am I affected? If you use ActiveStorage, process image uploads with libvips, and accept uploads from untrusted users.
What technique did the exploit use? XXE (XML external entity injection) via the SVG image path: the crafted SVG references a local file as an external entity, and variant processing reads it back.