KindaRails2Shell (CVE-2026-66066): Arbitrary File Read and RCE via Active Storage Uploads

1. Basic Information

• Article Title: Vulnerability Advisory on Remote Code Execution in Ruby on Rails Active Storage
• Publisher: JPCERT/CC
• Published Date: 2026-07-30 (Updated: 2026-08-31)
• Original Source: JPCERT/CC
• Related Sources: GitHub Security Advisory GHSA-xr9x-r78c-5hrm, Rails forensic guidance, SecurityWeek active exploitation report
• Related Malware, Threat Groups, CVEs, and Products: CVE-2026-66066, Ruby on Rails, Active Storage, libvips, activestorage
• Severity: Critical
• Update Reason: VulnCheck Canaries observed active exploitation, alongside additional disclosures showing that approximately 7,000 instances are publicly exposed, and that Marshal deserialization RCE gadgets still function with valid signatures even on the patched 8.1.3.1 version.

2. Executive Summary

KindaRails2Shell involves an unauthenticated arbitrary file read that exploits differences between Active Storage and libvips. Attackers steal credentials such as secret_key_base, forge signed variation keys, trigger Marshal deserialization, and achieve RCE. Active exploitation has been observed across multiple regions via canary deployments.

3. Attack Flow

From Arbitrary File Read to RCE

1. An unauthenticated attacker registers a crafted blob with Active Storage.
2. The attacker triggers variant processing, leveraging format handling discrepancies between Active Storage and libvips to invoke a dangerous loader.
3. The Rails process reads accessible files and the process environment to acquire secrets such as secret_key_base.
4. The attacker uses the obtained secrets to create a variation key with a valid signature.
5. The attacker triggers a Marshal deserialization gadget to execute code with the privileges of the Rails process.
6. The attacker may pivot laterally to databases, object storage, cloud environments, and external integrations.

4. Attacker Position and Execution Context

• An external, unauthenticated attacker who can reach Active Storage endpoints via HTTP for direct uploads or blob/variant processing.
• Post-RCE execution runs with the OS privileges of the Rails or image processing service.

5. Visibility for Victims and Administrators

Victims

• Visible indicators in the UI are minimal, as the attack can succeed without user interaction or an explicit upload screen.

Administrators

• Clues include suspicious Active Storage blobs, variant generation, libvips exceptions, access to sensitive files by the Rails process, signed variation keys, and child processes.

6. Success and Failure Conditions

Success Conditions

• Active Storage uses libvips as the variant processor and processes untrusted uploads.
• Vulnerable versions of activestorage/libvips are used, or the attacker possesses valid secrets leaked in the past.
• The acquired secrets or signed variation keys can be used for subsequent RCE.

Failure Conditions & Risk Mitigation

• Update activestorage to 7.2.3.2, 8.0.5.1, 8.1.3.1 or later, and update libvips to 8.13 or later.
• Rotate secret_key_base and any database, cloud, and external integration secrets that were readable from the process.
• Restrict untrusted uploads and variant processing, and isolate image processing in a least-privilege environment.

7. Impact of Successful Exploitation

• Leakage of arbitrary files on the server and process environment variables.
• Signature forgery and abuse of sessions and variation keys using secret_key_base and other stolen secrets.
• Code execution with the privileges of the Rails process.
• Lateral movement to databases, storage, cloud environments, and external integrations.

8. Observable Logs

• Email: None.
• Proxy/SWG/DNS: Abnormal requests to Active Storage upload/variant endpoints, followed by outbound communication from the Rails server to unknown C2 servers.
• Endpoint/EDR: Access to sensitive files by Rails/libvips, child processes spawned after image processing, shell execution, and retrieval of external tools.
• Identity/IdP: Suspicious sessions and authentication events occurring around the time secret_key_base or cloud/database credentials are compromised or rotated.
• SaaS/Cloud: Crafted blobs/variants in object storage, alongside audit logs for Secrets Manager, databases, and cloud platforms.
• Network: Upload → variant processing → outbound C2, or connections to external services using stolen credentials.

9. Attack Success Determination

• Attack Attempt Observed (Success Unconfirmed): Only Active Storage reconnaissance or crafted upload requests are identified; blob registration and variant processing remain unconfirmed.
• User Interaction Confirmed: No user interaction is required.
• Initial Execution Confirmed: Registration of the crafted blob and variant processing by libvips are confirmed.
• Malware Execution or Authentication Success Confirmed: Arbitrary file read, signature forgery, Marshal RCE, or authentication using stolen credentials is confirmed.
• Data Theft or Session Compromise Confirmed: Retrieval and use of secret_key_base, database/cloud credentials, sessions, or files are confirmed.
• Post-Compromise Confirmed: Code execution on Rails, persistence, or lateral movement to databases, cloud, or external integrations is confirmed. Canary observations indicate the onset of exploitation but do not imply success across all phases.

10. Investigation Playbook

• Trigger: Detect CVE-2026-66066 exploitation attempts, crafted blobs, libvips anomalies, and sensitive file access.
• Initial Verification: Determine activestorage/libvips versions, :vips configuration, accessibility of untrusted uploads, and the vulnerability window.
• Endpoints: Preserve logs and artifacts from Rails, Active Storage, libvips, file auditing, child processes, and outbound communications.
• Authentication & Cloud: Review usage history for secret_key_base, database, cloud, storage, CI/CD, and external API credentials.
• Post-Exploitation: Check for web shells, cron jobs/services, additional keys, database modifications, object retrieval, and C2 activity.
• Containment: Apply updates and functional restrictions, rotate all potentially exposed secrets, and rebuild from a known-good state if a compromise is confirmed.
• Classification: Categorize incidents as vulnerable, reconnaissance, malicious upload, file read, secret misuse, RCE, or post-compromise.

11. Defense and Detection Ideas

• Single Event: An abnormal variant is generated immediately after an Active Storage upload, and libvips accesses Rails secret files.
• Time-Series Correlation: Correlate blob registration → variant processing → secret read → signed variation key → child process/new authentication → outbound communication.
• Threat Hunting: Use the official Rails forensic tool (rails-forensics-CVE-2026-66066) to check the vulnerable timeframe and identify crafted blobs.
• Log Gaps: Without complete Active Storage, object storage, file auditing, and authentication logs, determining past secret exposure is difficult.
• Prioritized Actions: Prioritize software updates, secret rotation, isolation and least-privilege configuration for image processing, and control over untrusted uploads.

12. Facts / Inference / Hypothesis

Facts

• Affected versions include activestorage earlier than 7.2.3.2, versions from 8.0.0.beta1 up to (excluding) 8.0.5.1, and versions from 8.1.0.beta1 up to (excluding) 8.1.3.1.
• Discrepancies between libvips (which determines file formats via magic bytes) and Active Storage (which uses user-supplied content types) allow attackers to invoke dangerous loaders other than images.
• Arbitrary file reads can expose the process environment (secret_key_base) and external system credentials.
• VulnCheck observed canary deployments in Singapore, Israel, and the United Kingdom being exploited by a single IP in France, alongside connections to an Israeli C2 server.
• VulnCheck estimated that approximately 7,000 Internet-exposed Rails instances are vulnerable.
• The patched version 8.1.3.1 prevents libvips file reads, but Marshal deserialization RCE gadgets still execute when a variation key has a valid signature. This assumes attackers already possess valid secrets such as secret_key_base.

Inference

• Environments where secrets may have been read in the past cannot invalidate forged signatures simply by updating software; rotating secret_key_base and all readable credentials is required.

Hypothesis

• It remains unclear whether the single attacking source observed by the canary represents a broader coordinated campaign, or the exact number of victim organizations.

13. MITRE ATT&CK Mapping

• T1190 Exploit Public-Facing Application (High): Exploits unauthenticated Active Storage upload and variant processing.
• T1005 Data from Local System (High): Retrieves arbitrary files readable by the Rails process.
• T1552.001 Unsecured Credentials: Credentials In Files (High): May acquire secret_key_base and external system credentials.
• T1078 Valid Accounts (Medium): May use acquired credentials or forged signatures for subsequent authentication.
• T1059 Command and Scripting Interpreter (Medium): Corresponds to command execution following Marshal RCE, though full post-exploitation steps in the canary observations have not been disclosed.

14. Unknowns and Further Investigation

• The exact number of victim organizations, the scope of stolen secrets, and the final objectives of the attackers.
• The actual exposure scope of Active Storage and libvips across various hosting services and derived configurations.

15. Impact on SOCs and Organizations

Rails is widely used in web services globally. Even if image upload features are not visible in the UI, endpoints may still be reachable via direct uploads or APIs. Security teams should verify gem versions and execution settings, inspect historical blobs using the official Rails forensic tool, and rotate any secrets that could have been read.

16. Summary by Role

• For SOCs: Review suspicious blobs, variant generation, libvips exceptions, sensitive file reads, signed variation keys, child processes, and C2 activity in chronological order.
• For Administrators: Update activestorage and libvips, and rotate credentials for secret_key_base, databases, cloud environments, and external integrations.
• For End-Users: Exploitation can succeed without user interaction. Report application anomalies or suspicious data modifications to administrators.