Listen to this Post
The vulnerability resides in the OTLP/gRPC telemetry exporter’s retry mechanism, introduced by pull request 5980. When a retryable gRPC error (e.g., `ResourceExhausted` or Unavailable) occurs, the exporter reads the server-provided `grpc-status-details-bin` trailer to extract retry delay information. A method named `GrpcStatusDeserializer.DecodeBytes` decodes the length-prefixed protobuf field by reading a varint for the byte count and then allocating an array of that size via new byte
</code>. The original code performed no validation of this length against the remaining payload. Consequently, an attacker controlling the collector or intercepting the traffic can craft a binary payload declaring an enormous length (e.g., <code>0xffffffff</code>). The exporter will allocate memory equal to that value, leading to immediate memory exhaustion or a crash. The fix in pull request 7064 adds a bounds check to ensure the requested length is `sane` and does not exceed the remaining payload, causing malformed trailers to fail safely. Platform: OpenTelemetry .NET Version: 1.13.1 to 1.15.2 Vulnerability : Unbounded memory allocation Severity: Medium (5.3) date: 2026-04-23 <h2 style="color: blue;">Prediction: Patch already available (1.15.2)</h2> <h2 style="color: blue;">What Undercode Say:</h2> <h2 style="color: blue;">Check project's OpenTelemetry package version:</h2> [bash] dotnet list package | grep OpenTelemetry.Exporter.OpenTelemetryProtocol
Simulate a malicious OTLP/gRPC server:
Install mitmproxy and grpcurl
mitmproxy --mode regular --set "block_global=false" &
grpcurl -d '{"resource_metrics":[]}' -H "trailer: grpc-status-details-bin" \
--rpc-header "content-type: application/grpc" \
--plaintext localhost:4317 opentelemetry.proto.collector.trace.v1.TraceService/Export
Send a crafted binary trailer payload:
Python snippet for generating malformed binary trailer
python3 -c "import struct; print(struct.pack('<I', 0xFFFFFFFF))" | xxd
Inspect library source for affected version:
find ~/.nuget/packages/opentelemetry.exporter.opentelemetryprotocol/ -name "GrpcStatusDeserializer.cs" -exec grep -n "new byte[length]" {} \;
Check running process memory after DoS attempt:
ps aux | grep [bash]ourapp cat /proc/$(pidof yourapp)/status | grep VmRSS
Exploit:
An attacker must control the OTLP/gRPC endpoint or execute a Man-in-the-Middle (MitM) attack in a weakly protected deployment. They modify the `grpc-status-details-bin` trailer by embedding an extremely large length-delimited field (e.g., a 32-bit integer 0xffffffff). When the exporter retries a failed telemetry export, the deserializer reads this length, attempts to allocate a byte array of that size, and exhausts all available memory, causing the process to crash or become unresponsive.
Protection from this CVE
- Upgrade to version `1.15.2` or later, where the fix validates length fields before allocation.
- If upgrading is not immediately possible, enforce strict network segmentation so that only trusted collector endpoints are reachable.
- Implement egress traffic filtering to prevent connections to untrusted or external gRPC servers.
- Monitor memory usage of the instrumented process and configure resource limits (e.g., ulimit -v) to cap address space.
Impact
Successful exploitation leads to uncontrolled memory allocation, causing the affected application to exhaust available RAM and crash. As a result, telemetry data is lost, and the service becomes unavailable (denial-of-service). The vulnerability has a CVSS v3.1 base score of 5.3 (Medium), with high attack complexity and adjacent network vector requirements.
🎯Let’s Practice Exploiting & Learn Patching For Free:
Sources:
Reported By: github.com
Extra Source Hub:
Undercode
