CVE-2024-34088: frr · NULL Pointer Dereference
Affects frrSource CVE Database V5
Not known to be exploited · CVSS 7.5 High.
Data as of 26 Oct 2026, 10:12 UTC
- EPSS
- 0.6% chance of exploitation in 30 days – higher than 52% of CVEsExploit Prediction Scoring System: the likelihood attackers will use this flaw soon.
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:HExploitation evidence
Disclosed: evidence found.
CVE published 30 Apr 2024
Detectable: no evidence on record.
No public nuclei template indexed
Weaponised: no evidence on record.
No public exploit code indexed in Metasploit or Exploit-DB
Exploited in the wildExploited: no evidence on record.
Not in CISA KEV and no source reports exploitation
Observed by OffSeq MirageSeen by Mirage: no evidence on record.
No attack traffic recorded by OffSeq Mirage sensors
A missing step is not evidence of safety. Sources: cve.org (opens in a new tab), the Metasploit, Exploit-DB and nuclei-templates index as of 26 Oct 2026.
What to do
Affected software
| Product | Affected | Fixed in |
|---|---|---|
GitHubfrrouting/frrpkg:github/frrouting/frrOther threats | Affected
| Fixed in– |
Check your own hosts for these packages with threat-finder (opens in a new tab), our free open-source scanner.
AI-suggested
To mitigate CVE-2024-34088, organizations should first monitor for updates from the FRRouting project and apply patches as soon as they become available. In the absence of an official patch, consider the following specific mitigations: 1) Implement network segmentation and access controls to limit exposure of FRR OSPF daemons to untrusted networks, reducing the attack surface. 2) Deploy runtime monitoring and alerting on OSPF daemon crashes to enable rapid detection and response. 3) Use process supervision tools (e.g., systemd, monit) to automatically restart the OSPF daemon upon failure, minimizing downtime. 4) Review and harden configuration to restrict OSPF neighbors to trusted devices only, preventing unauthorized triggering of the vulnerability. 5) Conduct code audits or apply temporary source code fixes to add NULL pointer checks around get_edge() calls if feasible. 6) Employ network-level protections such as firewall rules or intrusion prevention systems to detect and block malformed OSPF packets that might trigger the bug. These targeted actions go beyond generic advice and help reduce the risk and impact until an official patch is released.
Description
In FRRouting (FRR) through 9.1, it is possible for the get_edge() function in ospf_te.c in the OSPF daemon to return a NULL pointer. In cases where calling functions do not handle the returned NULL value, the OSPF daemon crashes, leading to denial of service.