Replication-header injection can permanently brick MinIO S3 objects

TL;DR — Authenticated S3 clients can poison MinIO objects with fake server-side encryption metadata via replication headers, permanently breaking GetObject/HeadObject access (data availability DoS).

What happened

MinIO is an S3-compatible object storage server commonly deployed for self-hosted and private-cloud object storage.

A GitHub-reviewed advisory for CVE-2026-34204 reports that a flaw in extractMetadataFromMime() allows any authenticated principal with s3:PutObject permission to inject internal server-side encryption metadata into objects by sending crafted X-Minio-Replication-* headers on a normal PutObject request. The server maps these headers to X-Minio-Internal-* encryption metadata without verifying that the request is a legitimate replication request.

Per the advisory, objects written this way carry bogus encryption keys and become permanently unreadable via the S3 API. This enables targeted availability impact (selective object/bucket “bricking”) without requiring the ReplicateObjectAction IAM permission, because the request is processed as a normal PutObject.

This is the kind of “internal header trust” bug that tends to slip through review: replication and management-plane features frequently re-use data-plane paths, and header-driven control planes can silently widen attack surface in multi-tenant or shared-bucket environments.

Who is impacted

• Any MinIO deployment where untrusted or semi-trusted identities can perform s3:PutObject to buckets (including CI/CD uploaders, partner integrations, or multi-tenant workloads).
• The advisory states impact is availability: objects can be made unreadable via S3 API calls.

What to do now

• Follow vendor remediation guidance and apply the latest patched release available at the time of writing.

  "Users of the open-source minio/minio project should upgrade to MinIO AIStor RELEASE.2026-03-26T21-24-40Z or later."

• If upgrading is not immediately possible, apply the advisory’s workaround guidance:

  • "Restrict replication headers at a reverse proxy / load balancer. Drop or reject any request containing X-Minio-Replication-Server-Side-Encryption-* headers that does not also carry X-Minio-Source-Replication-Request."

  • "Audit IAM policies. Limit s3:PutObject grants to trusted principals."

• Treat unexplained object-read failures as a potential security signal: prioritize investigation where PutObject traffic originates from shared service accounts and where buckets accept uploads from external systems.