Skip to content

Nhost Storage Affected by MIME Type Spoofing via Trusted Client Content-Type Header in Storage Upload

Low severity GitHub Reviewed Published Mar 18, 2026 in nhost/nhost

Package

gomod github.com/nhost/nhost (Go)

Affected versions

< 0.0.0-20260318074820-c4bd53f042d7

Patched versions

0.0.0-20260318074820-c4bd53f042d7

Description

Summary

The storage service's file upload handler trusts the client-provided Content-Type header without performing server-side MIME type detection. This allows an attacker to upload files with an arbitrary MIME type, bypassing any MIME-type-based restrictions configured on storage buckets.

Affected Component

  • Service: services/storage
  • File: services/storage/controller/upload_files.go
  • Function: getMultipartFile (lines 48-70)

Root Cause

In getMultipartFile, if the client provides a non-empty Content-Type header that isn't application/octet-stream, the function returns it as-is without performing content-based detection:

contentType := file.header.Header.Get("Content-Type")
if contentType != "" && contentType != "application/octet-stream" {
    return fileContent, contentType, nil // skip detection entirely
}

// mimetype.DetectReader only reached if client sends no Content-Type
// or sends application/octet-stream
mt, err := mimetype.DetectReader(fileContent)

Impact

Incorrect MIME type in file metadata. The MIME type stored in file metadata reflects what the client claims rather than what the file actually contains. Any system consuming this metadata (browsers, CDNs, applications) may handle the file incorrectly based on the spoofed type.

Suggested Fix

Always detect MIME type from file content using mimetype.DetectReader, ignoring the client-provided Content-Type header entirely.

References

  • CWE-345: Insufficient Verification of Data Authenticity
  • CWE-434: Unrestricted Upload of File with Dangerous Type

References

@dbarrosop dbarrosop published to nhost/nhost Mar 18, 2026
Published to the GitHub Advisory Database Mar 18, 2026
Reviewed Mar 18, 2026

Severity

Low

CVSS overall score

This score calculates overall vulnerability severity from 0 to 10 and is based on the Common Vulnerability Scoring System (CVSS).
/ 10

CVSS v3 base metrics

Attack vector
Network
Attack complexity
High
Privileges required
None
User interaction
Required
Scope
Unchanged
Confidentiality
None
Integrity
None
Availability
None

CVSS v3 base metrics

Attack vector: More severe the more the remote (logically and physically) an attacker can be in order to exploit the vulnerability.
Attack complexity: More severe for the least complex attacks.
Privileges required: More severe if no privileges are required.
User interaction: More severe when no user interaction is required.
Scope: More severe when a scope change occurs, e.g. one vulnerable component impacts resources in components beyond its security scope.
Confidentiality: More severe when loss of data confidentiality is highest, measuring the level of data access available to an unauthorized user.
Integrity: More severe when loss of data integrity is the highest, measuring the consequence of data modification possible by an unauthorized user.
Availability: More severe when the loss of impacted component availability is highest.
CVSS:3.1/AV:N/AC:H/PR:N/UI:R/S:U/C:N/I:N/A:N

EPSS score

Weaknesses

Insufficient Verification of Data Authenticity

The product does not sufficiently verify the origin or authenticity of data, in a way that causes it to accept invalid data. Learn more on MITRE.

Unrestricted Upload of File with Dangerous Type

The product allows the upload or transfer of dangerous file types that are automatically processed within its environment. Learn more on MITRE.

CVE ID

CVE-2026-33221

GHSA ID

GHSA-g9f6-9775-hffm

Source code

Credits

Loading Checking history
See something to contribute? Suggest improvements for this vulnerability.