Description

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.

Executive Summary

Technical Details

Mitigations

References

Additional Metadata

{
  "score": "7.1",
  "pubDate": "2026-09-21T12:17:29.010Z",
  "pubdate": "2026-09-21T12:17:29.010Z",
  "executiveSummary": "A critical security flaw in the signature verification logic of noobaa-core allows for unauthorized request manipulation via S3 presigned URLs using Signature Version 4 (SigV4).\nThe vulnerability originates from inadequate validation of incoming HTTP headers, specifically the failure to reject requests containing unsigned x-amz- headers.\nBy stripping unsigned headers from the signature calculation rather than enforcing their inclusion, the service allows an attacker to inject arbitrary headers into a legitimately signed request.\nThe impact is significant, as an attacker possessing a valid presigned PUT URL can append an x-amz-copy-source header to trigger a CopyObject operation.\nThis capability effectively bypasses original access controls, enabling unauthorized data movement and access to any storage objects reachable by the original signer.\nThe vulnerability affects noobaa-core, the core engine of the NooBaa Multicloud Object Gateway, and poses a severe risk to data integrity and confidentiality within the storage infrastructure.\nExploitation requires the attacker to obtain a valid presigned PUT URL, which serves as the primary authentication vector for the malicious operation.",
  "technicalDetails": "The vulnerability exists within the SigV4 signature verification process of noobaa-core. When processing requests, the service is tasked with verifying that the provided signature matches the canonical request parameters, including headers defined in the 'SignedHeaders' element of the authorization header.\nThe root cause is an improper validation logic failure: when the service encounters 'x-amz-' prefixed headers that were not included in the original signature calculation, it incorrectly chooses to drop these headers from the verification process instead of rejecting the request as malformed or unauthorized.\nThis design flaw allows an attacker to manipulate the request body or parameters by injecting headers that the server ignores during the cryptographic integrity check but processes during the actual object storage operation.\nIn a typical attack flow, an attacker first acquires a legitimate, restricted-scope presigned PUT URL for a specific resource. This URL contains a signature generated for an upload operation. The attacker then modifies the request by injecting an 'x-amz-copy-source' header into the HTTP request.\nBecause the server's signature verification logic treats the injected 'x-amz-copy-source' header as an ignorable, unsigned entity rather than a signature violation, the server proceeds to process the request as a CopyObject operation.\nThe 'x-amz-copy-source' header instructs the S3-compatible backend to copy data from a source bucket/object to the destination defined in the presigned URL. Since the original signer's credentials authorize access to the target system, the backend performs the copy, effectively allowing the attacker to exfiltrate or overwrite data.\nThis effectively transforms a limited-write capability into an unauthorized cross-bucket or cross-object read/copy primitive. The scope of the impact is determined by the permissions assigned to the identity that generated the original presigned URL, potentially granting access to all storage system components that the signer is entitled to access.\nThe vulnerability requires that the attacker has existing network access to the NooBaa API and has successfully obtained a valid presigned URL. No further authentication or administrative privileges are required if the request is successfully crafted to bypass the flawed verification logic."
}