A Rails Image Upload Could Hand Back Your Secrets as Pixels

The vulnerability, nicknamed KindaRails2Shell, carries a CVSS score of 9.5. VulnCheck has reported active exploitation, while Rails has published technical detail and forensic tooling for organisations that need to determine whether a vulnerable application was exposed or compromised.

How a file becomes pixels

Affected applications use Active Storage variants with the libvips image-processing pipeline and accept untrusted uploads. A content-type confusion path can cause a specially prepared MATLAB or HDF5 file to reference another file on the server.

When the application processes the upload as an image variant, libvips reads the referenced server file and renders its bytes into pixels. The attacker does not receive a normal text file. They receive an image that encodes the information they wanted to steal.

This matters because application servers often hold database credentials, storage keys, secret-key material and tokens that are not intended to leave the host. Reading one of those files can convert a file-disclosure vulnerability into control over sessions, cloud storage or connected services.

Why Rails calls it more than a file read

The direct boundary crossed by CVE-2026-66066 is arbitrary file read. The operational impact depends on what the Rails process can access. If an attacker recovers the application’s secret key base or signing material, they may be able to forge trusted session data.

That can produce administrator access or reach deserialisation paths that execute code. It can also expose credentials that support lateral movement beyond the Rails server. A restricted application account and minimal secret access therefore reduce impact even after the vulnerable upload path is reached.

Patches exist, but the edge case still matters

Rails released patches in late July after public proof-of-concept material began to appear. Administrators should use the fixed versions identified by the Rails project and confirm that every internet-facing application using Active Storage has actually deployed them.

VulnCheck has also warned that a valid-signature Marshal deserialisation gadget path can remain relevant even on Rails 8.1.3.1 if an attacker has already obtained signing secrets. That claim does not mean the official patch fails to close the original file-read condition. It means incident response cannot end at patch installation when secrets may have been exposed before the fix.

Rails released investigation tools

The Rails team published a dedicated forensic repository for CVE-2026-66066. The tooling helps teams assess the exposure window and look for exploited applications or associated artefacts.

Forensic results should be combined with web, Active Storage, reverse-proxy, endpoint and cloud audit logs. Attackers can use stolen keys outside the original server, so a clean host scan does not prove that connected storage or signed sessions remained safe.

What defenders should do now

• Identify Rails applications that accept untrusted uploads and generate Active Storage variants through libvips.
• Deploy the fixed Rails versions and restart every affected application process.
• Use the Rails forensic tooling and preserve upload, variant-processing and reverse-proxy logs.
• Rotate the secret key base, storage credentials and other secrets readable by the application if exposure cannot be ruled out.
• Invalidate active sessions after rotating signing material.
• Review cloud and database audit trails for activity that used application credentials outside normal patterns.
• Restrict the Rails service account so it cannot read unrelated secrets or system files.

The BlackTree view

The clever part of CVE-2026-66066 is not simply that it reads a file. It passes the theft through an image-processing workflow that defenders may have treated as low risk.

Once exploitation is confirmed, patching becomes the start of the response. The harder question is whether the server already rendered a secret into pixels and whether that secret is still trusted somewhere else.

Sources

• Ruby on Rails: attack details and forensic investigation guidance for the vulnerability, initially published 31 July 2026 at 00:51. The forum displays the time without a timezone.
• Rails forensic tooling repository, accessed 31 August 2026.
• SecurityWeek: critical Ruby on Rails vulnerability in attackers’ crosshairs, published 31 August 2026 at 07:24 ET.