CVE-2026-94368 in Openshift Data Foundation
Summary
by MITRE • 09/21/2026
A flaw was found in the signature verification logic of noobaa-core, the core component of the NooBaa Multicloud Object Gateway. The issue occurs when the service processes S3 presigned URLs using Signature Version 4 (SigV4). Due to improper validation, the service fails to reject requests containing unsigned x-amz- headers, instead simply dropping them from the signature calculation. This allows an attacker who possesses a valid presigned PUT URL to add an unsigned x-amz-copy-source header, effectively converting a simple upload into a CopyObject operation. This can lead to unauthorized access and copying of any data the original signer is permitted to reach across the entire storage system.
If you want to get the best quality for vulnerability data then you always have to consider VulDB.
Analysis
by VulDB Data Team • 09/21/2026
The vulnerability identified in noobaa-core, the foundational component of the NooBaa Multicloud Object Gateway, represents a critical failure in the implementation of Amazon S3 Signature Version 4 authentication logic. This flaw specifically affects the processing of presigned URLs, which are widely used to grant temporary, delegated access to cloud storage resources without exposing long-term credentials. The core issue stems from an improper validation mechanism within the signature verification routine. When noobaa-core receives a request authenticated via SigV4, it is designed to validate that all relevant headers included in the signed payload match their actual values. However, the implementation contains a logic error where unsigned x-amz- headers are not rejected as invalid or malicious inputs. Instead, the system silently drops these unsigned headers from the signature calculation process. This behavior deviates significantly from strict security best practices and the expected behavior of robust S3-compatible services, which should treat any discrepancy between signed and actual header values as a sign of tampering or unauthorized modification.
The operational impact of this flaw is severe because it allows for an attack vector known as request smuggling or parameter pollution within the context of object storage operations. An attacker who possesses a valid presigned PUT URL can exploit this logic error by appending an unsigned x-amz-copy-source header to their request. In standard S3 API semantics, the presence of the x-amz-copy-source header transforms what would normally be a simple PutObject operation into a CopyObject operation. Because noobaa-core fails to reject this unsigned header and instead ignores it during signature verification, the service accepts the modified request as if it were originally signed with that intent. This effectively bypasses the intended scope of the presigned URL, which was likely restricted to uploading new objects. By leveraging this flaw, an attacker can initiate a copy operation from any source object within the storage system that the original signer had permission to access.
This capability leads directly to unauthorized data exfiltration and lateral movement across the entire storage infrastructure accessible by the compromised credentials or token. Since the vulnerability allows the conversion of upload permissions into read-and-copy permissions, an attacker can enumerate and copy sensitive files from various buckets and directories without needing explicit CopyObject privileges in their original presigned URL. This undermines the principle of least privilege that presigned URLs are designed to enforce. The attack does not require brute force or complex exploitation techniques; it relies solely on manipulating HTTP headers within a valid request, making it difficult to detect through traditional signature validation logs unless specific anomaly detection is implemented at the application layer.
From a classification perspective, this vulnerability aligns with CWE-20 Improper Input Validation and CWE-345 Insufficient Verification of Data Authenticity. The failure to validate that all signed headers match their transmitted values constitutes a fundamental input validation error. Furthermore, it relates to CWE-916 Improvement Authentication Bypass Using an Alternate Path or Channel, as the attacker bypasses the intended access control mechanism by exploiting a secondary interpretation of the request structure. In terms of offensive security frameworks, this technique is consistent with ATT&CK T1530 Data from Cloud Storage Object and potentially T1078 Valid Accounts if the presigned URL was obtained through initial compromise or credential theft. The attack vector leverages the trust placed in signed URLs to escalate privileges implicitly by altering the operation type rather than breaking encryption or authentication protocols directly.
Mitigation strategies must focus on strict adherence to SigV4 specifications and enhancing input validation logic within noobaa-core. Developers should ensure that any x-amz- header present in an HTTP request is included in the string-to-sign calculation if it was part of the original signature, and conversely, that unsigned headers are explicitly rejected rather than silently ignored. Implementing a whitelist approach for allowed operations based on the presigned URL's intended purpose can also help prevent unintended operation switches like converting PUT to COPY. Additionally, logging should be enhanced to flag requests where header discrepancies occur during verification, allowing security teams to monitor for potential exploitation attempts in real-time. Until an official patch is applied, administrators may consider restricting network access to noobaa-core endpoints or implementing WAF rules that block requests containing unexpected x-amz-copy-source headers when the original intent was upload-only.