Arista EOS CVE-2025-54546

Exploitation requires a valid but restricted user account with SSH access to the affected Arista platform, plus SSH TCP/port forwarding being permitted for that account; the attacker then forwards connections through the device to reach services bound to host-internal (e.g. loopback/management) interfaces that the restricted role is not authorized to access. Limiting factors: the attacker must already be authenticated (PR:L - not an unauthenticated internet attack), SSH forwarding must not be disabled, and realistic impact depends on which internal services are actually listening and reachable on the specific affected platform/version listed in Arista advisory 22538.

The supplied CVSS 3.1 vector (AV:N/AC:H/PR:L/UI:N/S:U/C:H/I:H/A:H, base 7.5) describes a network-reachable but authenticated flaw: PR:L confirms the attacker must already hold a (restricted) account, and AC:H implies some conditions beyond attacker control. No EPSS score, KEV listing, or public POC was provided, so by the precision rules this is 'no public exploit identified at time of analysis.' The absence of exploitation telemetry combined with the authentication requirement (PR:L) places this below the tier of internet-facing unauthenticated RCE; it is primarily a privilege/access-control boundary bypass affecting multi-user Arista platforms. One signal to flag: Arista rated full C:H/I:H/A:H, but the description and the 'Information Disclosure' tag point mainly at unauthorized access to internal services (a confidentiality/access-control issue), so the blanket High integrity and availability impacts are not clearly justified by the one-line description - verify scope of reachable internal services with the Arista advisory. This is a 'patch in normal cycle' item for Arista operators who provision restricted SSH accounts, not an emergency.

An organization grants a user a restricted shell/account on an Arista platform intending to limit them to a narrow set of functions. The user opens an SSH session and requests TCP port forwarding, tunneling through the device to services bound to the host's internal/loopback interfaces that the restricted role was never meant to reach, thereby bypassing the intended access control. No public exploit code is available, but the technique requires only a standard SSH client.