ISC DHCP’s OMAPI Bug Can Exhaust Server Memory

If an old ISC DHCP server still has its OMAPI management port enabled, check who can reach it. ISC has disclosed a memory-management bug that lets an unauthenticated remote attacker with access to that port drive the server’s memory usage upward without a bound.

The October 1 notice says the result can degrade system performance or cause the operating system’s out-of-memory killer to terminate dhcpd. All ISC DHCP branches are already end-of-life. ISC recommends restricting OMAPI access to trusted hosts and moving to Kea.

I went through the ISC DHCP-to-Kea move at work a few months ago. It took an evening on a Salt-managed, three-node setup. The configuration kept assigning the same IP addresses, followed by a switchover. There was not much drama to it.

Start with the management listener

This advisory concerns access to OMAPI, not an ordinary DHCP request from a client looking for an address. That distinction is worth checking before deciding how exposed a particular server is.

ISC’s OMAPI configuration guidance says the interface is disabled by default, although sample configurations often enable it. Defining omapi-port in the configuration opens the listener. The documented example uses port 7911; inspect the configuration actually loaded by your service rather than assuming that is the port in use.

I would trace that setting through any included files, confirm the listening socket, and review the firewall rules on the host and along the management path. A server being inside the network does not tell me whether guest devices, user workstations, or an unrelated service can reach its control port.

If OMAPI is unused, ISC recommends leaving it disabled. If something depends on it, identify that caller before changing access. Shared keys protect control requests, but the new advisory describes an unauthenticated memory-exhaustion problem and recommends restricting connections. A configured key is not a reason to skip the reachability check.

The Kea move did not require rebuilding everything

The environment I migrated has three hosts, runs without Docker, and uses keepalived to control which single node provides the service. That is the deployment arrangement; I am not describing a three-way active Kea cluster.

The move from ISC DHCP to Kea took an evening on the Salt-managed stack. Claude handled much of the migration work. The new configuration preserved the IP assignments, followed by a switchover, with keepalived keeping one node active at a time.

Having the configuration managed in Salt gave the work a familiar place to live. The migration did not have to become a container project or an excuse to replace the rest of the stack. For this environment, changing the DHCP implementation was enough.

That experience is one reason I would investigate the scope before assuming an ISC DHCP replacement needs a large project. An evening is what this particular migration took, not an estimate for an unfamiliar network.

Check what needs to survive your cutover

Preserving configured IP assignments is not the same as transferring every active dynamic lease. If your environment depends on that lease state, include it explicitly in the plan. Keepalived choosing an active service does not, by itself, establish how DHCP leases are stored or synchronized.

ISC’s migration guide separates configuration conversion, testing, lease migration, and cutover. Its Kea Migration Assistant translates configuration but does not convert lease files. It also does not carry over reservations created through OMAPI or manually stored in the lease file. Those need separate attention.

The guide identifies option-inheritance differences and different failover mechanisms as other things to review. I would compare the behavior the clients need: address assignments, subnet selection, router and DNS options, relay handling, and anything used by network booting. A configuration that parses is only the first check.

For validation, I would test a fresh client request as well as a renewal, on the networks the replacement must serve. Check the returned options and address, and decide how you will reverse the cutover before doing it.

The immediate task is to establish whether the OMAPI listener is reachable from places it should not be. After that, inventory the configuration that needs to move. You may find that replacing the unsupported service is considerably less work than the untouched configuration made it look.