GHSA-hv4r-mvr4-25vw is a high-severity (CVSS 8.2) Improper Authentication vulnerability in github.com/minio/minio. O3 Security confirms whether GHSA-hv4r-mvr4-25vw is actually reachable in your code before you act, and blocks exploitation at runtime until you patch.
MinIO has an Unauthenticated Object Write via Query-String Credential Signature Bypass in Unsigned-Trailer Uploads
Exploitation Status
No confirmed exploitation observed yet
- A successful exploit gives an attacker total control of the affected component, not partial access.
- 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-hv4r-mvr4-25vw.
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?
An authentication bypass vulnerability in MinIO's STREAMING-UNSIGNED-PAYLOAD-TRAILER code path
allows any user who knows a valid access key to write arbitrary objects to any bucket without knowing
the secret key or providing a valid cryptographic signature.
Any MinIO deployment is impacted. The attack requires only a valid access key (the well-known default
minioadmin, or any key with WRITE permission on a bucket) and a target bucket name.
PutObjectHandler and PutObjectPartHandler call newUnsignedV4ChunkedReader with a signature
verification gate based solely on the presence of the Authorization header:
newUnsignedV4ChunkedReader(r, true, r.Header.Get(xhttp.Authorization) != "")
Meanwhile, isPutActionAllowed extracts credentials from either the Authorization header or the
X-Amz-Credential query parameter, and trusts whichever it finds. An attacker omits the
Authorization header and supplies credentials exclusively via the query string. The signature gate
evaluates to false, doesSignatureMatch is never called, and the request proceeds with the
permissions of the impersonated access key.
This affects PutObjectHandler (standard and tables/warehouse bucket paths) and
PutObjectPartHandler (multipart uploads).
Affected components: cmd/object-handlers.go (PutObjectHandler),
cmd/object-multipart-handlers.go (PutObjectPartHandler).
Affected Versions
All MinIO releases through the final release of the minio/minio open-source project.
The vulnerability was introduced in commit
76913a9fd
("Signed trailers for signature v4", PR #16484),
which added authTypeStreamingUnsignedTrailer support. The first affected release is
RELEASE.2023-05-18T00-05-36Z.
Patches
Fixed in: MinIO AIStor RELEASE.2026-04-11T03-20-12Z
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_20260411032012.0.0_amd64.deb |
| DEB | arm64 | minio_20260411032012.0.0_arm64.deb |
| RPM | amd64 | minio-20260411032012.0.0-1.x86_64.rpm |
| RPM | arm64 | minio-20260411032012.0.0-1.aarch64.rpm |
Container Images
# Standard
docker pull quay.io/minio/aistor/minio:RELEASE.2026-04-11T03-20-12Z
podman pull quay.io/minio/aistor/minio:RELEASE.2026-04-11T03-20-12Z
# FIPS
docker pull quay.io/minio/aistor/minio:RELEASE.2026-04-11T03-20-12Z.fips
podman pull quay.io/minio/aistor/minio:RELEASE.2026-04-11T03-20-12Z.fips
Homebrew (macOS)
brew install minio/aistor/minio
Workarounds
If upgrading is not immediately possible:
-
Block unsigned-trailer requests at the load balancer. Reject any request containing
X-Amz-Content-Sha256: STREAMING-UNSIGNED-PAYLOAD-TRAILERat the reverse proxy or WAF layer. Clients can useSTREAMING-AWS4-HMAC-SHA256-PAYLOAD-TRAILER(the signed variant) instead. -
Restrict WRITE permissions. Limit
s3:PutObjectgrants to trusted principals. While this reduces the attack surface, it does not eliminate the vulnerability since any user with WRITE permission can exploit it with only their access key.
Credits
- Finder: Arvin Shivram of Brutecat Security (@ddd)
Affected Packages
| Ecosystem | Package | Vulnerable range | Fix |
|---|---|---|---|
| 🐹Go | github.com/minio/minio | ≥ 0.0.0-20230506025312-76913a9fd5c6 | No fix |
Detection & 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. O3's reachability analysis confirms whether the vulnerable code path is actually invoked in your application, so you act on real exposure instead of every transitive match.
Remediation status
No patched version of github.com/minio/minio has shipped for GHSA-hv4r-mvr4-25vw 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
If you can't upgrade right away: gate or disable the affected feature, validate untrusted input at the boundary, and avoid passing attacker-controlled data into the vulnerable path. O3's runtime protection blocks exploitation in production as an interim safeguard until the upgrade lands.
How O3 protects you
O3 pinpoints whether GHSA-hv4r-mvr4-25vw is reachable in your code and exactly where to fix it, then blocks exploitation in production at runtime until the patched version is deployed.
Tailored to GHSA-hv4r-mvr4-25vw. Runtime protection reduces exposure until a permanent patch is applied and verified — it complements patching, it doesn't replace it.
Frequently Asked Questions
Is GHSA-hv4r-mvr4-25vw in your dependencies?
O3 detects GHSA-hv4r-mvr4-25vw across Go dependencies and uses function-level reachability to confirm whether the vulnerable code path is actually reachable — not just present. No false positives.