Bug 2566943 (CVE-2026-119776)

Summary: CVE-2026-119776 frr: frr: Unauthorized routing adjacency establishment via missing OSPFv3 address validation
Product: [Other] Security Response Reporter: OSIDB Bzimport <bzimport>
Component: vulnerabilityAssignee: Product Security <prodsec-ir-bot>
Status: NEW --- QA Contact:
Severity: high Docs Contact:
Priority: high    
Version: unspecifiedCC: echaudro, fleitner, ktraynor, rhel-process-autobot, rkhan, sfaye, watson-tool-maintainers
Target Milestone: ---Keywords: Security
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: ---
Doc Text:
A flaw was found in FRRouting. The Open Shortest Path First version 3 (OSPFv3) implementation does not validate that incoming network packets originate from and are destined for expected local network addresses. A remote attacker can exploit this flaw by sending specially crafted packets from a distant network to establish unauthorized routing adjacencies. Successful exploitation may allow the attacker to manipulate network routing or cause a Denial of Service (DoS) by exhausting system resources.
 Story Points: ---
Clone Of: Environment:
Last Closed: Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Bug Depends On: 2567283    
Bug Blocks:    

Description OSIDB Bzimport 2026-11-04 14:25:40 UTC 
In all prior released versions of FRRouting, the OSPFv3 (for IPv6) implementation does not check that OSPFv3 packets have a link-local source address and either a link-local destination or one of the protocol multicast destination groups.  This may enable malicious actors to establish OSPFv3 adjacencies from unexpectedly, distant IPv6 hosts. Proper usage of OSPFv3 authentication trailers (RFC 7166, as is best practice) prevents full exploitation of this issue, though may allow a malicious actor to waste CPU on authentication checks.



Note the linked PR #23935 is not sufficient to fix the issue as it only verifies the source address. It is the destination address that must be checked.