Rails Active Storage: file disclosure to RCE in CVE-2026-66066

The Ruby on Rails team has released fixes for CVE-2026-66066, a critical attack path in Active Storage. An application that accepts images from untrusted users and generates variants through libvips can let an attacker read any file available to the application process. File disclosure may sound less severe than remote code execution, but Rails signing secrets make this boundary especially important.

An attacker who obtains secret_key_base, the credentials master key or service credentials may be able to extend the incident beyond one upload. Patching without rotating exposed credentials can block new requests while leaving the consequences of earlier disclosure intact.

When an application is exposed

The Rails security advisory identifies two necessary conditions:

• the application allows an untrusted person to upload an image;
• Active Storage processes that image with libvips.

Affected releases are:

Rails line	Vulnerable versions	First fixed version
7.2	earlier than 7.2.3.2	7.2.3.2
8.0	8.0 through 8.0.5.0	8.0.5.1
8.1	8.1 through 8.1.3.0	8.1.3.1

Rails 6 is exposed only where an application was deliberately switched from the default MiniMagick processor to libvips. The presence of the activestorage gem alone is not proof of exposure. Teams need to inspect the effective variant processor and every route that triggers image analysis or transformation.

How an image can read a server file

An image format is effectively untrusted structured input interpreted by a complex parser. Libvips supports many loaders, and some can refer to resources beyond ordinary pixels. In the vulnerable flow, crafted input could influence how the library opened data.

Active Storage produces thumbnails, previews and other variants inside a process that can reach the application environment. If the image library is induced to open a local file, it sees that file with the process’s privileges. Possible targets therefore include application files, mounted secrets, container configuration, cloud-provider tokens and database credentials.

This is why “just a photo upload” is a boundary where an untrusted format is executed, not merely a file-write operation.

How secret disclosure can become code execution

Rails uses cryptographic secrets to protect the integrity of data exchanged between clients and servers. Theft of the relevant key can allow an attacker to construct data the application accepts as authentic. The exact next step depends on the configuration, version and deserialisation path, but the advisory explicitly assesses a route to remote code execution.

That does not mean every successful attempt immediately yields an operating-system shell. A practical chain has stages:

1. deliver an image to a libvips processing path;
2. read a valuable local file;
3. identify a useful secret or credential;
4. use it against the application or a dependent service;
5. escalate into data access, identity compromise or code execution.

Defences should interrupt several stages, and incident response should assume that the first successful read may have preceded disclosure of the patch.

Patches and mitigations

The preferred response is to update Active Storage to the fixed release for the deployed Rails line. Rebuild and restart application images after the change so that an old gem is not left inside a running container or process.

For libvips 8.13 and later, the advisory documents a control that blocks untrusted operations. Teams can set VIPS_BLOCK_UNTRUSTED or enable Vips.block_untrusted(true) with ruby-vips 2.2.1 or later. This is a useful risk-reduction layer, but it does not replace the fixed Active Storage release.

There is no equivalent mitigation for libvips older than 8.13. If an immediate Rails update is impossible, a safer emergency response is to disable libvips image processing or the affected untrusted-upload feature. Checking the filename extension and MIME header does not remove a parser vulnerability.

Response checklist

Establish exposure first:

• inventory activestorage, image_processing, ruby-vips and libvips versions;
• inspect the effective variant_processor setting;
• identify upload endpoints available anonymously or to low-privilege accounts;
• include imports, avatars, support attachments and API integrations;
• determine whether variants are generated synchronously, by a worker or on first access.

Then reduce impact:

• update Rails and libvips;
• isolate image workers from application secrets and cloud metadata;
• assign a dedicated working directory and minimum operating-system permissions;
• restrict processor egress where internet access is unnecessary;
• store user files outside the application directory;
• monitor parser failures, unusual formats and bursts of variant generation.

Which secrets should be rotated

If the application was reachable and met the vulnerability conditions, review the log-retention window and treat credential rotation as part of remediation. Priorities include:

• secret_key_base and other signing or encryption secrets;
• RAILS_MASTER_KEY, or the equivalent used to decrypt credentials;
• Active Storage keys for S3, Google Cloud Storage or Azure;
• database, queue, email and third-party API credentials;
• platform tokens visible to the process or stored on its filesystem.

Rotation may invalidate sessions, signed identifiers and active integrations. It needs coordination, but it should not be postponed merely because the HTTP log contains no obvious filename. A local read does not necessarily expose a useful file path at the application edge.

Detection requires application, worker and cloud logs

Search Rails telemetry for unusual uploads, analysis failures, libvips exceptions and bursts of variant creation. At the host or container layer, watch for the image-processing process reading secret files or making unexpected network connections.

Where a credential may have leaked, investigation cannot stop at the upload. Correlate later access to databases, object storage, cloud consoles and APIs with the image-processing timeline. A new identity, region, user agent or sudden expansion in downloaded data can reveal the second stage.

Primary facts versus Breachroad analysis

Rails confirms the vulnerability conditions, affected versions, arbitrary file read, possible path to code execution and the documented mitigation for newer libvips. That does not prove every exposed application has been exploited.

Breachroad’s conclusion is that image processing should be operated like a sandbox for untrusted code: use a separate identity, a minimal filesystem, no application secrets and no unnecessary network access. The update removes this defect; isolation limits the next parser failure.

Cybersecurity training for technical teams helps staff rehearse patch prioritisation, secret rotation and evidence-preserving response. An IT security audit can assess upload paths, worker isolation, storage and the real reach of application credentials.