KindaRails2Shell: Active Attacks Against Ruby on Rails Use File Uploads to Steal Secrets and Credentials

As of August 31, 2026, CVE-2026-66066 is being actively exploited against exposed Ruby on Rails applications. Dubbed KindaRails2Shell, the vulnerability allows an attacker to turn a crafted image upload into arbitrary file reads accessible to the Rails process.

The issue carries a CVSS score of 9.5 and is classified as CWE-1188. The primary targets are applications that combine Active Storage, the libvips image processor, and uploads from untrusted users, including unauthenticated users.

The impact goes beyond file disclosure. Stolen secrets can enable session forgery, credential theft, access to connected services and, under certain conditions, remote code execution.

Which Rails Versions Are Vulnerable

According to NVD data, the affected Ruby on Rails versions are those earlier than:

• 7.2.3.2
• 8.0.5.1
• 8.1.3.1

Administrators should therefore upgrade at least to the patched version available for their current branch. The affected components include Ruby on Rails/Action Pack, Active Storage, libvips, libmatio and HDF5.

However, not all Rails deployments have the same level of exposure. The applications at greatest risk are those that:

• use Active Storage to receive and transform images;
• have libvips configured as the image-processing engine;
• allow anonymous uploads or uploads from accounts that are not fully trusted;
• run Rails with access to credentials, keys and sensitive configuration files on the filesystem.

At the beginning of August, VulnCheck identified approximately 7,000 exposed and vulnerable Ruby on Rails instances. That figure does not show how many were subsequently patched or how many may have been compromised.

Rails released fixes in late July and urged organizations to update exposed configurations immediately. Shortly afterward, independent researchers analyzed the patch, reconstructed the flaw and published proof-of-concept code. According to VulnCheck, attacks began approximately one month after the updates were released.

From a Crafted Image to Local File Reads

KindaRails2Shell exploits a discrepancy in how Rails and the underlying libraries determine a file’s format.

Rails may treat a blob as an image based on the content type declared by the client. libvips, by contrast, examines the so-called magic bytes—sequences in the content that identify its actual format. An attacker can exploit this difference by uploading an object presented to the application as an image but recognized by libvips as a MATLAB Level 5 file.

The attack chain continues across several libraries:

1. Rails accepts the upload as graphical content.
2. libvips detects the byte sequence characteristic of the MATLAB format.
3. The file is passed to libmatio.
4. A header field causes libmatio to identify the MAT 7.3 variant.
5. Processing is handed off to the HDF5 library.
6. HDF5’s External File List feature receives a path and offset controlled by the attacker.

External File List allows an HDF5 dataset to store its data in an external file. In this scenario, however, the feature is abused to read a local file selected by the attacker. During rendering, the retrieved bytes can be embedded in the resulting image and returned as pixels.

The vulnerability therefore stems from Active Storage failing to disable unsafe libvips operations when content comes from untrusted sources. No account is required; reaching a vulnerable upload function is enough.

Application Secrets, Sessions and Lateral Movement

The attacker can read any file accessible with the privileges of the Rails process. The precise scope depends on the server configuration and the permissions assigned to the application, but potentially includes:

• environment variables;
• files containing application secrets;
• databases or credential stores;
• keys for storage services;
• configuration files containing tokens;
• material used to sign sessions and other application data.

One of the most sensitive values is secret_key_base. Its exposure can compromise the cryptographic mechanisms that protect sessions, signed cookies and other objects generated by the application.

Once secrets have been stolen, an attacker may forge sessions, impersonate legitimate users or connect to external databases and infrastructure. Shared credentials or overprivileged keys can also facilitate lateral movement to other systems.

For this reason, installing the patch alone does not necessarily complete the incident response. The update blocks the known attack vector, but it does not revoke credentials or signing keys that may already have been stolen.

Concerns About the Marshal Variant After Patching

VulnCheck tested a server updated to version 8.1.3.1, which NVD lists as a patched release. The test reportedly confirmed that arbitrary file reads through libvips were blocked, but also highlighted a possible residual component of the attack chain.

Specifically, a variant involving Marshal deserialization and variation keys could remain exploitable when a valid signature is available. Under these conditions, the remote-code-execution gadget could continue to work even on the updated system.

The finding has been reported by a single source and does not demonstrate that the patch is ineffective against the primary attack vector. It does, however, introduce an important operational distinction: the patched versions may prevent file reads through libvips, while it remains uncertain whether they neutralize every possible subsequent stage of the chain.

Organizations should therefore test variation keys and Marshal deserialization separately. This assessment is especially urgent if signing keys or other secrets may already have been exposed.

CISA KEV Catalog and Threat Status

There is no verifiable indication that CVE-2026-66066 has been added to CISA’s Known Exploited Vulnerabilities catalog. As a result, there is no inclusion date or KEV deadline to report.

There is also no information about any recent Ruby on Rails entries in the catalog. Active exploitation is nevertheless supported by the telemetry described by VulnCheck, regardless of the vulnerability’s KEV status.

The activity has not been attributed to a specific threat group. The number of affected organizations, preferred targets and any indicators of compromise tied to a single campaign remain unknown.

Patching, Threat Hunting and Secret Rotation

The first step is to upgrade Rails to at least 7.2.3.2, 8.0.5.1 or 8.1.3.1, selecting the release corresponding to the branch in use. Systems running Active Storage and libvips with unauthenticated uploads should receive priority.

If the update cannot be applied immediately, organizations should temporarily disable image uploads or move image processing to an isolated environment. The process should have access only to the files it strictly requires and should not be able to read secrets, credentials or the application’s full configuration.

Rails has also published forensic tools for identifying exploitation attempts. In the absence of more specific public indicators, defenders should review:

• anomalous upload requests or content with an inconsistent declared type;
• unusual activity involving libvips processes;
• unexpected access to local files during rendering;
• errors associated with MATLAB, libmatio or HDF5;
• suspicious generation of variation keys;
• sessions created or used in ways inconsistent with normal user behavior.

If a vulnerable application was exposed, secret_key_base, credentials and storage keys readable by the process should be considered potentially compromised. These values must be rotated, and existing sessions should be revoked or regenerated.

Finally, post-patch testing should cover both malicious uploads processed through libvips and the potential Marshal variant. KindaRails2Shell is no longer merely a theoretical risk: active exploitation also makes retrospective checks for possible secret theft essential.