OpenTelemetry OpAMP Client CVE-2026-42348
MEDIUM
GHSA-w2jh-77fq-7gp8
Severity by source
AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:N/A:H
Primary rating from GitHub Advisory · only source for this CVE.
CVSS VectorGitHub Advisory
CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:N/A:H
Lifecycle Timeline
2DescriptionGitHub Advisory
Summary
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.
Details
#2926 introduced the initial HTTP transport components which uses ReadAsByteArrayAsync to copy the HttpResponseMessage.Content into a byte array. This code path allows an unbounded read of the entire HTTP response message.
Impact
If an application using the OpAMP client is configured to use an OpAMP server that is attacker-controlled (or a network attacker can MitM the connection) and an extremely large body is returned in the response, the application could have its memory exhausted and create a denial-of-service condition.
Mitigation
The application's configured OpAMP server needs to behave maliciously. If the OpAMP server is a well-behaved implementation, response bodies should not be excessively large.
Workarounds
None known.
Remediation
#4116 updates the OpAMP client HTTP transport to limit the maximum size of responses to 128KB.
Resources
AnalysisAI
OpenTelemetry OpAMP client allocates unbounded buffers when reading HTTP responses from an OpAMP server, enabling memory exhaustion denial-of-service attacks if the configured server is attacker-controlled or subject to network interception. An attacker can send an extremely large HTTP response body that forces the client application to allocate memory without limits, exhausting available memory and crashing the application. CVSS 5.9 reflects moderate severity; exploitation requires network positioning (man-in-the-middle or control of the OpAMP server endpoint), which limits real-world attack surface. Upstream fix available in version 0.2.0-alpha.1.
Technical ContextAI
The OpenTelemetry OpAMP client uses the .NET ReadAsByteArrayAsync() method (introduced in PR #2926) to read HTTP response content directly into memory as a byte array. This API reads the entire response body without enforcing any size limits, allowing CWE-789 (Uncontrolled Allocation of Resources with Externally Controlled Size) exploitation. The OpAMP protocol itself does not define maximum response sizes, and the client HTTP transport layer lacks input validation on response message size. The fix (PR #4116) implements a bounded read mechanism using ReadAsStreamAsync() with a 128KB maximum message size, plus Content-Length header validation before reading begins.
RemediationAI
Vendor-released patch: upgrade to OpenTelemetry.OpAmp.Client version 0.2.0-alpha.1 or later, which enforces a 128KB response size limit per PR #4116. Update the NuGet package reference in your project file and rebuild. For applications unable to upgrade immediately, implement network-layer mitigations: restrict OpAMP server endpoints to trusted, internal systems only; use HTTPS with certificate pinning to prevent man-in-the-middle attacks; configure network policies to block outbound connections to untrusted OpAMP servers. Monitor application memory usage and set process memory limits (OS-level cgroups, container resource limits) as a last-resort containment strategy, noting this prevents the root cause but only limits blast radius.
Same technique Information Disclosure
View allShare
External POC / Exploit Code
Leaving vuln.today