Author: CyberDudeBivash
Powered by: CyberDudeBivash Brand | cyberdudebivash.com
Related:cyberbivash.blogspot.com

Published by CyberDudeBivash • Date: Oct 31, 2025 (IST)

Attackers Can Crash Your DHCP Server Instantly with a Malformed Hostname

CVE-2025-11232 affects ISC Kea DHCPv4: a crafted DHCP packet with invalid/“malformed” hostname content can make kea-dhcp4 exit unexpectedly (DoS) when three config flags are set a certain way. Vendor fix is out; a one-line config tweak mitigates immediately. CyberDudeBivash Ecosystem:Apps & Services · Threat Intel (Blogger) · CryptoBivash · News Portal · Subscribe: ThreatWire

TL;DR — Patch or Flip One Line Now

What: Remote, unauthenticated DoS against kea-dhcp4 via malformed hostname content in a DHCP request (e.g., option 12 path). Server exits under specific config.
Affected: Kea 3.0.1 and 3.1.1–3.1.2 (per distro trackers mirroring ISC).
Fix: Upgrade to 3.0.2 or 3.1.3.
Workaround (safe & instant): Set "hostname-char-replacement": "x" (any non-empty) — effective regardless of other settings.

What’s the Bug?

In certain configurations, Kea’s DHCPv4 hostname validation can trigger an assert/path that causes the daemon to exit when a client sends specific option content (invalid characters in a “hostname” field). This creates a network-wide outage risk: no leases, renewals, or option delivery until the service restarts. CVSS 7.5 (AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H).

When Are You Vulnerable? (3 Flags)

You’re impacted only if all the following hold (defaults noted by vendor):

"hostname-char-set" left at default: "[^A-Za-z0-9.-]"
"hostname-char-replacement" is empty (default)
"ddns-qualifying-suffix" is not empty (default is empty)

DDNS does not have to be enabled for the crash to occur. Under these conditions, a crafted request can force kea-dhcp4 to exit.

Detections & Hunts (SOC/NOC)

Quick Signals

Service restarts: Spikes of kea-dhcp4 exit/start messages in syslog/journal; lease assignment gaps aligned to exits.
Packet traces: Bursts of DHCPDISCOVER/DHCPREQUEST containing non-RFC 952/1123 hostname characters shortly before a crash. (Hostname is typically DHCP option 12 in v4.)
Client impact: Many clients falling back to APIPA (169.254.0.0/16) or stuck at “Obtaining IP address”.

Example Hunts (conceptual)

# Syslog hunt: Kea exits/restarts
journalctl -u kea-dhcp4 | egrep -i "exit|segfault|assert|DHCP4_.*(START|SHUTDOWN)"

# Tshark: show DHCP packets whose option 12 (host name) contains invalid chars
tshark -Y 'bootp.option.type == 12 && frame matches "[^A-Za-z0-9.-]"' -T fields -e frame.time -e ip.src -e bootp.option.hostname

# Correlate crash window to packet source IP/MAC (if visible) and switchport

Mitigation & Patch Checklist

Immediate safe workaround (no reboot required): Set "hostname-char-replacement": "x" (any non-empty value) in Kea DHCPv4 config; reload Kea. **This alone prevents the crash**, regardless of the other two flags.
Patch to fixed builds: Upgrade Kea to 3.0.2 or 3.1.3 depending on your branch.
Validate: Confirm new version and that kea-dhcp4 survives malformed hostnames (test in lab with negative cases).
Edge controls: If patching is delayed, rate-limit or ACL DHCP to trusted L2 domains; monitor for first-seen MACs issuing malformed hostnames.
Observe: Add alerts for Kea process exits, lease-grant drop, and repeated malformed hostnames from a single source.

Hardening Kea DHCPv4

Sanitize inputs: Keep hostname-char-replacement non-empty even post-patch; enforce conservative hostname-char-set.
DDNS settings: If you must use ddns-qualifying-suffix, ensure replacement is set and monitor for invalid labels.
Service supervision: Run Kea under a watchdog (systemd Restart=on-failure) but remember this masks targeted DoS unless also alerting.
Network hygiene: DHCP should not traverse untrusted L2 segments; isolate guest VLANs; enable rogue DHCP detection on switches/APs.
Change control: Document version/flags; schedule periodic config linting; practice lease-service failover drills.

FAQ

Is there public exploitation or PoC?

As of Oct 31, 2025, ISC states they are not aware of active exploits. Treat as high-risk DoS and patch anyway.

Which versions are affected?

Kea 3.0.1 and 3.1.1–3.1.2 (mirrored in Ubuntu/Red Hat/GitHub trackers). Fixed in 3.0.2/3.1.3.

Does this impact ISC DHCP (legacy) or Windows DHCP?

No — this advisory is specific to Kea DHCPv4. (Separate vendors/devices have had malformed-DHCP issues historically, but this CVE is about Kea.)

What about dnsmasq?

Different codebase. Dnsmasq has had unrelated bugs in the past, but they are not this CVE. Stick to Kea guidance here.

Sources

ISC — CVE-2025-11232: “Invalid characters cause assert” (Workaround + fixed versions).
Ubuntu CVE tracker — affected versions & config conditions.
Red Hat CVE page — summary & conditions.
Nessus/Tenable plugin note — mirrors ISC guidance.
Roundups noting malformed-hostname crash path in Kea.

CyberDudeBivash — Services, Apps & Ecosystem

Network Exposure Reviews (DHCP/DNS segmentation, rogue DHCP detection)
Incident Response & Monitoring (Kea crash hunts, syslog/SIEM rules)
Config Governance for Kea/DDNS (safe hostname policies, rollout playbooks)

Apps & Products · Consulting & Services · ThreatWire Newsletter · CyberBivash (Threat Intel) · News Portal · CryptoBivash

Edureka: Network & Linux IR Kaspersky: Server Security AliExpress WW Alibaba WW

Ecosystem: cyberdudebivash.com | cyberbivash.blogspot.com | cryptobivash.code.blog | cyberdudebivash-news.blogspot.com | ThreatWire

#CyberDudeBivash #CyberBivash #DHCP #Kea #CVE202511232 #Hostname #DoS #Networking #Linux #ThreatWire

Cyberdudebivash