Withdrawn by the publisher.
Affected: CleanStart: tigera-operator
Multiple security vulnerabilities affect the tigera-operator package. These issues are resolved in later releases. See references for individual vulnerability details.
oras-go is a Go library for managing OCI artifacts. Prior to 2.6.1, registry/remote/repository.go in blobStore.completePushAfterInitialPost follows a registry-controlled Location header during monolithic blob upload and reuses the Authorization header from the initial POST request for the subsequent PUT request, allowing a malicious registry to return a cross-host Location and receive the caller's credentials at an attacker-controlled endpoint. This issue is fixed in version 2.6.1.
Affected: Go: oras.land/oras-go/v2
## Summary
oras-go follows a registry-controlled `Location` header during the monolithic blob upload flow and reuses the `Authorization` header from the initial `POST` request for the subsequent `PUT` request. If a malicious registry returns a cross-host `Location`, oras-go can send the caller's credentials to an attacker-controlled endpoint.
## Affected Versions
tested: v2.6.0 (commit 03243809936cce826494b5506f724c6dc11115b1, as-of 2026-01-24) range: unknown; likely affects earlier v2.x releases that include the same upload flow
## Impact
Credential leak to an attacker-controlled endpoint and client-side ssrf to a cross-host target.
## Affected Component
- `registry/remote/repository.go:878-916` (`blobStore.completePushAfterInitialPost`)
## Reproduction
Attachments include `poc.zip` with a local-only harness (no real registry required). It runs a fake registry server that returns a cross-host `Location` and a second server that records whether it received `Authorization`.
```bash unzip -q -o poc.zip -d /tmp/poc cd /tmp/poc/poc-F-ORAS-LOCATION-UPLOAD-001 make canonical make control ```
## Recommended Fix
- validate `Location` before uploading (scheme + hostname + effective port) against the original request, or require an explicit opt-in allowlist for cross-host upload urls - never forward `Authorization` when the upload target changes host or scheme
## references
- security policy: https://github.com/oras-project/oras-go/security/policy - vulnerable code: `reg…
helm-4.2.3-2.1 on GA media
golang.org/x/net/html: golang: golang.org/x/net/html: Cross-Site Scripting via HTML parsing bypass crypto/x509: golang: golang crypto/x509: Denial of Service via excessive processing of DNS SAN entries golang.org/x/net/idna: golang: net/http: golang.org/x/net/idna: Privilege escalation via incorrect Punycode label processing golang.org/x/crypto/ssh/knownhosts: golang: golang.org/x/crypto/ssh/knownhosts: Revocation bypass via unchecked SignatureKey github.com/go-git/go-billy: Billy: Denial of Service via crafted input due to insufficient validation sanitize-html: `sanitize-html`: Stored Cross-Site Scripting via HTML sanitizer bypass openssl: Heap Use-After-Free in OpenSSL PKCS7_verify() golang.org/x/crypto/ssh: golang.org/x/crypto/ssh: Authorization bypass due to skipped source-address validation oras-go: oras-go: Credential forwarding via unvalidated Location header during blob upload github.com/containerd/containerd: containerd: Host-root command execution via unvalidated image config labels in CRI plugin js-yaml: js-yaml: Denial of Service via crafted YAML documents
Security update for helm
Affected: Ubuntu:24.04:LTS: golang-oras-oras-go, Ubuntu:26.04:LTS: golang-oras-oras-go
oras-go is a Go library for managing OCI artifacts. Prior to 2.6.1, registry/remote/repository.go in blobStore.completePushAfterInitialPost follows a registry-controlled Location header during monolithic blob upload and reuses the Authorization header from the initial POST request for the subsequent PUT request, allowing a malicious registry to return a cross-host Location and receive the caller's credentials at an attacker-controlled endpoint. This issue is fixed in version 2.6.1.