A critical vulnerability in Ruby on Rails could allow unauthenticated attackers to manipulate files on vulnerable application servers simply by uploading a specially crafted file.
Tracked as CVE-2026-122006, the vulnerability affects the Active Storage component of Ruby on Rails and carries a CVSS 3.1 score of 9.8 (Critical). Successful exploitation can enable arbitrary file writes and, under certain storage configurations, unauthorized access to sensitive files containing application secrets and credentials.
The Ruby on Rails security team disclosed the vulnerability on November 4, 2026, and released fixes in Rails versions 8.0.5.2 and 8.1.4.1.
CVE-2026-122006 Overview
CVE-2026-122006 is an insecure-default-configuration vulnerability, classified as CWE-1188, involving the interaction between Rails Active Storage and ImageMagick.
Active Storage is the framework component responsible for attaching files to application records, managing uploads, and processing media such as images and videos.
The vulnerability arises when Active Storage uses ImageMagick to analyze uploaded images without adequately restricting the image-processing operations that ImageMagick is permitted to perform.
According to the Rails security advisory, an attacker who can upload a specially crafted file may be able to invoke ImageMagick functionality that reads or writes files beyond the intended image-processing operation.
Crucially, the vulnerable analyzer runs automatically when a file is attached. An attacker does not need to trigger a separate image preview, request a thumbnail, or wait for the application to explicitly invoke an image-analysis operation.
This creates a potentially dangerous attack surface in applications that accept user-generated content, including profile pictures, support attachments, uploaded documents, and other media.
How Attackers Can Exploit CVE-2026-122006
ImageMagick supports numerous file formats through specialized components known as coders. Although most coders handle ordinary image decoding and conversion, others provide additional functionality, including scripting, external file access, and interaction with other processing tools.
ImageMagick can select a coder based on the contents of a file rather than relying exclusively on its filename or extension.
Before the security update, Active Storage did not enforce its own restrictive ImageMagick security policy. Consequently, an attacker-controlled upload could reach functionality that was permitted by the underlying server’s ImageMagick configuration.
The Rails patch commit identifies one reported attack chain involving a malicious SVG image and ImageMagick’s MSL (Magick Scripting Language) coder.
MSL supports image-processing instructions that can reference files on the filesystem. When reached through the vulnerable analyzer, this functionality could be abused to perform unintended file operations.
The attack sequence can be summarized as follows:
- An attacker identifies a vulnerable Rails application that accepts uploads from untrusted users.
- The attacker submits a specially crafted image file designed to reach unsafe ImageMagick functionality.
- Active Storage automatically invokes its ImageMagick analyzer when the file is attached.
- ImageMagick processes the malicious content using a permitted coder, potentially accessing or modifying files outside the intended upload-processing workflow.
- Depending on the application’s storage configuration and filesystem permissions, the attacker may obtain sensitive information, overwrite server files, or establish conditions for further compromise.
Rails confirmed that one specific exploitation chain was privately reported, but warned that other attack paths may also exist.
The underlying issue is therefore broader than a single malicious file format. It concerns the ability of untrusted uploads to access ImageMagick operations that should not be available during routine attachment processing.
Potential Impact
The consequences of successful exploitation depend on the permissions of the application process, the available ImageMagick coders, and how attachments are stored.
Arbitrary file writes
An attacker may be able to create or overwrite files accessible to the application process. This introduces risks ranging from application disruption and data manipulation to more serious compromise if sensitive configuration files or executable resources can be modified.
Sensitive file disclosure
When Active Storage uses its local Disk storage service, the vulnerability can additionally expose arbitrary files readable by the application process.
Potential targets include Rails application secrets such as secret_key_base, the Rails master key, database credentials, storage credentials, and authentication tokens for external services.
Access to these secrets could undermine application security controls and expose connected infrastructure.
Remote code execution and lateral movement
Although CVE-2026-122006 is fundamentally a file-access vulnerability, Rails warns that the resulting access to sensitive files and credentials could enable subsequent remote code execution or lateral movement.
For example, compromised application credentials could provide an attacker with access to databases, cloud storage, or external services integrated with the affected application.
These outcomes represent potential follow-on attacks rather than confirmed capabilities of every vulnerable deployment.
Affected Rails Versions and Configurations
The following Active Storage versions are affected:
| Active Storage branch | Affected versions | Fixed version |
| 8.1 | 8.1 through versions before 8.1.4.1 | 8.1.4.1 |
| 8.0 | Versions before 8.0.5.2 | 8.0.5.2 |
| 7.2 and earlier | Affected versions using the vulnerable configuration | No patched release in these branches |
However, running an affected version alone does not necessarily make an application exploitable.
According to Rails, the vulnerable configuration requires all three conditions:
- The application uses ImageMagick for Active Storage processing through config.active_storage.variant_processor = :mini_magick. This is the default for applications using Rails configuration defaults from version 6.1 or earlier.
- The ImageMagick security policy does not already block the dangerous coders involved in the attack. Rails notes that the policies distributed with Debian and Ubuntu do not provide sufficient restrictions.
- The application accepts file uploads from untrusted users.
Applications using the alternative libvips image processor are not exposed to this specific ImageMagick attack path.
Organizations should also examine upload functionality requiring authentication. An application that allows public account registration may still expose the vulnerable processing path to an untrusted attacker.
Mitigation and Recommendations
Organizations operating potentially vulnerable Rails applications should prioritize the following actions.
1. Upgrade to a patched Rails release
Update affected applications to Active Storage 8.0.5.2 or 8.1.4.1, or a later patched release.
Applications running older Rails branches should plan migration to a supported release or implement the vendor-provided security policy workaround.
2. Ensure MiniMagick compatibility
Applications using the :mini_magick variant processor must run mini_magick version 5.1 or later.
The updated Rails releases require this version to apply the new ImageMagick security policy. Applications using an older MiniMagick version may fail to start after upgrading.
3. Enforce restrictive ImageMagick security policies
The patched Rails releases introduce a dedicated ImageMagick security policy that blocks dangerous functionality.
Restricted coders include MSL, coders that access external files or network resources, and several Ghostscript-backed formats. The policy also restricts filename indirection mechanisms.
Organizations unable to upgrade immediately should copy the vendor-provided policy rules into their system-level ImageMagick configuration.
The complete policy is available in the Rails source at activestorage/lib/active_storage/image_magick/policy.xml.
Administrators must also verify that custom MiniMagick configurations do not bypass the new policy. Applications using GraphicsMagick require separate protections because GraphicsMagick does not load ImageMagick policies.
4. Review upload functionality and reduce exposure
Identify all application endpoints that accept files from untrusted users.
Where practical, restrict accepted file types, validate uploaded content, enforce reasonable upload limits, and minimize the permissions granted to image-processing services.
These measures provide additional defense in depth but should not be treated as substitutes for the vendor’s security fix.
5. Rotate potentially exposed application secrets
Rails specifically recommends rotating secret_key_base and other secrets readable by the application process when attachments are stored using the Disk service.
This includes the Rails master key, database credentials, storage credentials, and third-party API tokens.
Applications showing evidence of compromise should undergo a broader credential review and incident-response investigation, regardless of their storage configuration.
6. Validate remediation
After applying the security update, verify that the application loads the intended ImageMagick security policies and that restricted coders cannot be accessed through the normal processing environment.
Rails provides the following command to inspect the policy loaded through MiniMagick:
bin/rails runner ‘puts MiniMagick.identify { |i| i.list “policy” }’
Administrators should also test legitimate image-processing workflows following remediation, especially where applications rely on PDF or PostScript processing, which may be affected by the stricter policy.
Stay Safe. Stay Secure.
OP Innovate Research Team
