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.

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.

A container privilege escalation flaw was found in certain Multi-Cloud Object Gateway Core images. This issue stems from the /etc/passwd file being created with group-writable permissions during build time. In certain conditions, an attacker who can execute commands within an affected container, even as a non-root user, can leverage their membership in the root group to modify the /etc/passwd file. This could allow the attacker to add a new user with any arbitrary UID, including UID 0, leading to full root privileges within the container