PER-16045: follow-ups from review of #342

[EliMoshkovich]

Follow-ups from Zeev's 2026-09-23 review of #342 (merged). #342 left 9 findings open: 5 inline threads and 4 in the review body. This PR fixes all 9.

Findings and changes

Pin the permit-opa checkout (body, MEDIUM, tests.yml:52 / release.yml:43)

• tests.yml and release.yml now check out permit-opa at ab54a3766111b3f6c4796c5ab0a7d7e75f7f590d (permit-opa main today, [Snyk] Security upgrade aiohttp from 3.7.2 to 3.8.0 #51) instead of ref: main, so the shipped /app/bin/opa doesn't change unless a PDP commit changes it.
• To bump: put the new full SHA in both files. The comment above the tests.yml checkout explains how, and the Pre build step fails if the two SHAs differ.
• release.yml's permit-opa checkout moves from actions/checkout@v3 to @v4.
• The two VEX removal gates and the tests.yml note now say x/crypto v0.57.0 arrives when the pin moves past permit-opa#52, not on "the next PDP build".

No CI gate for arm64 opa_build (body, MEDIUM, tests.yml:77)

• build-pdp-image now also runs --target opa_build --platform linux/arm64. That stage now cross-compiles (see below), so the extra build is cheap.

OPA_BUILD picks the plugin, not the binary (thread, MEDIUM, Dockerfile:166)

• opa_build now reads ARG OPA_BUILD:
  • permit needs custom/custom_opa.tar.gz and fails with a clear message if it's missing.
  • vanilla downloads upstream OPA.
  • Any other value fails.
• One arg now picks both the binary and PDP_OPA_PLUGINS.
• build_opal_bundle.sh always empties custom/. With PDP_VANILLA=true it tells you to pass --build-arg OPA_BUILD=vanilla.

Vanilla fallback: latest, no --fail, no checksum (thread, LOW, Dockerfile:175)

• It now downloads a pinned OPA_VERSION (1.20.2, today's latest) with curl --fail --show-error, checks it against a hardcoded sha256 for each arch, and picks the arch from $TARGETARCH, not uname -m.

-a defeats the build cache; opa_build under QEMU (thread, LOW, Dockerfile:175)

• Dropped -a. The stage is now FROM --platform=$BUILDPLATFORM and cross-compiles with GOOS=linux GOARCH=$TARGETARCH, so the arm64 release leg no longer compiles under QEMU.
• The FROM line still matches permit-opa's pdp-builder check (checked: go.mod go 1.26.0; PDP opa_build: golang:1.26 - ok).
• Updated release.yml's note on which stages build twice under QEMU.

PDP#338 note describes an old #338 head (thread, LOW, Dockerfile:97)

• The note now describes ci: gate releases on CVEs and unify Dependabot, Trivy and Docker Scout (PER-15358) #338 by what it does (a digest pin with a Dependabot entry, and a scheduled re-scan of published tags). No SHA, file name or cron.

"Both are open" (thread, LOW, Dockerfile:109)

• Removed the PR-status wording. The note now says what PER-16045 tracks (permit-opa#51, [Snyk] Security upgrade aiohttp from 3.7.2 to 3.8.0 #52) and points to permit-opa's tree.
• The old paragraphs about the unpinned ref: main backport rule are replaced by a short description of the pin. They also say that a release cut from a commit before the pin (v0.9.15 and older) still takes permit-opa main.

build_opal_bundle.sh masks a failing find (body, LOW)

• set -euo pipefail and ${PDP_VANILLA:-}.
• The two workflow Pre build steps now use shell: bash, which runs with pipefail.

test_offline_mode base has no version (body, LOW)

• FROM python:3.13-alpine3.23, matching the main image. Adding a digest waits for ci: gate releases on CVEs and unify Dependabot, Trivy and Docker Scout (PER-15358) #338's convention.

Validation (local, Docker Desktop on arm64)

• docker buildx build --target opa_build, using a permit-opa tarball built exactly like tests.yml builds it (find * ... | xargs -0 tar):
  • Pinned ab54a37, linux/arm64 (native) and linux/amd64 (cross-compiled on the arm64 host): both build. go version -m /opa shows go1.26.8, CGO_ENABLED=0, -tags=netgo, and the right GOARCH. The ELF machine bytes are aarch64 and x86-64.
  • permit-opa#52 head (8c2bb15, go 1.26.0), arm64: builds, with x/crypto v0.57.0.
  • OPA_BUILD=vanilla on both arches: builds, and the checksums match.
  • A wrong checksum fails (/opa: FAILED). A missing version fails (curl: (22) ... 404). OPA_BUILD=permit with no tarball fails with the message. OPA_BUILD=bogus fails.
• docker buildx build --check .: the same single pre-existing warning as main.
• test_offline_mode image builds.
• actionlint: nothing new. Its remaining findings (SC2035 on the tar line, and the Docker Hub secrets in docker-scout) are also on main.
• shellcheck build_opal_bundle.sh: only the same SC2035 info.
• pre-commit run --files ...: pass.
• Script run with an empty permit-opa checkout now fails (find: *: No such file, rc=1) instead of producing a tarball. A vanilla run leaves custom/ empty.

Merge order / notes

• Independent of permit-opa#52. The pin stays on ab54a37 (go 1.25.0) until a PDP PR moves it past [Snyk] Security upgrade aiohttp from 3.7.2 to 3.8.0 #52.
• Once this is on main, permit-opa's pdp-builder check (added in permit-opa#52) no longer guards a floating build. Its own comment says to delete it and the workflow when the PDP stops using ref: main. That is a permit-opa change for after this merges.

🤖 Generated with Claude Code

[linear-code]

PER-16045

[Copilot]

Copilot was unable to review this pull request because the user who requested the review has reached their quota limit.

[github-actions]

🔍 Vulnerabilities of permitio/pdp-v2:next

📦 Image Reference permitio/pdp-v2:next

digest	sha256:6d21862aa14f3d11d89f90df0cdef336f17026edec1c80e7e615a6ae93bf0cd4
vulnerabilities
platform	linux/amd64
size	136 MB
packages	247

📦 Base Image python:026d26881d2e1ebad06e4f309b0fc5f03c0471c5230d325d7b571be802586ee6

also known as	3.13-alpine3.23 3.13.15-alpine3.23
digest	sha256:f282f385cfce21b0a644094330930704424a48d59afe8f08052e0f8e0b7a35c6
vulnerabilities

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.397% EPSS Percentile 34th 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 31st 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. Improper Validation of Unsafe Equivalence in Input 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 36.257% EPSS Percentile 98th 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 9th 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".

golang.org/x/crypto 0.55.0 (golang) pkg:golang/golang.org/x/crypto@0.55.0 Affected range <0.56.0 Fixed version 0.56.0 EPSS Score 0.315% EPSS Percentile 25th percentile Description Previously, a channel registered in the mux's chanList is not usable until it is established. A malicious peer was able flood the channel's incomingRequests, deadlocking the entire connection. Now, we add an atomic established state, set when a channel becomes usable. Until such a time, handlePacket drops every packet other than the open confirmation/failure, without blocking and without tearing down the connection. Affected range <0.56.0 Fixed version 0.56.0 EPSS Score 0.378% EPSS Percentile 32nd percentile Description Previously, after a channel has been established, a malicious peer could send crafted messages that would deadlock the entire connection. Now, we handle all RFC 4254 channel messages; global requests are handled explicitly. Then, treat all other messages as a protocol error and tear the connection down instead of buffering and blocking. Affected range >=0 Fixed version Not Fixed Description The golang.org/x/crypto/openpgp package is unsafe by design, has numerous known security issues, is not maintained, and should not be used. If you are required to interoperate with OpenPGP systems and need a maintained package, consider github.com/ProtonMail/go-crypto/openpgp which is a maintained fork that aims to be a drop-in replacement for this package.

ddtrace 3.19.8 (pypi) pkg:pypi/ddtrace@3.19.8 Uncontrolled Resource Consumption Affected range <4.8.2 Fixed version 4.8.2 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.793% EPSS Percentile 55th percentile Description Impact Datadog tracing libraries that implement W3C baggage propagation parse incoming baggage HTTP headers without enforcing item-count or byte-size limits on the extract path. The DD_TRACE_BAGGAGE_MAX_ITEMS (default 64) and DD_TRACE_BAGGAGE_MAX_BYTES (default 8192) limits were applied only to baggage injection, not extraction. A remote, unauthenticated attacker can send a request whose baggage header contains an arbitrarily large number of comma-separated key-value pairs (or a single very large value). The tracer allocates a hash-map entry for each pair on every request, causing unbounded CPU and memory consumption and enabling a remote Denial of Service against any HTTP service that has the baggage propagation style enabled. The baggage propagation style is enabled by default in most affected tracers, so any internet-facing service that has been instrumented with an affected tracer version is exposed unless the propagation style has been explicitly narrowed. Patches This is resolved in version 4.8.2 and later of the dd-trace-py library Workarounds If users cannot upgrade immediately: Disable baggage extraction by removing baggage from DD_TRACE_PROPAGATION_STYLE (or DD_TRACE_PROPAGATION_STYLE_EXTRACT if set independently). Cap the maximum HTTP request header size at an upstream proxy or web server (for example, Apache LimitRequestFieldSize, Nginx large_client_header_buffers, Envoy max_request_headers_kb). Resources Related upstream advisories: opentelemetry-go GHSA-mh2q-q3fh-2475 opentelemetry-dotnet GHSA-g94r-2vxg-569j

busybox 1.37.0-r30 (apk) pkg:apk/alpine/busybox@1.37.0-r30?os_name=alpine&os_version=3.23 Affected range <=1.37.0-r30 Fixed version Not Fixed EPSS Score 0.291% EPSS Percentile 22nd percentile Description

github.com/containerd/containerd/v2 2.2.5 (golang) pkg:golang/github.com/containerd/containerd/v2@2.2.5 Uncontrolled Resource Consumption Affected range >=2.2.0 <2.2.8 Fixed version 2.2.8 CVSS Score 6.8 CVSS Vector CVSS:4.0/AV:L/AC:L/AT:N/PR:L/UI:N/VC:N/VI:N/VA:H/SC:N/SI:N/SA:N EPSS Score 0.193% EPSS Percentile 9th percentile Description Impact A bug in containerd's CRI ExecSync implementation allows exec probes and lifecycle hooks with background child processes to keep containerd's stdio-drain goroutines indefinitely blocked. Because the I/O drain phase lacks a default timeout or context cancellation handling, repeated ExecSync invocations (like probes) that include long-lived background processes against a container can cause containerd to leak goroutines and host memory. Over time, this resource exhaustion can cause the containerd daemon to be terminated by the OOM killer, rendering containerd unavailable until it is restarted. This issue affects containerd on Linux systems running with the CRI plugin enabled. Users not using containerd's CRI implementation or not running containers on Linux are not affected. Patches This bug has been fixed in containerd 2.3.5, 2.2.8, 2.0.12, and 1.7.35. Users should update to these versions to resolve the issue. Workarounds Ensure exec probes and lifecycle hooks do not launch long-lived background child processes. Credits The containerd project would like to thank XlabAI Team of Tencent Xuanwu Lab (xlabai@tencent.com), including Guannan Wang, Zhanpeng Liu, Jiashuo Liang, and Guancheng Li, and @IamwhatIamSY who independently discovered and responsibly disclosed this issue in accordance with the containerd security policy. 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)

go.opentelemetry.io/otel/exporters/otlp/otlptrace/otlptracehttp 1.43.0 (golang) pkg:golang/go.opentelemetry.io/otel/exporters/otlp/otlptrace/otlptracehttp@1.43.0 Exposure of Sensitive Information to an Unauthorized Actor Affected range >=1.5.0 <=1.44.0 Fixed version 1.45.0 CVSS Score 2 CVSS Vector CVSS:4.0/AV:L/AC:L/AT:P/PR:L/UI:N/VC:L/VI:N/VA:N/SC:N/SI:N/SA:N EPSS Score 0.187% EPSS Percentile 9th percentile Description Summary OpenTelemetry Go versions 1.5.0 through 1.44.0 can include trace exporter endpoint configuration in an internal diagnostic log emitted when an SDK TracerProvider is created. The default OpenTelemetry logger does not emit this event. Exposure requires an application to install a logger that enables OpenTelemetry's internal Info-level diagnostics and for someone other than the intended audience to have access to those logs. The logged configuration can disclose the address of the trace collector and whether the OTLP/HTTP connection is configured as insecure. The Zipkin exporter logs its complete collector URL, so credentials in URL userinfo or tokens in the query string are also disclosed if an application embeds them there. OTLP authentication headers, TLS key material, and exported span data are not included in this log. Exporter MarshalLog implementations that caused this configuration to be included in internal logs were introduced by a1fff3c. Details When sdk/trace.NewTracerProvider constructs a provider, it records a TracerProvider created internal Info event containing the provider configuration. In affected versions, the configuration's MarshalLog methods recursively include: the provider's span processors; each processor's span exporter; and for the OTLP trace exporter, its client configuration. This causes the following values to be present in the event: OTLP trace gRPC: the configured endpoint; OTLP trace HTTP: the configured endpoint and the Insecure flag; and Zipkin: the complete collector URL. OpenTelemetry Go does not emit this event with its default logger, which only emits errors. An application must explicitly configure a sufficiently verbose logger with otel.SetLogger. The required logr verbosity is version-dependent: versions 1.5.0 through 1.14.x use V(1) for this Info event; and versions 1.15.0 through 1.44.0 use V(4). OTLP header configuration is not part of the marshaled object, so credentials supplied with WithHeaders or the corresponding environment variables are not exposed. The documented OTLP WithEndpoint input is a collector address rather than a credential-bearing URL. The higher-risk case is therefore the Zipkin collector URL, which is retained and logged in full, or an application passing sensitive data in an OTLP endpoint outside the documented format. Proof of concept The following program demonstrates the behavior with OpenTelemetry Go 1.44.0. It deliberately places credentials and a token in the Zipkin collector URL and enables internal Info logging: package main import ( "bytes" "context" "fmt" "github.com/go-logr/logr/funcr" "go.opentelemetry.io/otel" "go.opentelemetry.io/otel/exporters/zipkin" sdktrace "go.opentelemetry.io/otel/sdk/trace" ) func main() { var logs bytes.Buffer otel.SetLogger(funcr.New(func(_, args string) { _, _ = logs.WriteString(args) }, funcr.Options{Verbosity: 4})) exporter, err := zipkin.New( "http://user:pass@<!-- -->zipkin.internal:9411/api/v2/spans?token=secret", ) if err != nil { panic(err) } tp := sdktrace.NewTracerProvider(sdktrace.WithBatcher(exporter)) _ = tp.Shutdown(context.Background()) fmt.Println(logs.String()) } The TracerProvider created event contains: http://user:pass@<!-- -->zipkin.internal:9411/api/v2/spans?token=secret For versions before 1.15.0, set funcr.Options{Verbosity: 1} instead. Impact This is a conditional disclosure through application logs. Affected applications must enable verbose OpenTelemetry internal diagnostics and configure a trace exporter containing information they do not intend to expose to readers of those logs. In that configuration, a person or system with log access can learn the trace collector address and internal network topology. If credentials or tokens are embedded directly in a Zipkin collector URL, those values can also be recovered from the logs. There is no exposure with the default OpenTelemetry logger, and the vulnerable log is generated from local application configuration rather than remotely supplied span data. OTLP authentication headers, certificate or private-key contents, and telemetry payloads are not logged by this path. Remediation Upgrade the affected OpenTelemetry Go modules to version 1.45.0 or later. The fix in 3a1412d stops recursively marshaling exporter and client configuration and records their types instead. If an immediate upgrade is not possible: keep OpenTelemetry internal logging below the Info verbosity described above; do not embed credentials or tokens in exporter endpoint URLs; use authentication headers or another supported credential mechanism; and restrict access to existing logs and rotate any credentials that may already have been recorded.

go.opentelemetry.io/otel/exporters/otlp/otlptrace/otlptracegrpc 1.43.0 (golang) pkg:golang/go.opentelemetry.io/otel/exporters/otlp/otlptrace/otlptracegrpc@1.43.0 Exposure of Sensitive Information to an Unauthorized Actor Affected range >=1.5.0 <=1.44.0 Fixed version 1.45.0 CVSS Score 2 CVSS Vector CVSS:4.0/AV:L/AC:L/AT:P/PR:L/UI:N/VC:L/VI:N/VA:N/SC:N/SI:N/SA:N EPSS Score 0.187% EPSS Percentile 9th percentile Description Summary OpenTelemetry Go versions 1.5.0 through 1.44.0 can include trace exporter endpoint configuration in an internal diagnostic log emitted when an SDK TracerProvider is created. The default OpenTelemetry logger does not emit this event. Exposure requires an application to install a logger that enables OpenTelemetry's internal Info-level diagnostics and for someone other than the intended audience to have access to those logs. The logged configuration can disclose the address of the trace collector and whether the OTLP/HTTP connection is configured as insecure. The Zipkin exporter logs its complete collector URL, so credentials in URL userinfo or tokens in the query string are also disclosed if an application embeds them there. OTLP authentication headers, TLS key material, and exported span data are not included in this log. Exporter MarshalLog implementations that caused this configuration to be included in internal logs were introduced by a1fff3c. Details When sdk/trace.NewTracerProvider constructs a provider, it records a TracerProvider created internal Info event containing the provider configuration. In affected versions, the configuration's MarshalLog methods recursively include: the provider's span processors; each processor's span exporter; and for the OTLP trace exporter, its client configuration. This causes the following values to be present in the event: OTLP trace gRPC: the configured endpoint; OTLP trace HTTP: the configured endpoint and the Insecure flag; and Zipkin: the complete collector URL. OpenTelemetry Go does not emit this event with its default logger, which only emits errors. An application must explicitly configure a sufficiently verbose logger with otel.SetLogger. The required logr verbosity is version-dependent: versions 1.5.0 through 1.14.x use V(1) for this Info event; and versions 1.15.0 through 1.44.0 use V(4). OTLP header configuration is not part of the marshaled object, so credentials supplied with WithHeaders or the corresponding environment variables are not exposed. The documented OTLP WithEndpoint input is a collector address rather than a credential-bearing URL. The higher-risk case is therefore the Zipkin collector URL, which is retained and logged in full, or an application passing sensitive data in an OTLP endpoint outside the documented format. Proof of concept The following program demonstrates the behavior with OpenTelemetry Go 1.44.0. It deliberately places credentials and a token in the Zipkin collector URL and enables internal Info logging: package main import ( "bytes" "context" "fmt" "github.com/go-logr/logr/funcr" "go.opentelemetry.io/otel" "go.opentelemetry.io/otel/exporters/zipkin" sdktrace "go.opentelemetry.io/otel/sdk/trace" ) func main() { var logs bytes.Buffer otel.SetLogger(funcr.New(func(_, args string) { _, _ = logs.WriteString(args) }, funcr.Options{Verbosity: 4})) exporter, err := zipkin.New( "http://user:pass@<!-- -->zipkin.internal:9411/api/v2/spans?token=secret", ) if err != nil { panic(err) } tp := sdktrace.NewTracerProvider(sdktrace.WithBatcher(exporter)) _ = tp.Shutdown(context.Background()) fmt.Println(logs.String()) } The TracerProvider created event contains: http://user:pass@<!-- -->zipkin.internal:9411/api/v2/spans?token=secret For versions before 1.15.0, set funcr.Options{Verbosity: 1} instead. Impact This is a conditional disclosure through application logs. Affected applications must enable verbose OpenTelemetry internal diagnostics and configure a trace exporter containing information they do not intend to expose to readers of those logs. In that configuration, a person or system with log access can learn the trace collector address and internal network topology. If credentials or tokens are embedded directly in a Zipkin collector URL, those values can also be recovered from the logs. There is no exposure with the default OpenTelemetry logger, and the vulnerable log is generated from local application configuration rather than remotely supplied span data. OTLP authentication headers, certificate or private-key contents, and telemetry payloads are not logged by this path. Remediation Upgrade the affected OpenTelemetry Go modules to version 1.45.0 or later. The fix in 3a1412d stops recursively marshaling exporter and client configuration and records their types instead. If an immediate upgrade is not possible: keep OpenTelemetry internal logging below the Info verbosity described above; do not embed credentials or tokens in exporter endpoint URLs; use authentication headers or another supported credential mechanism; and restrict access to existing logs and rotate any credentials that may already have been recorded.

go.opentelemetry.io/otel/exporters/otlp/otlptrace 1.43.0 (golang) pkg:golang/go.opentelemetry.io/otel/exporters/otlp/otlptrace@1.43.0 Exposure of Sensitive Information to an Unauthorized Actor Affected range >=1.5.0 <=1.44.0 Fixed version 1.45.0 CVSS Score 2 CVSS Vector CVSS:4.0/AV:L/AC:L/AT:P/PR:L/UI:N/VC:L/VI:N/VA:N/SC:N/SI:N/SA:N EPSS Score 0.187% EPSS Percentile 9th percentile Description Summary OpenTelemetry Go versions 1.5.0 through 1.44.0 can include trace exporter endpoint configuration in an internal diagnostic log emitted when an SDK TracerProvider is created. The default OpenTelemetry logger does not emit this event. Exposure requires an application to install a logger that enables OpenTelemetry's internal Info-level diagnostics and for someone other than the intended audience to have access to those logs. The logged configuration can disclose the address of the trace collector and whether the OTLP/HTTP connection is configured as insecure. The Zipkin exporter logs its complete collector URL, so credentials in URL userinfo or tokens in the query string are also disclosed if an application embeds them there. OTLP authentication headers, TLS key material, and exported span data are not included in this log. Exporter MarshalLog implementations that caused this configuration to be included in internal logs were introduced by a1fff3c. Details When sdk/trace.NewTracerProvider constructs a provider, it records a TracerProvider created internal Info event containing the provider configuration. In affected versions, the configuration's MarshalLog methods recursively include: the provider's span processors; each processor's span exporter; and for the OTLP trace exporter, its client configuration. This causes the following values to be present in the event: OTLP trace gRPC: the configured endpoint; OTLP trace HTTP: the configured endpoint and the Insecure flag; and Zipkin: the complete collector URL. OpenTelemetry Go does not emit this event with its default logger, which only emits errors. An application must explicitly configure a sufficiently verbose logger with otel.SetLogger. The required logr verbosity is version-dependent: versions 1.5.0 through 1.14.x use V(1) for this Info event; and versions 1.15.0 through 1.44.0 use V(4). OTLP header configuration is not part of the marshaled object, so credentials supplied with WithHeaders or the corresponding environment variables are not exposed. The documented OTLP WithEndpoint input is a collector address rather than a credential-bearing URL. The higher-risk case is therefore the Zipkin collector URL, which is retained and logged in full, or an application passing sensitive data in an OTLP endpoint outside the documented format. Proof of concept The following program demonstrates the behavior with OpenTelemetry Go 1.44.0. It deliberately places credentials and a token in the Zipkin collector URL and enables internal Info logging: package main import ( "bytes" "context" "fmt" "github.com/go-logr/logr/funcr" "go.opentelemetry.io/otel" "go.opentelemetry.io/otel/exporters/zipkin" sdktrace "go.opentelemetry.io/otel/sdk/trace" ) func main() { var logs bytes.Buffer otel.SetLogger(funcr.New(func(_, args string) { _, _ = logs.WriteString(args) }, funcr.Options{Verbosity: 4})) exporter, err := zipkin.New( "http://user:pass@<!-- -->zipkin.internal:9411/api/v2/spans?token=secret", ) if err != nil { panic(err) } tp := sdktrace.NewTracerProvider(sdktrace.WithBatcher(exporter)) _ = tp.Shutdown(context.Background()) fmt.Println(logs.String()) } The TracerProvider created event contains: http://user:pass@<!-- -->zipkin.internal:9411/api/v2/spans?token=secret For versions before 1.15.0, set funcr.Options{Verbosity: 1} instead. Impact This is a conditional disclosure through application logs. Affected applications must enable verbose OpenTelemetry internal diagnostics and configure a trace exporter containing information they do not intend to expose to readers of those logs. In that configuration, a person or system with log access can learn the trace collector address and internal network topology. If credentials or tokens are embedded directly in a Zipkin collector URL, those values can also be recovered from the logs. There is no exposure with the default OpenTelemetry logger, and the vulnerable log is generated from local application configuration rather than remotely supplied span data. OTLP authentication headers, certificate or private-key contents, and telemetry payloads are not logged by this path. Remediation Upgrade the affected OpenTelemetry Go modules to version 1.45.0 or later. The fix in 3a1412d stops recursively marshaling exporter and client configuration and records their types instead. If an immediate upgrade is not possible: keep OpenTelemetry internal logging below the Info verbosity described above; do not embed credentials or tokens in exporter endpoint URLs; use authentication headers or another supported credential mechanism; and restrict access to existing logs and rotate any credentials that may already have been recorded.

go.opentelemetry.io/otel/sdk 1.44.0 (golang) pkg:golang/go.opentelemetry.io/otel/sdk@1.44.0 Exposure of Sensitive Information to an Unauthorized Actor Affected range >=1.5.0 <=1.44.0 Fixed version 1.45.0 CVSS Score 2 CVSS Vector CVSS:4.0/AV:L/AC:L/AT:P/PR:L/UI:N/VC:L/VI:N/VA:N/SC:N/SI:N/SA:N EPSS Score 0.187% EPSS Percentile 9th percentile Description Summary OpenTelemetry Go versions 1.5.0 through 1.44.0 can include trace exporter endpoint configuration in an internal diagnostic log emitted when an SDK TracerProvider is created. The default OpenTelemetry logger does not emit this event. Exposure requires an application to install a logger that enables OpenTelemetry's internal Info-level diagnostics and for someone other than the intended audience to have access to those logs. The logged configuration can disclose the address of the trace collector and whether the OTLP/HTTP connection is configured as insecure. The Zipkin exporter logs its complete collector URL, so credentials in URL userinfo or tokens in the query string are also disclosed if an application embeds them there. OTLP authentication headers, TLS key material, and exported span data are not included in this log. Exporter MarshalLog implementations that caused this configuration to be included in internal logs were introduced by a1fff3c. Details When sdk/trace.NewTracerProvider constructs a provider, it records a TracerProvider created internal Info event containing the provider configuration. In affected versions, the configuration's MarshalLog methods recursively include: the provider's span processors; each processor's span exporter; and for the OTLP trace exporter, its client configuration. This causes the following values to be present in the event: OTLP trace gRPC: the configured endpoint; OTLP trace HTTP: the configured endpoint and the Insecure flag; and Zipkin: the complete collector URL. OpenTelemetry Go does not emit this event with its default logger, which only emits errors. An application must explicitly configure a sufficiently verbose logger with otel.SetLogger. The required logr verbosity is version-dependent: versions 1.5.0 through 1.14.x use V(1) for this Info event; and versions 1.15.0 through 1.44.0 use V(4). OTLP header configuration is not part of the marshaled object, so credentials supplied with WithHeaders or the corresponding environment variables are not exposed. The documented OTLP WithEndpoint input is a collector address rather than a credential-bearing URL. The higher-risk case is therefore the Zipkin collector URL, which is retained and logged in full, or an application passing sensitive data in an OTLP endpoint outside the documented format. Proof of concept The following program demonstrates the behavior with OpenTelemetry Go 1.44.0. It deliberately places credentials and a token in the Zipkin collector URL and enables internal Info logging: package main import ( "bytes" "context" "fmt" "github.com/go-logr/logr/funcr" "go.opentelemetry.io/otel" "go.opentelemetry.io/otel/exporters/zipkin" sdktrace "go.opentelemetry.io/otel/sdk/trace" ) func main() { var logs bytes.Buffer otel.SetLogger(funcr.New(func(_, args string) { _, _ = logs.WriteString(args) }, funcr.Options{Verbosity: 4})) exporter, err := zipkin.New( "http://user:pass@<!-- -->zipkin.internal:9411/api/v2/spans?token=secret", ) if err != nil { panic(err) } tp := sdktrace.NewTracerProvider(sdktrace.WithBatcher(exporter)) _ = tp.Shutdown(context.Background()) fmt.Println(logs.String()) } The TracerProvider created event contains: http://user:pass@<!-- -->zipkin.internal:9411/api/v2/spans?token=secret For versions before 1.15.0, set funcr.Options{Verbosity: 1} instead. Impact This is a conditional disclosure through application logs. Affected applications must enable verbose OpenTelemetry internal diagnostics and configure a trace exporter containing information they do not intend to expose to readers of those logs. In that configuration, a person or system with log access can learn the trace collector address and internal network topology. If credentials or tokens are embedded directly in a Zipkin collector URL, those values can also be recovered from the logs. There is no exposure with the default OpenTelemetry logger, and the vulnerable log is generated from local application configuration rather than remotely supplied span data. OTLP authentication headers, certificate or private-key contents, and telemetry payloads are not logged by this path. Remediation Upgrade the affected OpenTelemetry Go modules to version 1.45.0 or later. The fix in 3a1412d stops recursively marshaling exporter and client configuration and records their types instead. If an immediate upgrade is not possible: keep OpenTelemetry internal logging below the Info verbosity described above; do not embed credentials or tokens in exporter endpoint URLs; use authentication headers or another supported credential mechanism; and restrict access to existing logs and rotate any credentials that may already have been recorded.

[github-actions]

🔍 Vulnerabilities of permitio/pdp-v2:next

📦 Image Reference permitio/pdp-v2:next

digest	sha256:6d21862aa14f3d11d89f90df0cdef336f17026edec1c80e7e615a6ae93bf0cd4
vulnerabilities
platform	linux/amd64
size	136 MB
packages	247

📦 Base Image python:026d26881d2e1ebad06e4f309b0fc5f03c0471c5230d325d7b571be802586ee6

also known as	3.13-alpine3.23 3.13.15-alpine3.23
digest	sha256:f282f385cfce21b0a644094330930704424a48d59afe8f08052e0f8e0b7a35c6
vulnerabilities