Same protocol. Same malformed attribute. Five vendors go down. Four stay standing.
New BGP attribute parsing vulnerabilities are hitting the wire in 2026, and testing shows they don't affect every router equally. Juniper Junos OS, Nokia SR-OS, Extreme EXOS, OpenBGPd, and FRRouting are vulnerable. Cisco, MikroTik, Arista, Huawei, and Bird are not. Same route, same crafted update, completely different outcome depending on what sits in your rack.
WHAT ACTUALLY HAPPENED
The flaws live in how BGP implementations parse path attributes inside UPDATE messages. A malformed attribute reaches the parser, the affected implementation mishandles it, and the BGP process crashes. No route hijack required — just a peer willing to send the packet.
This is a control-plane bug, not a data-plane one. It doesn't steal traffic. It kills the process that tells your router where traffic should go — enough to drop every session that daemon manages, across your entire eBGP fabric at once.
WHY THIS MATTERS MORE THAN A SINGLE CVE
Most disclosures name one vendor. This one named five, and left four others untouched by the same test — a rare, direct answer to a question network teams rarely get to ask: does my specific BGP stack hold up, or am I inheriting risk from an assumption?
If your edge runs Juniper, Nokia, Extreme, OpenBGPd, or FRRouting, this is not theoretical. If it runs Cisco, MikroTik, Arista, Huawei, or Bird, you're clear on this flaw — but the next parsing bug could invert the list entirely. BGP security is a protocol-design problem as much as a vendor one.
WHAT TO DO NOW
INVENTORY YOUR BGP STACK — Know exactly which router OS and version terminates every eBGP session, not just your primary vendor.
CHECK VENDOR ADVISORIES DIRECTLY — Don't assume "not on this list" means "not affected." Confirm patch status with Juniper, Nokia, Extreme, and your FRRouting maintainers.
HARDEN SESSION ACCEPTANCE — TTL security, prefix filtering, and strict peer authentication reduce who can even attempt to send a malformed UPDATE your way.
MONITOR FOR UNEXPECTED SESSION RESETS — A BGP crash often looks like a flap before it looks like an attack. Treat repeated resets on one peer as an investigation, not noise.
DIVERSIFY WHERE IT MATTERS — Single-vendor core infrastructure is operationally simpler and a single point of systemic failure. Know which trade-off you made.
Multi-vendor networks are usually built for cost or capability. This is a reminder they can also be built for resilience against this exact kind of asymmetric flaw.
Do you actually know which BGP implementation sits behind every peering session in your network?