What are the signs that DHCP option 121 is being used in a way that may expose a client?

What DHCP option 121 is doing when it starts exposing the client

DHCP option 121 is classless static routing, so the client is receiving route instructions rather than just an address and default gateway. The exposure begins when those routes quietly expand what the client can reach, especially if they override expected pathing or introduce access to networks the client should not normally see. That makes the option a routing trust issue, not merely a configuration detail.

Operationally, the warning signs are usually visible in the client’s route summary, routing table, or interface status. If a DHCP lease adds specific prefixes that were not part of the host’s expected network design, the client may be steered toward infrastructure, remote access overlays, or translation ranges that change where traffic goes and who can observe it.

What to look for in the lease and route table

The clearest sign is the presence of classless_static_route entries in the DHCP summary for an interface, especially when the prefixes point to CGNAT space, Tailscale ranges, or other unexpected destinations. That does not prove malicious activity, but it does show the network is supplying host routes the client should review carefully.

Two practical checks matter most. First, compare the learned prefixes against the intended network design, including whether they should be reachable from that segment at all. Second, check whether the new route has higher precedence than the path the client would normally use, because an apparently harmless route can still redirect traffic away from the intended gateway.

• Unexpected route entries appear only after DHCP renewal or interface bounce.
• The route points to a destination range the host has no obvious business reason to use.
• More specific DHCP routes override a broader default or corporate routing path.
• The route changes how sensitive traffic leaves the endpoint, even if the address itself stays the same.

Why this matters and what practitioners should verify

Any time DHCP is instructing a client to reach additional networks, the exposure is about control of traffic paths. That can be legitimate for split tunnelling, remote access, or segmented internal services, but it becomes risky when the route set is broader than expected, undocumented, or inconsistent across hosts. The issue is usually route authority and reachability, not just connectivity.

Administrators should verify the source of the route, the reason it exists, and whether the client should be able to reach that prefix from its current trust zone. If the route is part of a known design, document the intended precedence. If it is not, treat it as a configuration anomaly and investigate the DHCP server, relay, scope, or downstream network policy before assuming the client is safe.

• Confirm whether the route was intentionally delivered by the DHCP scope for that segment.
• Check whether the route exists on other clients or only on a subset of hosts.
• Validate that the next hop, prefix length, and precedence match the approved design.
• Review whether the route opens a path to internal services, private overlays, or egress paths that should remain isolated.

Risk and Threat Considerations

When option 121 is misused or misconfigured, the risk is silent traffic redirection. A client may follow a route it did not expect, sending traffic through a network path that exposes internal communications, undermines segmentation, or enables interception and lateral reach that the operator did not intend.

Failure mechanism: DHCP-delivered routes can override the client’s normal forwarding choice, so a more specific prefix wins even when it was not meant to exist for that host or network segment. If the route lands in an unexpected private, overlay, or translation range, the client may be steered into an unintended trust boundary.

Impact: Sensitive traffic can leave the intended route, remote management or internal-only services may become reachable, and troubleshooting becomes harder because the host appears correctly configured from the DHCP perspective. In a worse case, a malicious or compromised network path can use the route to create a foothold for interception or abuse.

Practitioner Guidance

What to verify: Treat any DHCP option 121 change as authoritative only after you confirm the prefix list, next hop, and precedence against the intended network diagram. A route that looks valid on the wire can still be wrong for that host, VLAN, or trust zone.

Decision rule: If the route points to a range the client was not meant to reach, investigate the DHCP source and routing policy before assuming the client is merely misconfigured. If the route is expected but unusually specific, document why it must outrank the normal path and who approved it.

Practitioner takeaway: The key judgment is not whether DHCP option 121 exists, but whether the learned routes change the client’s trust boundary or traffic precedence in a way the environment actually intended.

Related resources from NHI Mgmt Group

• What are the signs that an identity provider account may have been used in an unauthorized way?
• What are the signs that an iframe is being used in an unsafe way?
• What are the signs that an SSH client may be used to exfiltrate credentials through DNS traffic?
• What are the signs that client side group based rendering is being used too broadly?