Skip to content

chore(deps): opentelemetry 1.45.1 and arize-phoenix-otel 0.17.2 in the lock (CVE-2026-114603) - #844

Open
OAraLabs wants to merge 1 commit into
mainfrom
claude/otel-api-cve-2026-114603
Open

OAraLabs wants to merge 1 commit into
mainfrom
claude/otel-api-cve-2026-114603

Conversation

@OAraLabs

Copy link
Copy Markdown
Owner

Why

Main's quality job is red. Its pip-audit step flags opentelemetry-api 1.42.1 with CVE-2026-114603, which is fixed in 1.45.1. Main has failed this way since 5f49fbb (run 39841872693, and again at 763e76d, run 39868039364), so every open PR shows the same red check, #843 included.

What changes (uv.lock only)

  • The opentelemetry family, 1.42.1 → 1.45.1: api, sdk, proto, exporter-otlp, exporter-otlp-proto-common/-grpc/-http. These packages pin one another exactly, so the api cannot move on its own.
  • instrumentation and semantic-conventions, 0.63b1 → 0.66b1.
  • Two new packages the 1.45 exporters depend on: opentelemetry-exporter-http-transport and opentelemetry-exporter-otlp-common, both 0.66b1.
  • arize-phoenix-otel 0.16.1 → 0.17.2. This is not optional:
    • 0.16.1 reads the exporter's private _headers, which 1.45 removed.
    • With only the opentelemetry bump, phoenix.otel.register raises 'HTTPSpanExporter' object has no attribute '_headers', so PROMETHEUS_TRACING=1 silently never starts.
    • 0.17.2 declares opentelemetry-exporter-otlp-proto-http>=1.45.0.

The lock was made with a targeted uv lock --upgrade-package … using uv 0.11.3. That keeps revision = 3, and the diff is one contiguous block of opentelemetry entries plus the arize-phoenix-otel entry. uv 0.13.0 would have rewritten the file as revision 5 and reordered markers, so it wasn't used.

Who is affected: everything here is in the evals extra only. The base install, the Mac app's extras (mcp slack discord discovery) and the Docker image's extras (mcp slack discord push) export no opentelemetry package.

Verified

  • CI's audit, run locally (uv export --all-extras then pip-audit --no-deps): No known vulnerabilities found. uv lock --check passes.
  • Real tracing check. In an environment synced --frozen from this lock with the evals extra:
    • I started an in-process OTLP/HTTP collector on loopback, ran prometheus.tracing.phoenix.init_tracing against it, emitted a span with span_context, and called shutdown_tracing.
    • With this lock the span arrives (POST /v1/traces, protobuf). Main's lock passes the same check.
    • With only the opentelemetry bump (before adding arize-phoenix-otel 0.17.2), tracing did not start.
  • tests/test_evals.py, test_extras_security_floors.py, test_web_is_base.py, test_honest_status_notes.py and test_template_key_placement.py in that environment: 126 passed.

🤖 Generated with Claude Code

…e lock (CVE-2026-114603)

pip-audit in the quality job flags opentelemetry-api 1.42.1 with
CVE-2026-114603 (fixed in 1.45.1), so quality has been red on main
since 5f49fbb. The opentelemetry packages pin one another exactly, so
the family moves together: api, sdk, proto and the OTLP exporters
1.42.1 -> 1.45.1, instrumentation and semantic-conventions 0.63b1 ->
0.66b1, plus two packages the 1.45 exporters now need
(opentelemetry-exporter-http-transport, -otlp-common 0.66b1).

arize-phoenix-otel moves 0.16.1 -> 0.17.2 with them: 0.16.1 reads the
exporter's private _headers, which 1.45 removed, so phoenix.otel.register
raised and PROMETHEUS_TRACING never started. 0.17.2 requires
opentelemetry-exporter-otlp-proto-http>=1.45.0. A real span sent through
prometheus.tracing.phoenix to a loopback OTLP collector arrives with the
new lock (and with the old one; it failed with only the otel bump).

All of it is in the evals extra only: the base install, the Mac app's
extras and the Docker image do not carry opentelemetry. Locked with uv
0.11.3 so the lock stays revision 3 and nothing else moves.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
OAraLabs pushed a commit that referenced this pull request Oct 23, 2026
…es (CVE-2026-114603)

The quality job's pip-audit step fails on main (opentelemetry-api 1.42.1,
CVE-2026-114603, fixed in 1.45.1), so it fails every PR. #844 is the fix; this
is the identical uv.lock change so this PR's check can go green. It is the same
bytes as #844, so whichever merges second is a no-op.

Verified: pip-audit on the exported lock reports no known vulnerabilities;
ruff and the mypy gate were already clean; the purge tests pass on the bumped
lock.

Co-Authored-By: Claude <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_018UjrXNciMTQJ8Ms46sH4fu

This branch has not been deployed

No deployments
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant