NooBaa CVE-2026-94368

Exploitation requires the attacker to already hold a valid SigV4 (Signature Version 4) presigned PUT URL issued by a legitimate signer against a noobaa-core / OpenShift Data Foundation S3 endpoint - this is the PR:L prerequisite. Given such a URL, no user interaction or additional authentication is needed: the attacker simply adds an unsigned x-amz-copy-source header, which the service drops from the signature calculation rather than rejecting. Impact scope is bounded by the original signer's permissions (the copy can only reach data that signer is authorized to access). Limiting factors: requires possession of a presigned URL, applies to the S3/SigV4 presigned request path, and confidentiality/integrity impact is capped at whatever the signer's IAM/access scope permits; there is no availability impact.

This is a genuine authorization/data-confidentiality issue, but not a top-tier emergency. The CVSS 3.1 vector (AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:L/A:N, score 7.1) shows network reach and low complexity, but crucially requires PR:L - the attacker must already possess a valid SigV4 presigned PUT URL issued by a legitimate signer. That single prerequisite is the difference between 'trivially exploitable by anyone' and 'exploitable by anyone who has been handed a scoped upload credential.' No EPSS score, no CISA KEV entry, and no public POC were provided, so all exploitation signals point to no observed real-world activity - this is a vendor/Red-Hat-reported flaw (bugzilla 2537364), not an in-the-wild finding. No SSVC decision data was supplied. The real risk driver is the C:H rating: because the unsigned x-amz-copy-source header lets a bounded upload turn into a CopyObject across the entire store, a leaked or over-shared presigned URL becomes a lever to read/copy anything the signer could reach. Priority: medium-high for environments that hand out presigned URLs broadly; lower where such URLs are tightly held and short-lived. Note the tag conflict: the input tags 'Jwt Attack' and 'Authentication Bypass' misrepresent the mechanism - this is SigV4 signature-verification weakness (CWE-347), not JWT and not a full auth bypass.

An application issues a scoped SigV4 presigned PUT URL to a user or partner so they can upload a single object. The recipient (or anyone the URL leaks to) appends an unsigned x-amz-copy-source header pointing at a sensitive bucket/object; noobaa-core silently drops the unsigned header from the signature check instead of rejecting the request, so the signature still validates and the PUT is executed as a CopyObject. The attacker thereby copies data anywhere the original signer's permissions allow, across the whole storage system. No public exploit code was identified at time of analysis.