CVE-2026-33173

What it actually does

Active Storage direct uploads in affected Rails versions trust client-supplied metadata and persist it with the blob. Because security-relevant internal state such as whether a blob has been identified or analyzed is stored in the same metadata structure, a client can mark an upload as already processed and provide a benign content type. Applications that rely on Active Storage’s automatic MIME identification, analyzer results, or validations based on those values may then accept files whose actual bytes do not match the claimed type. The flaw is an input-validation and trust-boundary issue; by itself it does not grant code execution, but it can bypass file-type controls and may enable stored malicious content, unsafe downstream processing, or policy evasion depending on how uploaded files are later used.

Why it matters to the business

Organizations using affected Rails versions with Active Storage direct uploads may accept unsafe or disallowed files while believing normal file validation has occurred. This can undermine upload restrictions for user-generated content, document portals, media workflows, support attachments, or any application logic that depends on MIME type detection. Consequences may include malicious content being stored and served, compliance violations from accepting prohibited file types, exposure to downstream parser or antivirus gaps, and increased incident response burden. The current public exploitation signal is low: it is not listed in CISA KEV, is not reported as ransomware-associated, has low EPSS, and has no known exploit maturity in the provided data; however, the affected ecosystem is broad because Rails is commonly embedded in many web applications.

How an attack unfolds

An attacker first identifies a Rails application that exposes Active Storage direct-upload functionality and enforces upload restrictions based on Active Storage’s identified content type or analysis results. The attacker initiates a direct upload request and supplies normal file attributes, but also includes crafted metadata that sets internal processing flags such as the blob being already identified or analyzed. The attacker then provides a safe-looking declared content type, such as an allowed image or document type, while uploading content whose actual bytes represent a different or disallowed format. In vulnerable versions, the server persists the attacker-controlled metadata and may skip MIME identification or analysis. If the application’s validation logic trusts those skipped results, the upload is accepted and stored. The attacker can then use the accepted file wherever the application makes it available, potentially causing malicious content to be downloaded, rendered, processed by another component, or used to bypass business rules.

How to fix it

Upgrade Rails/Active Storage to a patched version: 8.1.2.1 or later for the 8.1 branch, 8.0.4.1 or later for the 8.0 branch, and 7.2.3.1 or later for the 7.2 branch. If immediate upgrade is not possible, mitigate by rejecting or stripping client-supplied metadata keys that overlap with internal Active Storage processing state, especially flags such as identified and analyzed; perform server-side MIME detection using file bytes before accepting attachments; do not rely solely on client-provided content_type; and apply allowlists based on independently verified content. Consider reprocessing or revalidating previously uploaded files in applications where upload restrictions are security-sensitive.

How to confirm the fix worked

Confirm the running Rails and Active Storage versions are at or above the fixed releases for the deployed branch. Review dependency lockfiles and deployed container or package manifests to ensure no vulnerable Rails version remains in production, staging, or background worker images. Functionally validate the patch by attempting a direct upload that supplies client metadata containing internal processing flags and a mismatched content_type; a fixed or mitigated system should not allow client metadata to bypass server-side identification or analysis. Also verify that application-level validators perform server-side content checks and that disallowed file bytes are rejected even when the declared content type is allowed.

Typical attack path

1. Locate a Rails application that uses Active Storage direct uploads.
2. Determine whether uploads are accepted based on Active Storage content type, identification status, or analyzer metadata.
3. Create a direct-upload request that includes client-controlled metadata with internal flags such as identified or analyzed set to trusted values.
4. Declare an allowed content_type while supplying file bytes that are actually a prohibited or unsafe type.
5. Complete the upload and attach the blob through the application workflow.
6. Use the accepted file to bypass upload policy, store malicious content, trigger unsafe downstream processing, or evade review controls.

How to detect it

To assess prior exploitation, review web access logs, application logs, request audit logs, WAF events, and upload telemetry for Active Storage direct-upload requests containing client-supplied metadata keys that should be server-controlled. Focus on POST requests to direct-upload endpoints where metadata includes identified, analyzed, or similar internal processing flags, especially when paired with a benign declared content_type and later attachment of files that fail independent magic-byte or MIME inspection. Compare declared content types against server-side file signature results for recently uploaded blobs, and prioritize files uploaded by newly created, unauthenticated, or low-reputation users if the application supports public uploads. Look for accepted uploads where analyzer jobs did not run, MIME identification was skipped, or downstream workflows treated unverified content as allowed. There are no provided named threat actors, KEV activity, or ransomware campaigns for this issue, so detection should be behavior-based rather than actor-based.

• POST /rails/active_storage/direct_uploads
• ActiveStorage::DirectUploadsController
• "metadata"
• "identified":true
• "identified":"true"
• "analyzed":true
• "analyzed":"true"
• "content_type":"image/png"
• "content_type":"image/jpeg"
• "content_type":"application/pdf"
• "identified"
• "analyzed"
• /rails/active_storage/direct_uploads

What your security team should do

• Prioritize upgrading Rails to 8.1.2.1, 8.0.4.1, or 7.2.3.1 or later across all applications using Active Storage direct uploads.
• Inventory Rails applications that expose /rails/active_storage/direct_uploads or custom direct-upload endpoints.
• Identify upload workflows where security decisions depend on Active Storage content_type, identified, analyzed, or analyzer-derived metadata.
• Add server-side file-type validation based on file bytes and enforce allowlists independent of client-supplied metadata.
• Search historical upload logs for direct-upload requests containing suspicious metadata keys such as identified or analyzed.
• Revalidate or quarantine previously uploaded files in high-risk workflows such as public file sharing, document intake, image rendering, or attachment processing.
• Add regression tests that submit mismatched file content and declared content types through direct upload paths.
• Monitor framework advisories for Rails and Active Storage because this issue affects common application infrastructure even though current EPSS and KEV signals are low.