ISC warns Kea DHCP bug can crash key services with a single remote message

ISC has disclosed a high-severity vulnerability in Kea DHCP that can let a remote attacker crash several Kea daemons by sending a specially crafted message to an exposed API socket or High Availability listener. The flaw is tracked as CVE-2026-3608, and ISC’s CNA score on NVD is 7.5 out of 10.

The issue affects more than just one daemon. ISC says a malicious message can cause kea-ctrl-agent, kea-dhcp-ddns, kea-dhcp4, or kea-dhcp6 to exit with a stack overflow error. In practice, that can knock out DHCP services, break IP assignment for new devices, and disrupt network operations until the affected service restarts or gets manually recovered.

This is a denial-of-service issue, not a confirmed remote code execution bug. Your sample overstates that part slightly by calling it “critical,” while the official scoring published through NVD lists it as high severity with a CVSS v3.1 vector of AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H.

ISC published fixed releases on March 25, 2026. The patched versions are Kea 2.6.5 and Kea 3.0.3. ISC announced both new releases alongside the disclosure on the oss-sec mailing list.

What the Kea flaw does

According to the official description in NVD, an attacker can send a maliciously crafted message over any configured API socket or HA listener and force the receiving daemon to exit with a stack overflow error. The bug affects Kea versions 2.6.0 through 2.6.4 and 3.0.0 through 3.0.2.

That means the attack does not depend on user interaction or valid credentials. It depends on network reachability to the relevant Kea listening interface. If those interfaces are exposed to untrusted networks, the path to service disruption becomes much easier. This last point is an inference from the official network attack vector and the affected listener types.

Affected versions and fixes

ISC’s announcement explicitly points users to the 2.6.5 and 3.0.3 downloads as the remedy for CVE-2026-3608.

Why this matters for admins

Kea often sits in a critical network role. When DHCP services fail, new clients may not receive IP addresses, DNS settings, or gateway information. That can quickly turn a single daemon crash into a wider service outage for offices, labs, cloud environments, or ISP deployments.

The strongest operational risk here is availability loss. NVD’s published CVSS vector shows no confidentiality or integrity impact, but it assigns high impact to availability. That matches the official description of daemons exiting on malformed input.

What admins should do now

• Upgrade Kea 2.6.x deployments to 2.6.5.
• Upgrade Kea 3.0.x deployments to 3.0.3.
• Check whether API sockets or HA listeners are reachable from untrusted networks.
• Restrict network access to those interfaces wherever possible.
• Prioritize internet-exposed or multi-tenant environments first.

I could verify the patched versions directly from ISC’s public disclosure trail. I could not verify the sample article’s specific workaround wording about TLS and mutual authentication from the official advisory page itself because the KB page content was not directly accessible in the fetched results here, so I would not state that exact workaround as confirmed unless we pull the advisory text itself.

FAQ