MinIO CVE-2026-40344

Requires knowledge of a valid MinIO access key with WRITE (s3:PutObject) permission on target bucket. The well-known default access key 'minioadmin' satisfies this requirement in many deployments where default credentials remain unchanged. Target MinIO instance must be running vulnerable versions RELEASE.2023-05-18T00-05-36Z through RELEASE.2026-04-11T03-20-12Z. No special configuration, non-default features, or specific deployment modes required - the vulnerability exists in default Snowball auto-extract functionality present in all standard MinIO installations. Network accessibility to MinIO S3 API endpoint (typically port 9000) is required per CVSS AV:N, but no user interaction (UI:N), no elevated privileges beyond the access key (PR:N in CVSS:4.0 context means no authentication barrier beyond knowing the key), and no attack complexity beyond basic S3 API knowledge (AC:L). Critically: Exploitation does NOT require knowledge of the secret key corresponding to the access key, which is the core authentication bypass. Limiting factor for exploitation is discovery of valid access keys; once obtained, the attack succeeds unconditionally against vulnerable versions with no additional barriers.

Real-world risk is HIGH despite no confirmed active exploitation. CVSS:4.0 vector AV:N/AC:L/PR:N indicates network-accessible exploitation with low complexity and no authentication, yielding 8.8 severity with high integrity impact (VI:H) and low availability impact (VA:L). The PR:N (no privileges required) metric is critically important - attackers need only knowledge of a valid access key, which may be the widely-known default 'minioadmin' or any key leaked/discovered through other means. Attack complexity is genuinely low: crafting a malicious S3 PUT request with fabricated signature requires only basic AWS SDK knowledge and the ability to create tar payloads. The vulnerability is highly automatable for mass exploitation once target MinIO instances are identified. EPSS data not provided but expected to be elevated given the trivial exploitation barrier and widespread MinIO deployment in cloud storage infrastructure. No CISA KEV listing indicates no confirmed widespread exploitation, but the combination of unauthenticated network access, default credential viability, and clear vendor advisory suggests imminent weaponization risk. The fix availability in RELEASE.2026-04-11T03-20-12Z is recent (April 2026 per version timestamp), indicating this may be a recently disclosed vulnerability with limited time for attacker awareness. Priority for remediation should be CRITICAL for any deployment using default credentials or with WRITE-permissioned keys that may be compromised.

An attacker identifies a MinIO deployment through Shodan/Censys scanning of S3-compatible endpoints or discovers MinIO use through reconnaissance of a target organization's infrastructure. The attacker obtains a valid access key either by using the common default 'minioadmin' credential (often unchanged in development/test environments) or through previous credential leakage from configuration files, environment variables, or public code repositories. Using a modified S3 client or raw HTTP library, the attacker crafts a PUT request to the MinIO endpoint targeting a known or enumerated bucket name. The request includes header 'X-Amz-Content-Sha256: STREAMING-UNSIGNED-PAYLOAD-TRAILER' to trigger the vulnerable code path, 'X-Amz-Meta-Snowball-Auto-Extract: true' to invoke the Snowball handler, and an Authorization header containing the valid access key with a completely fabricated signature (random string). The request body contains a malicious tar archive with web shells, malware, or data exfiltration tools. MinIO's PutObjectExtractHandler validates the access key has WRITE permission via IAM check but skips signature verification due to the missing authTypeStreamingUnsignedTrailer case, accepting the request and extracting the tar contents into arbitrary paths within the bucket. The attacker achieves unauthorized write access without ever knowing or needing the secret key, bypassing S3 cryptographic authentication entirely.