OpenTelemetry Go

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 Separately, for a merged upstream patch : up to $5,000 Google Patch Rewards pays for a patch you get accepted upstream and that stays merged, without reverts, for one month. It does not pay for the report. This project sits at Tier 2, the OSS-Fuzz row, where the panel grades a merged patch from $100 for a one-liner up to $5,000 for a complicated, high-impact improvement, entirely at its discretion. The $15,000 headline and the 2× and 3× memory-safety multipliers are Tier 1 only and are not reachable here. Patches must be at least one month and no more than twelve months old, submissions are capped at three per person per month, and sanctions and territory exclusions apply. CVE history 2 Last 12 months 5 Lifetime Denial of service 45 % Parsing/validation 25 % Info disclosure 20 % Access control 5 % Latest advisories Loading the feed Overview OpenTelemetry Go is the instrumentation layer for the cloud-native control plane. It is a dependency of a very large fraction of Go infrastructure software, and otelhttp and otelgrpc arrive transitively in services whose authors never chose OpenTelemetry at all. It runs in-process and privileged, with a twist its own record demonstrates: because request attributes become metric labels, an attacker who controls a header can make the instrumented service allocate without bound. CVE-2023-45142 in otelhttp is that exact shape, a denial of service delivered through the observability layer against the application it was meant to watch. The project's security process publishes advisories promptly and pays nothing, so sorona.xyz pays you directly on qualified, reproduced findings. In scope The project takes reports at [email protected] or through GitHub private advisory reporting and publishes a GHSA. The Google patch pathway is narrower and reaches two repositories only: opentelemetry-go and opentelemetry-go-contrib open-telemetry/opentelemetry-go in full: the trace, metric and log SDKs, the OTLP exporters over gRPC and HTTP, the W3C TraceContext and Baggage propagators, and the semantic-convention packages open-telemetry/opentelemetry-go-contrib in full, meaning every instrumentation library it carries, of which otelhttp and otelgrpc matter most because they sit in the request path of an enormous number of Go services Protobuf and JSON decoding on the OTLP receive and export paths Baggage and TraceContext header parsing, which processes attacker-controllable HTTP headers on every single request Cardinality control and attribute handling in the metric SDK, the point at which a request attribute becomes a metric label and an allocation Exporter transport and configuration, covering endpoint selection, TLS setup and the credentials an exporter carries off-host Out of scope opentelemetry-collector and opentelemetry-collector-contrib , which have no OSS-Fuzz project and therefore no patch pathway The non-Go language SDKs, covering Java, Python, JavaScript, .NET, PHP, Rust and C++, none of which has an OSS-Fuzz directory The bare opentelemetry OSS-Fuzz entry, which points at open-telemetry/community , a governance repository rather than code, and must not be cited as covering anything Vendor distributions of OpenTelemetry, which belong to the vendor's own program where one exists One-line fixes for non-exploitable crashes, which the Patch Rewards rules exclude by name Patches outside the one-to-twelve-month age window the rules impose Most-valued findings Unbounded metric cardinality driven by an attacker-controlled header or gRPC metadata field, the CVE-2023-45142 and CVE-2023-47108 shape. Denial of service is 45% of this project's distribution, and it arrives through the instrumentation against the application it was meant to observe A structural fix to attribute and cardinality handling that bounds a whole class of label explosion rather than one field, since the panel will not pay for a one-liner crash fix Parsing and validation defects in OTLP protobuf or JSON decoding, which run on data arriving from processes the receiving service does not control Baggage or TraceContext parsing flaws, since those headers are attacker-controllable on literally every request that reaches an instrumented service Anything that leaks request data into telemetry that the exporter then ships off-host, which turns instrumentation into an information-disclosure channel and accounts for 20% of the distribution Findings in otelhttp or otelgrpc specifically, because those two packages arrive transitively in services whose authors never chose OpenTelemetry 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 to [email protected] or through GitHub private advisory reporting; the project triages there, publishes GHSAs, and pays nothing for the report itself Send a detailed, reproducible report with the header, payload or configuration that triggers it; if we can't reproduce it, it isn't eligible Coverage on the patch pathway is Go-only: opentelemetry-go and opentelemetry-go-contrib , and nothing else in the OpenTelemetry organisation If you also want the Google patch money, land the fix upstream yourself and keep it merged without reverts for a month; that is a separate pathway with its own rules The Patch Rewards side is capped at three submissions per person per month, takes patches between one and twelve months old, and will not pay for one-liner fixes to non-exploitable crashes Patch Rewards is discretionary and cancellable, and excludes researchers on sanctions lists or located in Russia or Belarus Disclosure Coordinated with the OpenTelemetry security team through [email protected] , which publishes GitHub Security Advisories promptly and with researcher credit; hold the detail until the advisory is out. On the patch pathway the fix is public the moment it merges, so Google's rules carry no confidentiality term at all. 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