NIST deprecates RSA-2048 from 2030. Find every one of them before attackers do.
💎 RubyGems
Not in CISA KEV

Active Storage has possible arbitrary file read and remote code execution in Active Storage variant processingGHSA-xr9x-r78c-5hrm

Fix: rails/rails@1c01bb5

GHSA-xr9x-r78c-5hrm is a CWE-1188 vulnerability in activestorage. 4 public exploit or proof-of-concept references are indexed, so weaponization risk is real. A fix is available for activestorage — see the affected versions and patch details below.

Also known asCVE-2026-66066
Published
Updated
Affected
3 pkgs
Patched
3 / 3
Exploits
4 known
Exploitation data as of Oct 30, 2026 · OSV.dev, NVD, FIRST.org (EPSS)

Exploitation Status

Proof-of-concept exploit code exists

  • CISA’s SSVC triage found public proof-of-concept exploit code for this CVE, though no confirmed active exploitation.
  • CISA assesses this as automatable — exploitation doesn’t require manual, per-target effort, which raises the odds of mass scanning and opportunistic attacks.
  • A successful exploit gives an attacker total control of the affected component, not partial access.

Exploitation and automatability from CISA’s SSVC triage for GHSA-xr9x-r78c-5hrm.

EPSS Exploitation Probability

via FIRST.org ↗
30.1%probability of exploitation in next 30 days
Moderate Risk+27.97%
Lower risk than most CVEs98th percentile — riskier than 98% of all scored CVEsHighest risk
0.00%12.9%25.7%38.6%1.7%27.9%2.1%30.1%Aug 26Oct 26Oct 26

Probability of exploitation in the next 30 days, from FIRST.org EPSS.

Real-World Exposure

3 pkgs affected
💎activestorage💎activestorage💎activestorage

Real-time download stats are indexed for npm and PyPI packages. This vulnerability affects RubyGems packages — download data is not available via public APIs for these ecosystems.

Description

Impact

In its default configuration, a Rails application that displays image variants may allow an unauthenticated attacker to read arbitrary files from the server, including the process environment. That environment typically holds secret_key_base and often credentials for external systems, which may in turn allow escalation to remote code execution or lateral movement to those systems.

Details

libvips reads and writes file formats through "loaders" and "savers" (or more generally "operations"), many of which are backed by third-party libraries. It marks some of these operations as "unfuzzed", meaning they are unsafe for untrusted content, and several handle formats unrelated to web images. Active Storage did not disable the unfuzzed operations, so an attacker who can upload a crafted file and cause a variant to be generated from it may be able to invoke one.

We are aware of a mechanism by which an attacker, by uploading a crafted file, is able to cause disclosure of the contents of arbitrary files accessible on the filesystem of the targeted application. One specific attack chain has been reported to us (see "Disclosure" below), but we do not assume it is the only one that exists.

Affected applications

An application is affected if it meets all of these requirements:

  • Uses libvips for Active Storage image processing. This is config.active_storage.variant_processor = :vips, which load_defaults 7.0 set and no later default has changed.
  • Allows image uploads from untrusted users.

Generating variants is not a separate requirement.

Mitigation

  • Upgrade to a fixed version of activestorage.
  • The minimum version of libvips must be upgraded to >= 8.13.
  • Change secret_key_base and change any secrets accessible in the application environment (see "Expire and change secrets" below)

Earlier versions of libvips (< 8.13) cannot disable unfuzzed operations at all, and Active Storage will raise an exception during boot in such an unsecurable environment.

Expire and change secrets

Upgrading closes the vulnerability but does not undo an exfiltrated secret if that already occurred. An affected application should treat every secret readable by the application process as potentially exposed and change it, including:

  • secret_key_base
  • The master key, whether stored in config/master.key or supplied as RAILS_MASTER_KEY, along with everything in config/credentials.yml.enc that it decrypts
  • Credentials for the Active Storage service, such as S3, GCS, or Azure keys
  • Database credentials
  • Tokens and keys for any third-party service the application calls

Changing secret_key_base expires active sessions and requires users to log in again. Encrypted cookies, signed cookies, signed global IDs, and Active Storage URLs are also affected.

Rotation should only be used as an intermediate step if necessary. Do not retain an exposed secret as a fallback.

Workarounds

If libvips < 8.13 is being used, there are no workarounds available other than removing the dependency on libvips from the application. Some applications may have ruby-vips declared as a dependency only for image analysis, and those applications may be able to simply remove ruby-vips from the Gemfile to remove libvips from the application. Applications that do not use Active Storage can remove ruby-vips from the Gemfile to avoid the boot-time checks.

If libvips >= 8.13 is present on the system, applications can disable the unfuzzed operations without upgrading Rails by setting the VIPS_BLOCK_UNTRUSTED environment variable, which libvips reads while initializing.

Applications also running ruby-vips >= 2.2.1 or later can instead call Vips.block_untrusted(true) from an initializer.

Releases

The fixed releases are available at the normal locations.

Versions affected

  • activestorage < 7.2.3.2
  • activestorage >= 8.0, < 8.0.5.1
  • activestorage >= 8.1, < 8.1.3.1

Disclosure

Technical details of the attack chain are intentionally omitted from this advisory. They would add nothing to an administrator's decision to upgrade, while making it substantially easier to attack applications that have not yet done so.

Details will be disclosed no later than 2026-08-28, via the Rails Security Announcements forum.

Credit

This issue was responsibly reported by 0xacb, s3np41k1r1t0 and castilho from Ethiack, and RyotaK from GMO Flatt Security Inc..

References

Affected Packages

3 total 3 fixed
EcosystemPackageVulnerable rangeFix
💎RubyGemsactivestorageall versions7.2.3.2bundle update activestorage --conservative
💎RubyGemsactivestorage≥ 8.0.0.beta1&&< 8.0.5.18.0.5.1bundle update activestorage --conservative
💎RubyGemsactivestorage≥ 8.1.0.beta1&&< 8.1.3.18.1.3.1bundle update activestorage --conservative
Exploits & PoCs
4

Research use only. For defensive security, authorized penetration testing, and academic research only. Never execute exploit code against systems without explicit written authorization.

rails/rails-forensics-CVE-2026-66066

⭐ 28🍴 4Sep 2026

Zer0SumGam3/CVE-2026-66066-POC

PoC for CVE-2026-66066 in Ruby on Rails

⭐ 23🍴 13Aug 2026

0xsha/KindaRails2Shell

CVE-2026-66066 + File Read, RCE, Scanner, Lab

⭐ 4🍴 4Sep 2026

HackSpeak/CVE-2026-66066

CVE-2026-66066 (KindaRails2Shell) PoC - Rails Active Storage/libvips arb

⭐ 3🍴 2Sep 2026

Detection & mitigation playbook

Open-source dependency

  1. Detect

    Scan your dependency tree (package-lock.json, pnpm-lock.yaml, requirements.txt, go.sum, etc.) for activestorage, including transitive dependencies — a direct dependency you never call can still pull in a vulnerable version.

  2. Fix

    Update activestorage to 7.2.3.2 or later, then make sure no transitive (indirect) dependency still pins the vulnerable range — O3 confirms GHSA-xr9x-r78c-5hrm is resolved across your whole dependency graph.

  3. Workarounds

    If you can't upgrade right away: gate or disable the affected feature, validate untrusted input at the boundary, and avoid passing attacker-controlled data into the vulnerable path. O3's runtime protection blocks exploitation in production as an interim safeguard until the upgrade lands.

Frequently Asked Questions

### Impact In its default configuration, a Rails application that displays image variants may allow an unauthenticated attacker to read arbitrary files from the server, including the process environment. That environment typically holds `secret_key_base` and often credentials for external systems, which may in turn allow escalation to remote code execution or lateral movement to those systems. ### Details libvips reads and writes file formats through "loaders" and "savers" (or more generally "operations"), many of which are backed by third-party libraries. It marks some of these operations as
O3 Security · Impact-Aware SCA

Is GHSA-xr9x-r78c-5hrm in your dependencies?

Find it across RubyGems, including transitive dependencies.

Scan my dependencies How O3 SCA works
Active Storage has possible arbitrary file read and remote…