CVE-2026-73443

Executive Summary

CVE-2026-73443 is an authentication replay vulnerability in Arista EOS affecting platforms configured to run VRRPv2 (Virtual Router Redundancy Protocol, version 2) with IP Authentication Header (IP-AH) authentication. An unauthenticated attacker positioned on the same layer 2 network segment as the participating VRRP routers can passively capture a legitimate, authenticated VRRP advertisement and replay it indefinitely, causing the VRRP state machine to accept stale topology information. Because replayed advertisements can persistently advertise an obsolete master state — for example, keeping a backup router from assuming the virtual gateway role after the legitimate master has failed — the practical result is a denial of service for all hosts that depend on the VRRP virtual gateway address for default gateway reachability. The vulnerability carries a CVSS 3.1 base score of 4.7 (Medium), reflecting an adjacent attack vector requiring layer 2 adjacency, no privileges or user interaction, and a limited availability impact, but with a scope change (S:C) indicating the impact crosses the security boundary between the compromised VRRP control plane and the dependent host population.

Technical Analysis

VRRP is a first-hop redundancy protocol in which a group of routers elect a single master that owns one or more virtual IP addresses and answers ARP/ND for them. The master periodically transmits VRRP advertisements to the group's multicast destination; backups monitor these advertisements and, if they stop arriving within the Master_Down_Interval, a backup transitions to master and takes ownership of the virtual addresses. The security of this election depends entirely on ensuring that only a legitimate group member can produce valid advertisements — otherwise an arbitrary third party can inject topology claims.

VRRPv2 provides the IP Authentication Header (IP-AH) authentication method for this purpose. IP-AH supplies packet-level authentication and integrity via a keyed hash over the IP packet (typically HMAC-MD5 with a configured shared secret, as standardized in RFC 2338 and RFC 1826/IPsec AH). Critically, IP-AH provides integrity and authentication of origin at the time the packet was generated — it does not provide replay protection. There is no sequence number window, no nonce, no timestamp, and no challenge–response element in the VRRPv2 IP-AH scheme that a receiver validates against freshness. Consequently, a packet that was valid when captured remains cryptographically valid forever. Verification of the AH digest will still succeed on a byte-for-byte replay because the shared key never changes and the digest covers only the static packet contents.

CVE-2026-73443 is mapped to CWE-294 (Authentication Bypass by Capture-replay), which is precisely the weakness class involved. The flaw is architectural rather than a coding defect: the protocol design validates authenticity but not liveness. The attack surface is the layer 2 segment on which VRRP is running. Because VRRP advertisements are transmitted to a multicast group and are therefore visible to every host on the segment (subject to switch multicast handling), an attacker does not need to be a group member, does not need the shared secret, and does not need to inject traffic during the capture window — they need only capture one valid advertisement and then retransmit it. The "authentication" check, which successful replays pass, is what makes this a bypass of the intended control rather than a simple forgery.

The NVD description states that replayed advertisements "can be used to advertise stale VRRP state, for example to prevent a backup router from taking over the virtual gateway after the original master has gone down." This establishes the operational consequence: because the backup continues to receive apparently authenticated advertisements from a master that is actually dead, the Master_Down_Interval never expires from the backup's perspective, and the failover that VRRP exists to provide never occurs. The virtual gateway IP therefore continues to be advertised by no live device, and hosts using that address as their default gateway lose off-subnet connectivity.

The CVSS vector contributes important nuance. AV:A (Adjacent) confirms the attacker must be on the same layer 2 segment — this is not remotely exploitable across routed boundaries. AC:L (Low) reflects that no special conditions are required beyond the ability to capture and replay traffic. PR:N (None) confirms no authentication or account is needed, since the replay automatically satisfies the IP-AH check. UI:N (None) confirms no operator action is required. S:C (Changed) reflects that the vulnerable component (the VRRP control plane on the routers) affects a different security authority (the hosts relying on the virtual gateway), which is the correct scope assessment for a gateway-availability failure. C:N / I:N confirm no confidentiality or integrity impact — this is purely an availability issue. A:L (Low) is consistent with degraded availability of the virtual gateway rather than a total compromise of the network device itself. It is important to note that the CVSS metric's "Low" availability impact understates real-world blast radius when the VRRP group is a production default gateway, because the number of downstream hosts affected can be very large even though the type of impact is bounded to availability.

No public proof-of-concept, exploit code, or Nuclei template has been published, and no CISA KEV entry exists. There is no EPSS score yet assigned by FIRST.org. Patch confidence is 0/4, meaning no tracked source has evidenced a fix; the vulnerability must be treated as unpatched.

Exploitation Scenarios

No public PoC available; attack chain is inferred from the vulnerability class (CWE-294) and the NVD description. The steps below describe the attack at the protocol-mechanics level and deliberately avoid inventing implementation details that are not in the source data.

1. Reconnaissance / target identification. The attacker first gains a foothold on the same layer 2 network segment on which VRRP is running. This can be a physical access port, an unmanaged switch port, a VM on the same VLAN, or a compromised host on that broadcast domain. The attacker identifies that VRRP is present and that the group is using IP-AH authentication — for instance by observing periodic multicast advertisements characteristic of VRRP to the VRRP multicast destination. No credentials are required for this step.

2. Capture. Using any packet capture capability on the segment, the attacker records a single legitimate VRRP advertisement emitted by the current master along with its IP-AH authentication data. Because advertisements are sent to a multicast group and are visible at layer 2, this capture does not require spoofing, MITM positioning, or possession of the shared secret. The captured frame is entirely self-contained: it carries the group ID, priority, virtual address information, and the valid AH digest.

3. Replay / trigger. The attacker retransmits the captured frame — either once, to win a specific election window, or repeatedly at an interval shorter than the backup routers' Master_Down_Interval — onto the segment. Each replayed frame is byte-identical to the original and therefore passes the IP-AH integrity check exactly as the original did. The receiving VRRP peers accept the advertisement as a live, authenticated message from the master. No payload crafting, no key recovery, and no protocol manipulation are required; the vulnerability-class trigger is simply replaying valid material.

4. Post-exploitation impact. If the legitimate master has failed (or is deliberately taken offline, or is attacked separately), the replayed advertisements continue to satisfy the backups and prevent the Master_Down_Interval from expiring. The backup never transitions to master, so no device claims the virtual gateway address. Hosts configured with that virtual address as their default gateway lose the ability to reach any destination off their local subnet — effectively a denial of service against all gateway-dependent hosts in the group's coverage area. The attacker can persist the condition as long as they can continue emitting the standing replay. Notably, the attacker can also use replay to advertise stale state in other directions — for example to sustain a topology that no longer reflects reality — but the denial-of-service case is the one the vendor description highlights.

An important characteristic of this flaw is that it is trivially retargetable: the same captured advertisement can be replayed by any actor on the segment, and the material never expires. There is no "detection window" in the cryptographic sense, only network-level opportunity.

Impact Assessment

The vulnerability is strictly an availability issue. CVSS subscores break down as follows: Attack Vector (AV:A) adjacency — the attacker must reside on the same layer 2 segment, which limits exposure to anyone who can gain a foothold on that broadcast domain. Attack Complexity (AC:L) low — capture and replay with commodity tooling requires no special conditions. Privileges Required (PR:N) none. User Interaction (UI:N) none. Scope (S:C) changed — the failure of the router control plane degrades a distinct set of resources, namely the upstream-reachable services and off-subnet endpoints consumed by hosts behind the virtual gateway. Confidentiality (C:N), Integrity (I:N) no impact. Availability (A:L) limited — the gateway itself remains reachable at the local level for the group's own members, but the virtual gateway service is withheld from dependent hosts.

Business impact centers on the denial of first-hop redundancy. Any organization using Arista EOS with VRRPv2 IP-AH as its gateway redundancy mechanism is potentially affected. The realistic blast radius is every host whose default gateway is the affected virtual address: desktop fleets, servers, appliances, building systems, and any service reachable only through that gateway. For a data-center or campus distribution layer, this can mean an entire subnet losing egress simultaneously. The attack requires no compromised credentials and no insider privilege, so a single guest-access port or a single compromised workstation on the segment is sufficient. Because the replayed packet remains valid indefinitely, an attacker can sustain the denial for arbitrarily long periods — and can even preserve the effect across the legitimate master's own maintenance windows, defeating the very redundancy that motivated deploying VRRP.

Secondary impact: the failure mode is silent from the perspective of the backup routers, which believe they are correctly honoring an authentic master. This complicates troubleshooting during an incident, since operators may see an apparently healthy adjacency with no obvious sign of injection unless they capture and inspect traffic on the segment.

Detection Guidance

Sigma Rule

title: Possible VRRPv2 Advertisement Replay - Identical Frame Repeated
id: 7b3e9c4a-2d41-4f8a-9c1e-arista-vrrp-replay
status: experimental
description: Detects repeated byte-identical VRRPv2 IP-AH authenticated advertisements on a monitored segment, consistent with CVE-2026-73443 replay activity. Requires flow/packet capture telemetry ingestion.
references:
  - https://nvd.nist.gov/vuln/detail/CVE-2026-73443
  - https://cwe.mitre.org/data/definitions/294.html
author: valtersit.com Threat Intelligence
date: 2026/01/01
tags:
  - attack.t1498
  - cve.2026.73443
logsource:
  category: network_connection
  product: zeek
  service: conn
detection:
  selection:
    proto: '112'
  condition: selection | count() by src_ip, dst_ip, id.orig_p > 1
falsepositives:
  - Legitimate VRRP advertisements are periodic and similar but not byte-identical; only true frame duplication should match
  - Packet-capture duplication artifacts
level: medium

YARA Rule

rule CVE_2026_73443_VRRP_Replay_Artifact
{
    meta:
        description = "Detects captured/replayed VRRPv2 advertisement artifacts (IP protocol 112) with IP-AH authentication payloads"
        author = "valtersit.com Threat Intelligence"
        reference = "https://nvd.nist.gov/vuln/detail/CVE-2026-73443"
        cve = "CVE-2026-73443"
        cwe = "CWE-294"
        date = "2026-01-01"
        severity = "medium"

    strings:
        // VRRP advertisement: version/type byte = 0x21 followed by vrid 0x00-0xFF
        $vrrp_hdr = { 21 ?? 00 }
        // IP header with protocol 112 (0x70) indicating VRRP (IPv4)
        $ip_proto_vrrp = { 45 ?? ?? ?? ?? ?? ?? ?? 70 }
        // IP-AH protocol number 51 (0x33) in a following header, associated with VRRPv2 IP-AH auth
        $ip_ah_marker = { 33 }

    condition:
        $ip_proto_vrrp and $vrrp_hdr and $ip_ah_marker
}

Suricata IDS Rule

alert ip any any -> any any (msg:"CVE-2026-73443 Possible VRRPv2 Advertisement Replay (IP-AH) - repeated identical frame"; ip_proto:112; dsize:>20; threshold: type both, track by_src, count 5, seconds 5; classtype:attempted-dos; reference:cve,2026-73443; reference:url,nvd.nist.gov/vuln/detail/CVE-2026-73443; sid:202673443; rev:1;)

Elastic Detection

sequence by source.ip, destination.ip with maxspan=10s
  [network where network.transport == "ip" and network.protocol == "vrrp" and destination.ip == "224.0.0.18"]
  [network where network.transport == "ip" and network.protocol == "vrrp" and destination.ip == "224.0.0.18"]
  [network where network.transport == "ip" and network.protocol == "vrrp" and destination.ip == "224.0.0.18"]

Splunk SPL Query

index=network sourcetype=suricata OR sourcetype=zeek_conn
| search proto=112 OR vrrp=*
| stats count, distinct(flow_id) as distinct_flows, values(bytes) as byte_sizes by src, dest
| where count > 5 AND distinct_flows < count
| table _time, src, dest, count, distinct_flows, byte_sizes

Wazuh OSSEC Rule

<group name="network,cve-2026-73443,">
  <rule id="2027670" level="10" frequency="5" timeframe="10">
    <if_matched_sid>2027669</if_matched_sid>
    <description>CVE-2026-73443: Repeated identical VRRPv2 advertisement observed on segment - possible replay attack (CWE-294).</description>
    <mitre>
      <id>T1498</id>
    </mitre>
    <group>network_dos,vrrp_replay,</group>
  </rule>

  <rule id="2027669" level="3">
    <decoded_as>json</decoded_as>
    <field name="proto">112</field>
    <description>VRRP (IP protocol 112) packet observed on monitored segment.</description>
    <group>network_monitor,vrrp,</group>
  </rule>
</group>

Mitigation & Patch Guidance

Patch confidence is 0/4 (UNPATCHED). No vendor fix has been evidenced by any tracked source, no affected-version matrix has been published in the available data, and no workaround has been officially documented. Treat the issue as unpatched and prioritize compensating controls.

1) Immediate mitigations.

• Eliminate or reduce layer 2 reachability: ensure VRRP-bearing segments are strictly access-controlled, disable unused switch ports, enable port security and DHCP snooping/ARP inspection where applicable, and prevent untrusted devices (guest VLANs, lab systems, unmanaged switches) from sharing the VRRP broadcast domain.
• Where feasible, migrate from VRRPv2 IP-AH to a configuration that avoids reliance on a non-replay-resistant authentication mechanism, or to an alternative first-hop redundancy design, in accordance with vendor-supported options. Do not assume IP-AH is safe merely because a password is configured.
• Enable network-level detection (e.g., the Suricata/Zeek rules above) to identify repeated identical advertisements on VRRP segments, which is the observable signature of replay.
• Segment gateway redundancy domains so that a single compromised segment cannot suppress failover for a large population.
• Monitor for unexpected duplicate VRRP advertisements via existing NetFlow/packet-capture telemetry and alert on anomalies.

2) Patch/upgrade steps.

• No patch is currently available. Monitor the Arista security advisory portal and the NVD entry for CVE-2026-73443 for a fixed EOS release. When a fix is published, stage and validate it against a representative VRRP topology before fleet rollout.
• Maintain a documented inventory of EOS devices running VRRP with IP-AH to enable rapid remediation once a fix lands.

3) Long-term hardening.

• Adopt first-hop redundancy designs that provide cryptographic replay protection, or compensate architecturally (e.g., independent gateway designs, redundant non-VRRP paths).
• Enforce rigorous layer 2 access control and monitor for unauthorized devices on infrastructure VLANs as a standing control against adjacent attacks (T1498 and related).
• Add VRRP replay detection logic to the SOC's network detection playbook and periodically test the scenario in a lab to validate detection fidelity.
• Track CWE-294 class weaknesses across the protocol portfolio; capture-replay is a recurring pattern whenever keyed integrity is used without freshness.

References

• NVD — CVE-2026-73443: https://nvd.nist.gov/vuln/detail/CVE-2026-73443
• CWE-294 — Authentication Bypass by Capture-replay: https://cwe.mitre.org/data/definitions/294.html
• MITRE ATT&CK T1498 — Network Denial of Service: https://attack.mitre.org/techniques/T1498/
• FIRST.org EPSS (score not yet assigned for this CVE): https://api.first.org/data/v1/epss?cve=CVE-2026-73443
• CISA Known Exploited Vulnerabilities Catalog (no entry as of analysis): https://www.cisa.gov/known-exploited-vulnerabilities-catalog

Threat actor / exploit-in-the-wild note: No public proof-of-concept, exploit code, or Nuclei template is available. There is no CISA KEV listing and no evidence of active exploitation in the supplied data. Exploitation requires only commodity packet capture/replay tooling and layer 2 adjacency, so the barrier to weaponization is low even in the absence of a published exploit — defenders should not treat the lack of a PoC as evidence of safety.