CVE-2026-119776: Medium severity vulnerability
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.
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Configuration
Configure OSPFv3 authentication trailers using "ipv6 ospf6 authentication".
FRRouting OSPFv3 (ospf6d) ipv6 ospf6 authentication = enabled - Compensating control
Configure the firewall to accept input for IPv6 protocol 89 (OSPF) only when packets have a link-local or multicast destination address.
Event History
Frequently Asked Questions
Who is exposed to this issue?
Deployments running any prior released version of FRRouting with OSPFv3 enabled are affected. The risk is that an unexpectedly distant IPv6 host may be able to establish an OSPFv3 adjacency.
What does an attacker need to exploit it?
An attacker needs the ability to send OSPFv3 packets to the affected router from an IPv6 host that would normally be considered too distant for an adjacency. The implementation fails to require both a link-local source address and an allowed link-local or OSPFv3 multicast destination address.
Does OSPFv3 authentication mitigate the issue?
Properly configured OSPFv3 authentication trailers under RFC 7166 prevent full exploitation. An attacker may still be able to consume CPU resources by causing authentication checks.
What should be checked when evaluating a fix?
A fix must validate the packet destination address as well as the source address. The referenced PR #23935 alone is not sufficient because it verifies only the source address.