CVE-2026-50151 oras-project CVE debrief

Who should care

Users of the oras-go library, particularly those using versions prior to 2.6.1, should be aware of this vulnerability and take steps to mitigate it. This includes verifying and validating registry responses, implementing additional security measures for authentication and authorization, and reviewing compensating controls for exposed systems while remediation is scheduled and verified.

Technical summary

The oras-go library, used for managing OCI artifacts, had a vulnerability in its blobStore.completePushAfterInitialPost function. This function followed a registry-controlled Location header during monolithic blob upload and reused the Authorization header from the initial POST request for the subsequent PUT request. This allowed a malicious registry to return a cross-host Location and receive the caller's credentials at an attacker-controlled endpoint. The issue was fixed in version 2.6.1. Users should verify and validate registry responses and implement additional security measures for authentication and authorization.

Defensive priority

High

Recommended defensive actions

• Upgrade to oras-go version 2.6.1 or later
• Verify and validate registry responses
• Implement additional security measures for authentication and authorization
• Review compensating controls for exposed systems while remediation is scheduled and verified
• Check relevant monitoring, detection, and logs for exposed assets that need extra review
• Track exceptions, retest remediated assets, and close the item only after evidence is documented
• Confirm whether affected product deployments exist in managed environments and assign an owner for follow-up

Evidence notes

The CVE record was published on 2026-07-17T20:17:23.683Z and has not been modified since then. The NVD entry is currently 7.5 HIGH. This information is based on the NVD entry and the CVE record. The oras-go library, used for managing OCI artifacts, had a vulnerability in its blobStore.completePushAfterInitialPost function. This function followed a registry-controlled Location header during monolithic blob upload and reused the Authorization header from the initial POST request for the subsequent PUT request. This allowed a malicious registry to return a cross-host Location and receive the caller's credentials at an attacker-controlled endpoint. The issue was fixed in version 2.6.1. Users should verify and validate registry responses and implement additional security measures for authentication and authorization.

Sources and references

Methodology and review provenance

AI-assisted synthesis based on stored public vulnerability evidence. System validation, approval state, and publication status do not by themselves establish human review of this revision. PatchSiren helps prioritize defensive review and does not prove exposure or remediation on any system.