Arista EOS CVE-2026-2379

Exploitation requires all of the following: the device must be an Arista EOS platform with hardware IPsec support, certain IPsec features must be explicitly enabled (default state not confirmed in the advisory excerpt), and a triggering event must occur - specifically a physical interface flap on the IPsec-bearing interface or a restart of certain EOS agents. The CVSS 4.0 AT:P flag confirms these are non-trivial attack requirements rather than a default-configuration exposure. Limiting factors include the need for the affected hardware class, the specific IPsec feature combination called out by Arista, and the timing/triggering of the flap or agent restart; devices without hardware IPsec or with the relevant features disabled are not in scope.

The CVSS 4.0 vector (AV:N/AC:L/AT:P/PR:N/UI:N) indicates a network-reachable, low-complexity issue requiring no privileges or user interaction, but the AT:P flag signals that specific attack requirements (here, an interface flap or particular agent restart on a device with hardware IPsec and the affected features enabled) must align. The impact metrics are notable: VC:H (high confidentiality) drives the 8.2 score, while VI:N and VA:N indicate no direct integrity or availability impact per the vendor scoring - though the description's reference to 'unstable communication' suggests an operational impact that is not reflected in the vector and should be clarified with Arista. There is no CISA KEV listing, no EPSS data provided, and no public exploit identified, so this currently reads as a configuration-dependent issue worth patching in normal cycles rather than an emergency, with the caveat that confidentiality impact on encrypted tunnel traffic warrants priority for high-assurance deployments.

An attacker with network adjacency to a tunnel endpoint induces or waits for a physical interface flap (for example, by leveraging upstream link instability or coordinating around a known maintenance event) on an Arista EOS device with hardware IPsec enabled; the tunnel re-establishes while reusing prior Security Associations, producing sequence number desynchronization that may expose ciphertext or anti-replay state useful for further confidentiality attacks against tunneled traffic. No public exploit identified at time of analysis, and the scenario depends on the attacker's ability to either observe the resulting state or trigger the flap condition.