CVE-2025-40779: ISC Kea · NULL Pointer Dereference
Affects ISC KeaSource CVE Database V5
Not known to be exploited · CVSS 7.5 High.
Data as of 26 Oct 2026, 07:57 UTC
- EPSS
- 0.5% chance of exploitation in 30 days – higher than 45% 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 27 Aug 2025
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 2026-10-26.
What to do
Affected software
| Product | Affected | Fixed in |
|---|---|---|
| ISC Kea | Affected
| Fixed in– |
AI-suggested
1. Upgrade ISC Kea DHCP server to a patched version once the vendor releases a fix addressing CVE-2025-40779. Monitor ISC advisories and security bulletins for updates. 2. Implement network-level filtering to restrict unicast DHCP requests to trusted clients only, using firewall rules or DHCP relay configurations to limit exposure. 3. Monitor DHCP server logs and system stability to detect abnormal crashes or assertion failures indicative of exploitation attempts. 4. Deploy redundancy and failover mechanisms for DHCP services to maintain availability in case of process crashes. 5. Conduct regular security assessments and penetration testing focusing on DHCP infrastructure to identify potential weaknesses. 6. Educate network administrators about this vulnerability and ensure incident response plans include DHCP service disruptions. 7. Consider isolating DHCP servers in dedicated network segments to reduce attack surface and limit impact scope.
Description
If a DHCPv4 client sends a request with some specific options, and Kea fails to find an appropriate subnet for the client, the `kea-dhcp4` process will abort with an assertion failure. This happens only if the client request is unicast directly to Kea; broadcast messages do not cause the problem. This issue affects Kea versions 2.7.1 through 2.7.9, 3.0.0, and 3.1.0.