KindaRails2Shell: Ruby on Rails CVE-2026-66066 RCE Flaw
A crafted image can turn a standard avatar upload form into a covert conduit for stealing web application secrets. A vulnerable Ruby on Rails server may expose encryption keys, database passwords, service tokens, and cloud credentials. Under specific configurations, a malicious actor does not even require an active user account to execute this exploit.
Researchers at Ethiack have unearthed the critical KindaRails2Shell Rails RCE vulnerability within Active Storage. This component handles integrated file uploading and image processing for Ruby on Rails. Designated as CVE-2026-66066, this severe flaw can trigger arbitrary file reads and remote code execution. It also allows profound infiltration into interconnected systems.
The Role of libvips in Active Storage
The vulnerability stems from the libvips library, which Active Storage employs to generate avatars, thumbnails, and other image variations. Libvips supports multiple formats through distinct operations and loaders. Some of these loaders rely heavily on third-party dependencies. While libvips developers openly deem certain operations unsafe for processing untrusted files, Active Storage previously failed to block them.
An attacker can upload a manipulated file through a standard profile picture submission form. During processing, libvips analyzes the file contents and automatically initiates the corresponding loader. Consequently, this malicious payload can trigger an unsafe operation. This action reveals the contents of arbitrary files accessible to the web application process.
For successful exploitation, the target application must utilize libvips as its primary image processor. It must also explicitly permit file uploads from untrusted sources. According to the investigating researchers, the overall risk fluctuates based on the specific libvips build and its associated third-party libraries. Notably, applications relying on ImageMagick remain impervious to this particular attack vector.
Critical Secret Exposure and Remediation
The paramount danger lies in the potential exposure of environment variables and configuration files. Ruby on Rails frequently utilizes these locations to store the secret_key_base and master keys. They also hold database passwords, external service tokens, and critical access keys for cloud providers like Amazon S3, Google Cloud Storage, and Microsoft Azure. Exfiltrating these secrets empowers attackers to forge signed data, hijack user sessions, and seamlessly pivot into auxiliary systems. Remote code execution typically materializes as an advanced escalation of the attack. It is not necessarily a guaranteed immediate outcome of every exploitation attempt.
This profound vulnerability impacts Ruby on Rails versions spanning 7.0.0 through 7.2.3.1, 8.0.0 through 8.0.5, and 8.1.0 through 8.1.3. Furthermore, legacy branches from 6.0.0 to 6.1.7.10 remain at risk solely under non-standard Active Storage configurations that accept images from untrusted users.
According to the official security bulletin, developers have definitively rectified the issue in Active Storage versions 7.2.3.2, 8.0.5.1, and 8.1.3.1. Crucially, applying this remediation requires libvips version 8.13 or newer. Because older iterations of the library lack the capability to disable unsafe operations, merely updating the Rails framework proves woefully insufficient.
If immediate patching proves impossible, administrators running libvips 8.13 or newer can temporarily configure the VIPS_BLOCK_UNTRUSTED environment variable. Alternatively, users leveraging ruby-vips 2.2.1 or newer can explicitly invoke Vips.block_untrusted(true) within their application initializer. However, these temporary defensive measures cannot substitute a comprehensive framework update.
Following successful patch deployment, system owners must urgently rotate all cryptographic secrets accessible to the Rails process. This comprehensive mandate includes the secret_key_base, master keys, database passwords, cloud storage credentials, and third-party service tokens. While the update successfully seals the vulnerability, it intrinsically cannot revoke keys that adversaries may have stealthily compromised prior to remediation.
Support Our Threat Intelligence
If you find our technology report and cybersecurity news helpful, consider supporting our work.