Anoymask

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

1. Basic Information

2. One-Sentence Summary

This is a vulnerability that combines Active Storage direct uploads and variant processing by libvips, allowing attackers to upload a crafted file without authentication, read files and credentials on the server, and potentially execute code under the Rails process permissions depending on the conditions.

3. Attack Flow

  1. The attacker discovers or guesses that the target Rails app uses Active Storage.
  2. The attacker registers a crafted file to the unauthenticated direct upload feature.
  3. The attacker triggers variant processing, which is handled by the vulnerable Active Storage and default builds of libvips.
  4. The attacker reads arbitrary files on the server.
  5. The attacker retrieves Rails secrets, cloud credentials, database credentials, and other sensitive data.
  6. The attacker may achieve remote code execution by using the retrieved secrets or the processing chain.
  7. The attacker may move laterally to databases, storage, cloud environments, or CI/CD pipelines as a next step (Inference).

4. Attacker Position and Execution Location

The attacker uploads files from the external network via HTTP. The processing happens on the Rails application server and the libvips process. Remote code execution runs with the OS permissions of the Rails or variant processing service.

5. What Victims and Administrators See

  • Even without a user-facing upload screen, apps can be vulnerable if Active Storage is enabled.
  • Administrators may see direct uploads, blob creation, variant requests, and libvips exceptions or file access in logs.
  • Because it looks like normal image processing, it is hard to detect using a WAF alone.

6. Success and Failure Conditions

Success Conditions

  • Active Storage is enabled.
  • The variant processor is set to :vips.
  • libvips uses a default build, such as from distribution packages.
  • Vulnerable versions are used (earlier than 7.2.3.2, 8.0 to 8.0.5.1, or 8.1 to 8.1.3.1).

Failure Conditions

  • Updated to a fixed version.
  • Official workarounds for libvips/ruby-vips conditions are applied.
  • Direct upload and variant processing are stopped or network access is restricted.
  • Secrets are separated from files and follow the principle of least privilege.

7. What Happens on Success

Files and credentials on the server are leaked, leading to remote code execution, database compromise, cloud resource abuse, and theft of source code or customer data. JPCERT/CC recommends changing all readable credentials as if they have been compromised.

8. Observable Logs

  • Email: Usually none.
  • Proxy/SWG/DNS: Subsequent traffic from the app server to unknown destinations, downloading packages or tools.
  • Endpoint/EDR: Abnormal file access by Rails/libvips, child processes, shells, and reading secret files.
  • Identity/IdP: Abnormal use of app secrets, cloud keys, and database credentials.
  • SaaS/Cloud: Object storage blobs/variants, Secrets Manager, and cloud audit logs.
  • Network: Direct uploads, crafted blobs, variant processing requests, and outbound traffic after remote code execution.

9. Attack Success Determination

  • Contact Only: Probing target endpoints.
  • User Action: Not required.
  • Initial Execution: Registering the crafted blob and variant processing.
  • Malware or Successful Auth: Arbitrary file read, use of secrets, and child process execution.
  • Data Theft / Session Compromise: Abnormal access to secrets, databases, and cloud data.
  • Confirming Later-Stage Compromise: Web shells, persistent processes, new keys, database tampering, and external data exfiltration.

10. Investigation Playbook

  • Trigger: Detection of vulnerable versions, PoC-style uploads, libvips anomalies, or secret file access.
  • Initial Check: Confirm Rails, activestorage, libvips, and ruby-vips versions, :vips settings, and direct upload accessibility.
  • Endpoints: Preserve Web, Rails, and Active Storage logs, blobs, variants, processes, and file audits.
  • Auth and Cloud: Check for abnormal use of all secrets, including Rails credentials, environment variables, databases, and S3.
  • Subsequent Actions: Track new processes, cron jobs, services, web shells, outbound traffic, and data access.
  • Containment: Update software, stop features if needed, isolate affected hosts, revoke and rotate all readable credentials, and rebuild from known good versions.
  • Judgment Categories: Vulnerable / Probed / Malicious Upload / File Read / Credential Use / RCE / Downstream Compromise.

11. Defense and Detection Ideas

  • Single Events: Abnormal variants right after direct uploads, libvips accessing secret files, or Rails spawning a shell.
  • Timeline Correlation: Blob creation -> Variant processing -> Secret file read -> New authentication -> Outbound traffic.
  • Threat Hunting: Cross-check Active Storage settings and past blob/variant requests across all internet-facing Rails applications.
  • Lack of Logs: Without object storage and file access audits, it is hard to determine if file reads were successful.
  • Priority Countermeasures: Update software, manage secrets securely, apply service least privilege, and restrict uploads. Do not rely on a WAF as a replacement for updates.

12. Facts / Inference / Hypothesis

Facts

  • JPCERT/CC confirmed a public PoC and warned about widespread exploit potential.
  • Applications without a user-facing upload feature can still be targeted because direct upload lacks authentication.
  • JPCERT/CC recommended changing all readable credentials.

Inference

  • If a Rails application has high cloud privileges, file reads alone before remote code execution can lead to severe cloud compromise.

Hypothesis

  • Combining Active Storage events with host file access logs can determine success with higher accuracy than a WAF.

13. MITRE ATT&CK Mapping

  • High Confidence: T1190 Exploit Public-Facing Application, T1005 Data from Local System, T1552.001 Credentials In Files.
  • Medium Confidence: T1059 Command and Scripting Interpreter, T1078 Valid Accounts, T1105 Ingress Tool Transfer, T1041 Exfiltration Over C2.

14. Unknowns and Additional Investigations

  • Presence and start time of actual exploitation
  • Exact file format and request sequence of the PoC
  • Readable range and complete prerequisites for remote code execution
  • Impact on hosting services and derived frameworks

15. Impact on SOCs and Organizations

Rails is widely used in web services, and environments without visible upload features can still be targeted, which poses a significant risk. Organizations must check Gem lockfiles and runtime configurations against asset inventories, and rotate credentials assuming a breach has occurred.

16. Summary by Role

  • For SOCs: Correlate uploads, variants, secret reads, and authentication usage. Investigate all historical logs after the PoC release.
  • For Administrators: Check Rails and libvips dependencies, update them, and rotate all readable secrets.
  • For Users: No user action is required. Report service anomalies to administrators if found.