CVE-2026-66066: 
Ruby vulnerability analysis and mitigation

CVE-2026-66066 is a critical arbitrary file read and potential remote code execution vulnerability in Ruby on Rails' Active Storage component, dubbed KindaRails2Shell. It affects Rails versions prior to 7.2.3.2, 8.0.0.beta1–8.0.5.1, and 8.1.0.beta1–8.1.3.1 when configured to use libvips for image processing and accepting uploads from untrusted users. The vulnerability was responsibly disclosed by researchers from Ethiack (0xacb, s3np41k1r1t0, castilho) and RyotaK from GMO Flatt Security Inc., with the advisory published on July 29–30, 2026. It carries a CVSS v3.1 score of 8.9 (High) and a CVSS v4.0 score of 9.5 (Critical) (GitHub Advisory, Feedly).

The root cause is an insecure default initialization (CWE-1188) combined with unrestricted file upload handling (CWE-434): Active Storage did not call Vips.block_untrusted(true) at boot, leaving libvips "unfuzzed" loaders and savers — operations marked unsafe for untrusted content — fully accessible. libvips categorizes certain loaders (e.g., those backed by ImageMagick, HDF5/MATLAB .mat files) as unfuzzed because they are not hardened against malicious input. An attacker crafts a file (e.g., a MATLAB .mat or HDF5 file disguised as an image) that, when processed by Active Storage's variant pipeline, triggers one of these unsafe libvips operations to read arbitrary files from the server filesystem. The fix, applied in commits 1c01bb5, 349e7a5, and d79b7f4, adds a new activestorage/vips.rb initializer that calls Vips.block_untrusted(true) at boot and enforces minimum versions of libvips ≥ 8.13 and ruby-vips ≥ 2.2.1 (GitHub Advisory, Rails Commit). A fully functional Python PoC (rails_vips_oast_poc.py) that constructs malicious HDF5/Marshal payloads and achieves RCE has been publicly released (PoC Repo).

A successful exploit allows an unauthenticated remote attacker to read arbitrary files accessible to the Rails process, including /proc/self/environ, config/master.key, config/credentials.yml.enc, and any environment variables — exposing secret_key_base, database credentials, cloud storage keys (S3/GCS/Azure), and third-party API tokens. Exposure of secret_key_base enables forging of signed cookies and session tokens, which can escalate to remote code execution via deserialization gadgets. Lateral movement to connected cloud services or databases is also possible if their credentials are present in the environment. The NVD SSVC assessment rates the technical impact as "total" (GitHub Advisory, Feedly).

A fully functional, publicly available Python PoC exploit (rails_vips_oast_poc.py) exists that constructs malicious HDF5/Marshal payloads, uploads them to a target Rails application, and achieves RCE — with documented output confirming ARBITRARY_ENV_READ_RESULT=CONFIRMED (PoC Repo). A Metasploit module has also been reported as available (GBHackers). The NVD SSVC marks exploitation status as "poc" and the attack as "automatable." The EPSS score is approximately 0.0177 (1.77%), and as of the report date there is no confirmed in-the-wild exploitation or CISA KEV listing. Ethiack estimated over 500,000 websites were potentially exposed (Cybersecurity Insiders).

1. Reconnaissance: Identify Rails applications using Active Storage with libvips (config.active_storage.variant_processor = :vips) that accept image uploads from unauthenticated or untrusted users. Use Shodan/Censys to find internet-facing Rails apps, or check Gemfile.lock for ruby-vips and activestorage versions below the patched thresholds.
2. Craft malicious payload: Using the public PoC (rails_vips_oast_poc.py), construct a crafted file (e.g., a MATLAB .mat / HDF5 file) that, when processed by libvips's unfuzzed loader, triggers a file-read operation targeting a sensitive path such as /proc/self/environ or config/master.key.
3. Upload the crafted file: Submit the malicious file to the application's image upload endpoint (e.g., a profile picture, attachment, or any Active Storage-backed upload form) via an HTTP POST request. No authentication is required.
4. Trigger variant generation: Request a variant of the uploaded file (e.g., by visiting a URL that generates a resized thumbnail), causing Active Storage to pass the file through the libvips processing pipeline and invoke the unsafe loader.
5. Exfiltrate secrets: The libvips unfuzzed operation reads the targeted file and its contents are returned or observable via an out-of-band channel (OAST/DNS callback as demonstrated in the PoC), exposing secret_key_base, credentials, and tokens.
6. Escalate to RCE: Use the exfiltrated secret_key_base to forge a malicious signed Rails session cookie containing a serialized Ruby object (Marshal gadget chain), submit it to the application, and achieve remote code execution upon deserialization (GitHub Advisory, PoC Repo, Rapid7 ETR).

• Network: Unusual HTTP POST requests to Active Storage upload endpoints (e.g., /rails/active_storage/direct_uploads, /rails/active_storage/blobs) with non-standard file types (e.g., .mat, HDF5, or files with mismatched MIME types); outbound DNS or HTTP requests to unknown external hosts from the Rails server process (OAST callbacks).
• File System: Presence of crafted .mat, HDF5, or other non-image files in Active Storage blob storage directories; forensic artifacts detectable by the Rails forensics toolkit (lib/crafted_mat_file.rb header signatures) (Rails Forensics).
• Logs: Rails application logs showing Vips::Error exceptions during image variant processing; Active Storage logs with blob IDs corresponding to non-image MIME types being processed as variants; access log entries showing variant generation requests for recently uploaded blobs from unauthenticated sessions.
• Process: Unexpected child processes spawned by the Rails/Puma process (e.g., curl, wget, bash, ruby) following image upload and variant generation events.
• Application State: Unexpected session invalidations or new sessions with forged cookies following secret exfiltration; unauthorized access to cloud storage buckets (S3/GCS/Azure) using credentials stored in the Rails environment.

Primary remediation: Upgrade activestorage (and the full Rails stack) to patched versions 7.2.3.2, 8.0.5.1, or 8.1.3.1, and simultaneously upgrade libvips to ≥ 8.13 and ruby-vips to ≥ 2.2.1 — both are now required minimums (GitHub Advisory, Rails Release).

Workarounds (if immediate patching is not possible):

• Set the environment variable VIPS_BLOCK_UNTRUSTED=1 before starting the Rails process (requires libvips ≥ 8.13).
• Alternatively, add Vips.block_untrusted(true) in a Rails initializer (requires ruby-vips ≥ 2.2.1).
• Remove ruby-vips from the Gemfile entirely if libvips is only used for image analysis and not variant generation.
• Switch the variant processor to :mini_magick (config.active_storage.variant_processor = :mini_magick) to avoid libvips entirely.
• Restrict image upload functionality to authenticated users only as a risk-reduction measure.

Post-exploitation: If compromise is suspected, rotate all secrets readable by the Rails process: secret_key_base, RAILS_MASTER_KEY, database credentials, and all third-party API tokens. Use the official forensics toolkit to determine exposure scope (Rails Forensics).

The Rails core team published the advisory on July 29–30, 2026, intentionally omitting full technical details until August 28, 2026, to allow administrators time to patch — however, a working PoC appeared on GitHub the same day the advisory was released (Duggan USA). Rapid7 published both an early threat report (ETR) and a full technical analysis, and Akamai, Fastly, Cloudflare (WAF rules), and Check Point all released coverage or detections within days (Rapid7 ETR, Akamai, Fastly). The vulnerability received significant community attention on Hacker News, Reddit's r/netsec, and Mastodon/Bluesky, with the KindaRails2Shell name coined by the Ethiack researchers who discovered the attack chain. BleepingComputer, The Hacker News, SecurityWeek, and Heise all covered the story, and the Canadian Centre for Cyber Security issued advisory AV26-767 (BleepingComputer, CCCS). A notable post-patch complication was documented: simply patching the gem was insufficient without also upgrading libvips to ≥ 8.13 (FastRuby Blog).