Rails Active Storage: CVE-2026-66066 File Read Flaw

What does CVE-2026-66066 describe?

According to BleepingComputer (August 1, 2026), it is a vulnerability rated critical by the Rails maintainers, exploitable when libvips is used to generate image thumbnails. An attacker uploads a specially crafted image and can read arbitrary files on the server. Exposed data can include the process environment, which typically holds secret_key_base and credentials for databases, cloud storage and other services.

The attacker does not need to be authenticated. The prerequisite is that the server accepts images uploaded by untrusted users. The article gives no numeric CVSS score.

Which versions are affected?

• Active Storage before 7.2.3.2;
• 8.0.x before 8.0.5.1;
• 8.1.x before 8.1.3.1;
• Rails 6.x only if Active Storage was configured outside its defaults.

The fixed versions are 7.2.3.2, 8.0.5.1 and 8.1.3.1. The article also recommends libvips 8.13 or later. ImageMagick is not affected by this vector, while libvips is the default processor in the official Rails Docker images and in default Debian and Ubuntu setups.

How does file read become code execution?

Akamai, which named the chain "KindaRails2Shell", explains that a compromised secret_key_base lets an attacker forge session cookies, sign global IDs and manipulate serialized data, which leads to full code execution. The other readable secrets (database and cloud storage credentials) open other pivot paths into the infrastructure.

What is the disclosure timeline?

Full technical details were scheduled for August 28, 2026 on the Rails forums. Public proofs of concept appeared quickly, and the maintainers published the details and a forensic tool earlier. The flaw was responsibly reported to the Rails team by Ethiack and GMO Flatt Security Inc.; Akamai coordinated with Ethiack before disclosure. Akamai released web application firewall protections; Ethiack stresses that a firewall may only buy time, since attackers using AI tooling could rebuild the attack from patch diffs.

What should you do, in order?

1. Identify your Rails applications that accept images from untrusted people (avatars, attachments, documents, customer imports).
2. Update Active Storage to 7.2.3.2, 8.0.5.1 or 8.1.3.1, and libvips to 8.13 or later.
3. Temporary workaround on libvips 8.13 or later: set the VIPS_BLOCK_UNTRUSTED environment variable, or call Vips.block_untrusted(true) with ruby-vips 2.2.1 or later. There is no workaround for libvips before 8.13.
4. Rotate the secrets the application can read: secret_key_base, database credentials, Active Storage service credentials and all others. Changing secret_key_base invalidates existing sessions.
5. Look for traces: unusual image uploads, thumbnail requests on files of unknown origin, secret access from new addresses. Use the forensic tool published by the maintainers.
6. Reduce environment contents: not every secret should be readable by the web process; scope them per service and use a secrets manager.

How do you test this exposure?

With authorization, on a staging environment that mirrors production.

1. Versions: record the Rails, Active Storage and libvips versions (vips --version) in every image and server.
2. Image processing: check whether image variants (thumbnails, resizing) go through libvips for user-uploaded files.
3. Upload surface: list the endpoints that accept a file without authentication.
4. Active workaround: if you use the blocking variable, confirm it is set in the real process (not only in your shell) and that an untrusted test file is refused.
5. Environment contents: list what the web process would disclose if read, and shrink that list.

How do you durably harden the processing of uploaded files?

A file upload is third-party-controlled input that goes through complex decoding libraries. A few principles limit the impact of the next flaw of this kind.

• Isolate processing: run thumbnail generation in a separate process or container, with no access to the application's secrets, a read-only filesystem and no outbound network.
• Least environment content: the process that decodes images needs neither secret_key_base nor database credentials. Separate roles and go through a secrets manager.
• Limit accepted formats: accept only the image types you need, check the real content type and not just the extension, and cap size and dimensions.
• Process offline: put files in a processing queue and serve variants only after validation, rather than decoding on the fly inside the web request.
• Monitor: alerts on repeated decoding errors, bursts of uploads from one origin and unusual file reads by the web process.
• Update system libraries: libvips is a system and container image dependency, not just a Gemfile one. Put it in your dependency inventory and update routine.

What should you look for in the logs to know whether you were hit?

Start with the period from the publication of the fixes to your update, and widen it if your application was exposed earlier.

• Requests for image variants (thumbnails, resizes) on files recently uploaded by unknown accounts or anonymous visitors.
• Unusual image processing errors, or files whose content does not match the extension.
• Connections to your databases or cloud storage from unknown addresses, suggesting use of stolen credentials.
• Valid sessions for accounts that never logged in, or changes to serialized data, suggesting cookie forgery.

If you suspect a read, consider all environment secrets exposed, rotate them and invalidate sessions.

Document the decision either way. A short note recording the version you were running, the date you patched, the checks you performed and the secrets you rotated will help with customer questions, audits and, if personal data was in scope, any regulatory notification.

What is the link with AI applications?

AI products often rest on a classic web application that receives files: document analysis, extraction from images, attachment import before summarization by a model. A file read flaw on that front end exposes the same secrets as the application's own, including model provider API keys. For the frame, see the AI agent security page and the article on October 2026 flaws that reach agents.

CleanIssue's Agent Red Team Express (EUR 1,900, 5 days) tests AI agents and the file flows that feed them: see the offer. To start, a free 30-minute discovery call lets us know which stored files your agent can reach through Active Storage.