Arista EOS: crafted DHCP packet restarts the DHCP relay service on client-facing VLANs

CVSS 7.1CVE-2026-19655Firmware, BMC & network fabriccurated

Impact

An unauthenticated device on a client-facing VLAN can crash and restart the DHCP relay agent on an EOS switch. On a cluster where GPU nodes, BMCs or storage hosts get their addressing through relay on that switch, the outage window means nodes that reboot or renew a lease during the restart come up without an address. Nothing is disclosed or modified - the record describes availability loss only. The exposure exists only where relay/snooping is configured with Option 82, or where the DHCP server matches on the information option.

Who can reach it

Anyone with unauthenticated layer 2 access to a VLAN where the relay is configured - in practice a tenant or host port on the switch, not the management network.

What to do

Apply the fixed EOS release or the hotfix listed in Arista security advisory 0155; the advisory is the authority on affected trains and fixed versions, and this record does not name one. As a configuration mitigation, the relay is only exposed where Option 82 handling is enabled. Plan the change as a switch maintenance window - a leaf switch upgrade drains traffic for every node behind it unless the fabric is dual-homed.

References

https://nvd.nist.gov/vuln/detail/CVE-2026-19655 https://www.arista.com/en/support/advisories-notices/security-advisory/24711-security-advisory-0155

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.