Search for packages
| purl | pkg:nuget/OpenTelemetry.Exporter.OpenTelemetryProtocol@1.15.2 |
| Vulnerability | Summary | Fixed by |
|---|---|---|
|
VCID-scbv-9xb1-kfa8
Aliases: CVE-2026-42191 GHSA-4625-4j76-fww9 |
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. |
Affected by 0 other vulnerabilities. |
|
VCID-w23h-teb2-uqgf
Aliases: CVE-2026-40891 GHSA-mr8r-92fq-pj8p |
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. |
Affected by 0 other vulnerabilities. |
| Vulnerability | Summary | Aliases |
|---|---|---|
| VCID-11b7-tme1-kqa7 | 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-40182
GHSA-q834-8qmm-v933 |