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.
PUBLISHED5.2CWE-789
OpAMP client reads unbounded HTTP response bodies
Problem type
Affected products
open-telemetry
opentelemetry-dotnet-contrib
< 0.2.0-alpha.1 - AFFECTED
References
https://github.com/open-telemetry/opentelemetry-dotnet-contrib/security/advisories/GHSA-w2jh-77fq-7gp8
https://github.com/open-telemetry/opentelemetry-dotnet-contrib/security/advisories/GHSA-w2jh-77fq-7gp8
https://github.com/open-telemetry/opentelemetry-dotnet-contrib/pull/4116
https://github.com/open-telemetry/opentelemetry-dotnet-contrib/pull/4116
GitHub Security Advisories
GHSA-w2jh-77fq-7gp8
OpAMP client reads unbounded HTTP response bodies
https://github.com/advisories/GHSA-w2jh-77fq-7gp8Summary
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
github.com
https://github.com/open-telemetry/opentelemetry-dotnet-contrib/security/advisories/GHSA-w2jh-77fq-7gp8
github.com
https://github.com/open-telemetry/opentelemetry-dotnet-contrib/pull/4116
github.com
https://github.com/open-telemetry/opentelemetry-dotnet-contrib/commit/bf1fad4fa298ff451cda0efb0ee9c7a7eb46212a
nvd.nist.gov
https://nvd.nist.gov/vuln/detail/CVE-2026-42348
github.com
https://github.com/advisories/GHSA-w2jh-77fq-7gp8
JSON source
https://cveawg.mitre.org/api/cve/CVE-2026-42348Click to expand
{
"dataType": "CVE_RECORD",
"dataVersion": "5.2",
"cveMetadata": {
"cveId": "CVE-2026-42348",
"assignerOrgId": "a0819718-46f1-4df5-94e2-005712e83aaa",
"assignerShortName": "GitHub_M",
"dateUpdated": "2026-05-12T18:01:41.812Z",
"dateReserved": "2026-04-26T13:26:14.515Z",
"datePublished": "2026-05-12T18:01:41.812Z",
"state": "PUBLISHED"
},
"containers": {
"cna": {
"providerMetadata": {
"orgId": "a0819718-46f1-4df5-94e2-005712e83aaa",
"shortName": "GitHub_M",
"dateUpdated": "2026-05-12T18:01:41.812Z"
},
"title": "OpAMP client reads unbounded HTTP response bodies",
"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."
}
],
"affected": [
{
"vendor": "open-telemetry",
"product": "opentelemetry-dotnet-contrib",
"versions": [
{
"version": "< 0.2.0-alpha.1",
"status": "affected"
}
]
}
],
"problemTypes": [
{
"descriptions": [
{
"lang": "en",
"description": "CWE-789: Memory Allocation with Excessive Size Value",
"cweId": "CWE-789",
"type": "CWE"
}
]
}
],
"references": [
{
"url": "https://github.com/open-telemetry/opentelemetry-dotnet-contrib/security/advisories/GHSA-w2jh-77fq-7gp8",
"name": "https://github.com/open-telemetry/opentelemetry-dotnet-contrib/security/advisories/GHSA-w2jh-77fq-7gp8",
"tags": [
"x_refsource_CONFIRM"
]
},
{
"url": "https://github.com/open-telemetry/opentelemetry-dotnet-contrib/pull/4116",
"name": "https://github.com/open-telemetry/opentelemetry-dotnet-contrib/pull/4116",
"tags": [
"x_refsource_MISC"
]
}
],
"metrics": [
{
"cvssV3_1": {
"version": "3.1",
"vectorString": "CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:N/A:H",
"attackVector": "NETWORK",
"attackComplexity": "HIGH",
"privilegesRequired": "NONE",
"userInteraction": "NONE",
"scope": "UNCHANGED",
"confidentialityImpact": "NONE",
"integrityImpact": "NONE",
"availabilityImpact": "HIGH",
"baseScore": 5.9,
"baseSeverity": "MEDIUM"
}
}
]
}
}
}