CVE-2026-66066

What it actually does

CVE-2026-66066 is an information disclosure flaw in Rails Active Storage image processing when applications use libvips for image variants/previews and accept uploads from untrusted users. A crafted image upload can cause libvips to execute an operation that should be considered unsafe for untrusted content, allowing the attacker to read files accessible to the Rails application process. Depending on runtime permissions and deployment configuration, exposed files may include environment-derived secrets, Rails credentials, signing keys such as secret_key_base, cloud credentials, database credentials, API tokens, or other application configuration. If sensitive credentials are disclosed, the impact can escalate beyond file disclosure to session forgery, remote code execution through stolen signing/encryption material, access to external services, or lateral movement.

Why it matters to the business

Organizations running affected Rails versions with Active Storage configured to use libvips and accepting user-controlled image uploads risk leakage of application secrets and service credentials. The direct operational impact is unauthorized access to confidential configuration files, but the practical business impact can include account takeover, data theft, forged user sessions, compromise of cloud or third-party services, production outage from credential abuse, and incident response costs. Although this issue is not currently listed in CISA KEV and the provided EPSS score is low, the vulnerability is recent, remotely reachable, unauthenticated in affected upload workflows, and affects a common Rails component, so internet-facing upload features should be prioritized for review and patching.

How an attack unfolds

An attacker first identifies a Rails application that accepts image uploads from unauthenticated or low-privileged users and processes those uploads with Active Storage using libvips. The attacker then submits a specially crafted file that is accepted as an image and later processed to generate a variant, thumbnail, preview, or metadata-derived transformation. During processing, vulnerable Rails versions do not prevent libvips from invoking operations marked unsafe for untrusted input. The crafted content causes libvips to reference or read a local file available to the Rails process. The attacker retrieves the resulting processed output, error output, or application response containing the disclosed content. If the disclosed data includes Rails secrets, cloud credentials, database passwords, API tokens, or signing keys, the attacker can use those credentials to impersonate users, forge signed data, access backing services, deploy malicious code, or move laterally to connected systems.

How to fix it

Upgrade Rails/Action Pack to a fixed version: 7.2.3.2, 8.0.5.1, or 8.1.3.1, depending on the application branch. If using Bundler, update the Rails gems and verify that actionpack and activestorage resolve to fixed versions. If immediate upgrade is not possible, reduce exposure by disabling libvips processing for untrusted uploads, switching to a safer processor configuration where feasible, preventing automatic variant generation for untrusted content, strictly validating uploaded file types by content rather than extension alone, limiting accepted image formats, and isolating image processing in a sandboxed worker with minimal filesystem and secret access. Ensure the Rails process and image-processing workers run with least privilege and cannot read unnecessary secrets or host files. Rotate any credentials that may have been readable by the Rails process if exploitation is suspected.

How to confirm the fix worked

Confirm dependency versions with package tooling and runtime inspection. For Bundler-based applications, check Gemfile.lock for actionpack and activestorage versions and ensure they are at least 7.2.3.2, 8.0.5.1, or 8.1.3.1. Verify the application is actually running the updated build after deployment by checking container images, release artifacts, and runtime gem versions. Review Active Storage configuration to determine whether libvips is enabled, commonly through config.active_storage.variant_processor = :vips. Validate exposure by identifying upload flows that accept user-supplied images and generate variants or previews. After patching, test that normal image uploads and variant generation still work, and that crafted files intended to trigger unsafe libvips behavior are rejected, fail safely, or do not disclose local file contents. Also verify that image-processing workers have restricted filesystem access and do not inherit unnecessary production secrets.

Typical attack path

1. Find a Rails application with an upload endpoint that accepts image files from untrusted users.
2. Confirm that uploaded images are processed by Active Storage variants, previews, thumbnails, or metadata extraction using libvips.
3. Upload a crafted image designed to trigger an unsafe libvips operation during server-side processing.
4. Trigger processing by viewing the uploaded image, requesting a resized variant, or waiting for background variant generation.
5. Retrieve the generated response, derivative file, error output, or side effect that contains data read from the server filesystem.
6. Extract secrets such as Rails signing keys, credentials, environment configuration, service tokens, or cloud credentials.
7. Use the stolen secrets to forge sessions, access data stores or third-party services, execute code through trusted integrations, or move laterally.

How to detect it

Investigate whether untrusted image uploads were processed by affected Rails versions using libvips before patching. Review web access logs for upload endpoints followed by Active Storage representation, variant, preview, or redirect requests from the same source. Examine Rails application logs and background job logs for ActiveStorage::AnalyzeJob, ActiveStorage::TransformJob, image_processing, ruby-vips, or Vips::Error messages associated with unusual uploads or failed transformations. Look for uploads with misleading extensions, uncommon image formats, SVG/XML-like content submitted as images, or files that trigger libvips loader behavior unexpectedly. Review object storage or local Active Storage blob records for recently uploaded files with small sizes, strange metadata, unexpected content types, or repeated transformation attempts. Correlate suspicious processing events with subsequent authentication anomalies, session forgery indicators, cloud API activity, database access from unusual locations, or use of secrets that would normally only be available to the Rails runtime. If exploitation is suspected, preserve uploaded original blobs, generated variants, application logs, job logs, container logs, and relevant access logs before cleanup. Named threat actor exploitation is not provided, and the issue is not currently marked as known exploited, so detection should focus on behavioral evidence around crafted uploads and downstream credential misuse rather than a single definitive signature.

• config.active_storage.variant_processor = :vips
• ActiveStorage::AnalyzeJob
• ActiveStorage::TransformJob
• ActiveStorage::Previewer
• ActiveStorage::Representations
• /rails/active_storage/blobs/
• /rails/active_storage/representations/
• /rails/active_storage/disk/
• Vips::Error
• ruby-vips
• image_processing
• libvips
• ActiveStorage::IntegrityError
• ActiveStorage::InvariableError
• ActiveStorage::UnpreviewableError
• Content-Type: image/svg+xml
• <?xml
• <!DOCTYPE
• xlink:href="file://
• href="file://
• file:///etc/passwd
• file:///proc/self/environ
• secret_key_base
• RAILS_MASTER_KEY

What your security team should do

• Inventory Rails applications that use Active Storage and accept user-controlled image uploads, especially internet-facing or unauthenticated upload workflows.
• Prioritize upgrades to Rails/Action Pack fixed versions 7.2.3.2, 8.0.5.1, or 8.1.3.1 for applications using libvips.
• Search code and configuration for config.active_storage.variant_processor = :vips and review whether untrusted uploads are processed automatically.
• Temporarily disable or restrict variant and preview generation for untrusted uploads where rapid patching is not possible.
• Review recent upload, application, background job, and object storage logs for suspicious crafted image uploads, repeated processing failures, or unusual variant requests.
• Rotate Rails secrets, signing keys, cloud credentials, database passwords, and external-service tokens if there is evidence that arbitrary file read was attempted or successful.
• Run image-processing components with least privilege, sandboxing, read-only filesystems where possible, and minimal environment variables.
• Add monitoring for anomalous Active Storage errors, libvips processing exceptions, unexpected upload MIME types, and high-volume variant generation attempts.