LOW 3.8

CVE-2026-13322: KubeVirt Downward Metrics Memory Exhaustion (CWE-770)

A memory exhaustion vulnerability exists in KubeVirt's downward metrics virtio-serial server. When a guest VM has this device enabled, a local attacker can repeatedly write data without line breaks, forcing the virt-handler process to allocate unbounded memory until the process crashes. This requires prior VM access and affects deployments where the downward metrics feature is configured.

Source data · NVD / CISA · public domain

CVSS
3.1 · 3.8 LOW · CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:C/C:N/I:N/A:L
Weaknesses (CWE)
CWE-770
Affected products
2 configuration(s)
Published / Modified
2026-06-26 / 2026-07-06

NVD description (verbatim)

A flaw was found in KubeVirt's downward metrics virtio-serial server. The server reads guest requests using textproto.Reader.ReadLine(), which buffers input indefinitely until a newline character is received, with no length limit or read deadline. A user with access to a VM guest that has the downward metrics virtio-serial device configured can write a continuous byte stream to the device, causing unbounded memory allocation in the virt-handler process until it is OOM-killed.

2 reference(s) · View on NVD →

SEC.co analysis · AI-assisted, reviewed against source

Technical summary

The vulnerability stems from KubeVirt's use of textproto.Reader.ReadLine() in its downward metrics virtio-serial server implementation. This function buffers incoming data until a newline character arrives, but the code lacks input length limits and read timeouts. An authenticated guest can exploit this by sending a continuous byte stream, causing the virt-handler process to allocate memory indefinitely until an out-of-memory (OOM) condition terminates the process. The root cause is classified under CWE-770 (Allocation of Resources Without Limits or Throttling).

Business impact

This vulnerability can disrupt virtualized workloads by causing virt-handler crashes, leading to service unavailability for affected VMs and potential cascading failures in OpenShift Virtualization clusters. Organizations relying on KubeVirt for production workloads may experience pod evictions, failovers, and operational overhead. The impact is contained to denial-of-service scope—no data exposure or integrity compromise occurs—but reliability is compromised in multi-tenant or high-density virtualization environments.

Affected systems

The vulnerability affects KubeVirt (all versions with the downward metrics virtio-serial server enabled) and Red Hat OpenShift Virtualization, which bundles KubeVirt. The attack vector requires local access to a guest VM and requires that the downward metrics device be explicitly configured on that VM. Environments without this device enabled, or air-gapped VM deployments, have reduced risk exposure.

Exploitability

Exploitability is relatively constrained due to multiple preconditions: an attacker must already have access to a guest VM (local privilege level), and the downward metrics virtio-serial device must be configured. No network access is required, and no special tools or techniques are needed—writing continuous data to a character device is straightforward. The CVSS 3.1 score of 3.8 (LOW) reflects these barriers but acknowledges that insider threats or compromised workloads can trigger the flaw.

Remediation

Patch KubeVirt to a version that implements input length limits and read timeouts in the virtio-serial server's ReadLine() logic. Verify the specific patched version against the official KubeVirt security advisory. As interim mitigation, disable the downward metrics virtio-serial device on VMs that do not require it, restrict VM access to trusted users, and monitor virt-handler process memory and OOM events. Network segmentation and pod security policies should be used to limit guest-to-host attack surface.

Patch guidance

Contact your KubeVirt and Red Hat OpenShift Virtualization vendors for official patch releases. Patch availability and version numbers should be verified directly from the KubeVirt project repository and Red Hat security advisories. Test patches in a staging environment before production deployment, paying attention to any behavioral changes in metrics collection or virtio-serial communication. Plan maintenance windows to update virt-handler components across your cluster with minimal guest disruption.

Detection guidance

Monitor virt-handler process memory usage patterns for unexpected growth correlated with guest activity on systems where downward metrics are enabled. Enable kernel audit logging or container runtime monitoring to detect excessive or sustained writes to virtio-serial device paths (/dev/virtio-ports/com.redhat.spice.0 or similar). Kubernetes node metrics and Prometheus scraping can expose anomalous memory pressure on nodes hosting affected VMs. Establish baseline memory profiles and alert on sustained deviations indicating potential exploitation attempts.

Why prioritize this

Despite the LOW CVSS score, prioritize this vulnerability in environments running multi-tenant or semi-trusted virtualization workloads. The flaw is easily triggered by any guest user once VM access is obtained, and can cause operational disruption in production clusters. Organizations with strong VM access controls and no reliance on downward metrics can safely deprioritize, but those with permissive guest policies or shared VM pools should address it promptly to prevent denial-of-service scenarios.

Risk score, explained

The CVSS 3.1 score of 3.8 reflects a LOW severity due to the local attack vector (AV:L), low complexity (AC:L), and requirement for existing user privileges (PR:L). The impact is limited to availability (A:L), with no confidentiality or integrity loss. The scope changes the context (S:C), but the overall severity remains low because exploitation requires prior VM access and does not escalate privilege or leak sensitive data. In high-availability or critical infrastructure deployments, real-world risk may exceed the numerical score.

Frequently asked questions

Does this vulnerability require guest kernel modifications or special privileges within the VM?

No. Any process running in the guest—even unprivileged user processes—can write to the virtio-serial device if it is configured and accessible. Kernel-level access is not required.

Can this be exploited remotely, or is it strictly local to the guest VM?

Exploitation is strictly local to the guest VM. An attacker must already have execution capability within the guest; they cannot trigger this flaw over the network from the host or other VMs.

What is the downward metrics virtio-serial device, and do we need it enabled?

The downward metrics device allows VMs to query resource metrics and host information. It is optional and not enabled by default on all deployments. Review your VM specifications (pod templates in OpenShift) to check if it is configured; if your workloads do not require it, disabling it eliminates the attack surface.

If virt-handler is OOM-killed, what happens to running VMs?

The virt-handler process manages VM lifecycle and I/O. If it crashes, the affected node's VM stability may degrade, potentially leading to guest disruption, pod eviction, or failover, depending on your cluster's redundancy and recovery policies.

This analysis is based on publicly available CVE data and vendor advisories current as of the publication date. Security landscape and patch availability may change; verify all patch versions and supported configurations directly with KubeVirt and Red Hat documentation. This assessment does not constitute a comprehensive risk audit or substitute for your organization's internal vulnerability management process. Consult your security and infrastructure teams to determine applicability to your specific environment and deployment topology. Source: NVD (public-domain), retrieved 2026-08-04. Analysis generated by SEC.co (claude-haiku-4-5).