Opentelemetry Dotnet
Approved changes feed: RSS · Atom
cpe:2.3:a:open-telemetry:opentelemetry-dotnet:*:*:*:*:*:*:*:*
part: a version: * update: *
| Vendor | Open Telemetry (e0933b97-2767-54e8-948d-aac7569a5839) |
|---|---|
| Product | Opentelemetry Dotnet (a9ea7a22-8b0c-5209-b4ca-a616f6f923ee) |
| Edition | * |
| Language | * |
| Software edition | * |
| Target software | * |
| Target hardware | * |
| Other | * |
| Notes | Imported from gcve-enriched-dumps CVE data |
PURL mappings
| PURL | Source | Last updated |
|---|---|---|
| No PURL mappings for this CPE yet. | ||
Vulnerability references
| Identifier | cpeApplicability | Submitted | db.gcve.eu details | Rationale |
|---|---|---|---|---|
CVE:CVE-2026-42191 |
vulnerable | 2026-06-08 08:03:16.004820 |
OpenTelemetry.Exporter.OpenTelemetryProtocol: Disk retry default temp path enables local blob injection for OTLP Exporter
MEDIUM (6.5)
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 and loaded *.blob files under fixed, signal-named subdirectories (traces, metrics, logs) beneath that shared temporary root path. On multi-user systems where the temporary directory is accessible to other local accounts, this allows an attacker to write crafted *.blob files, read *.blob files written by the application between export failures, or deposit numerous or oversized blob files, degrading retry-loop performance or consuming disk space. This vulnerability is fixed in 1.15.3.
Published: 2026-05-12T19:12:03.221Z
Updated: 2026-05-13T14:16:18.810Z |
Imported from gcve-enriched-dumps CVE data |
CVE:CVE-2026-41310 |
vulnerable | 2026-06-08 08:03:15.200512 |
OpenTelemetry .NET Zipkin exporter has unbounded remote endpoint cache leading to memory growth
MEDIUM (5.3)
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 process memory usage over time and degrading availability. This issue is fixed in version 1.15.3, which introduces a bounded, thread-safe LRU cache for remote endpoints with a fixed maximum size.
Published: 2026-05-06T20:54:37.492Z
Updated: 2026-05-07T13:19:12.396Z |
Imported from gcve-enriched-dumps CVE data |
CVE:CVE-2026-41078 |
vulnerable | 2026-06-08 08:03:14.694656 |
OpenTelemetry dotnet: Potential memory exhaustion via unbounded pooled-list sizing in Jaeger exporter conversion path
MEDIUM (5.9)
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.
Published: 2026-04-23T18:05:41.367Z
Updated: 2026-04-23T18:52:26.466Z |
Imported from gcve-enriched-dumps CVE data |
CVE:CVE-2026-40894 |
vulnerable | 2026-06-08 08:01:21.099670 |
OpenTelemetry dotnet: Excessive memory allocation when parsing OpenTelemetry propagation headers
MEDIUM (5.3)
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.
Published: 2026-04-23T18:03:28.211Z
Updated: 2026-04-23T19:22:47.268Z Reference links
|
Imported from gcve-enriched-dumps CVE data |
CVE:CVE-2026-40891 |
vulnerable | 2026-06-08 08:01:21.097039 |
OpenTelemetry dotnet: Unbounded `grpc-status-details-bin` parsing in OTLP/gRPC retry handling
MEDIUM (5.3)
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.
Published: 2026-04-23T17:54:36.033Z
Updated: 2026-04-23T18:23:08.858Z |
Imported from gcve-enriched-dumps CVE data |
CVE:CVE-2026-40182 |
vulnerable | 2026-06-08 08:01:20.009404 | db.gcve.eu details were skipped to keep the page responsive. | Imported from gcve-enriched-dumps CVE data |
CVE:CVE-2025-27513 |
vulnerable | 2026-06-08 07:14:55.257531 | db.gcve.eu details were skipped to keep the page responsive. | Imported from gcve-enriched-dumps CVE data |
CVE:CVE-2024-32028 |
vulnerable | 2026-06-08 06:35:32.643722 | db.gcve.eu details were skipped to keep the page responsive. | Imported from gcve-enriched-dumps CVE data |
Contribute
You can submit an edit proposal for this CPE entry or suggest a related product/vendor addition using the action button above.