CVE-2026-33221: 
vulnerability analysis and mitigation

CVE-2026-33221 is a MIME type spoofing vulnerability in Nhost's open-source storage service that allows unauthenticated attackers to upload files with arbitrary, attacker-controlled MIME types by bypassing server-side content-type validation. The flaw affects the nhost/storage service in all versions prior to 0.12.0. It was disclosed on March 18, 2026, via a GitHub Security Advisory (GHSA-g9f6-9775-hffm) and published to the NVD on March 20, 2026. The vulnerability carries a CVSS v3.1 score of 5.3 (Medium) and a CVSS v4.0 score of 2.1 (Low) (GitHub Advisory).

The root cause lies in the getMultipartFile function within services/storage/controller/upload_files.go (lines 48–70), which unconditionally trusts the client-supplied Content-Type HTTP header. If the header is non-empty and not application/octet-stream, the function returns the client-provided value immediately without invoking mimetype.DetectReader for server-side content inspection (GitHub Advisory, Nhost Security Advisory). This maps to CWE-345 (Insufficient Verification of Data Authenticity) and CWE-434 (Unrestricted Upload of File with Dangerous Type). An attacker simply sets an arbitrary Content-Type header in a multipart file upload request to store a spoofed MIME type in file metadata, requiring no authentication or special privileges (GitHub Advisory).

The primary impact is integrity degradation: the MIME type stored in file metadata reflects the attacker's claim rather than the file's actual content, causing downstream systems — including browsers, CDNs, and application logic — to mishandle the file based on the spoofed type (Nhost Security Advisory). This can be used to bypass MIME-type-based access controls or upload restrictions configured on storage buckets, potentially enabling delivery of malicious content disguised as a benign file type. There is no direct confidentiality or availability impact, and the vulnerability does not by itself enable remote code execution or lateral movement (GitHub Advisory).

No public proof-of-concept exploit code is known to exist, and there is no evidence of in-the-wild exploitation at this time (GitHub Advisory). The vulnerability is not listed in the CISA Known Exploited Vulnerabilities (KEV) catalog. The EPSS score is approximately 0.007% (1st percentile), indicating a very low probability of exploitation in the near term. The vulnerability was reported by security researcher 0xkakash1 (Nhost Security Advisory).

1. Identify target: Locate an Nhost deployment running the storage service at version prior to 0.12.0, accessible over the network.
2. Craft malicious upload request: Prepare a multipart file upload HTTP request containing a file of any type (e.g., an executable or HTML file).
3. Spoof the Content-Type header: Set the Content-Type header of the file part to an arbitrary MIME type (e.g., image/png for an HTML file, or text/plain for a binary), exploiting the fact that the server skips mimetype.DetectReader for any non-empty, non-application/octet-stream value.
4. Submit the upload: Send the crafted multipart request to the storage service's file upload endpoint. The server stores the attacker-supplied MIME type in file metadata without validation.
5. Abuse downstream behavior: Retrieve or share the uploaded file. Browsers, CDNs, or application logic consuming the metadata will treat the file according to the spoofed MIME type, potentially bypassing content-type restrictions or causing unsafe rendering (GitHub Advisory, Nhost Security Advisory).

• Network: Multipart file upload requests to the Nhost storage service endpoint where the Content-Type header of the file part does not match the actual file content type (e.g., an executable uploaded with Content-Type: image/png).
• Logs: Storage service access logs showing file uploads where the recorded MIME type in metadata is inconsistent with the file extension or actual content (e.g., .exe files stored with image/jpeg MIME type).
• File System / Metadata: Files in storage buckets whose stored MIME type metadata does not correspond to the actual file content as determined by independent content inspection.

Upgrade the Nhost storage service to version 0.12.0 or later, which resolves the issue by always invoking mimetype.DetectReader on file content and ignoring the client-provided Content-Type header entirely (Nhost Release, GitHub Advisory). The fix was introduced in commit c4bd53f via pull request #4018 (Nhost PR #4018). As a temporary workaround where patching is not immediately possible, configure downstream systems (browsers, CDNs, applications) to validate file content type based on actual content inspection rather than relying solely on stored metadata.