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.
4 steps from start to impact.
Reach the gNMI service on TCP/6030
gnmic or Arista's sample gNMI tooling. This is a management-plane attack, not a passive data-plane bug.- 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
- 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
show management api gnmi and management ACL review.Satisfy the low-priv identity requirement
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.- Attacker has some accepted gNMI identity or credential material
- Target uses the vulnerable OpenConfig-with-SSL-profile condition
- Authorization boundaries for
Setare not correctly enforced
- 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
Send a malicious OpenConfig.Set request
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.- Attacker knows relevant OpenConfig paths for the target function
- The request reaches the vulnerable handler
- The target accepts the malformed or unauthorized change path
- 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
Translate config tampering into outage or policy bypass
- 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
- 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
The supporting signals.
| In-the-wild status | No public exploitation confirmed in the vendor advisory; Arista says it is *not aware of malicious use in customer networks*. |
|---|---|
| KEV status | Not in CISA KEV based on the current Known Exploited Vulnerabilities Catalog. |
| Proof-of-concept availability | No 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. |
| EPSS | No 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 vector | CVSS: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 versions | 4.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 versions | Fixed 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 condition | Narrower 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 reality | I 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 / discovery | The 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. |
noisgate verdict.
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.
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.
What to do — in priority order.
- 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.
- Deny
OpenConfig.Setby policy — Apply per-RPC authorization and ensure no user or mapped identity is allowed to invokeOpenConfig.Setunless there is a clear operational need. Arista explicitly recommends this workaround for CVE-2024-27892; deploy within 30 days if you cannot patch immediately. - 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. - 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.
- 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.
- 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.
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.
#!/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"If you remember one thing.
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
- Arista Security Advisory 0099
- Arista Security Advisory 0099 PDF view
- Arista OpenMgmt gNMI client examples
- Arista OpenConfig configuration docs
- Containerlab vEOS notes on gNMI service
- CISA Known Exploited Vulnerabilities Catalog
- Rapid7 vulnerability entry mirroring advisory timeline
- Feedly CVE page noting no EPSS yet
What defenders are saying.
Crowdsourced verification outputs.
Results submitted by users who ran the verification payload against their environment.