External risk intelligence

Arista EOS S-BFD Kernel Crash Leading to Reboot

CVE advisorySeverity: CRITICAL (CVSS 9.2)

CVE-2026-121295

S-BFD (Seamless Bidirectional Forwarding Detection) is a network infrastructure protocol used for path monitoring between routers. While it operates over the network, it is typically restricted to internal peering links or private management networks between infrastructure devices, making public internet exposure uncommon in standard deployments.

Halo Surface Signal: 2 out of 5 — less likely to be public-facing.

External exposure likelihood

Horizon Alert

Summary of the vulnerability and why it matters

This advisory concerns a vulnerability in Arista EOS network devices configured for S-BFD, where a specially crafted network message could cause a device to crash and reboot. While the impact is a denial of service, the specific technology affected and its configuration requirements may limit its relevance to certain network environments.

A network message can crash specific devices.
Matters due to potential network disruption.
Confirm relevance and exposure for your infrastructure.

Attack Path

How an attacker could exploit the issue

An unauthenticated attacker could send a specially crafted S-BFD packet over the network to a vulnerable device. If the device is configured as an S-BFD peer, this malicious packet could trigger a kernel crash, leading to an unexpected device reboot.

Attackers need network access.
Triggered by sending a crafted S-BFD PDU.
Risk of unexpected device reboot.

Live Threat

Current exploitation, exposure, and threat context

On affected platforms running Arista EOS configured as S-BFD peers, an unauthenticated attacker could send a crafted S-BFD PDU to an initiator device. This crafted PDU could cause the kernel on the initiator device to crash, resulting in an unexpected device reboot.

Device kernel and operational state at risk.
Crafted S-BFD PDUs sent to initiator.
Unexpected device reboots causing service disruption.

Operational Fix

Recommended remediation, mitigation, and detection steps

The primary responsibility for addressing this vulnerability likely falls to network infrastructure or platform teams, given the nature of Arista EOS and S-BFD peering. The first practical step is to identify all Arista EOS devices configured as S-BFD peers, confirm their exposure and criticality, and then coordinate with the accountable owner for remediation.

Network infrastructure teams own remediation.
Verify S-BFD peer reachability and criticality.
Plan maintenance for affected devices.

Supplementary metadata

CVSS vector

Validate whether this threat affects your internet-facing exposure.

Halo Threat Intelligence helps prioritize remediation with Halo Surface Signal and H/A/L/O context. Start exposure validation with a free external attack surface trial.

Free EASM Trial See How Signal Works

Frequently asked questions

What is Arista EOS and S-BFD?

Arista EOS is the extensible operating system that powers Arista's high-performance network switches and routers. S-BFD, or Seamless Bidirectional Forwarding Detection, is a specialized network protocol running on top of EOS. It is primarily used by network engineers to rapidly monitor the health and connectivity of paths between infrastructure devices, ensuring that data traffic is rerouted quickly if a link fails.

What does CWE-1284 mean for CVE-2026-121295?

CWE-1284 refers to improper input validation during data processing. In the context of this CVE, it means the device's kernel fails to properly inspect the structure or contents of incoming S-BFD packets. Because the software does not correctly handle this malformed data, it triggers a critical error that forces the operating system to shut down and reboot unexpectedly.

How is this CVE-2026-121295 triggered?

The vulnerability is triggered when an attacker sends a specially crafted S-BFD Protocol Data Unit (PDU) directly to an Arista EOS device configured as an S-BFD initiator. If the device is not configured to use S-BFD peering, it will not process these packets in the vulnerable manner, meaning the bug cannot be triggered on devices where this feature is disabled.

Who should be concerned about this vulnerability?

Organizations running Arista EOS infrastructure should prioritize this. According to Halo Surface Signal, while this vulnerability is reachable over a network, S-BFD is typically restricted to internal peering links or private management networks rather than the public internet. Therefore, the risk is highest for those who expose these specific management interfaces to wider, less-trusted segments of their internal network.

What are the first steps to address this issue?

You should begin by auditing your network configuration to identify any Arista EOS devices where S-BFD peering is currently enabled. Once identified, evaluate the criticality of those specific links and coordinate with your network infrastructure team to plan a maintenance window for applying the necessary updates provided by the vendor.

References

www.arista.com/en/support/advisories-notices/security-advisory/25045…

Written by Nicholas Merritt

Nicholas Merritt is VP of Security Solutions at Halo Security. With more than 25 years across application security, vulnerability prioritization, and offensive security, he helps teams translate threat data into practical exposure validation and remediation focus. He authors Halo Threat Intelligence CVE advisories using Halo Surface Signal and H/A/L/O context to prioritize internet-facing risk.