Reported by 7 outlets
Ruby on Rails Active Storage Flaw (CVE-2026-66066, CVSS 9.5): Unauthenticated Server File Read via Image Uploads
Why this score
- Breadth
- 2.00 / 2.0 · 7 sources
- Authority
- 1.80 / 2.0 · best outlet weight
- Severity
- 4.90 / 5.0 · CVSS + content signals
- Velocity
- 0.00 / 2.0 · updates in 48h
- Pickup speed
- 0.22 / 0.6 · time to second source
- Recency
- × 0.00 temporal multiplier
- Community
- + 0.00 / 1.5 · reddit signal
- Score
- 0.0 / 10 = base × recency + community
Desk analysis
CVE-2026-66066 (GHSA-xr9x-r78c-5hrm, CVSS v4 9.5) is an unauthenticated arbitrary file read in Rails Active Storage variant processing, patched in emergency releases 7.2.3.2, 8.0.5.1 and 8.1.3.1 on July 30, 2026. The defect is a double trust failure: Active Storage trusts a database-stored, attacker-controlled content_type to gate image processing while libvips picks its parser from file bytes, and the unfuzzed MAT loader, whose sniffer keys on a 10-byte MATLAB 5.0 prefix that disagrees with libmatio's version field at bytes 124 and 125, converts that mismatch into a read of any file the Rails worker can open, including /proc/self/environ. Default Rails 7.0 through 8.1.3 running libvips is exposed, Rails 6.x only where Active Storage is configured outside defaults, ImageMagick setups are not affected by this vector, and Rails 7.0 and 7.1 are EOL with no backport. Ethiack (0xacb, s3np41k1r1t0, castilho) and RyotaK of GMO Flatt Security found it independently and coordinated the July 29 and 30 disclosure with the Rails maintainers.
The read does not require secret_key_base: Rapid7 showed a genuine signed variation_key replayed against a new direct-upload blob bypasses signing entirely, so any reachable app that accepts image uploads is exposed regardless of how well its secrets are guarded. Escalation is then mechanical: secret_key_base recovered from /proc/self/environ forges sessions and signs Global IDs (Akamai's KindaRails2Shell chain), and Rapid7 validated code execution reaching Kernel#spawn and Kernel#eval when message_serializer is :json. The reporting carries no confirmed in-the-wild exploitation, but Rapid7 shipped a Metasploit module, exploit/multi/http/rails_activestorage_vips_rce, on August 3, which drops the skill floor to zero and means exposure alone now defines risk. The blast radius is the cloud context, not the host: one read harvests config/master.key, decrypted credentials.yml.enc contents, database passwords and S3, GCS or Azure storage keys, so a single unpatched app can hand over its storage account and everything sharing it. The disclosure timeline is itself the warning: details were scheduled for August 28, public PoCs appeared within days of the July 30 advisory and forced early release, so patch cycles measured in weeks arrive after the exploit does.
Upgrade to Rails 7.2.3.2, 8.0.5.1 or 8.1.3.1 and verify the host libvips is 8.13 or newer; below libvips 8.13 there is no workaround and patched Active Storage raises on boot, so the gem bump and the system library upgrade must land together, or drop ruby-vips from the Gemfile where it exists only for image analysis. Where upgrade lags, set VIPS_BLOCK_UNTRUSTED (libvips 8.13+) or call Vips.block_untrusted(true) from an initializer (ruby-vips 2.2.1+), and treat Akamai's released WAF protections as delay, not fix. Rotate every secret the Rails process can read: secret_key_base, the master key in config/master.key or RAILS_MASTER_KEY plus everything it decrypts, database credentials, S3, GCS and Azure keys, and third-party tokens; changing secret_key_base expires sessions and signed URLs, and the effective rotation deadline is July 30, not the day you patch. Hunt the Rails application log for direct-upload blobs whose stored content_type claims an image type but whose body starts with the MATLAB 5.0 prefix, for variant requests replaying a variation_key against a blob they did not create, and for reads resolving to /proc/self/environ, config/master.key or credentials paths through variant endpoints.
Two developments would change the assessment. Confirmed exploitation, a CISA KEV listing or scanner telemetry at scale would turn this from urgent patching into incident response for every app unpatched since July 30. The longer-term risk is the long tail: Rails 7.0 and 7.1 get no fix, 6.x non-default configurations are easy to miss in inventory, and the maintainers explicitly cautioned the reported chain may not be the only one, so permanently vulnerable installs and any second independent chain are what to watch.
Timeline
-
original reporting
Ruby on Rails Active Storage Flaw (CVE-2026-66066, CVSS 9.5): Unauthenticated Server File Read via Image Uploads
socprime.com · 75d ago · July 31st, 2026
Ruby on Rails released emergency fixes for CVE-2026-66066, a critical Active Storage vulnerability letting an unauthenticated attacker read arbitrary files from the application server through crafted image uploads — potentially escalating to RCE and lateral movement.
Root cause: Active Storage passes uploaded attachments to libvips (default processor since Rails 7.0) without blocking "untrusted" operations — unsafe libvips loaders can be invoked by a malicious file to disclose data readable by the Rails worker.
Exposure: secret_key_base,
config/master.key, decrypted credentials, database passwords, cloud storage keys (S3/GCS/Azure), and third-party API tokens. Obtaining secret_key_base can enable session forgery and, with gadget chains, code execution. Affects Rails 7.0–7.2.3.1, 8.0–8.0.5, 8.1–8.1.3 using libvips with untrusted uploads. No known in-the-wild exploitation; a third-party PoC claiming an arbitrary-file-read-to-RCE chain appeared shortly after disclosure. Rails 7.0/7.1 are EOL and get no backport.Action: Upgrade to Rails 7.2.3.2 / 8.0.5.1 / 8.1.3.1 with libvips 8.13+ (or ruby-vips 2.2.1+); interim: set
VIPS_BLOCK_UNTRUSTED. Rotate every secret readable by the Rails process — updating the code does not invalidate already-disclosed credentials. -
update from ethiack.com
KindaRails2Shell - Critical RCE in Rails via Active Storage (CVE-2026-66066) - Ethiack original research disclosure
ethiack.com · 77d ago · July 29th, 2026
Ethiack researchers André Baptista (0xacb), Bruno Mendes (s3np41k1r1t0) and Rafael Castilho published the original disclosure overview of KindaRails2Shell on July 29, 2026, an arbitrary file read and RCE chain in Rails Active Storage with the default vips processor, found independently of RyotaK at GMO Flatt Security who reported it days later. The post lists affected ranges (Rails 6.0.0 to 6.1.7.10 in non-default Active Storage setups, 7.0.0 to 7.2.3.1, 8.0.0 to 8.0.5, 8.1.0 to 8.1.3), notes ImageMagick users are not affected by this vector, and states technical details and PoC were withheld to allow patching. It directs readers to the official Rails advisory and recommends upgrading to 7.2.3.2, 8.0.5.1 or 8.1.3.1, libvips 8.13 or newer, VIPS_BLOCK_UNTRUSTED as a stopgap, and treating WAF rules as time-buying rather than a fix.
-
update from flatt.tech
Overview and response guidance for the critical Rails vulnerability KindaRails2Shell (CVE-2026-66066) - GMO Flatt Security (RyotaK)
flatt.tech · 76d ago · July 30th, 2026
The post concludes the chain does not trigger on a fully default install but does on common configurations, that Rails arbitrary file read can escalate to remote code execution by multiple methods, and that PoC publication was withheld because pre-validation suggested AI-assisted tooling could rebuild one within hours. Mitigation guidance: upgrade Rails, ensure libvips 8.13+ with VIPS_BLOCK_UNTRUSTED, call Vips.block_untrusted(true) on ruby-vips 2.2.1+, and do not substitute WAF rules for the patch.
-
update from github.com
Possible arbitrary file read and remote code execution in Active Storage variant processing (GHSA-xr9x-r78c-5hrm) - official Rails advisory
github.com · 75d ago · July 30th, 2026
Affected versions are activestorage < 7.2.3.2, >= 8.0 < 8.0.5.1 and >= 8.1 < 8.1.3.1, with fixes in 7.2.3.2, 8.0.5.1 and 8.1.3.1 requiring libvips >= 8.13; below libvips 8.13 no workaround exists and Active Storage raises on boot.
-
update from bleepingcomputer.com
Rails Active Storage CVE-2026-66066: Public PoCs Force Early Full Disclosure; Akamai Names Chain "KindaRails2Shell"
bleepingcomputer.com · 73d ago · August 2nd, 2026
Disclosure analysis covered Jul 31 (SOC Prime). New today: Rails maintainers publish the official advisory and early full technical details, Akamai names the RCE chain and ships WAF protections.
Rails maintainers published the official advisory (GHSA-xr9x-r78c-5hrm) for CVE-2026-66066 (critical, CVSS 9.5) — an unauthenticated arbitrary file read in Active Storage via crafted image uploads processed by libvips, potentially escalating to RCE. New material since yesterday's coverage:
- Early disclosure: Technical details were initially withheld and scheduled for release August 28 on the Rails forums; because public PoC exploits appeared within days, maintainers released the full details plus forensic investigation tooling early. - Discovery credit: Ethiack and GMO Flatt Security Inc. (responsible disclosure). - Akamai "KindaRails2Shell": Akamai published its own warning, naming the chain KindaRails2Shell — with
secret_key_basein hand, an attacker can forge session cookies, sign Global IDs, and manipulate serialized data for full RCE on the server. - Affected scope clarified: Active Storage before 7.2.3.2, 8.0.x before 8.0.5.1, 8.1.x before 8.1.3.1; Rails 6.x only if Active Storage is configured outside defaults; ImageMagick users are not affected by this vector. libvips is the default processor in official Rails Docker images and Debian/Ubuntu setups. Ethiack notes a WAF "might buy admins some time," but AI tooling can reconstruct the attack chain from patch diffs — patch and rotate secrets now. No confirmed in-the-wild exploitation as of digest time.
- Early disclosure: Technical details were initially withheld and scheduled for release August 28 on the Rails forums; because public PoC exploits appeared within days, maintainers released the full details plus forensic investigation tooling early. - Discovery credit: Ethiack and GMO Flatt Security Inc. (responsible disclosure). - Akamai "KindaRails2Shell": Akamai published its own warning, naming the chain KindaRails2Shell — with
-
update from rapid7.com
KindaRails2Shell (CVE-2026-66066): Rapid7 Publishes Full Chain Analysis — Metasploit Module Now Public
rapid7.com · 71d ago · August 4th, 2026
New today: Rapid7's independent technical analysis reproduces the file-read and RCE chains and ships a Metasploit module — public weaponized exploitation tooling now exists.*
Rapid7's analysis (Aug 3) confirms and extends the Rails Active Storage / libvips picture for CVE-2026-66066:
- Reproduction: the file-read chain was reproduced against Rails 6.0.6.1, 6.1.7.10, 7.2.3.1, 8.0.5, and 8.1.3; patched builds (7.2.3.2 / 8.0.5.1 / 8.1.3.1) block it. Root cause is a double trust failure: Rails trusts a database-stored
content_type(attacker-controlled via the direct-upload endpoint) to gate image processing, while libvips selects the parser from file bytes — and libvips' MAT sniffer (10-byte "MATLAB 5.0" prefix check) disagrees with libmatio's version field at bytes 124–125, enabling the MAT/HDF5 external-storage arbitrary file read. - No secret needed for the read: replaying a genuine signedvariation_keyfrom the same app against a new direct-upload blob bypasses signing entirely — file read works without secret_key_base. - RCE confirmed: Rapid7 validated a code-execution path using only JSON-compatible Hash/Array/String values in a signed variation (reachingKernel#spawn/Kernel#evalvia ImageProcessing's chain builder) whenconfig.active_support.message_serializer = :json. - Metasploit moduleexploit/multi/http/rails_activestorage_vips_rcedemonstrated end-to-end: recovers SECRET_KEY_BASE from /proc/self/environ via the file-read oracle, derives verifier keys, and spawns a shell as the rails user. Action: The window for "no public exploit" has closed — treat unpatched Active Storage deployments as remotely reachable.
- Reproduction: the file-read chain was reproduced against Rails 6.0.6.1, 6.1.7.10, 7.2.3.1, 8.0.5, and 8.1.3; patched builds (7.2.3.2 / 8.0.5.1 / 8.1.3.1) block it. Root cause is a double trust failure: Rails trusts a database-stored
-
update from www.urbanmind.net
CVE-2026-66066: an image upload path that reads /proc/self/environ The shortest way to describe CVE-2026-66066 is that a framework default t
www.urbanmind.net · 17d ago · September 26th, 2026
CVE-2026-66066: an image upload path that reads /proc/self/environ The shortest way to describe CVE-2026-66066 is that a framework default t
via Mastodon https://www.urbanmind.net/search?tag=cybersecurity