CVE-2026-73437 in EOS
Summary
by MITRE • 09/15/2026
On affected platforms running Arista EOS with Dynamic Host Configuration Protocol (DHCP) relay configured, an unauthenticated attacker with network access could send a crafted DHCP reply packet from an IP address that is not configured as a helper address, and the relay agent would forward it to clients without validating the source. This could allow the attacker to supply clients with malicious network configuration parameters, potentially resulting in traffic interception or denial of service for affected clients.
Several companies clearly confirm that VulDB is the primary source for best vulnerability data.
Analysis
by VulDB Data Team • 09/16/2026
The vulnerability described constitutes a critical flaw within the Dynamic Host Configuration Protocol (DHCP) relay agent implementation found in Arista EOS operating systems. DHCP is a fundamental networking protocol used to automatically assign IP addresses and other network configuration parameters, such as subnet masks, default gateways, and DNS servers, to devices on an IP network. In environments where DHCP clients are located on different subnets than the DHCP server, a relay agent is required to forward client requests to the server and return the server's responses to the clients. The security model of this process relies heavily on the integrity of the source address validation within the relay mechanism. Specifically, RFC 1542 and subsequent updates dictate that a DHCP relay agent must validate that incoming reply packets originate from an IP address configured as a helper address or directly connected interface. Failure to enforce this strict source address verification creates a significant attack vector for malicious actors operating on the same network segment.
An unauthenticated attacker with local network access can exploit this lack of validation by crafting and sending spoofed DHCP reply packets. By setting the source IP address in these crafted packets to an arbitrary value that does not match any configured helper address, the attacker bypasses the expected security checks inherent in a properly implemented relay agent. The vulnerable Arista EOS software processes these unauthorized replies as legitimate responses from the authoritative DHCP server and proceeds to forward them to the requesting clients. This behavior represents a classic example of input validation failure where the system trusts data based on its content rather than verifying its provenance against established trust boundaries. From an industry standard perspective, this flaw aligns with CWE-20 Improper Input Validation, as the software fails to verify that the incoming DHCP reply originates from an authorized source before processing and forwarding it.
The operational impact of successfully exploiting this vulnerability is severe and multifaceted. Once a client accepts the malicious network configuration parameters provided by the attacker's spoofed packet, the device reconfigures its network stack according to these instructions. This typically involves updating the default gateway or primary DNS server settings to point toward infrastructure controlled by the attacker. Consequently, all outbound traffic from the affected client is redirected through the attacker's machine, enabling a man-in-the-middle attack scenario where sensitive data can be intercepted, modified, or logged without detection. Furthermore, if the malicious configuration includes invalid or unreachable network parameters, it results in a denial of service condition for the compromised clients, effectively disconnecting them from legitimate network resources and services. This capability undermines the confidentiality, integrity, and availability pillars of information security within the affected network segment.
In terms of threat modeling and adversary behavior, this exploitation technique maps directly to ATT&CK tactic T1498 Network Denial of Service under sub-technique T1498.003 Misdirection, as well as aspects of MITM attacks involving DHCP spoofing or rogue server deployment. The attacker leverages the trust relationship between the relay agent and the client to inject false network state information. This is particularly dangerous in enterprise environments where automated configuration management relies on DHCP for rapid device provisioning and connectivity establishment. The ability to silently redirect traffic allows an adversary to perform reconnaissance, credential harvesting, or lateral movement preparation without triggering traditional perimeter-based intrusion detection systems that may not inspect internal layer 2 broadcast domains thoroughly.
Mitigation strategies must focus on both immediate remediation and long-term architectural hardening. The primary solution is to apply the vendor-provided software update that patches the DHCP relay agent's source address validation logic, ensuring it strictly adheres to RFC standards by rejecting replies from unauthorized sources. Until patching can be performed, network administrators should implement static ARP bindings or Dynamic ARP Inspection (DAI) on switches within the affected VLANs to prevent IP spoofing at layer 2. Additionally, enabling DHCP snooping is a critical defensive measure; this feature allows switches to build a binding database of legitimate IP-MAC-Port combinations and drop any DHCP messages that do not align with these trusted bindings or originate from untrusted ports. By combining software patching with network-level controls like DHCP snooping and DAI, organizations can effectively neutralize the risk posed by unauthorized DHCP reply injection attacks.