GHSA-xr9x-r78c-5hrm
Fix: rails/rails@1c01bb5GHSA-xr9x-r78c-5hrm is a CWE-1188 vulnerability in activestorage. 3 public exploit references exist, so weaponization risk is real. O3 Security confirms whether GHSA-xr9x-r78c-5hrm is actually reachable in your code before you act, and blocks exploitation at runtime until you patch.
Active Storage has possible arbitrary file read and remote code execution in Active Storage variant processing
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
EPSS (Exploit Prediction Scoring System) is a daily probability model maintained by FIRST.org. It estimates the likelihood a CVE will be exploited in production environments within the next 30 days, derived from real-world threat intelligence signals.
Real-World Exposure
activestorage💎activestorage💎activestorageReal-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, whichload_defaults 7.0set 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_baseand 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.keyor supplied asRAILS_MASTER_KEY, along with everything inconfig/credentials.yml.encthat 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
- libvips 8.13 release notes, blocking of unfuzzed loaders
- W.A. Arbaugh, W.L. Fithen, and J. McHugh, "Windows of Vulnerability: A Case Study Analysis", IEEE Computer 33(12), December 2000
- https://ethiack.com/info-hub/research/kindarails2shell-rails-rce-cve
- https://blog.flatt.tech/entry/kindarails2shell_rails
Affected Packages
| Ecosystem | Package | Vulnerable range | Fix |
|---|---|---|---|
| 💎RubyGems | activestorage | all versions | 7.2.3.2 |
| 💎RubyGems | activestorage | ≥ 8.0.0.beta1&&< 8.0.5.1 | 8.0.5.1 |
| 💎RubyGems | activestorage | ≥ 8.1.0.beta1&&< 8.1.3.1 | 8.1.3.1 |
Research use only. For defensive security, authorized penetration testing, and academic research only. Never execute exploit code against systems without explicit written authorization.
Detection & mitigation playbook
Open-source dependencyDetect
Scan your dependency tree (package-lock.json, pnpm-lock.yaml, requirements.txt, go.sum, etc.) for activestorage. O3's reachability analysis confirms whether the vulnerable code path is actually invoked in your application, so you act on real exposure instead of every transitive match.
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.
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.
How O3 protects you
O3 pinpoints whether GHSA-xr9x-r78c-5hrm is reachable in your code and exactly where to fix it, then blocks exploitation in production at runtime until the patched version is deployed.
Tailored to GHSA-xr9x-r78c-5hrm. Runtime protection reduces exposure until a permanent patch is applied and verified — it complements patching, it doesn't replace it.
Frequently Asked Questions
Is GHSA-xr9x-r78c-5hrm in your dependencies?
O3 detects GHSA-xr9x-r78c-5hrm across RubyGems dependencies and uses function-level reachability to confirm whether the vulnerable code path is actually reachable — not just present. No false positives.