CVE-2026-34204: 
MinIO vulnerability analysis and mitigation

CVE-2026-34204 is a server-side encryption (SSE) metadata injection vulnerability in MinIO, a high-performance object storage system, that allows any authenticated user with s3:PutObject permission to render stored objects permanently unreadable. The flaw exists in the extractMetadataFromMime() function within cmd/handler-utils.go, which unconditionally maps X-Minio-Replication-* HTTP headers to internal encryption metadata without verifying the request is a legitimate replication operation. All MinIO releases from RELEASE.2024-03-30T09-41-56Z through the final open-source release are affected; the fix is available in MinIO AIStor RELEASE.2026-03-26T21-24-40Z. The vulnerability carries a CVSS v3.1 base score of 7.1 (High) and a CVSS v4.0 base score of 7.1 (High) (GitHub Advisory, MinIO Advisory).

The root cause is classified as CWE-287 (Improper Authentication): the server fails to verify that a PutObject request carrying X-Minio-Replication-Server-Side-Encryption-* headers is actually a legitimate replication request (i.e., it does not check for the X-Minio-Source-Replication-Request header or the ReplicateObjectAction IAM permission) (GitHub Advisory). An attacker sends a standard PutObject request with crafted X-Minio-Replication-Server-Side-Encryption-* headers; the server maps these to internal metadata fields such as X-Minio-Internal-Server-Side-Encryption-Sealed-Key, causing the object to be stored with bogus encryption key references. All subsequent GetObject and HeadObject calls then treat the object as encrypted with non-existent keys, making it permanently inaccessible via the S3 API. The vulnerability was introduced in commit 468a9fae83e9 (PR #19107, "Enable replication of SSE-C objects", 2024-03-28) (MinIO Advisory).

Successful exploitation results in a targeted denial-of-service against stored data: any authenticated user with s3:PutObject permission can selectively corrupt individual objects or entire buckets, making them permanently unreadable through the S3 API without deleting them. There is no confidentiality impact (data is not exposed), but integrity is degraded (bogus metadata is written) and availability is severely impacted for affected objects. Because the attack requires only standard s3:PutObject access — a broadly granted permission in many deployments — the blast radius can extend to all buckets accessible to the attacker's credentials (GitHub Advisory, MinIO Advisory).

No public proof-of-concept exploit code or evidence of in-the-wild exploitation has been reported as of the time of this report. The EPSS score is approximately 0.023% (10th percentile), indicating a low near-term exploitation probability (GitHub Advisory). The vulnerability is not listed in the CISA Known Exploited Vulnerabilities (KEV) catalog. Exploitation requires valid credentials with s3:PutObject permission, limiting the attack surface to authenticated insiders or compromised accounts, though the technique itself is straightforward to execute with standard S3 tooling.

1. Reconnaissance: Identify a MinIO instance running a version between RELEASE.2024-03-30T09-41-56Z and the last open-source release. Confirm access credentials with s3:PutObject permission on one or more buckets.
2. Craft malicious PutObject request: Prepare an HTTP PUT request targeting a specific object key in a bucket. Include crafted X-Minio-Replication-Server-Side-Encryption-* headers (e.g., X-Minio-Replication-Server-Side-Encryption-Sealed-Key: <arbitrary_value>) but deliberately omit the X-Minio-Source-Replication-Request header.
3. Submit the request: Send the crafted PutObject request to the MinIO S3 API endpoint (e.g., PUT /bucket/object). The server's extractMetadataFromMime() function maps the replication headers to internal metadata (X-Minio-Internal-Server-Side-Encryption-Sealed-Key, etc.) without validating the request origin.
4. Verify corruption: Attempt a GetObject or HeadObject call on the targeted object. The server will treat the object as SSE-encrypted with a non-existent key and return an error, confirming the object is permanently inaccessible.
5. Scale the attack: Repeat for additional objects or enumerate all objects in a bucket and apply the injection to each, effectively rendering entire buckets unreadable (GitHub Advisory, MinIO Advisory).

• Network: Inbound PutObject requests (PUT /bucket/object) containing X-Minio-Replication-Server-Side-Encryption-* headers but lacking the X-Minio-Source-Replication-Request header; unusual volume of PutObject requests from a single authenticated principal targeting multiple objects or buckets.
• Logs: MinIO access logs showing PutObject operations with X-Minio-Replication-* headers from non-replication source IPs or accounts; subsequent GetObject/HeadObject errors (e.g., decryption failures) on objects recently written by the same principal.
• File System / Metadata: Objects stored with X-Minio-Internal-Server-Side-Encryption-Sealed-Key metadata set to arbitrary or malformed values, detectable via MinIO admin metadata inspection tools.
• Behavioral: A pattern of objects becoming unreadable shortly after being written or overwritten by a specific user account, particularly if that account does not normally perform replication operations (GitHub Advisory).

The primary fix is to upgrade to MinIO AIStor RELEASE.2026-03-26T21-24-40Z or later, which correctly validates replication request authenticity before mapping replication headers to internal encryption metadata (MinIO Advisory). If immediate upgrade is not possible, two workarounds are available: (1) configure a reverse proxy or load balancer to drop or reject any PutObject request containing X-Minio-Replication-Server-Side-Encryption-* headers that does not also include the X-Minio-Source-Replication-Request header; and (2) audit and restrict IAM policies to limit s3:PutObject grants to only trusted principals, reducing the attack surface though not eliminating the vulnerability. Note that the open-source minio/minio repository has been archived and will not receive further patches; users must migrate to MinIO AIStor for ongoing security support (GitHub Advisory).

The advisory was published by MinIO maintainer harshavardhana on March 27, 2026, with remediation review credited to donatello and shtripat (GitHub Advisory). The disclosure coincided with the archiving of the open-source minio/minio repository on April 25, 2026, prompting TuxCare to announce an Endless Lifecycle Support offering for MinIO users who cannot immediately migrate to AIStor. Security aggregators including VulDB, CVEFeed, and OpenSUSE security lists picked up the advisory, and a technical write-up was published at infinitsec.net shortly after disclosure.