Zephyr RTOS EUVD-2026-64925

CONFIG_VIRTIO must be enabled in the Zephyr build (not the default in all configurations), and the system must use either the PCI or MMIO virtio transport. The attacker must control or have compromised the virtio backend - specifically the component that writes to the used ring and raises the virtqueue interrupt - which in practice means a malicious or compromised hypervisor, a rogue PCI device, or a peer processor on an MMIO-connected virtio design. No guest-side authentication, privilege, or user interaction is required once backend control is established. Exploitation is limited to devices running Zephyr 4.2.0 through 4.4.1 with the above build-time option. Systems using neither PCI nor MMIO virtio transport, or built without CONFIG_VIRTIO, are not exploitable regardless of backend trust status.

The CVSS 3.1 score of 8.8 (AV:A/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H) accurately reflects the technical severity: the attack requires no guest-side privileges or user interaction and has low complexity once the backend is controlled, but is bounded by the adjacent-network vector, meaning the attacker must already control or have compromised the virtio backend (hypervisor, firmware, or PCI device) rather than operating over arbitrary internet paths. That prerequisite is non-trivial in well-secured cloud or embedded deployments but is exactly the threat model Zephyr's virtio stack must defend against when running under untrusted or partially-trusted hypervisors. No EPSS score was provided in the source data; given the absence of active exploitation or public POC, real-world exploitation probability is likely low in the near term, though the technical barrier to exploitation for a backend-controlling attacker is minimal once the vulnerability is understood. There is no CISA KEV listing and no public exploit code, so this is not a fire-drill scenario - but operators deploying Zephyr with CONFIG_VIRTIO under environments where the hypervisor or virtio device trustworthiness cannot be fully guaranteed (multi-tenant embedded, mixed-trust IPC designs, or third-party MMIO hardware) should treat patching as a priority rather than optional hygiene. The S:U (unchanged scope) rating is consistent: the impact is confined to the Zephyr guest itself, with no demonstrated lateral movement, though arbitrary code execution in interrupt context effectively represents full guest compromise.

An attacker controlling a malicious hypervisor or a compromised PCI/MMIO virtio device writes a crafted descriptor-chain head ID (e.g., 0xFFFF) into the used ring and raises the virtqueue interrupt on the Zephyr guest. When virtio_isr() processes the interrupt without a bounds check, it reads a function pointer and its argument from heap memory at recv_cbs[0xFFFF] - memory the attacker has pre-shaped through other allocations - and calls that pointer in the guest's interrupt context. No public proof-of-concept exploit code has been identified at time of analysis, but the exploitation path is mechanically straightforward for an attacker with backend control.