GHSA-3rh2-v3gr-35p9 — minio
HIGHGHSA-3rh2-v3gr-35p9 is a high-severity (CVSS 7.1) Improper Authentication vulnerability in github.com/minio/minio. No vendor fix is recorded yet; mitigation options are listed below.
MinIO is Vulnerable to SSE Metadata Injection via Replication Headers
Exploitation Status
No confirmed exploitation observed yet
- CISA assesses this as automatable — exploitation doesn’t require manual, per-target effort, which raises the odds of mass scanning and opportunistic attacks.
- CISA’s own triage has not observed active exploitation or public proof-of-concept code for this CVE as of its last assessment.
Exploitation and automatability from CISA’s SSVC triage for GHSA-3rh2-v3gr-35p9.
EPSS Exploitation Probability
Probability of exploitation in the next 30 days, from FIRST.org EPSS.
How urgent is this, really
GHSA-3rh2-v3gr-35p9 by exploitation likelihood (EPSS) against impact (CVSS). Outside the shaded patch-first corner.
Where this sits among everything scored
Of 379,842 CVEs with a current EPSS score, this one falls in the < 10% band (highlighted). Counts from FIRST.org, log-scaled.
Real-World Exposure
github.com/minio/minioReal-time download stats are indexed for npm and PyPI packages. This vulnerability affects Go packages — download data is not available via public APIs for these ecosystems.
Description
Impact
What kind of vulnerability is it? Who is impacted?
A flaw in extractMetadataFromMime() allows any authenticated user 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 unconditionally maps these headers to X-Minio-Internal-* encryption metadata without verifying that the request is a legitimate replication request. Objects written this way carry bogus encryption keys and become permanently unreadable through the S3 API.
Any authenticated user or service with s3:PutObject permission on any bucket can make objects permanently unreadable by injecting fake SSE encryption metadata. The attacker sends a standard PutObject request with X-Minio-Replication-Server-Side-Encryption-* headers but without the X-Minio-Source-Replication-Request header that marks legitimate replication traffic. The server maps these headers to internal encryption metadata (X-Minio-Internal-Server-Side-Encryption-Sealed-Key, etc.), causing all subsequent GetObject and HeadObject calls to treat the object as encrypted with keys that do not exist.
This is a targeted denial-of-service vulnerability. An attacker can selectively corrupt individual objects or entire buckets. The ReplicateObjectAction IAM permission is never checked because the request is a normal PutObject, not a replication request.
Affected component: cmd/handler-utils.go, function extractMetadataFromMime().
Affected Versions
All MinIO releases through the final release of the minio/minio open-source project.
The vulnerability was introduced in commit 468a9fae83e965ecefa1c1fdc2fc57b84ece95b0 ("Enable replication of SSE-C objects", PR #19107, 2024-03-28). The first affected release is RELEASE.2024-03-30T09-41-56Z.
Patches
Fixed in: MinIO AIStor RELEASE.2026-03-26T21-24-40Z
Binary Downloads
| Platform | Architecture | Download |
|---|---|---|
| Linux | amd64 | minio |
| Linux | arm64 | minio |
| macOS | arm64 | minio |
| macOS | amd64 | minio |
| Windows | amd64 | minio.exe |
FIPS Binaries
| Platform | Architecture | Download |
|---|---|---|
| Linux | amd64 | minio.fips |
| Linux | arm64 | minio.fips |
Package Downloads
| Format | Architecture | Download |
|---|---|---|
| DEB | amd64 | minio_20260326212440.0.0_amd64.deb |
| DEB | arm64 | minio_20260326212440.0.0_arm64.deb |
| RPM | amd64 | minio-20260326212440.0.0-1.x86_64.rpm |
| RPM | arm64 | minio-20260326212440.0.0-1.aarch64.rpm |
Container Images
# Standard
docker pull quay.io/minio/aistor/minio:RELEASE.2026-03-26T21-24-40Z
podman pull quay.io/minio/aistor/minio:RELEASE.2026-03-26T21-24-40Z
# FIPS
docker pull quay.io/minio/aistor/minio:RELEASE.2026-03-26T21-24-40Z.fips
podman pull quay.io/minio/aistor/minio:RELEASE.2026-03-26T21-24-40Z.fips
Homebrew (macOS)
brew install minio/aistor/minio
Workarounds
If upgrading is not immediately possible:
-
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 carryX-Minio-Source-Replication-Request. This blocks the injection path without modifying the server. -
Audit IAM policies. Limit
s3:PutObjectgrants to trusted principals. While this reduces the attack surface, it does not eliminate the vulnerability since any authorized user can exploit it.
References
- Introducing commit:
468a9fae8(PR #19107) - MinIO AIStor
Affected Packages
| Ecosystem | Package | Vulnerable range | Fix |
|---|---|---|---|
| 🐹Go | github.com/minio/minio | ≥ 0.0.0-20240328174456-468a9fae83e9 | No fix |
Affected Products
miniominioDetection & mitigation playbook
Open-source dependencyDetect
Scan your dependency tree (package-lock.json, pnpm-lock.yaml, requirements.txt, go.sum, etc.) for github.com/minio/minio, including transitive dependencies — a direct dependency you never call can still pull in a vulnerable version.
Remediation status
No patched version of github.com/minio/minio has shipped for GHSA-3rh2-v3gr-35p9 yet. Where your build allows, override or pin the dependency away from the vulnerable range, and apply any maintainer-recommended mitigation.
Mitigate without a patch
Put an independent control in front of the weakness: restrict the affected endpoint or interface to trusted networks, require an additional authentication factor or proxy-level check, and invalidate existing sessions and credentials in case the flaw has already been used.
Frequently Asked Questions
Is GHSA-3rh2-v3gr-35p9 in your dependencies?
Find it across Go, including transitive dependencies.