Search
Search Results (5 CVEs found)
| CVE | Vendors | Products | Updated | CVSS v3.1 |
|---|---|---|---|---|
| CVE-2026-40182 | 1 Opentelemetry | 1 Opentelemetry-dotnet | 2026-04-28 | 5.3 Medium |
| 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 consuming application if the configured back-end/collector endpoint is attacker-controlled (or a network attacker can MitM the connection) and an extremely large body is returned by the response. This vulnerability is fixed in 1.15.2. | ||||
| CVE-2026-40891 | 1 Opentelemetry | 2 Opentelemetry-dotnet, Opentelemetry.exporter.opentelemetryprotocol | 2026-04-28 | 5.3 Medium |
| 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, allowing excessive memory allocation and potential denial of service (DoS). This vulnerability is fixed in 1.15.2. | ||||
| CVE-2026-40894 | 1 Opentelemetry | 3 Opentelemetry-dotnet, Opentelemetry.api, Opentelemetry.extensions.propagators | 2026-04-28 | 5.3 Medium |
| 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 service (DoS) in the consuming application. This vulnerability is fixed in 1.15.3. | ||||
| CVE-2026-41078 | 1 Opentelemetry | 2 Opentelemetry-dotnet, Opentelemetry.exporter.jaeger | 2026-04-28 | 5.9 Medium |
| 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 potentially cause denial of service. There is no plan to fix this issue as OpenTelemetry.Exporter.Jaeger was deprecated in 2023. | ||||
| CVE-2026-41173 | 1 Opentelemetry | 1 Opentelemetry-dotnet-contrib | 2026-04-28 | 5.9 Medium |
| The AWS X-Ray Remote Sampler package provides a sampler which can get sampling configurations from AWS X-Ray. Prior to 0.1.0-alpha.8, OpenTelemetry.Sampler.AWS reads unbounded HTTP response bodies from a configured AWS X-Ray remote sampling endpoint into memory. AWSXRaySamplerClient.DoRequestAsync called HttpClient.SendAsync followed by ReadAsStringAsync(), which materializes the entire HTTP response body into a single in-memory string with no size limit. The sampling endpoint is configurable via AWSXRayRemoteSamplerBuilder.SetEndpoint (default: http://localhost:2000). An attacker who controls the configured endpoint, or who can intercept traffic to it (MitM), can return an arbitrarily large response body. This causes unbounded heap allocation in the consuming process, leading to high transient memory pressure, garbage-collection stalls, or an OutOfMemoryException that terminates the process. This vulnerability is fixed in 0.1.0-alpha.8. | ||||
Page 1 of 1.