Mixed IP Address Encoding

How Mixed IP Address Encoding Works

Mixed IP address encoding is a parser ambiguity problem, not a network transport problem. The same target address can be written using different textual forms inside one string, or across components of a request, and a lenient parser may normalise it differently from a filter, validator, proxy, or log pipeline. That mismatch is what makes the issue security-relevant.

In practice, the danger comes from disagreement over what the address actually is. One component may treat the input as a harmless internal or blocked destination, while another resolves it to a sensitive host. The term is closely related to alternate IP address encodings and to other cases of using multiple input interpretation layers in application security.

Why It Bypasses Validation and Filtering

Security controls often assume a single canonical representation of an IP address. Mixed encoding breaks that assumption by creating a gap between what the application thinks it saw and what the downstream resolver or network stack ultimately uses. That can let an attacker slip past deny rules, allow lists, SSRF protections, host checks, or logging controls that operate on the wrong normalised form.

This is especially dangerous when validation is split across layers, for example a web application, a reverse proxy, and an outbound fetcher. A control that checks only the raw string may miss the real destination, while a later component that performs its own parsing will still connect. A useful defensive reference point is the CWE Top 25 Guide, because the issue sits in the family of parsing and canonicalisation weaknesses that routinely lead to security bypasses.

Common Places the Risk Appears

Mixed encoding matters wherever software accepts user-controlled destinations, especially URL fetchers, redirect handlers, proxy features, webhook systems, SSRF-prone integrations, and security tooling that inspects text before forwarding traffic. It also appears in logging and alerting paths, where the recorded value may not match the address that was actually contacted.

Organisations should assume exposure is broader when IP parsing is duplicated across components. If one system accepts dotted decimal, hexadecimal, octal, shortened, embedded, or otherwise non-standard forms and another interprets them differently, the security boundary becomes inconsistent. The same concern applies when address handling is buried in libraries or helper functions rather than centralised policy.

Defensive Handling and Review

The safest pattern is to normalise once, compare once, and reject anything that is not a single unambiguous canonical representation. Defenders should align input validation, policy enforcement, and logging on the same parsing rules, rather than allowing each layer to reinterpret the address independently. For analysts, safe inspection tools can help expose the real value behind mixed encodings; CyberChef for Analysts Guide is useful when you need to decode and compare suspicious address forms offline.

When mixed encoding is detected, treat it as a sign that the request may be trying to evade a filter or route to a protected host. Review the affected validation path, the downstream resolver behaviour, and any logs or proxy traces that may have recorded the raw string without showing the final interpreted destination.

Related resources from NHI Mgmt Group

• What is the difference between an IP address and an identity signal?
• What breaks when DTLS session state is tied to IP address and port?
• How should security teams model access when a logical service cannot be tied to a single host or IP address?
• What breaks when organisations rely on cookies or IP address alone to identify suspicious sessions?