Introduction
A crafted RIPv2 packet sent from an adjacent network segment can crash the Rip agent on Arista EOS devices that use MD5 authentication for RIP, and the sender does not need to know the shared key. Because repeated triggering reliably interrupts routing on the affected device, the effect can extend to other devices that depend on it, and Arista lists arbitrary code execution as a worst-case outcome.
Arista Networks builds networking equipment for data center and AI, campus, and routing environments, all running its EOS network operating system. The company was founded in 2008, went public in 2014, and serves cloud, enterprise, financial, and specialty cloud customers. Arista says networking analysts rank it number one in data center switching. EOS runs across a broad fixed and modular switch portfolio as well as virtual and cloud form factors, so a bug in a single routing protocol agent touches a long list of platforms.
Technical Information
Scoring and classification. CVE-2026-121287 carries a CVSS v3.1 base score of 8.8 with vector CVSS:3.1/AV:A/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H. Arista's advisory also gives a CVSS v4.0 score of 7.7. Arista Networks is the assigning CNA, and the record was published on November 10, 2026. The weakness is classified as CWE-124, Buffer Underwrite ('Buffer Underflow'). Arista tracks the bug internally as BUG 1981970.
Root cause. The flaw sits in the RIPv2 MD5 authentication handling of the Rip agent, the EOS process that parses incoming RIP packets. A buffer underwrite occurs when code writes to memory before the start of a buffer. That usually stems from a pointer or index calculated from attacker-controlled length or offset fields that is never checked against the buffer's lower bound. In RIPv2 with MD5 authentication, the packet carries its own authentication entry and trailer, so the parser has to trust lengths and positions taken from the packet itself.
The crafted packet is handled before authentication succeeds, which is why an attacker with no valid MD5 key can still reach the vulnerable code path. Arista has not published a deeper root cause, and because EOS is closed source there is no public commit, diff, or vulnerable code snippet to examine.
Required configuration. Per the advisory, an affected release is only exploitable when all three conditions hold:
- RIP is enabled.
- MD5 authentication is configured on an interface.
- A RIP
networkstatement covers that interface's IP address.
Attack flow. Based on the advisory, exploitation looks like this:
- The attacker obtains a position on a network segment adjacent to a RIP-enabled interface that meets the three conditions above. No credentials or user interaction are required.
- The attacker sends crafted RIPv2 packets to that interface. A valid MD5 key is not needed because the malformed content is processed before authentication completes.
- While handling the MD5 authentication data, the Rip agent performs a write before the start of a buffer, and the agent crashes.
- ProcMgr restarts the agent. By repeating the packets, the attacker can keep interrupting routing service on the device, which may also disrupt routing for devices that rely on it.
- In the worst case, Arista says the memory corruption may allow arbitrary code execution on the device. The advisory does not say code execution has been demonstrated or observed.
Not to be confused with CVE-2026-121288. The same advisory covers CVE-2026-121288 (BUG 1985547), a separate RIPv2 MD5 authentication bypass that involves unauthorized route updates. That issue has a different impact from this CVE's agent crash and possible code execution, although both are fixed by the same releases.
Patch Information
Arista fixed CVE-2026-121287 in EOS itself. The fix ships as a set of remediated maintenance releases rather than a standalone patch file or hotfix. Everything known about the fix comes from Arista Security Advisory 0221, published November 10, 2026.
Fixed releases by train:
| Train | Fixed in | Vulnerable |
|---|---|---|
| 4.36.x | 4.36.3M and later | 4.36.2F and below |
| 4.35.x | 4.35.7M and later | 4.35.6M and below |
| 4.34.x | 4.34.9M and later | 4.34.8M and below |
| 4.33.x | 4.33.11M and later | 4.33.10M and below |
The same releases also fix the companion RIPv2 issue, CVE-2026-121288, so one upgrade closes both RIP flaws in the advisory.
What the fix likely changes. Arista has not published the code change. Fixes for this class of bug normally validate packet-derived offsets and lengths before any memory write and drop malformed packets instead of processing them. That is our inference from the CWE class, not a documented detail. After the fix, packets that previously crashed the agent should be discarded.
Gaps in fix coverage:
- Arista says no hotfix (an in-place software extension) is available, so a full EOS upgrade is the only fix.
- 4.37.0F appears on the affected list, but the advisory names no fixed 4.37.x build. Sites on 4.37.0F should check with Arista TAC or watch for a later 4.37 release that includes BUG 1981970.
- Every release in the 4.32 train and in End of Support trains is affected, and none gets a fixed build. These devices need to move to a supported train (4.33.11M or newer).
- Arista recommends moving to the latest release in your train rather than the minimum fixed build, to pick up other accumulated fixes.
Workaround. Where RIP is not needed, Arista's stated workaround is to disable RIP in each affected VRF instance. Arista warns that disabling RIP or changing network statements may withdraw routes and interrupt connectivity, so plan a change window, confirm alternate routing, and verify the resulting configuration and route behavior.
Verifying the fix. After upgrading, run show version and confirm the EOS release is at or above the fixed build for its train. If Rip agent restarts that previously correlated with RIP traffic stop after the upgrade, that is a useful operational sign the remediated code is running.
Detection Methods
Arista's advisory is the only public source with detection guidance for this CVE. Arista states plainly that there are no direct indicators of compromise, and we found no public Sigma, YARA, Snort, Suricata, or other IDS signature. In practice, detection has two parts: identifying devices that can be attacked, and watching the Rip process for the crash this bug causes.
1. Identify attackable devices. The advisory shows the CLI checks for the three required conditions:
switch# show running-config | section router rip router rip no shutdown network 192.0.2.0/24 switch# show running-config interfaces Ethernet1 interface Ethernet1 ip address 192.0.2.1/24 rip authentication algorithm md5 tx key-id 10
If router rip is active, a network statement covers an interface's address, and that interface has rip authentication algorithm md5, the device is attackable on an affected release. Running these checks, or equivalent queries in your configuration management or CloudVision tooling, across devices on affected releases tells you which switches need runtime monitoring. Since the attacker must be adjacent, prioritize segments where untrusted hosts share a Layer 2 domain with RIP-enabled interfaces.
2. Watch for Rip agent crashes and restarts. The bug crashes the Rip agent, so the most useful signal is EOS's process manager (ProcMgr) reporting that the agent died. Arista says unexpected Rip agent termination or repeated restarts "may serve as potential warning signs" and recommends filtering the logs for Rip events and lining up timestamps with routing disruption:
switch# show logging | include Rip ProcMgr-worker: %PROCMGR-6-PROCESS_TERMINATED: 'Rip' (PID=<old-pid>) has terminated. ProcMgr-worker: %PROCMGR-6-PROCESS_RESTART: Restarting 'Rip' immediately (it had PID=<old-pid>) ProcMgr-worker: %PROCMGR-6-PROCESS_STARTED: 'Rip' starting with PID=<new-pid> (PPID=<parent-pid>) -- execing '/usr/bin/Rip'
The three messages normally appear together:
PROCESS_TERMINATEDmeans the agent died.PROCESS_RESTARTmeans ProcMgr is restarting it immediately.PROCESS_STARTEDshows the new process with a new PID.
A single occurrence may have a benign cause, such as an unrelated software bug or a planned agent restart. It becomes much more suspicious when the full sequence repeats, when there was no change window or admin action, or when it lines up with RIP adjacency loss, route withdrawals, or reachability complaints from downstream devices.
3. Turn the guidance into monitoring. These are severity 6 informational messages, so they may never reach your SIEM unless the switch forwards informational-level syslog. Confirm that it does, then build alerts on ProcMgr events naming the 'Rip' process and tune them by:
- Frequency: Several terminate-and-restart cycles in a short window are a strong signal.
- Correlation: Match crashes against routing change telemetry, such as RIP route churn or alarms for lost prefixes.
- Scope: Prioritize devices identified in step 1 as running RIP with MD5.
Because Arista lists arbitrary code execution as a worst case, a crash-and-restart pattern on an exposed device should start a deeper investigation rather than a routine service-health ticket. Check for configuration changes, unexpected sessions, or other unusual behavior around the crash timestamps.
Limitations. There is no public packet-level signature for the crafted RIPv2 packets, so network detection stays generic. One option is to capture and review RIP traffic (UDP/520) from unexpected sources on segments with RIP-enabled interfaces. Vulnerability database entries such as Rapid7's page list the CVE and its scores but publish no additional detection logic.
Affected Systems and Versions
Affected EOS releases:
- EOS 4.37.0F
- EOS 4.36.2F and earlier in the 4.36 train
- EOS 4.35.6M and earlier in the 4.35 train
- EOS 4.34.8M and earlier in the 4.34 train
- EOS 4.33.10M and earlier in the 4.33 train
- All releases in the 4.32 train
- All End of Support release trains
Affected platforms: 710, 720D, 720XP/722XPM, 750X, 7010TX, 7020R/R4, 7130 running EOS, 7170, 7050X3/X4, 7060X/X2/X4/X5/X6/XE7, 7260X/X3, 7280R/R2/R3/R4, 7300X/X3, 7320X, 7358X4, 7368X4, 7388X5, 7500R/R2/R3, 7800R3/R4, and 7700R4 series. Arista also names AWE 5000, AWE 7200R, CloudEOS, cEOS lab, vEOS lab, and CloudVision eXchange virtual or physical appliances.
Vulnerable configuration: RIP enabled, MD5 authentication configured on an interface, and a RIP network statement matching that interface's IP address. Devices on affected releases without this combination are not exploitable according to the advisory.
Vendor Security History
Arista's 2025 annual filing states that product defects or vulnerabilities can damage perceptions of reliability and that the company has at times replaced products or provided remediation for defects and bugs, including software protocol failures. The filing does not quantify a security incident rate. Arista describes its vulnerability process as combining scanning, CVSS v3.1 and v4.0 assessment, and manual validation by PSIRT engineers and outside consultants. For this CVE, Arista discovered the issue internally, reported no known malicious exploitation, and published upgrade and workaround guidance. CVE-2026-121287 was not listed in the CISA Known Exploited Vulnerabilities catalog at the time of review.
References
- NVD: CVE-2026-121287
- CVE Record: CVE-2026-121287
- Arista Security Advisory 0221
- Arista Security Advisory 0221 (PDF format)
- Rapid7 Vulnerability Database: CVE-2026-121287
- CWE-124: Buffer Underwrite
- CISA Known Exploited Vulnerabilities Catalog
- About Arista Networks
- Arista Device Hardening and Vulnerability Management
- Arista Networks 2025 Annual Report (SEC filing)
