Between 8 September and 2 October 2026, NVD recorded about a dozen CVEs across the OpenTelemetry project. They hit the Kubernetes Operator, Collector Contrib, the eBPF profiler, the Go SDK and the JavaScript instrumentation packages. One Operator bug can leak a service account token, and a GitHub receiver bug lets unauthenticated senders put fake CI traces into your pipeline.
Telemetry pipelines are easy to forget because they are plumbing. The Collector often has a service account, API tokens for backends and a public ingest port. Here is how to tell which advisories touch you.
What's affected
| CVE | Component | Affected | Fixed in | NVD score |
|---|---|---|---|---|
| CVE-2026-47701 | OpenTelemetry Operator, target allocator with prometheusCR enabled | Before 0.152.0 | 0.152.0 | 7.7 |
| CVE-2026-55701 | Collector Contrib githubreceiver | Before 0.151.0 | 0.151.0 | 6.9 |
| CVE-2026-47256 | Collector Contrib Sentry exporter | Before 0.154.0 | 0.154.0 | 5.3 |
| CVE-2026-48496 | eBPF Profiler | 0.0.202527 up to before 0.0.202622 | 0.0.202622 | 6.2 |
| CVE-2026-81871 | otel-go otlploggrpc | Before 0.21.0 | 0.21.0 | 6.3 |
| CVE-2026-81872 | otel-go sdk/log BatchingProcessor | Before 0.21.0 | 0.21.0 | 6.3 |
| CVE-2026-81870 | otel-go sdk/trace | 1.5.0 to 1.44.0 | 1.45.0 | 2.0 |
| CVE-2026-81869 | otel-go sdk/trace | 1.10.0 until 1.33.0 | 1.33.0 | 5.1 |
| CVE-2026-104872 | JS contrib DB instrumentations | Before pg 0.73.0, mysql2 0.67.0, knex 0.65.0 and others | Same versions | 5.8 |
| CVE-2026-44163 | fluent-plugin-opentelemetry | Before 0.5.3 | 0.5.3 | 5.3 |
Operator, CVE-2026-47701. A tenant who can create or update a ServiceMonitor matched by the Operator's selectors can point bearerTokenFile at a file in the Collector pod, including the service account token, and direct scraping to an endpoint they control. The Collector sends that file's contents as bearer authorization on every scrape. The CVE text requires the token to be mounted and the Collector to reach the target, and says Kubernetes API impact is limited by the service account's permissions. If you do not enable targetAllocator.prometheusCR, this one does not apply.
githubreceiver, CVE-2026-55701. The receiver validates required_headers at startup but not on incoming webhooks. If the secret is empty, HMAC validation is also skipped. An unauthenticated sender can submit arbitrary payloads and inject fabricated CI/CD trace data. This only matters if you run the receiver and expose its webhook port.
Sentry exporter, CVE-2026-47256. The service.name resource attribute, which a remote OTLP sender controls, goes into a Sentry API URL without validation. The Collector's configured bearer token is attached. The CVE text says Sentry's token middleware prevents cross organization access.
Go SDK. CVE-2026-81871 matters if you rely on OTEL_EXPORTER_OTLP_CERTIFICATE variables for private CA pinning or mutual TLS with the log exporter. The text says the environment only path uses system roots and no client certificate, so a network attacker with a system trusted certificate could read or alter log telemetry. CVE-2026-81870 only fires if you enabled OpenTelemetry's internal Info logging with otel.SetLogger.
JavaScript. CVE-2026-104872 is about disclosure of database usernames in span attributes by default, to whatever backend you export to.
How to check if you're exposed
Which Collector and Operator versions are running:
kubectl get deploy -A -o jsonpath='{range .items[*]}{.metadata.name}{" "}{.spec.template.spec.containers[*].image}{"\n"}{end}' | grep -i -E "otel|opentelemetry"
otelcol-contrib --version
Does your Collector config use the receivers or exporters in question?
grep -rnE "githubreceiver|^\s*github:|sentry:|prometheusCR|serviceMonitorSelector" collector-config.yaml otel-*.yaml
For SDKs, check the resolved versions:
go list -m all | grep -E "go.opentelemetry.io/otel"
npm ls @opentelemetry/instrumentation-pg @opentelemetry/instrumentation-mysql2
What to do now
- Upgrade the Operator to 0.152.0 or later if you use the target allocator with prometheusCR.
- Upgrade Collector Contrib to 0.154.0 or later, which is above the githubreceiver and Sentry fixes. Set a webhook secret on any githubreceiver in service, and do not leave the secret empty.
- In the Operator setup, limit who can create ServiceMonitors in namespaces your selectors match.
- Bump Go modules: go.opentelemetry.io/otel to 1.45.0 and the log SDK and exporter to 0.21.0.
- Update the JS instrumentation packages listed in the table. If your telemetry backend is shared with other teams, review whether database account names in spans are acceptable.
- Rotate the Collector service account token if you ran an affected Operator where tenants could create ServiceMonitors.
Why it matters
Collectors sit between your applications and your observability vendor. They hold credentials for both and accept input from anywhere. A scrape configuration that a tenant controls, or a webhook that anyone can post to, is a trust boundary that is easy to miss on a diagram.
Most of this batch is conditional. The Operator bug needs prometheusCR, the GitHub bug needs the receiver, and the Go log bug needs internal logging switched on. Counting the components in your own manifests tells you more than reading the scores.
Try it yourself
List every OpenTelemetry module in your dependency tree. The demo below shows how an inventory of direct and transitive packages is built.
Click through it at your own pace, or open it full screen.
Quick check
You run the Operator but never set prometheusCR on the target allocator. Does CVE-2026-47701 apply?
The CVE text ties it to targetAllocator.prometheusCR.enabled set to true. Without it the path is not reachable, but upgrading to 0.152.0 is still sensible.
Is a signed webhook payload enough on githubreceiver?
Only if you set the secret. When the Secret field is empty, the CVE text says HMAC validation is skipped.
