fix: patch CVE-2025-70873 by bumping base image to python:3.10-alpine3.23 by omer9564 · Pull Request #308 · permitio/PDP

omer9564 · 2026-04-27T15:21:07Z

Summary

Bumps the runtime base image from python:3.10-alpine3.22 → python:3.10-alpine3.23 to remediate CVE-2025-70873 (information disclosure in SQLite's zipfile extension zipfileInflate, fixed upstream in SQLite 3.51.2).
Alpine 3.22 main ships sqlite-libs 3.49.2-r1 (vulnerable). Alpine 3.23 ships sqlite-libs 3.51.2-r0, which contains the fix.
apk del sqlite already in the Dockerfile only drops the CLI; sqlite-libs remains because Python's stdlib _sqlite3 module is dynamically linked against it — so a base-image bump is required to actually clear the finding.
Build-only stages (rust:1.94-alpine, golang:1.25-bookworm) don't contribute layers to the runtime image, so no changes needed there.

Test plan

CI builds the image successfully on both linux/amd64 and linux/arm64.
E2E tests pass against the rebuilt image.
Docker Scout no longer reports CVE-2025-70873 (sqlite-libs ≥ 3.51.2-r0).
No regression in apk add bash libffi libressl gcompat or the pip build-deps virtual package on Alpine 3.23.

References

CVE: https://nvd.nist.gov/vuln/detail/CVE-2025-70873
Alpine 3.23 sqlite-libs: https://pkgs.alpinelinux.org/package/v3.23/main/x86_64/sqlite-libs

Alpine 3.22 ships sqlite-libs 3.49.2-r1, which is vulnerable to CVE-2025-70873 (info disclosure in SQLite zipfile extension's zipfileInflate). Alpine 3.23 ships sqlite-libs 3.51.2-r0, which contains the upstream fix. Note that `apk del sqlite` only removes the CLI; sqlite-libs remains because Python's stdlib _sqlite3 module is dynamically linked against it, so a base-image bump is required.

github-actions · 2026-04-27T15:37:02Z

🔍 Vulnerabilities of `permitio/pdp-v2:next`

📦 Image Reference permitio/pdp-v2:next

digest	`sha256:c99553c9743d72997c06db7a0de699bcad062a41b6e8ec3e673bb1b1b26de8b8`
vulnerabilities
platform	linux/amd64
size	122 MB
packages	252

📦 Base Image python:3.10-alpine

also known as	`3.10-alpine3.23` `3.10.20-alpine` `3.10.20-alpine3.23`
digest	`sha256:1d5630a8fe200e88d58cbef2722d634a47d2f0979a28f3980bc7012b56975a3e`
vulnerabilities

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.008%`
EPSS Percentile	`1st 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.

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.

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.007%`
EPSS Percentile	`0th 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

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.051%`
EPSS Percentile	`16th percentile`

Description

github-actions · 2026-04-27T15:37:07Z

🔍 Vulnerabilities of `permitio/pdp-v2:next`

📦 Image Reference permitio/pdp-v2:next

digest	`sha256:c99553c9743d72997c06db7a0de699bcad062a41b6e8ec3e673bb1b1b26de8b8`
vulnerabilities
platform	linux/amd64
size	122 MB
packages	252

📦 Base Image python:3.10-alpine

also known as	`3.10-alpine3.23` `3.10.20-alpine` `3.10.20-alpine3.23`
digest	`sha256:1d5630a8fe200e88d58cbef2722d634a47d2f0979a28f3980bc7012b56975a3e`
vulnerabilities

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.008%`
EPSS Percentile	`1st 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.

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

fix: patch CVE-2025-70873 by bumping base image to python:3.10-alpine3.23#308

fix: patch CVE-2025-70873 by bumping base image to python:3.10-alpine3.23#308
omer9564 wants to merge 1 commit intomainfrom
fix/april-27-2026-cves

omer9564 commented Apr 27, 2026

Uh oh!

github-actions Bot commented Apr 27, 2026

Summary

Root Cause

Attack

Suggested Fix

Summary

Uh oh!

github-actions Bot commented Apr 27, 2026

Summary

Root Cause

Attack

Suggested Fix

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

1 participant

Conversation

omer9564 commented Apr 27, 2026

Summary

Test plan

References

Uh oh!

github-actions Bot commented Apr 27, 2026

🔍 Vulnerabilities of permitio/pdp-v2:next

Summary

Root Cause

Attack

Suggested Fix

Summary

Uh oh!

github-actions Bot commented Apr 27, 2026

🔍 Vulnerabilities of permitio/pdp-v2:next

Summary

Root Cause

Attack

Suggested Fix

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

1 participant

🔍 Vulnerabilities of `permitio/pdp-v2:next`

🔍 Vulnerabilities of `permitio/pdp-v2:next`