OpenTelemetry.OpAmp.Client
OpAMP Client for OpenTelemetry .NET.
Activity
- Latest release
- 2mo ago
- Total releases
- 9
- Cadence
- ~31 days
- Last 12 months
- 8
Details
- License
- Apache-2.0
- First release
- Sep 23, 2025
| Version | Released | |
|---|---|---|
0.6.0-alpha.1
pre
|
0.6.0-alpha.1
pre
Dependencies (1)
|
|
0.5.0-alpha.1
pre
|
0.5.0-alpha.1
pre
Dependencies (1)
|
|
0.4.0-alpha.1
pre
|
0.4.0-alpha.1
pre
Dependencies (1)
|
|
0.3.0-alpha.1
pre
|
0.3.0-alpha.1
pre
Dependencies (2)
|
|
0.2.0-alpha.1
pre
|
0.2.0-alpha.1
pre
Dependencies (2)
|
|
0.1.0-alpha.4
pre
1 CVE
CVE-2026-42348
GHSA-w2jh-77fq-7gp8
May 05, 2026
OpAMP client reads unbounded HTTP response bodies
5.9
/ 10
Medium
Network
High
None
None
Unchanged
None
None
High
SummaryWhen 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 ImpactIf 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. MitigationThe 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. WorkaroundsNone known. Remediation#4116 updates the OpAMP client HTTP transport to limit the maximum size of responses to 128KB. ResourcesFixed in
0.2.0-alpha.1
References
Updated May 13, 2026 · Source: OSV.dev |
0.1.0-alpha.4
pre
Dependencies (2)
|
|
0.1.0-alpha.3
pre
1 CVE
CVE-2026-42348
GHSA-w2jh-77fq-7gp8
May 05, 2026
OpAMP client reads unbounded HTTP response bodies
5.9
/ 10
Medium
Network
High
None
None
Unchanged
None
None
High
SummaryWhen 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 ImpactIf 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. MitigationThe 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. WorkaroundsNone known. Remediation#4116 updates the OpAMP client HTTP transport to limit the maximum size of responses to 128KB. ResourcesFixed in
0.2.0-alpha.1
References
Updated May 13, 2026 · Source: OSV.dev |
0.1.0-alpha.3
pre
Dependencies (2)
|
|
0.1.0-alpha.2
pre
1 CVE
CVE-2026-42348
GHSA-w2jh-77fq-7gp8
May 05, 2026
OpAMP client reads unbounded HTTP response bodies
5.9
/ 10
Medium
Network
High
None
None
Unchanged
None
None
High
SummaryWhen 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 ImpactIf 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. MitigationThe 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. WorkaroundsNone known. Remediation#4116 updates the OpAMP client HTTP transport to limit the maximum size of responses to 128KB. ResourcesFixed in
0.2.0-alpha.1
References
Updated May 13, 2026 · Source: OSV.dev |
0.1.0-alpha.2
pre
Dependencies (2)
|
|
0.1.0-alpha.1
pre
1 CVE
CVE-2026-42348
GHSA-w2jh-77fq-7gp8
May 05, 2026
OpAMP client reads unbounded HTTP response bodies
5.9
/ 10
Medium
Network
High
None
None
Unchanged
None
None
High
SummaryWhen 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 ImpactIf 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. MitigationThe 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. WorkaroundsNone known. Remediation#4116 updates the OpAMP client HTTP transport to limit the maximum size of responses to 128KB. ResourcesFixed in
0.2.0-alpha.1
References
Updated May 13, 2026 · Source: OSV.dev |
0.1.0-alpha.1
pre
Dependencies (3)
|