Safeguard
Research•

How does DHCP work and what are its security risks?

DHCP hands out IP addresses in four messages with no built-in authentication. Learn the exchange, how rogue servers abuse it, and which controls help.

Safeguard Security Team
5 min read

The Dynamic Host Configuration Protocol (DHCP) automatically gives a device an IP address and network settings when it joins a network. It uses a four-message exchange and, by design, has no strong authentication. Anyone who answers first can tell a device where its gateway and DNS servers are, so networks need controls around it.

What does DHCP do?

RFC 2131, the standard that defines DHCP, calls it a framework for passing configuration information to hosts on a TCP/IP network. It builds on the older BOOTP and adds automatic allocation of reusable network addresses and additional configuration options. An address is given for a finite lease. The client may extend the lease with later requests, and it may release the address back to the server when done.

The settings a client receives can include more than its address: typically a subnet mask, a default gateway and the DNS servers to use.

What are the four messages?

RFC 2131 describes the exchange:

  1. DHCPDISCOVER. The client broadcasts on its local subnet to find available servers.
  2. DHCPOFFER. A server answers with an offer of configuration parameters. More than one server may answer.
  3. DHCPREQUEST. The client picks one offer and requests it, which also tells other servers that their offers are declined. The same message type is used to confirm an address after a reboot or to extend a lease.
  4. DHCPACK. The chosen server confirms the committed address and parameters.

If a server decides a client's idea of its address is wrong, for example because the client moved to a new subnet, it sends DHCPNAK.

Because the first message is a broadcast, every device on the local network segment can hear it. Across subnets, a relay agent forwards the messages to a central server.

Why is it a security concern?

RFC 2131 is direct about this. Its security section says DHCP is built on UDP and IP, which are inherently insecure, and concludes that DHCP in its current form is quite insecure. It then lists two threats:

  • Unauthorized DHCP servers may be easily set up. Such servers can send false and potentially disruptive information to clients: incorrect or duplicate addresses, incorrect routing information including spoof routers, and incorrect DNS servers such as spoof name servers. Once that seed information is in place, an attacker can further compromise the affected systems.
  • Malicious clients can masquerade as legitimate clients and retrieve information meant for them. With dynamic allocation, a malicious client could also acquire many addresses and exhaust the pool.

A constructed example

A hotel's conference center network has 200 addresses in its pool. During a trade show, an attendee plugs in a small travel router with its own DHCP server turned on, by accident. Some laptops get an answer from it first. They receive the travel router as the default gateway and an unknown DNS server. Web pages fail to load for those people, and a helpdesk spends an hour finding out why. If the same device were set up on purpose, the same position would let its owner watch or redirect their traffic.

What controls help?

The RFC predates modern switch features, so this list goes beyond it from general network practice, but it follows the same threat model:

  • Switch-level DHCP controls that only accept server replies on trusted ports. Many managed switches call this DHCP snooping.
  • Port security or network access control, so unknown devices cannot join wired ports and wireless networks freely.
  • Monitoring for a second DHCP server on any segment, and for lease pool exhaustion.
  • Reservations for servers and printers, so important devices keep stable addresses.
  • Logs of leases with time stamps, so you can map an IP address to a device at a point in time during an investigation.

How to check or apply this

  1. List all DHCP servers on your network, and which segments they serve. Any unexpected one is a finding.
  2. On managed switches, check whether trusted-port filtering for DHCP is enabled on access ports, and fix it where it is not.
  3. Check lease time. Short leases on guest networks make address reuse faster, but make logs more important.
  4. Keep lease logs for as long as your incident response needs, and confirm you can answer "who had this address at 14:05 yesterday?".
  5. Alert when the pool is above 80 percent used.
  6. Test it: connect a test device with a DHCP server in a lab VLAN and confirm the switch drops its replies.

Quick check

Does DHCP authenticate clients or servers?

Not in its basic form. RFC 2131 describes it as quite insecure in its current form, which is why network-level controls are used around it.

What is a lease?

The period during which a client may use an assigned address. The client can renew it with further requests or release it back to the server.

Sources

Last reviewed: 18 October 2026.

Never miss an update

Weekly insights on software supply chain security, delivered to your inbox.

Self-healing security runs on Safeguard.

Your first fix PR is minutes away.

No sales call required, even your agent can complete the purchase over MCP.