Kielek

**Name of the Vulnerable Software and Affected Versions** OpenTelemetry.OpAmp.Client versions prior to 0.2.0-alpha.1 **Description** When receiving responses from the OpAMP server over HTTP, the client allocates an unbounded buffer to read all bytes from the server without an upper limit on the number of bytes consumed. This occurs because the HTTP transport components use the `ReadAsByteArrayAsync()` function to copy the `HttpResponseMessage.Content` into a byte array, allowing an unbounded read of the entire HTTP response message. If the configured OpAMP server is attacker-controlled or a network attacker performs a Man-in-the-Middle (MitM) attack, an extremely large response body could lead to memory exhaustion and a denial-of-service condition in the consuming application. **Recommendations** Update to version 0.2.0-alpha.1.

**Name of the Vulnerable Software and Affected Versions** OpenTelemetry.Exporter.Zipkin versions prior to 1.15.3 **Description** The remote endpoint cache in the Zipkin exporter accepts unbounded key growth derived from span attributes. In high-cardinality scenarios—situations where there is a large number of unique values—a process using Zipkin export for client or producer spans may experience continuous memory growth under sustained unique remote endpoint values, which increases memory usage over time and degrades availability. **Recommendations** Update to version 1.15.3.

**Name of the Vulnerable Software and Affected Versions** OpenTelemetry dotnet versions 1.13.1 through 1.15.1 **Description** 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. A malformed trailer can encode an extremely large length-delimited protobuf field (a method of serializing structured data) which is used directly for allocation. This occurs because the `DecodeBytes()` function in `GrpcStatusDeserializer` decodes a protobuf varint length and allocates a byte array without validating the bounds against the remaining payload size. A malicious or compromised collector, or a man-in-the-middle attacker, could return a crafted payload to force oversized memory allocation, leading to memory exhaustion and a potential denial of service (DoS) causing process instability or crashes. **Recommendations** Update to version 1.15.2.

**Name of the Vulnerable Software and Affected Versions** OpenTelemetry.Api versions 0.5.0-beta.2 through 1.15.2 OpenTelemetry.Extensions.Propagators versions 1.3.1 through 1.15.2 **Description** Implementation details of the baggage, B3, and Jaeger processing code in the OpenTelemetry.Api and OpenTelemetry.Extensions.Propagators NuGet packages can allocate excessive memory during parsing. This occurs because certain methods eagerly allocate intermediate arrays before applying size limits, and the `BaggagePropagator.Inject<T>()` function may fail to enforce length limits when injected baggage contains only one item. This behavior can lead to a denial of service (DoS) in the consuming application when processing excessively large or malformed propagation headers. The affected functions include `BaggagePropagator.Extract<T>()`, `BaggagePropagator.Inject<T>()`, `B3Propagator.Extract<T>()`, and `JaegerPropagator.Extract<T>()`. **Recommendations** Update OpenTelemetry.Api to version 1.15.3. Update OpenTelemetry.Extensions.Propagators to version 1.15.3. Configure appropriate HTTP request header limits. Disable baggage or trace propagation as a temporary workaround.

**Name of the Vulnerable Software and Affected Versions** OpenTelemetry.Exporter.Jaeger (affected versions not specified) **Description** This issue allows sustained memory pressure when the internal pooled-list sizing grows based on a large observed span or tag set and that enlarged size is reused for subsequent allocations. In environments where telemetry attributes or events can be influenced by untrusted input and limits are increased from defaults, high-cardinality or attacker-influenced telemetry input can increase memory consumption, potentially leading to process instability or denial of service. **Recommendations** Use maintained exporters, such as the OpenTelemetry Protocol format (OTLP), instead of the Jaeger exporter.