CVE-2025-32801: Kea DHCP Server RCE Vulnerability

CVE-2025-32801 Overview

CVE-2025-32801 affects Internet Systems Consortium (ISC) Kea Dynamic Host Configuration Protocol (DHCP) server. Configuration and API directives can be abused to load a malicious hook library into the running Kea process. Many common Kea deployments run as root, expose API entry points without authentication, and place control sockets in insecure filesystem paths. An attacker with local access to the control channel can leverage this behavior to execute arbitrary code in the context of the Kea process. The issue is tracked under CWE-94: Improper Control of Generation of Code.

Critical Impact
A local attacker with access to the Kea control socket or unsecured API endpoint can load arbitrary hook libraries, resulting in code execution—often as root—on the DHCP server.

Affected Products

ISC Kea versions 2.4.0 through 2.4.1
ISC Kea versions 2.6.0 through 2.6.2
ISC Kea versions 2.7.0 through 2.7.8

Discovery Timeline

2025-05-28 - CVE-2025-32801 published to the National Vulnerability Database (NVD)
2026-06-17 - Last updated in NVD database

Technical Details for CVE-2025-32801

Vulnerability Analysis

Kea supports a hook library mechanism that dynamically loads shared objects (.so files) to extend server functionality. Administrators configure hook libraries through the Kea configuration file or through control channel commands such as config-set and config-reload. The server does not restrict the filesystem paths from which hook libraries can be loaded, and it does not require authentication on the control channel by default.

An attacker who can reach the control socket or REST API can direct Kea to load an attacker-controlled shared object. When the library loads, its initialization routine executes inside the Kea process. Because operators frequently run Kea as root to bind privileged DHCP ports, the resulting code execution inherits root privileges.

The vulnerability is classified as code injection under [CWE-94]. It requires local access as reflected by the attack vector, but that access can be obtained through any low-privilege account that can read or write the control socket path.

Root Cause

The root cause is a combination of insecure defaults and missing input validation. Kea accepts arbitrary library paths through configuration directives without validating library origin, signature, or path restrictions. Default packaging often places the control socket in a world-accessible directory and leaves the REST API without authentication.

Attack Vector

An attacker first stages a malicious shared library on the target host in a location readable by the Kea process. The attacker then connects to the Kea control socket—typically a Unix domain socket—or the unauthenticated REST API. The attacker issues a config-set or equivalent command that references the malicious library through the hooks-libraries parameter. Kea calls dlopen() on the supplied path, invoking the library constructor and executing attacker code as the Kea user.

See the ISC Security Advisory CVE-2025-32801 for vendor technical details.

Detection Methods for CVE-2025-32801

Indicators of Compromise

Unexpected entries in the hooks-libraries section of the active Kea configuration referencing paths outside the vendor-installed hook directory.
New or modified .so files in world-writable directories such as /tmp, /var/tmp, or user home directories that are subsequently referenced by Kea.
Kea log entries showing successful config-set, config-reload, or library-reload API calls from unexpected sources.
Child processes or outbound network connections originating from the kea-dhcp4 or kea-dhcp6 process that do not match normal DHCP behavior.

Detection Strategies

Baseline the legitimate hook library list and alert on deviations detected during configuration audits.
Monitor process telemetry for dlopen() activity on Kea processes referencing non-standard library paths.
Correlate control socket access events with the identity of the connecting process to detect unauthorized clients.
Inspect Kea REST API access logs for config-set or config-write requests, especially from unauthenticated sources.

Monitoring Recommendations

Enable verbose Kea logging for the kea-dhcp-ddns and control channel loggers and forward logs to a central SIEM.
Monitor file integrity on /etc/kea/ and any directory listed in hooks-libraries for unauthorized changes.
Track network access to the Kea REST API port and restrict it to known management hosts.

How to Mitigate CVE-2025-32801

Immediate Actions Required

Upgrade Kea to a fixed release above the affected 2.4.x, 2.6.x, and 2.7.x ranges as documented in the ISC Security Advisory CVE-2025-32801.
Remove world access from the control socket path and place the socket in a directory owned by the Kea service account.
Enable authentication on the Kea Control Agent REST API and place it behind a firewall or listen only on 127.0.0.1.
Run Kea under a dedicated non-root user account with capabilities limited to binding DHCP ports (CAP_NET_BIND_SERVICE, CAP_NET_RAW).

Patch Information

ISC has published fixed releases addressing CVE-2025-32801. Refer to the ISC Security Advisory CVE-2025-32801 for the specific patched versions and upgrade guidance. Operators running any version in the 2.4.0–2.4.1, 2.6.0–2.6.2, or 2.7.0–2.7.8 ranges must upgrade.

Workarounds

Restrict the control socket directory permissions to 0700 and set ownership to the Kea service user only.
Disable the Kea Control Agent if it is not required for operations.
Apply mandatory access controls such as AppArmor or SELinux profiles that restrict dlopen() to a specific hook library directory.
Deploy filesystem monitoring on Kea configuration files and hook library directories to detect tampering.

bash

# Example: restrict Kea control socket directory
sudo install -d -o kea -g kea -m 0700 /var/run/kea
# Example: run Kea Control Agent bound to localhost only
# In kea-ctrl-agent.conf:
#   "http-host": "127.0.0.1",
#   "http-port": 8000,
#   "authentication": { "type": "basic", "clients": [ ... ] }