GPU VulnDB

Database/Control plane, storage & DevOps

Elastic Metricbeat: oversized Prometheus remote_write request drives an unbounded allocation and kills the beat

CVSS 5.7CVE-2026-26931Control plane, storage & DevOpscurated

Impact

The Prometheus remote_write input turns Metricbeat into an HTTP receiver, and that handler sizes an allocation from a value in the request rather than from what it actually has to read. A crafted request makes the beat allocate far more than it needs and fall over. On a GPU node that costs you two things: the memory spike competes with the workload on a box you sized tightly, and you lose the telemetry stream that is how you notice a wedged GPU, a thermal event or a fabric flap in the first place. Scored 5.7, availability only, adjacent network, and it only applies to deployments that actually enable the remote_write input.

Who can reach it

Anyone who can reach the Metricbeat remote_write listener, with the low-privilege credentials the vector assumes. The vendor rates it adjacent-network, so the exposure is whoever sits on your monitoring VLAN or in a pod that can route to it, not the internet.

What to do

Upgrade to the releases named in Elastic's ESA-2026-09 announcement, 8.19.13 and 9.2.5. Metricbeat is an agent, so the rollout is a package update and a service restart per host, which you can stage across the fleet without draining or rebooting GPU nodes. If you cannot patch immediately, the effective mitigation is to stop exposing the remote_write listener: disable the input where it is unused, or bind it so only your Prometheus senders can reach it.

References

Related entries

All Control plane, storage & DevOps entries

This entry is curated: imported from vendor advisories with machine assistance, not yet individually verified. Confirm against your vendor's advisory before acting, and report anything wrong.