CVE-2026-33173: 
Ruby vulnerability analysis and mitigation

CVE-2026-33173 is a content type bypass vulnerability in Rails Active Storage's DirectUploadsController that allows attackers to upload arbitrary file content while spoofing a safe MIME type. It affects all Rails versions prior to 7.2.3.1, 8.0.x prior to 8.0.4.1, and 8.1.x prior to 8.1.2.1. The vulnerability was disclosed on March 23, 2026, and patches were released the same day. It carries a CVSS v3.1 base score of 5.3 (Medium) (GitHub Advisory). IBM products including Aspera Faspex, CloudPak for AIOps, and License Metric Tool are also affected as downstream consumers of the Rails gem (IBM Aspera Advisory).

The root cause is improper input validation (CWE-1287) in ActiveStorage::Blob.create_before_direct_upload!, which persists client-supplied metadata directly onto the blob without filtering reserved internal keys. Active Storage uses the same metadata hash to store both user-defined data and internal processing flags — specifically analyzed, identified, and composed — which signal whether MIME detection and content analysis have been completed. A malicious client can include these flags in the direct upload request payload (e.g., metadata: { "identified" => true, "analyzed" => true }), causing Active Storage to skip its own MIME detection pipeline and accept the client-provided content_type at face value. The fix introduces a PROTECTED_METADATA constant (%w(analyzed identified composed)) and a filter_metadata method that strips these keys from any client-supplied metadata before persisting the blob (GitHub Commit, GitHub Advisory).

Successful exploitation allows an attacker to upload files with arbitrary content (e.g., executable scripts, malware, HTML for stored XSS) while the application records a benign content_type such as image/png or text/plain. Any application-level security controls that rely on Active Storage's automatic content type identification — such as file type allowlists or downstream processing restrictions — can be bypassed entirely. The primary impact is an integrity violation; confidentiality and availability are not directly affected, though the ability to store and serve malicious files could enable secondary attacks against other users or systems (GitHub Advisory, Feedly).

No public proof-of-concept exploit code has been published, and there is no evidence of in-the-wild exploitation as of the time of disclosure (Feedly). The vulnerability was responsibly reported to the Rails team via HackerOne by researcher "pwnie" (GitHub Advisory). The EPSS score is approximately 0.016% (0.000160), indicating a very low probability of exploitation in the near term. The vulnerability is not listed in the CISA Known Exploited Vulnerabilities (KEV) catalog. Exploitation requires no authentication and no special privileges, but the practical impact is constrained by the application's use of Active Storage content type checks for security decisions.

1. Identify target: Locate a Rails application using Active Storage with direct upload functionality enabled (i.e., the DirectUploadsController is mounted, typically at /rails/active_storage/direct_uploads).
2. Craft malicious upload request: Prepare a POST request to the direct uploads endpoint with a payload that includes a dangerous file (e.g., a PHP/Ruby script or HTML file) but specifies a safe content_type (e.g., image/jpeg) and injects internal metadata flags:

{
  "blob": {
    "filename": "malicious.jpg",
    "byte_size": 1234,
    "checksum": "<valid_md5_base64>",
    "content_type": "image/jpeg",
    "metadata": {
      "identified": true,
      "analyzed": true
    }
  }
}

3. Submit the request: Send the crafted POST request to /rails/active_storage/direct_uploads. The server creates a blob record with the spoofed content_type and skips MIME detection because identified is already set to true.
4. Upload file content: Use the pre-signed URL returned in the response to upload the actual malicious file content directly to the storage backend (cloud or disk).
5. Trigger downstream processing: Submit the signed blob ID through the application's normal form submission flow to associate the blob with a record, causing the application to serve or process the file as the declared safe content type, bypassing any content-type-based security controls (GitHub Advisory, GitHub Commit).

• Network: POST requests to /rails/active_storage/direct_uploads containing a metadata parameter with keys analyzed, identified, or composed set to non-null values; unusual content_type values in direct upload requests that do not match the actual file extension or magic bytes.
• Logs: Rails application logs showing blob creation via DirectUploadsController where the stored content_type does not match the file's actual MIME type as determined by independent inspection; repeated direct upload requests from the same IP with varying spoofed content types.
• File System / Storage: Blobs stored in Active Storage whose declared content_type (e.g., image/jpeg) does not match the file's actual magic bytes upon inspection; unexpected executable or script files stored in the Active Storage directory or cloud bucket with image or document extensions.

Upgrade Rails (and the activestorage gem) to one of the patched versions: 7.2.3.1, 8.0.4.1, or 8.1.2.1 depending on the branch in use (Rails Release, GitHub Release). As an interim measure, avoid relying solely on Active Storage's automatic content type detection for security-critical decisions; implement independent server-side MIME validation using a library such as Marcel or MimeMagic that inspects file magic bytes rather than trusting stored metadata. Additionally, consider restricting direct upload access to authenticated and trusted users only, and audit existing stored blobs for content type mismatches (GitHub Advisory).

The Rails core team (jhawthorn/Jean Boussier) published the advisory and patches simultaneously on March 23, 2026, alongside fixes for several other Active Storage CVEs in the same release (Rails Release). Red Hat tracked the vulnerability and assigned it a Medium severity rating (Red Hat CVE). IBM issued downstream advisories for Aspera Faspex, CloudPak for AIOps, and License Metric Tool acknowledging the inherited risk (IBM Aspera Advisory). Community reaction was measured given the Medium severity rating and absence of public exploit code.