REDHAT-BUG-2537364: High severity noobaa-core vulnerability

Q: What does an attacker need to exploit this flaw?

An attacker needs a legitimate presigned PUT URL generated by a user whose permissions allow access to objects the attacker wants to copy. They can add an unsigned x-amz-copy-source header to change the request into a CopyObject operation.

Q: Who is exposed to the greatest risk?

Deployments where presigned PUT URLs are issued to untrusted or less-trusted recipients are exposed, particularly when the URL signer has read access to objects beyond the bucket or key scope intended for the URL. The copied object is accessed using the signer's permissions.

Q: How can this lead to access outside the intended presigned URL scope?

NooBaa verifies only headers listed in X-Amz-SignedHeaders and does not reject additional x-amz- headers. The unsigned x-amz-copy-source header remains available to the S3 handler, which treats the request as a copy operation rather than the originally authorized PUT.

Published Sep 21, 2026

Updated

A flaw was found in noobaa-core within the SigV4 signature verification mechanism. The vulnerability exists in the stringtosignv4 function in src/util/signatureutils.js, where the isSignableHeader predicate is used to filter headers for the canonical string. When a client provides a list of signed headers in the X-Amz-SignedHeaders parameter, NooBaa only includes those specific headers in its signature verification. However, if additional x-amz- headers are present in the request but not listed in X-Amz-SignedHeaders, NooBaa omits them from the signature check instead of rejecting the request. These unsigned headers remain present when the request is passed to the S3 operation handler. An attacker can exploit this by taking a legitimate presigned PUT URL and adding an unsigned x-amz-copy-source header. The S3 handler interprets the presence of this header as a CopyObject request. Because the operation executes with the permissions of the user who generated the presigned URL, the attacker can copy and subsequently read any object that the signer has access to, regardless of the bucket or key restrictions intended by the original URL.

Affected Software

1 affected component

noobaa-core><=

Event History

Sep 21, 2026

Data Sourced

via Red Hat·11:20 AM

DescriptionSeverityAffected Software

Frequently Asked Questions

What does an attacker need to exploit this flaw?

An attacker needs a legitimate presigned PUT URL generated by a user whose permissions allow access to objects the attacker wants to copy. They can add an unsigned x-amz-copy-source header to change the request into a CopyObject operation.

Who is exposed to the greatest risk?

Deployments where presigned PUT URLs are issued to untrusted or less-trusted recipients are exposed, particularly when the URL signer has read access to objects beyond the bucket or key scope intended for the URL. The copied object is accessed using the signer's permissions.

How can this lead to access outside the intended presigned URL scope?

NooBaa verifies only headers listed in X-Amz-SignedHeaders and does not reject additional x-amz- headers. The unsigned x-amz-copy-source header remains available to the S3 handler, which treats the request as a copy operation rather than the originally authorized PUT.