Arista published a set of security advisories on November 10, 2026. Most of them touch features that many networks never turn on. One does not. Security Advisory 0218 covers eAPI, the web command interface built into EOS, and it lets someone with no password read files off the switch, sensitive credentials included. If you run Arista switches from the 7050X3/X4 Series, the 7280R/R2/R3/R4 Series, the 7260X/X3 Series or most other EOS families, start with this one.
What Arista published on November 10, 2026
Each advisory has its own number, CVE and list of fixed releases. These are the ones an owner of a data center or campus EOS switch should read:
- Security Advisory 0218: an eAPI path traversal tracked as CVE-2026-121371. No login needed, reachable over the network, and the vulnerable settings are the defaults.
- Security Advisory 0220: RIPv2 can end up running on the management interface without showing in the configuration, tracked as CVE-2026-121367.
- Security Advisory 0224 and Security Advisory 0225: denial of service issues that Arista lists as affecting only the 750X Series.
For both of the main advisories covered here, Arista says it found the issue itself and that it is not aware of malicious exploitation in customer networks. That is good news, but once details are public the time before someone builds an attack gets shorter, so treat this as a patch cycle, not a footnote.
Advisory 0218: eAPI can hand out files without a login
In Arista's words, on affected EOS versions with the eAPI service enabled, a specially crafted HTTP request can allow an unauthenticated, remote attacker to read arbitrary files, including sensitive credentials from the switch filesystem. Arista scores it CVSSv3.1 Base Score 7.5 and CVSSv4.0 Base Score 8.7, and files it under CWE-22, path traversal.
Both conditions must be met: eAPI is enabled and running, and default-service is enabled. The important part is Arista's note under those conditions: they reflect default system configurations, so systems remain vulnerable even without custom or explicit configuration changes. A switch that nobody ever set up for automation can still be exposed.
A file read can sound mild next to remote code execution. It is not mild here. The advisory names credentials as something an attacker can read, and stolen switch credentials turn a read into a login.
How to check a switch:
- Run show management api http-commands. If it reports Enabled: Yes with an HTTPS or HTTP server running, eAPI is up.
- Run show running-config all and look in the management http-server or management api http-commands section for the line default-services.
- For signs of abuse, Arista says to review the local nginx access log at /var/log/nginx-access.log for irregular HTTP requests aimed at device static resources, especially requests built with unexpected paths.
Which EOS releases are affected and which fix it
Arista lists these EOS versions as affected by CVE-2026-121371:
- 4.36.3M and earlier releases in the 4.36.x train
- 4.35.7M and earlier releases in the 4.35.x train
- 4.34.9M and earlier releases in the 4.34.x train
- 4.33.11M and earlier releases in the 4.33.x train
- All releases in the 4.32.x train
- All releases in the End of Support software release trains
The fixed releases are 4.37.0F and later in the 4.37.x train, 4.36.3.2M and later in the 4.36.x train, 4.35.7.2M and later in the 4.35.x train, 4.34.9.2M and later in the 4.34.x train, and 4.33.11.2M and later in the 4.33.x train. Arista says no hotfix is available for this issue, so the lasting answer is an upgrade.
Read the list carefully if you run an older train. The 4.32.x train and the End of Support trains have no fixed release in the list. A switch held on one of those trains stays exposed until it moves to a fixed train, and until then it depends on the stopgap below.
Arista also gives a simple rule for scoping: if your software release is not listed, your deployment is not vulnerable, regardless of the hardware platform in use. The model on the front panel does not decide exposure. The EOS version does.
The stopgap: turn off default services
Arista's recommended mitigation is to disable default services on the management HTTP server. In configuration mode, enter management http-server and then no default-services. The same setting is available under management api http-commands with no default-services. Confirm the result with show running-config and the matching section.
There is a cost. Arista says disabling the default services removes access to the built-in eAPI documentation and explorer web page and to the TapAgg GUI. On most production switches nobody uses those pages day to day, but check with whoever runs your automation before you change every switch, and try it on one switch first.
Advisory 0220: RIPv2 on the management interface
The second advisory to read is about Routing Information Protocol version 2 (RIPv2). Arista says that on affected EOS platforms with RIPv2 configured, under certain conditions RIPv2 might be silently enabled on management interfaces even when the RIP agent intends to disable it. An unauthenticated attacker on the adjacent network can then send crafted RIPv2 route advertisements to the management IP address, and the switch could install those routes without authentication. Arista warns this could redirect traffic to an attacker controlled destination or blackhole legitimate traffic.
Arista scores it CVSSv3.1 Base Score 9.6 and CVSSv4.0 Base Score 6.1. Both conditions must be met: RIP is enabled, and a RIP network statement matches the subnet assigned to the management interface in the same VRF. The warning that matters most: RIP processing on the management interface may not appear in running configuration, so routine configuration review may not reveal the exposure.
If you do not need RIP, Arista says to disable it within each affected VRF instance. Arista also warns that disabling RIP or changing network statements may withdraw routes and interrupt connectivity, and says to plan a change window, confirm alternate routing, and verify the result. If you need RIP on data interfaces, make sure no RIP network prefix matches the management subnet.
Affected releases are 4.37.0F, 4.36.2F and below in the 4.36.x train, 4.35.6M and below, 4.34.8M and below, 4.33.10M and below, all of 4.32.x, and all End of Support trains. Fixes are in 4.36.3M, 4.35.7M, 4.34.9M and 4.33.11M and later in each train. One trap: 4.37.0F appears as fixed for advisory 0218 but as affected by advisory 0220, and the 0220 fix list names no 4.37.x release.
Two advisories that only touch the 750X Series
Security Advisory 0224 is a denial of service through Precision Time Protocol (PTP), CVE-2026-121370, scored CVSSv3.1 Base Score 8.6. Security Advisory 0225, CVE-2026-121369, can drive CPU and memory up until the switch reboots when interfaces on certain line cards are left at speed auto or no speed. Arista lists the 750X Series as the affected platform for both, and for 0225 names the CCS-750XM-48TX-LC, CCS-750XPM-48NH-LC and CCS-750XPM-48TXH-LC line cards. Both advisories list the 7050X3/X4 Series among the products not affected, and 0224 lists the 7280R/R2/R3/R4 Series and the 7260X/X3 Series as not affected too. If you run a 750X campus chassis, read both in full. If you run only fixed data center switches, you can set them aside.
What to do on your Arista switches now
- List every EOS switch and its running release. Compare each against the 0218 and 0220 lists, not against the model.
- Where eAPI is up with default services on, apply no default-services now unless something depends on the explorer page.
- Check RIP: if any RIP network statement covers the management subnet, fix it in a change window or turn RIP off where you do not use it.
- Plan the upgrade to the latest fixed release in your train. Arista recommends moving to the latest version of each release that contains all the listed fixes.
- Switches on 4.32.x or an End of Support train need a plan to reach a fixed train, or a decision to retire them.
- Review the nginx access log on exposed switches and change any credentials stored on a switch that was reachable.
If you are buying Arista switches now
A used switch arrives with whatever release its last owner ran, and Arista ties exposure to the release, not the hardware. Check the running version on arrival, load a fixed release in a supported train before the switch goes into production, and set no default-services as part of your standard build if your team does not use the explorer page. Families like the 7050X3/X4 Series, the 7280R/R2/R3/R4 Series and the 7260X/X3 Series are named in both advisories 0218 and 0220, so a fixed release is part of putting any of them into service.
In stock at Townsend
We have these Arista switches in stock: an Arista 7050X3 switch, an Arista 7280R Series switch (R3 generation) and an Arista 7260X Series switch (X3 generation). Browse the Arista 7050X3 collection or all Arista switches, or send your list through the quote page.