GHSA-W2JH-77FQ-7GP8
Vulnerability from github – Published: 2026-05-05 21:57 – Updated: 2026-05-13 16:27Summary
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
{
"affected": [
{
"package": {
"ecosystem": "NuGet",
"name": "OpenTelemetry.OpAmp.Client"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "0.2.0-alpha.1"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2026-42348"
],
"database_specific": {
"cwe_ids": [
"CWE-789"
],
"github_reviewed": true,
"github_reviewed_at": "2026-05-05T21:57:54Z",
"nvd_published_at": "2026-05-12T18:17:24Z",
"severity": "MODERATE"
},
"details": "### Summary\n\nWhen 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.\n\nThis 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. \n\n### Details\n\n[#2926](https://github.com/open-telemetry/opentelemetry-dotnet-contrib/pull/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.\n\n### Impact\n\nIf 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.\n\n### Mitigation\n\nThe application\u0027s configured OpAMP server needs to behave maliciously. If the OpAMP server is a well-behaved implementation, response bodies should not be excessively large.\n\n### Workarounds\n\nNone known.\n\n### Remediation\n\n[#4116](https://github.com/open-telemetry/opentelemetry-dotnet-contrib/pull/4116) updates the OpAMP client HTTP transport to limit the maximum size of responses to 128KB.\n\n### Resources\n\n- [#2926](https://github.com/open-telemetry/opentelemetry-dotnet-contrib/pull/2926)\n- [#4116](https://github.com/open-telemetry/opentelemetry-dotnet-contrib/pull/4116)\n- [CWE-789](https://cwe.mitre.org/data/definitions/789.html)",
"id": "GHSA-w2jh-77fq-7gp8",
"modified": "2026-05-13T16:27:09Z",
"published": "2026-05-05T21:57:54Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/open-telemetry/opentelemetry-dotnet-contrib/security/advisories/GHSA-w2jh-77fq-7gp8"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-42348"
},
{
"type": "WEB",
"url": "https://github.com/open-telemetry/opentelemetry-dotnet-contrib/pull/4116"
},
{
"type": "WEB",
"url": "https://github.com/open-telemetry/opentelemetry-dotnet-contrib/commit/bf1fad4fa298ff451cda0efb0ee9c7a7eb46212a"
},
{
"type": "PACKAGE",
"url": "https://github.com/open-telemetry/opentelemetry-dotnet-contrib"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:N/A:H",
"type": "CVSS_V3"
}
],
"summary": "OpAMP client reads unbounded HTTP response bodies"
}
Sightings
| Author | Source | Type | Date | Other |
|---|
Nomenclature
- Seen: The vulnerability was mentioned, discussed, or observed by the user.
- Confirmed: The vulnerability has been validated from an analyst's perspective.
- Published Proof of Concept: A public proof of concept is available for this vulnerability.
- Exploited: The vulnerability was observed as exploited by the user who reported the sighting.
- Patched: The vulnerability was observed as successfully patched by the user who reported the sighting.
- Not exploited: The vulnerability was not observed as exploited by the user who reported the sighting.
- Not confirmed: The user expressed doubt about the validity of the vulnerability.
- Not patched: The vulnerability was not observed as successfully patched by the user who reported the sighting.