Affected platforms running Arista EOS with OpenConfig configured

CVE-2024-27890 is an authorization failure in Arista EOS OpenConfig/gNMI handling: a gNMI Set request can succeed when policy says it should be rejected, letting an attacker push unauthorized configuration to the switch. Arista says affected releases are 4.29.7M and below in the 4.29.x train, 4.28.10M and below in 4.28.x, plus older 4.27.x through 4.24.x trains; fixed code is in 4.30.0M+, 4.29.8M+, and 4.28.11M+, with SA99 hotfixes for selected interim releases.

Arista's 9.6 CRITICAL score is technically defensible *if* you assume a reachable management listener and a usable low-privilege gNMI identity. In enterprise reality, that assumption is the whole fight: OpenConfig must be explicitly enabled, the target is usually on a management network, many shops do not expose TCP/6030 broadly, and this is a single-device management-plane compromise rather than unauthenticated internet-wide RCE. That keeps it serious, but not top-of-pile drop everything critical for most fleets.

Why this verdict

• Downgrade for feature gating: the box is not exposed unless OpenConfig/gNMI is actually enabled.
• Downgrade for attacker position: PR:L implies the attacker already has a usable management-plane identity, which is post-initial-access in most enterprises.
• Downgrade for reachable population: EOS management services usually live on restricted management networks, not broad end-user address space or internet edge.
• Hold at HIGH for blast radius: if exploited on a core or aggregation switch, unauthorized config changes can directly disrupt traffic, security controls, or visibility.
• Hold at HIGH for tooling simplicity: once on the management plane, the exploit path is not exotic; standard gNMI clients can exercise Set operations.

Why not higher?

This is not unauthenticated internet-facing code execution, and it does not hit every EOS deployment by default. The chain assumes a prior foothold on the management plane plus an explicitly enabled feature, which sharply narrows both attacker population and exposed asset count.

Why not lower?

The affected asset class is network infrastructure, not a low-value edge utility. If an attacker can abuse this on reachable switches, the resulting unauthorized configuration changes can create immediate outage or traffic-manipulation impact, which is too operationally dangerous to file as routine medium-severity hygiene.

1. Disable gNMI where unused — If a switch does not need OpenConfig/gNMI, remove the listener with no management api gnmi. This is the cleanest exposure kill-switch and should be deployed within 30 days for all non-automation-managed devices.
2. Enforce per-RPC authorization — Turn on authorization for gNMI requests and ensure no low-privilege principal can invoke OpenConfig.Set. This directly targets the vulnerable behavior and should be applied within 30 days on devices that must keep gNMI enabled.
3. Restrict TCP/6030 to controllers only — Use management-plane ACLs, out-of-band segmentation, or firewalls so only your automation controllers and jump hosts can reach the gNMI service. Do this within 30 days to collapse the reachable population even before upgrades finish.
4. Audit automation identities — Review client certs, service accounts, and AAA mappings used for gNMI access; remove stale principals and validate least privilege. Complete this within 30 days because PR:L is the prerequisite that makes this flaw matter.
5. Watch for gNMI config writes — Enable logging/accounting that highlights Set operations and unexpected config drift so you can catch exploitation or testing fast. Stand this up within 30 days on high-value switching tiers.

Run this on the EOS switch itself from a privileged shell session that can invoke Cli -p 15, or via an EOS bash shell obtained through your normal break-glass/admin method. Invoke it as bash check_cve_2024_27890.sh; it needs privilege to run show version, show management api gnmi, and show extensions.

#!/usr/bin/env bash
# check_cve_2024_27890.sh
# Determine likely exposure to CVE-2024-27890 on Arista EOS.
# Outputs one of: VULNERABLE / PATCHED / UNKNOWN
# Exit codes: 0=PATCHED, 1=VULNERABLE, 2=UNKNOWN

set -u

run_cli() {
  Cli -p 15 -c "$1" 2>/dev/null
}

VERSION_OUT="$(run_cli 'show version')"
GNMI_OUT="$(run_cli 'show management api gnmi')"
EXT_OUT="$(run_cli 'show extensions')"

if [[ -z "$VERSION_OUT" || -z "$GNMI_OUT" ]]; then
  echo "UNKNOWN - unable to query EOS CLI via 'Cli -p 15'"
  exit 2
fi

VERSION_LINE="$(echo "$VERSION_OUT" | grep -Ei 'Software image version|System image file is|image version' | head -n1)"
VERSION_RAW="$(echo "$VERSION_LINE" | sed -E 's/.*version[: ]+//I; s/.*EOS-//' | awk '{print $1}')"

if [[ -z "$VERSION_RAW" ]]; then
  echo "UNKNOWN - could not parse EOS version"
  exit 2
fi

GNMI_ENABLED="no"
if echo "$GNMI_OUT" | grep -qi 'Enabled:[[:space:]]*yes'; then
  GNMI_ENABLED="yes"
elif echo "$GNMI_OUT" | grep -qi 'Enabled:[[:space:]]*no transports enabled'; then
  GNMI_ENABLED="no"
fi

if [[ "$GNMI_ENABLED" == "no" ]]; then
  echo "PATCHED - OpenConfig/gNMI is not enabled, so this device is not exposed to CVE-2024-27890"
  exit 0
fi

if echo "$EXT_OUT" | grep -q 'sa99-CVE-2024-27890'; then
  echo "PATCHED - SA99 hotfix for CVE-2024-27890 appears installed"
  exit 0
fi

# Extract numeric parts from versions like 4.29.7M, 4.28.10.1M, 4.30.0M
NUM="$(echo "$VERSION_RAW" | sed -E 's/[^0-9.].*$//')"
IFS='.' read -r MAJ MIN PAT EXTRA <<< "$NUM"
MAJ=${MAJ:-0}
MIN=${MIN:-0}
PAT=${PAT:-0}
EXTRA=${EXTRA:-0}

# Only EOS 4.x logic is encoded from Arista SA0099.
if [[ "$MAJ" -ne 4 ]]; then
  echo "UNKNOWN - version '$VERSION_RAW' is outside the trains covered by this checker"
  exit 2
fi

# Patched trains per advisory:
# 4.30.0M+
# 4.29.8M+
# 4.28.11M+
# Older 4.24-4.27 trains are affected and require upgrade to a fixed train or hotfix where applicable.

if (( MIN >= 30 )); then
  echo "PATCHED - EOS $VERSION_RAW is in 4.30.0M+ train"
  exit 0
fi

if (( MIN == 29 )); then
  if (( PAT >= 8 )); then
    echo "PATCHED - EOS $VERSION_RAW is in 4.29.8M+"
    exit 0
  else
    echo "VULNERABLE - OpenConfig/gNMI enabled on affected 4.29.x release ($VERSION_RAW)"
    exit 1
  fi
fi

if (( MIN == 28 )); then
  if (( PAT >= 11 )); then
    echo "PATCHED - EOS $VERSION_RAW is in 4.28.11M+"
    exit 0
  else
    echo "VULNERABLE - OpenConfig/gNMI enabled on affected 4.28.x release ($VERSION_RAW)"
    exit 1
  fi
fi

if (( MIN >= 24 && MIN <= 27 )); then
  echo "VULNERABLE - OpenConfig/gNMI enabled on affected legacy train ($VERSION_RAW); move to a fixed train or vendor hotfix path"
  exit 1
fi

echo "UNKNOWN - version '$VERSION_RAW' not covered by explicit advisory logic"
exit 2

Sources

1. Arista Security Advisory 0099
2. Arista Security Advisory 0099 PDF
3. Arista OpenConfig Configuration Documentation
4. Arista EOS User Manual
5. CISA Known Exploited Vulnerabilities Catalog
6. MITRE CVE Record Placeholder for CVE-2024-27890
7. Rapid7 Vulnerability Database Entry
8. Containerlab vEOS Notes on gNMI Service