OpenTelemetry Collector
By sorona.xyz Bug bounty on Sorona opentelemetry.io
- Top reward
- $1,500
- Top severity paid
- Critical
- Assets in scope
- 13
- Public CVEs
- 34
- Last change
- No changes yet
At a glance
What to know before you start testing.
- Pays from $1,500
- for critical bugs.
- Report on Sorona
- Submit through the program page.
- Partial safe harbor
- Some legal protection; read the terms.
- Publish after a fix
- Coordinate the timing with the company.
Rewards
What Sorona lists as the payout for each severity.
| Severity | Relative size | Reward |
|---|---|---|
| Critical | $1,500+ | |
| High | $700+ | |
| Medium | $300+ | |
| Low |
|
$100 $100 / 1 month Claude Max |
- Safe harbor
-
Partial
Sorona will not pursue legal action against you for good-faith research submitted to us in line with this policy. We cannot speak for the upstream project, its vendor, or any third party, and we do not grant authorization on their behalf.
Summarised with AI from the program policy on Sorona, read 12 Nov 2026, and checked word for word against it. Read the original
Scope
13 assets you may test, 6 excluded.
Web 1
- https://opentelemetry.io/docs/collector
Products and areas 12
- Connectors and the service graph that routes data between pipelines
- Every exporter and the credentials it holds for its backend, along with the retry and queue behaviour behind it
- Every receiver, starting with OTLP over gRPC and HTTP, and extending across the Prometheus, Jaeger, Zipkin, Fluent Forward, syslog, statsd, kafka, filelog, hostmetrics and webhook receivers in contrib
- Extensions in full, covering the auth extensions (bearer token, OIDC, basic auth, sigv4, headers setter), the health check, pprof and zpages
- The batch processor, the memory limiter and the behaviour of the whole pipeline under load or backpressure
- The builder that assembles a custom distribution and the component manifest it consumes
- The Collector's own internal telemetry: the metrics it exposes about itself and the debug surfaces that describe its configuration
- The configuration loader, environment variable expansion, and the confmap providers that resolve configuration from a file, an HTTP endpoint, S3 or another remote source
- The OpAMP supervisor and remote configuration where it is enabled, which lets a control server change what the Collector runs
- The processors, in particular the transform, filter, attributes, redaction and tail sampling processors that decide what leaves the pipeline
- The security process asks for a private GitHub advisory on the collector repositories with [email protected] as fallback, and declares no boundary narrower than the Collector itself. Both the core and contrib repositories sit inside it
- TLS configuration on every receiver and exporter, including certificate verification, minimum versions and mutual TLS
Out of scope (6)
- A pipeline an operator configured to forward or expose data they did not intend to forward or expose
- Resource consumption that the memory limiter is configured to allow
- The observability backends the Collector exports to, which belong to their vendors
- The OpenTelemetry language SDKs and instrumentation libraries, separate repositories with their own advisory streams
- The OpenTelemetry Operator and Helm charts, which live in their own repositories
- Third-party components maintained outside the two collector repositories
Rules
What the policy asks of you, and the bug types it won't reward, quoted from Sorona's policy.
While testing
-
Report through GitHub private vulnerability reporting on the affected collector repository. the address on the policy page is the documented fallback
-
Both opentelemetry-collector and opentelemetry-collector-contrib are in scope for the same process. Name which one
-
Give the full collector configuration that reproduces it, with credentials redacted.
-
Say whether the Collector ran as a node agent or as a central gateway.
-
Distinguish a defect in a component from a pipeline an operator configured to do what it did.
Not accepted
-
Forwarding data an operator told it to forward is configuration, not a vulnerability
-
Resource consumption that the memory limiter is configured to allow
Summarised with AI from the program policy on Sorona, read 12 Nov 2026, and checked word for word against it. Read the original
Changes
Tracked since 11 Nov 2026. Last checked 1 hour ago.
No changes yet. When the rewards or scope move, you will see it here and in the RSS feed.
Public CVEs
Published vulnerabilities in this vendor's products, from the NVD.
| CVE | Summary | Severity | Published |
|---|---|---|---|
| CVE-2026-54285 | opentelemetry-js is the OpenTelemetry JavaScript Client. Prior to 2.8.0, W3CBaggagePropagator.extract() in @opentelemetry/core does not enforce size limits when parsing inbound baggage HTTP headers. The W3C Baggage specification recommends a maximum of 8,192 bytes and 180 entries; these limits were only enforced on the outbound (inject()) path, not on the inbound (extract()) path. Parsing oversize | Medium 5.3 | 22 Jun 2026 |
| CVE-2026-44967 | OpenTelemetry-cpp is the C++ implementation of OpenTelemetry. Prior to release 1.27.0, the OTLP HTTP exporters (traces/metrics/logs) read the full HTTP response into an in-memory vector of bytes 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). This vulnerability is f | Medium 5.3 | 12 Jun 2026 |
| CVE-2026-45287 | OpenTelemetry-Go is the Go implementation of OpenTelemetry. Prior to version 0.0.17, `go.opentelemetry.io/otel/schema/v1.0` and `go.opentelemetry.io/otel/schema/v1.1` leaks one file descriptor on each successful `ParseFile` call. `ParseFile` opens the schema file and passes it to `Parse` without closing it; repeated parsing in a long-running process can exhaust the process file descriptor limit an | Low 2.1 | 4 Jun 2026 |
| CVE-2026-41178 | OpenTelemetry-Go is the Go implementation of OpenTelemetry. Versions 1.41.0 and 1.43.0 removed raw-length rejection and it causes `Parse` to process arbitrarily large/invalid baggage headers and log errors, enabling DoS via oversized inputs. Versions 1.42.0 and 1.44.0 fix the issue. | Medium 5.3 | 4 Jun 2026 |
| CVE-2026-45680 | OpenTelemetry eBPF Instrumentation provides eBPF instrumentation based on the OpenTelemetry standard. Prior to version 0.9.0, OBI replays BPF probe hits into histogram observations by looping once per recorded run count. On busy systems, the run-count delta can become very large, causing the metrics exporter to spend excessive CPU time in a tight loop every collection interval. This issue has been | Medium 5.9 | 2 Jun 2026 |
| CVE-2026-45681 | OpenTelemetry eBPF Instrumentation provides eBPF instrumentation based on the OpenTelemetry standard. Prior to version 0.9.0, the per-CPU message-buffer fallback path uses a 256-byte backup buffer but preserves the original payload size, which can be up to 8KB. If a CPU mismatch occurs, OBI can read beyond the fallback buffer and leak adjacent memory into telemetry. This issue has been patched in | Medium 5.9 | 2 Jun 2026 |
| CVE-2026-45682 | OpenTelemetry eBPF Instrumentation provides eBPF instrumentation based on the OpenTelemetry standard. Prior to version 0.9.0, the custom CappedConcurrentHashMap introduced for Java TLS state tracking never removes keys from its insertion-order queue when entries are deleted. In long-running instrumented JVMs, repeated connection churn can therefore grow the queue without bound and exhaust heap mem | Medium 5.1 | 2 Jun 2026 |
| CVE-2026-45683 | OpenTelemetry eBPF Instrumentation provides eBPF instrumentation based on the OpenTelemetry standard. Prior to version 0.9.0, the Java TLS ioctl probe reads user-controlled ioctl pointers with bpf_probe_read instead of bpf_probe_read_user. An instrumented local process can therefore point OBI at kernel memory and cause that memory to be copied into telemetry. This issue has been patched in version | Low 3.8 | 2 Jun 2026 |
| CVE-2026-45684 | OpenTelemetry eBPF Instrumentation provides eBPF instrumentation based on the OpenTelemetry standard. From version 0.7.0 to before version 0.9.0, OBI's log enricher mishandles writev buffers by reading only the first iovec entry but using the total iov_iter.count as the copy length. When log injection is enabled, a crafted multi-segment writev call can make OBI read and overwrite memory beyond the | Medium 4.9 | 2 Jun 2026 |
| CVE-2026-45685 | OpenTelemetry eBPF Instrumentation provides eBPF instrumentation based on the OpenTelemetry standard. From version 0.1.0 to before version 0.9.0, malformed MongoDB wire messages can trigger uncaught panics in the MongoDB TCP parser, allowing a remote unauthenticated attacker to crash the telemetry agent and cause a denial of service. The parser operates on raw attacker-controlled network payloads | High 7.5 | 2 Jun 2026 |
| CVE-2026-45686 | OpenTelemetry eBPF Instrumentation provides eBPF instrumentation based on the OpenTelemetry standard. From version 0.7.0 to before version 0.9.0, a remotely reachable integer overflow in OBI's memcached text protocol parser can crash the OBI process and cause denial of service. When parsing memcached storage commands such as set, add, replace, append, prepend, or cas, OBI accepts extremely large < | High 7.5 | 2 Jun 2026 |
| CVE-2026-45676 | OpenTelemetry eBPF Instrumentation provides eBPF instrumentation based on the OpenTelemetry standard. Prior to version 0.9.0, OBI's replacement ELF parser trusts section offsets, counts, and string offsets from the executable file. A crafted local ELF can make OBI dereference invalid section pointers or slice past string tables, causing the agent to panic while determining the process language. Th | Medium 5.5 | 2 Jun 2026 |
| CVE-2026-45678 | OpenTelemetry eBPF Instrumentation provides eBPF instrumentation based on the OpenTelemetry standard. Prior to version 0.9.0, the Postgres protocol parser assumes BIND message payloads contain a valid NUL-terminated portal name. A crafted empty or unterminated payload can make OBI slice beyond the end of the captured buffer and panic. This issue has been patched in version 0.9.0. | High 7.5 | 2 Jun 2026 |
| CVE-2026-45679 | OpenTelemetry eBPF Instrumentation provides eBPF instrumentation based on the OpenTelemetry standard. Prior to version 0.9.0, OBI exports raw Redis error text as the span status message. Because Redis error replies can contain attacker-controlled or sensitive values, this behavior can exfiltrate tokens, PII, or other confidential input into telemetry backends and inject untrusted text into downstr | Medium 6.5 | 2 Jun 2026 |
| CVE-2026-44902 | opentelemetry-js is the OpenTelemetry JavaScript Client. Prior to 0.217.0, a single malformed HTTP request crashes any Node.js process running the OpenTelemetry JS Prometheus exporter. The metrics endpoint (default 0.0.0.0:9464) has no error handling around URL parsing, so a request with an invalid URI causes an uncaught TypeError that terminates the process. This vulnerability is fixed in 0.217.0 | High 7.5 | 27 May 2026 |
| CVE-2026-42602 | azureauthextension is the Azure Authenticator Extension. From 0.124.0 to 0.150.0, a server-side authentication bypass in azureauthextension allows any party who holds a single valid Azure access token for any scope the collector's configured identity can mint for to authenticate to any OpenTelemetry receiver that uses auth: azure_auth. The extension's Authenticate method does not validate incoming | High 8.1 | 13 May 2026 |
| CVE-2026-42191 | OpenTelemetry.Exporter.OpenTelemetryProtocol is the OTLP (OpenTelemetry Protocol) exporter implementation. From 1.8.0 to 1.15.2, the OTLP disk retry feature in OpenTelemetry.Exporter.OpenTelemetryProtocol silently fell back to Path.GetTempPath() when OTEL_DOTNET_EXPERIMENTAL_OTLP_RETRY=disk was set but OTEL_DOTNET_EXPERIMENTAL_OTLP_DISK_RETRY_DIRECTORY_PATH was not configured. The exporter stored | Medium 6.5 | 12 May 2026 |
| CVE-2026-42348 | OpenTelemetry.OpAmp.Client is the OpAMP client for OpenTelemetry .NET. Prior to 0.2.0-alpha.1, when receiving responses from the OpAMP server over HTTP, the OpAMP client allocates an unbounded buffer to read all bytes from the server, with no upper-bound on the number of bytes consumed. This could cause memory exhaustion in the consuming application if the configured OpAMP server is attacker-contr | Medium 5.9 | 12 May 2026 |
| CVE-2026-41310 | OpenTelemetry.Exporter.Zipkin is the .NET Zipkin exporter for OpenTelemetry. In versions 1.15.2 and earlier, the Zipkin exporter remote endpoint cache accepts unbounded key growth derived from span attributes. In high-cardinality scenarios, a process using Zipkin export for client or producer spans could experience avoidable memory growth under sustained unique remote endpoint values, increasing p | Medium 5.3 | 6 May 2026 |
| CVE-2026-41483 | OpenTelemetry.Resources.Azure is the .NET resource detector for Azure environments. In versions 1.15.0-beta.1 and earlier, the AzureVmMetaDataRequestor class makes HTTP requests to the Azure VM instance metadata service and reads the response body into memory without any size limit. An attacker who controls the configured endpoint, or who can intercept traffic to it via a man-in-the-middle attack, | Medium 5.9 | 6 May 2026 |
| CVE-2026-41484 | OpenTelemetry.Exporter.OneCollector is a .NET exporter that sends telemetry to a OneCollector back-end over HTTP. In versions 1.15.0 and earlier, when a request to the configured back-end or collector results in an unsuccessful HTTP 4xx or 5xx response, the HttpJsonPostTransport class reads the entire response body into memory with no upper bound on the number of bytes consumed in order to include | Medium 5.3 | 6 May 2026 |
| CVE-2026-41433 | OpenTelemetry eBPF Instrumentation provides eBPF instrumentation based on the OpenTelemetry standard. From 0.4.0 to before 0.8.0, a flaw in the Java agent injection path allows a local attacker controlling a Java workload to overwrite arbitrary host files when Java injection is enabled and OBI is running with elevated privileges. The injector trusted TMPDIR from the target process and used unsafe | High 8.4 | 24 Apr 2026 |
| CVE-2026-40894 | OpenTelemetry dotnet is a dotnet telemetry framework. In OpenTelemetry.Api 0.5.0-beta.2 to 1.15.2 and OpenTelemetry.Extensions.Propagators 1.3.1 to 1.15.2, The implementation details of the baggage, B3 and Jaeger processing code in the OpenTelemetry.Api and OpenTelemetry.Extensions.Propagators NuGet packages can allocate excessive memory when parsing which could create a potential denial of servic | Medium 5.3 | 23 Apr 2026 |
| CVE-2026-41078 | OpenTelemetry dotnet is a dotnet telemetry framework. In 1.6.0-rc.1 and earlier, OpenTelemetry.Exporter.Jaeger may allow sustained memory pressure when the internal pooled-list sizing grows based on a large observed span/tag set and that enlarged size is reused for subsequent allocations. Under high-cardinality or attacker-influenced telemetry input, this can increase memory consumption and potent | Medium 5.9 | 23 Apr 2026 |
| CVE-2026-40182 | OpenTelemetry dotnet is a dotnet telemetry framework. From 1.13.1 to before 1.15.2, When exporting telemetry to a back-end/collector over gRPC or HTTP using OpenTelemetry Protocol format (OTLP), if the request results in a unsuccessful request (i.e. HTTP 4xx or 5xx), the response is read into memory with no upper-bound on the number of bytes consumed. This could cause memory exhaustion in the cons | Medium 5.3 | 23 Apr 2026 |
| CVE-2026-40891 | OpenTelemetry dotnet is a dotnet telemetry framework. From 1.13.1 to before 1.15.2, When exporting telemetry over gRPC using the OpenTelemetry Protocol (OTLP), the exporter may parse a server-provided grpc-status-details-bin trailer during retry handling. Prior to the fix, a malformed trailer could encode an extremely large length-delimited protobuf field which was used directly for allocation, al | Medium 5.3 | 23 Apr 2026 |
| CVE-2026-39882 | OpenTelemetry-Go is the Go implementation of OpenTelemetry. Prior to 1.43.0, 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). This vulnerability is fixed in | Medium 5.3 | 8 Apr 2026 |
| CVE-2026-39883 | OpenTelemetry-Go is the Go implementation of OpenTelemetry. From 1.15.0 to 1.42.0, the fix for 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. This vulnerability is fixed in 1.43.0. | High 7.3 | 8 Apr 2026 |
| CVE-2026-29181 | OpenTelemetry-Go is the Go implementation of OpenTelemetry. From 1.36.0 to 1.40.0, multi-value baggage: header extraction parses each header field-value independently and aggregates members across values. This allows an attacker to amplify cpu and allocations by sending many baggage: header lines, even when each individual value is within the 8192-byte per-value parse limit. This vulnerability is | High 7.5 | 7 Apr 2026 |
| CVE-2026-24051 | OpenTelemetry-Go is the Go implementation of OpenTelemetry. The OpenTelemetry Go SDK in version v1.20.0-1.39.0 is vulnerable to Path Hijacking (Untrusted Search Paths) on macOS/Darwin systems. The resource detection code in sdk/resource/host_id.go executes the ioreg system command using a search path. An attacker with the ability to locally modify the PATH environment variable can achieve Arbitrar | High 7.0 | 2 Feb 2026 |
| CVE-2024-36129 | The OpenTelemetry Collector offers a vendor-agnostic implementation on how to receive, process and export telemetry data. An unsafe decompression vulnerability allows unauthenticated attackers to crash the collector via excessive memory consumption. OTel Collector version 0.102.1 fixes this issue. It is also fixed in the confighttp module version 0.102.0 and configgrpc module version 0.102.1. | High 8.2 | 5 Jun 2024 |
| CVE-2023-47108 | OpenTelemetry-Go Contrib is a collection of third-party packages for OpenTelemetry-Go. Starting in version 0.37.0 and prior to version 0.46.0, the grpc Unary Server Interceptor out of the box adds labels `net.peer.sock.addr` and `net.peer.sock.port` that have unbound cardinality. It leads to the server's potential memory exhaustion when many malicious requests are sent. An attacker can easily floo | High 7.5 | 10 Nov 2023 |
| CVE-2023-45142 | OpenTelemetry-Go Contrib is a collection of third-party packages for OpenTelemetry-Go. A handler wrapper out of the box adds labels `http.user_agent` and `http.method` that have unbound cardinality. It leads to the server's potential memory exhaustion when many malicious requests are sent to it. HTTP header User-Agent or HTTP method for requests can be easily set by an attacker to be random and lo | High 7.5 | 12 Oct 2023 |
| CVE-2023-43810 | OpenTelemetry, also known as OTel for short, is a vendor-neutral open-source Observability framework for instrumenting, generating, collecting, and exporting telemetry data such as traces, metrics, logs. Autoinstrumentation out of the box adds the label `http_method` that has unbound cardinality. It leads to the server's potential memory exhaustion when many malicious requests are sent. HTTP metho | High 7.5 | 6 Oct 2023 |
Original policy
Copied from sorona.xyz on 12 Nov 2026. The summaries on this page are made from it; the live page may have changed since.
Skip to content What this pays This project runs no bounty of its own. sorona.xyz pays you directly on qualified, reproduced findings. Severity │ sorona.xyz pays Critical │ $1,500+ High │ $700+ Medium │ $300+ Low │ $100 / 1 month Claude Max Submit a vulnerability Latest advisories Loading the feed Overview The Collector is the telemetry gateway nearly every OpenTelemetry deployment routes through, running as a per-node agent and as a central gateway between applications and whichever observability backend the organisation buys. It receives untrusted data from every instrumented service, parses several wire formats, and holds the API credentials for each backend it exports to. A parsing defect there is code execution on a component that talks to everything, and a configuration leak exposes the whole pipeline at once. The OpenTelemetry project publishes advisories promptly and pays nothing for a report. sorona.xyz pays you directly on qualified, reproduced findings. In scope The security process asks for a private GitHub advisory on the collector repositories with [email protected] as fallback, and declares no boundary narrower than the Collector itself. Both the core and contrib repositories sit inside it Every receiver, starting with OTLP over gRPC and HTTP, and extending across the Prometheus, Jaeger, Zipkin, Fluent Forward, syslog, statsd, kafka, filelog, hostmetrics and webhook receivers in contrib The processors, in particular the transform, filter, attributes, redaction and tail sampling processors that decide what leaves the pipeline Every exporter and the credentials it holds for its backend, along with the retry and queue behaviour behind it The configuration loader, environment variable expansion, and the confmap providers that resolve configuration from a file, an HTTP endpoint, S3 or another remote source Extensions in full, covering the auth extensions (bearer token, OIDC, basic auth, sigv4, headers setter), the health check, pprof and zpages The Collector's own internal telemetry: the metrics it exposes about itself and the debug surfaces that describe its configuration TLS configuration on every receiver and exporter, including certificate verification, minimum versions and mutual TLS The batch processor, the memory limiter and the behaviour of the whole pipeline under load or backpressure Connectors and the service graph that routes data between pipelines The OpAMP supervisor and remote configuration where it is enabled, which lets a control server change what the Collector runs The builder that assembles a custom distribution and the component manifest it consumes Out of scope The OpenTelemetry language SDKs and instrumentation libraries, separate repositories with their own advisory streams The observability backends the Collector exports to, which belong to their vendors The OpenTelemetry Operator and Helm charts, which live in their own repositories A pipeline an operator configured to forward or expose data they did not intend to forward or expose Third-party components maintained outside the two collector repositories Resource consumption that the memory limiter is configured to allow Most-valued findings Unauthenticated remote code execution or memory corruption in any receiver, since a receiver accepts data from anything that can reach the port and most deployments authenticate nothing at that layer Configuration and credential disclosure through pprof, zpages or the internal telemetry endpoints, which are enabled far more often than operators realise and describe every exporter's destination confmap providers fetching configuration from a location an attacker can influence, which turns configuration loading into code and credential loading The auth extensions accepting a token, assertion or signature they should reject, since they are what stands between the gateway and any sender on the network Processors failing to redact or drop what an operator told them to, because the redaction processor is the control keeping secrets out of a third-party backend Decompression and unbounded allocation on receive, the classic telemetry denial-of-service shape and one any sender can trigger TLS verification defaults on exporters, where a silent downgrade or a skipped check sends an organisation's whole telemetry stream to an interceptor The OpAMP remote configuration path, where a control server or something impersonating one changes the running configuration on every Collector in the fleet Cross-tenant leakage in a gateway deployment, where data attributed to one sender appears in another's pipeline or export Program rules Submit through sorona.xyz. This project runs no bounty of its own; we validate, coordinate disclosure with the maintainers, and pay you directly. Report through GitHub private vulnerability reporting on the affected collector repository. [email protected] is the documented fallback Both opentelemetry-collector and opentelemetry-collector-contrib are in scope for the same process. Name which one, since almost all receivers and exporters live in contrib Nothing is paid at any severity. The CNCF runs no umbrella bounty for its projects outside Kubernetes Give the full collector configuration that reproduces it, with credentials redacted. A finding usually depends on which receivers, processors and extensions were enabled Say whether the Collector ran as a node agent or as a central gateway. The gateway holds more credentials and sees more tenants, so the same defect lands very differently Distinguish a defect in a component from a pipeline an operator configured to do what it did. Forwarding data an operator told it to forward is configuration, not a vulnerability Disclosure Coordinated through the GitHub advisory flow with the Collector maintainers, published as a GHSA with a CVE alongside a release across the affected modules. The Collector ships as many independently versioned Go modules, so the fix may span several of them and the embargo runs to that coordinated release rather than to a day count you set. Safe harbor Sorona will not pursue legal action against you for good-faith research submitted to us in line with this policy. We cannot speak for the upstream project, its vendor, or any third party, and we do not grant authorization on their behalf. You are responsible for understanding and following the laws that apply to you, wherever you are, and for staying within any scope the project has defined. Submit a vulnerability