← Back to Feed CACHED · 2026-05-17 09:42:19 · cache_key CVE-2025-29912
CVE-2024-27892 · CWE-306 · Disclosed 2026-06-04

Affected platforms running Arista EOS with OpenConfig configured

ASSESSED — NOISGATE V0.5
Vendor
Reassessed
Verdict:
01 · The Real Story

This is a master key that only works if you already got through the lobby and into the management hallway

CVE-2024-27892 is an authorization failure in Arista EOS OpenConfig/gNMI handling: a Set request can be accepted when it should be rejected, letting an attacker push unintended configuration to the switch. Arista says the vulnerable condition is OpenConfig enabled with an SSL profile; affected releases span 4.24.11M and below in the 4.24 train, 4.25.10M and below, 4.26.9M and below, 4.27.8M and below, 4.28.10M and below, 4.29.7M and below, 4.30.5M and below, and 4.31.2F and below. Fixed trains are 4.28.11M+, 4.29.8M+, 4.30.6M+, and 4.31.3M+; older trains need a jump forward or a hotfix where available.

Arista scored it 9.6 CRITICAL, but that overstates enterprise reality. The bug is dangerous after an attacker can reach the gNMI management plane and satisfy the product's low-priv/authn assumptions, yet it is not a wormable pre-auth RCE and it is not broadly reachable on most well-run networks because OpenConfig/gNMI is opt-in and normally fenced to management segments. The impact on a hit device is absolutely real — switch reconfiguration can blackhole traffic or change policy — so this stays HIGH, just not 'drop everything, internet fire drill' critical.

"Serious switch-tampering bug, but not a true internet-scale critical: it needs gNMI exposure and low-priv access first."
02 · The Attack Path

4 steps from start to impact.

STEP 01

Reach the gNMI service on TCP/6030

The attacker first needs IP reachability to the EOS gNMI endpoint, typically TCP/6030, using a standard client such as gnmic or Arista's sample gNMI tooling. This is a management-plane attack, not a passive data-plane bug.
Conditions required:
  • Target is running Arista EOS with OpenConfig/gNMI enabled
  • Network path exists to the gNMI listener, commonly port 6030
  • OpenConfig transport is enabled on the target
Where this breaks in practice:
  • Most enterprises keep switch management services on dedicated VRFs, OOB networks, or ACL-restricted management segments
  • Many EOS deployments do not enable OpenConfig/gNMI at all
  • Internet exposure of switch management ports is much rarer than web apps or VPNs
Detection/coverage: External vuln scanners often miss this because exposure depends on EOS feature state, not just banner grab. Best coverage comes from config audit: show management api gnmi and management ACL review.
STEP 02

Satisfy the low-priv identity requirement

Arista's own CVSS vector assigns PR:L, so treat this as requiring an attacker-controlled low-priv identity accepted by the gNMI service rather than anonymous exploitation. In practice that means a valid client cert, mapped username, or other accepted gNMI authn path, then abusing broken authorization around OpenConfig.Set.
Conditions required:
  • Attacker has some accepted gNMI identity or credential material
  • Target uses the vulnerable OpenConfig-with-SSL-profile condition
  • Authorization boundaries for Set are not correctly enforced
Where this breaks in practice:
  • Getting a valid management-plane identity is already a post-initial-access or insider condition in most networks
  • PKI-backed client auth and RBAC reduce who can even attempt this
  • Credential theft from a network automation system is possible but materially harder than anonymous probing
Detection/coverage: Look for gNMI auth events and unexpected client cert/common-name usage on switches and automation controllers. Identity use is more detectable than classic unauthenticated exploit traffic.
STEP 03

Send a malicious OpenConfig.Set request

Using gnmic, pygnmi, or similar gRPC clients, the attacker submits a Set RPC that should have been denied but is processed anyway. This enables configuration changes through OpenConfig paths rather than EOS CLI, which can bypass operator expectations if teams assume RBAC blocks that action.
Conditions required:
  • Attacker knows relevant OpenConfig paths for the target function
  • The request reaches the vulnerable handler
  • The target accepts the malformed or unauthorized change path
Where this breaks in practice:
  • Real impact requires familiarity with OpenConfig schemas and the target network role
  • Bad payloads can fail harmlessly or create noisy config errors
  • Some organizations do per-RPC authorization already, which blocks the practical exploit path
Detection/coverage: Telemetry and config-diff systems can catch unexpected changes after the fact. Signature-based IDS coverage is weak because this is encrypted gRPC and the maliciousness is semantic, not protocol-level.
STEP 04

Translate config tampering into outage or policy bypass

Once the switch accepts unauthorized config, the attacker can alter routing, ACLs, interfaces, or other supported settings and create a real integrity/availability hit. The blast radius is usually the individual switch or its local forwarding domain, but on a spine/edge role that can still be painful.
Conditions required:
  • Target switch sits on a path where config changes matter operationally
  • Change-control tooling does not immediately overwrite the rogue config
  • Operator notices do not trigger fast rollback
Where this breaks in practice:
  • Strong source-of-truth automation may revert unauthorized drift quickly
  • Many gNMI-driven changes are visible in config management and monitoring
  • Impact is usually bounded to the compromised device or its segment, not arbitrary code exec across the fleet
Detection/coverage: Config drift alerts, routing change alerts, interface flap alarms, and automation reconciliation logs are the best practical detections. There are no vendor-provided IOCs in the advisory.
03 · Intelligence Metadata

The supporting signals.

In-the-wild statusNo public exploitation confirmed in the vendor advisory; Arista says it is *not aware of malicious use in customer networks*.
KEV statusNot in CISA KEV based on the current Known Exploited Vulnerabilities Catalog.
Proof-of-concept availabilityNo widely cited public PoC surfaced in the sources reviewed. That does not mean hard to exploit — standard gNMI clients like gnmic are enough once the attacker has access.
EPSSNo verifiable public EPSS figure surfaced in the sources reviewed; one public aggregator even showed *No EPSS yet*. Treat that as sparse telemetry, not a safety signal.
CVSS vectorCVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:C/C:N/I:H/A:H — network reachable and low complexity, but notably PR:L, which is the biggest reason this is not a true critical in practice.
Affected versions4.31.2F and below, 4.30.5M and below, 4.29.7M and below, 4.28.10M and below, 4.27.8M and below, 4.26.9M and below, 4.25.10M and below, 4.24.11M and below.
Fixed versionsFixed in 4.31.3M+, 4.30.6M+, 4.29.8M+, 4.28.11M+; Arista also published hotfix SWIX packages for selected affected releases in Advisory 0099.
Required exposure conditionNarrower than the CVSS headline suggests: Arista says CVE-2024-27892 requires OpenConfig enabled with an SSL profile. If show management api gnmi shows Enabled: no transports enabled, you are not exposed.
Scanning / exposure realityI found no reliable public GreyNoise/KEV-style evidence of active scanning for this CVE. Operationally, exposure is usually limited to management networks because gNMI is commonly on TCP/6030 and is a deliberately enabled interface, not a default public service.
Disclosure / discoveryThe user's 2026-06-04 date appears wrong. Arista Advisory 0099 shows initial release on 2024-07-02, updated on 2024-07-08 and 2024-07-25, and says the issue was discovered internally.
04 · The Call

noisgate verdict.

Final Verdict
DOWNGRADED to HIGH (7.6/10)

The decisive downgrade factor is attacker position: this is a management-plane authorization bug that already assumes network reachability to gNMI and a low-privilege accepted identity. That sharply narrows the exposed population compared with a true unauthenticated internet-facing pre-auth critical, even though the on-box impact can be severe.

HIGH Affected-version and required-configuration assessment
MEDIUM Real-world exposure estimate across enterprise fleets
MEDIUM Absence of public exploitation / PoC evidence

Why this verdict

  • Start at the vendor's 9.6, then subtract for PR:L: Arista's own vector says this is not anonymous exploitation; the attacker needs a low-privilege foothold in the management plane.
  • Subtract again for opt-in exposure: CVE-2024-27892 only applies when OpenConfig/gNMI is enabled and configured with an SSL profile. That is a much smaller reachable population than generic EOS deployment counts imply.
  • Keep it HIGH because impact is operationally ugly: unauthorized switch config can break routing, ACLs, interfaces, or service reachability on a critical network node, which is absolutely a serious integrity/availability event.

Why not higher?

This is not a broad unauthenticated RCE and not a likely internet-spray candidate in mature enterprises. The attack chain already presumes access to a specialized management interface and a valid low-privilege identity, which compounds downward pressure on severity.

Why not lower?

Once the prerequisites are met, the attacker can change live switch configuration with real operational consequences. On the wrong device — leaf pair, WAN edge, route reflector-adjacent box, or a sensitive segmentation point — the outage and policy impact can be major enough that calling this medium would understate the risk.

05 · Compensating Control

What to do — in priority order.

  1. Fence gNMI to management networks — Restrict TCP/6030 reachability to your automation controllers and admin jump paths only. For a HIGH verdict, deploy this within 30 days; it removes the biggest prerequisite in the attack chain.
  2. Deny OpenConfig.Set by policy — Apply per-RPC authorization and ensure no user or mapped identity is allowed to invoke OpenConfig.Set unless there is a clear operational need. Arista explicitly recommends this workaround for CVE-2024-27892; deploy within 30 days if you cannot patch immediately.
  3. Disable gNMI where unused — If the switch is not managed through OpenConfig/gNMI, turn the agent off entirely with no management api gnmi. For a HIGH finding this is a strong compensating control to deploy within 30 days because it collapses exposure to zero.
  4. Remove the SSL profile if OpenConfig over TLS is not needed — Arista states CVE-2024-27892 requires OpenConfig enabled with an SSL profile. If that mode is not required, removing the SSL profile is a valid workaround; do it within 30 days while scheduling code remediation.
  5. Watch for config drift on network nodes — Feed EOS config diffs, route changes, ACL changes, and interface-state changes into your NMS/SIEM and alert when automation identity owners are unexpected. This will not prevent exploitation, but it improves dwell time reduction and rollback speed within the 30-day mitigation window.
What doesn't work
  • A WAF does nothing here; this is gRPC/gNMI on the management plane, not HTTP application traffic.
  • MFA on SSH is not the control point for this path; the relevant exposure is the gNMI service and its authorization model.
  • Perimeter internet scanning only is insufficient because the real question is internal or management-segment reachability to TCP/6030 plus feature enablement.
  • Backups alone do not stop exploitation; they help recovery, not prevention.
06 · Verification

Crowdsourced verification payload.

Run this on the Arista switch itself from the EOS bash shell, or via an automation job that can execute Cli -c locally. Save it as /mnt/flash/check_cve_2024_27892.sh, then run bash /mnt/flash/check_cve_2024_27892.sh; it needs privilege to invoke EOS CLI locally, which normally means admin access on the device.

noisgate-verify.sh
BASHREAD-ONLYSAFE
#!/usr/bin/env bash
# check_cve_2024_27892.sh
# Determine likely exposure to CVE-2024-27892 on an Arista EOS device.
# Output: VULNERABLE / PATCHED / UNKNOWN
# Exit codes: 0=PATCHED, 1=VULNERABLE, 2=UNKNOWN

set -u

fail_unknown() {
  echo "UNKNOWN - $1"
  exit 2
}

# Use EOS local CLI helper if present.
if command -v Cli >/dev/null 2>&1; then
  CLI_CMD="Cli -c"
elif command -v FastCli >/dev/null 2>&1; then
  CLI_CMD="FastCli -p 15 -c"
else
  fail_unknown "Neither Cli nor FastCli found"
fi

run_cli() {
  # shellcheck disable=SC2086
  eval $CLI_CMD "$1" 2>/dev/null
}

ver_out="$(run_cli 'show version' )"
[ -n "$ver_out" ] || fail_unknown "Unable to read show version"

gnmi_out="$(run_cli 'show management api gnmi' )"
[ -n "$gnmi_out" ] || fail_unknown "Unable to read show management api gnmi"

# Extract EOS version from common output forms.
version="$(printf '%s
' "$ver_out" | grep -Eo 'Software image version: [^ ]+' | awk '{print $4}' | head -n1)"
if [ -z "$version" ]; then
  version="$(printf '%s
' "$ver_out" | grep -Eo 'version [0-9]+\.[0-9]+\.[0-9A-Za-z.]+' | awk '{print $2}' | head -n1)"
fi
[ -n "$version" ] || fail_unknown "Could not parse EOS version"

# Exposure condition from Arista advisory: OpenConfig/gNMI enabled with an SSL profile.
if printf '%s
' "$gnmi_out" | grep -qi 'Enabled: no transports enabled'; then
  echo "PATCHED - gNMI/OpenConfig transport is not enabled"
  exit 0
fi

if ! printf '%s
' "$gnmi_out" | grep -qi 'Enabled: yes'; then
  fail_unknown "Could not confirm whether gNMI transport is enabled"
fi

ssl_line="$(printf '%s
' "$gnmi_out" | grep -i 'SSL profile:' | head -n1)"
[ -n "$ssl_line" ] || fail_unknown "Could not parse SSL profile line"

if printf '%s
' "$ssl_line" | grep -qi 'SSL profile: none'; then
  echo "PATCHED - gNMI is enabled but no SSL profile is configured; Arista says CVE-2024-27892 requires an SSL profile"
  exit 0
fi

# Version helpers.
train="$(printf '%s' "$version" | awk -F. '{print $1"."$2}')"
rest="$(printf '%s' "$version" | cut -d. -f3-)"
[ -n "$train" ] || fail_unknown "Could not determine version train"

# Parse release number and flavor from last segment, e.g. 10M, 10.1M, 2F, 3M
# We only need enough fidelity for the affected/fixed thresholds in Advisory 0099.
num_part="$(printf '%s' "$rest" | sed -E 's/^([0-9]+(\.[0-9]+)?).*/\1/')"
flavor="$(printf '%s' "$rest" | sed -E 's/^[0-9]+(\.[0-9]+)?([A-Za-z]).*/\2/' | head -c1)"
[ -n "$num_part" ] || fail_unknown "Could not parse release number"
[ -n "$flavor" ] || fail_unknown "Could not parse release flavor"

verlte() {
  # returns true if $1 <= $2 using sort -V
  [ "$(printf '%s
%s
' "$1" "$2" | sort -V | head -n1)" = "$1" ]
}

is_vuln=0
reason=""

case "$train" in
  4.24)
    if [ "$flavor" = "M" ] && verlte "$num_part" "11"; then is_vuln=1; reason="4.24.11M and below affected"; fi
    ;;
  4.25)
    if [ "$flavor" = "M" ] && verlte "$num_part" "10"; then is_vuln=1; reason="4.25.10M and below affected"; fi
    ;;
  4.26)
    if [ "$flavor" = "M" ] && verlte "$num_part" "9"; then is_vuln=1; reason="4.26.9M and below affected"; fi
    ;;
  4.27)
    if [ "$flavor" = "M" ] && verlte "$num_part" "8"; then is_vuln=1; reason="4.27.8M and below affected"; fi
    ;;
  4.28)
    if [ "$flavor" = "M" ] && verlte "$num_part" "10"; then is_vuln=1; reason="4.28.10M and below affected"; fi
    ;;
  4.29)
    if [ "$flavor" = "M" ] && verlte "$num_part" "7"; then is_vuln=1; reason="4.29.7M and below affected"; fi
    ;;
  4.30)
    if [ "$flavor" = "M" ] && verlte "$num_part" "5"; then is_vuln=1; reason="4.30.5M and below affected"; fi
    ;;
  4.31)
    # Advisory text lists 4.31.2F and below as affected and 4.31.3M+ as fixed.
    if { [ "$flavor" = "F" ] && verlte "$num_part" "2"; } || { [ "$flavor" = "M" ] && verlte "$num_part" "2"; }; then
      is_vuln=1
      reason="4.31.2 and below affected"
    fi
    ;;
  *)
    # Later trains are assumed not affected unless vendor says otherwise.
    ;;
esac

if [ "$is_vuln" -eq 1 ]; then
  echo "VULNERABLE - EOS $version with gNMI enabled and SSL profile configured ($reason)"
  exit 1
fi

# Known fixed trains from Advisory 0099.
case "$train" in
  4.28)
    if [ "$flavor" = "M" ] && ! verlte "$num_part" "10"; then
      echo "PATCHED - EOS $version is at or above 4.28.11M"
      exit 0
    fi
    ;;
  4.29)
    if [ "$flavor" = "M" ] && ! verlte "$num_part" "7"; then
      echo "PATCHED - EOS $version is at or above 4.29.8M"
      exit 0
    fi
    ;;
  4.30)
    if [ "$flavor" = "M" ] && ! verlte "$num_part" "5"; then
      echo "PATCHED - EOS $version is at or above 4.30.6M"
      exit 0
    fi
    ;;
  4.31)
    if [ "$flavor" = "M" ] && ! verlte "$num_part" "2"; then
      echo "PATCHED - EOS $version is at or above 4.31.3M"
      exit 0
    fi
    ;;
esac

# For versions outside explicitly covered trains, we avoid guessing.
fail_unknown "Version $version not explicitly classified by this script; verify against current Arista advisory"
07 · Bottom Line

If you remember one thing.

TL;DR
Monday morning: pull an inventory of EOS nodes with show management api gnmi, isolate the subset with OpenConfig enabled and an SSL profile configured, and treat those as the real exposure set. Because this is HIGH, use the noisgate mitigation SLA to fence or disable the vulnerable path within 30 days — ideally deny OpenConfig.Set, restrict TCP/6030 to automation hosts, or disable gNMI where unused — and use the noisgate remediation SLA to move exposed devices to fixed code within 180 days; prioritize any internet-reachable, shared-management, or crown-jewel network roles first.

Sources

  1. Arista Security Advisory 0099
  2. Arista Security Advisory 0099 PDF view
  3. Arista OpenMgmt gNMI client examples
  4. Arista OpenConfig configuration docs
  5. Containerlab vEOS notes on gNMI service
  6. CISA Known Exploited Vulnerabilities Catalog
  7. Rapid7 vulnerability entry mirroring advisory timeline
  8. Feedly CVE page noting no EPSS yet
Peer Review

What defenders are saying.

Submit a review attribution: handle + country only
0 flags selected · stored anonymously
Validation Results

Crowdsourced verification outputs.

Results submitted by users who ran the verification payload against their environment.