Open actionable advisories and recorded vendor fixes. This public package view has no inventory attached and cannot establish whether your deployment is affected. A vendor fix never resolves your finding; verify your installed version and the source guidance.
Open advisories
3 actionable advisories, newest first. Withdrawn advisories and news are excluded. Coverage is partial.
The OTLP disk retry feature in OpenTelemetry.Exporter.OpenTelemetryProtocol silently fell back to Path.GetTempPath() when OTELDOTNETEXPERIMENTALOTLPRETRY=disk was set but OTELDOTNETEXPERIMENTALOTLPDISKRETRYDIRECTORYPATH 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 exposed three attack surfaces: - Blob injection (integrity): an attacker could write crafted .blob files into the predictable path; the exporter picks them up on the next retry cycle and forwards them to the configured OTLP endpoint under the application's identity. - Telemetry disclosure (confidentiality): an attacker reads .blob files written by the application between export failures, recovering encoded telemetry payloads (spans, metric data points, log records). - Resource exhaustion…
Recommended action: Upgrade to 1.15.3 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
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). Details #5980 introduced a retry path that parses grpc-status-details-bin to extract gRPC retry delay information for retryable responses. On that path: - OtlpGrpcExportClient captures grpc-status-details-bin from retryable status responses (ResourceExhausted / Unavailable). - OtlpRetry invokes GrpcStatusDeserializer.TryGetGrpcRetryDelay using this untrusted trailer value. - GrpcStatusDeserializer.DecodeBytes decoded a protobuf varint length and allocated new byte[length] without validating the bounds against the remaining payload size. A malicious or compromised collector (or a MitM in…
Recommended action: Upgrade to 1.15.3 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
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. Details https://github.com/open-telemetry/opentelemetry-dotnet/pull/6564 introduced a change to read the response body when a non-200 HTTP status code is received when exporting telemetry to aid debugging by operators so that the error response is included in the logs emitted by the exporter for both gRPC and HTTP/protobuf. An unintended consequence of this change is that the response body is fully read into memory when received with no upper-bound. This vulnerability was…
Recommended action: Upgrade to 1.15.2 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.