DEBIAN-CVE-2026-116694: Medium severity debian/python-opentelemetry vulnerability

Q: Which deployments are most exposed to this issue?

Services that enable the optional Jaeger propagator and accept untrusted inbound carriers are exposed. Risk is higher with custom getters, non-HTTP transports, or HTTP deployments that have raised header-size limits; common default Python HTTP server limits reduce the practical impact.

Q: What must an attacker be able to send to trigger the resource consumption?

An attacker must be able to provide an untrusted carrier containing numerous or oversized uberctx-* baggage values. Exploitation does not require privileges or user interaction, but transport-level input limits can constrain the payload.

Q: What can be done if upgrading is not immediately possible?

Disable the optional Jaeger propagator where it is not needed, and enforce transport-level limits on inbound header or carrier size and count. Avoid custom or non-HTTP carrier handling that permits unconstrained uberctx-* values.

Q: How can I determine whether a service is affected?

Check whether the service uses opentelemetry-propagator-jaeger and enables JaegerPropagator.extract() for inbound request handling. Versions prior to 1.45.0 are affected when untrusted carriers can reach that extraction path without effective size or count limits.

Published Oct 27, 2026

Updated

OpenTelemetry Python provides the Python API and SDK for OpenTelemetry. Prior to 1.45.0, JaegerPropagator.extract() in opentelemetry-propagator-jaeger processes inbound uberctx- baggage values without entry, per-entry byte, or total-byte limits. Services that enable the optional Jaeger propagator can perform unnecessary CPU work and short-lived heap allocations when an untrusted carrier supplies numerous or oversized values, contributing to denial of service when transport-level limits do not constrain the input. Common default Python HTTP server limits reduce the practical impact, while custom getters, non-HTTP transports, or raised header limits increase exposure. This issue is fixed in version 1.45.0.

Affected Software

1 affected componentFixes available

debian/python-opentelemetry<1.45.1-1

1.45.1-1

Remediation

Recommended actions to resolve this vulnerability, in priority order.

Upgrade
Upgrade debian/python-opentelemetry to a version that resolves this vulnerability.
Fixed in 1.45.1-1
Upgrade
Upgrade opentelemetry-propagator-jaeger to a version that resolves this vulnerability.
Fixed in 1.45.0

Event History

Oct 27, 2026

CVE Published

via OSV·09:18 PM

Data Sourced

via OSV·09:18 PM

DescriptionSeverityAffected Software

Frequently Asked Questions

Which deployments are most exposed to this issue?

Services that enable the optional Jaeger propagator and accept untrusted inbound carriers are exposed. Risk is higher with custom getters, non-HTTP transports, or HTTP deployments that have raised header-size limits; common default Python HTTP server limits reduce the practical impact.

What must an attacker be able to send to trigger the resource consumption?

An attacker must be able to provide an untrusted carrier containing numerous or oversized uberctx-* baggage values. Exploitation does not require privileges or user interaction, but transport-level input limits can constrain the payload.

What can be done if upgrading is not immediately possible?

Disable the optional Jaeger propagator where it is not needed, and enforce transport-level limits on inbound header or carrier size and count. Avoid custom or non-HTTP carrier handling that permits unconstrained uberctx-* values.

How can I determine whether a service is affected?

Check whether the service uses opentelemetry-propagator-jaeger and enables JaegerPropagator.extract() for inbound request handling. Versions prior to 1.45.0 are affected when untrusted carriers can reach that extraction path without effective size or count limits.

DEBIAN-CVE-2026-116694: Medium severity debian/python-opentelemetry vulnerability

Affected Software

Remediation

Event History

Frequently Asked Questions

Which deployments are most exposed to this issue?

What must an attacker be able to send to trigger the resource consumption?

What can be done if upgrading is not immediately possible?

How can I determine whether a service is affected?

Company

Resources

Contact

Frequently Asked Questions

Which deployments are most exposed to this issue?

What must an attacker be able to send to trigger the resource consumption?

What can be done if upgrading is not immediately possible?

How can I determine whether a service is affected?