https://cve.radiocsirt.org/rss/recent/all/10 Most recent entries from all 2026-10-09T20:29:06.610475+00:00 Vulnerability-Lookup csirt@opendfir.org python-feedgen Contains only the most 10 recent entries. https://cve.radiocsirt.org/vuln/euvd-2026-318199 EUVD-2026-318199 2026-10-09T20:29:06.663981+00:00 EUVD-2026-318199 https://cve.radiocsirt.org/vuln/fkie_cve-2026-42348 fkie_cve-2026-42348 2026-10-09T20:29:06.664019+00:00

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.

 https://cve.radiocsirt.org/vuln/ghsa-w2jh-77fq-7gp8 GHSA-w2jh-77fq-7gp8 — OpAMP client reads unbounded HTTP response bodies 2026-10-09T20:29:06.664053+00:00

Affected: NuGet: OpenTelemetry.OpAmp.Client

### 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](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.

### 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](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.

### Resources

- [#2926](h…