Using Alternative IP Address Encodings is representing the same IP address in another format to evade filters or confuse logs. Attackers use decimal, hexadecimal, octal, mixed, or shortened forms to slip past weak validation. Defenders should normalise inputs, compare parsed values, and enforce consistent address handling at gateways and applications.
What Alternative IP Address Encodings Are
Alternative ip address encodings are different textual or numeric ways to write the same address, such as decimal, hexadecimal, octal, mixed, or shortened forms. Security tools that only compare strings can miss them, so robust handling depends on parsing, normalising, and comparing the underlying address value.
How They Bypass Weak Validation and Filters
The danger is not that the address changes, but that the representation changes. Filters that look for a literal dotted-quad IPv4 form, exact hostname patterns, or simple denylist matches can be bypassed when an attacker supplies an equivalent value in another encoding. That can affect input validation, logging, allowlist enforcement, and downstream routing decisions.
This is why normalisation needs to happen before policy checks, not after. If one component accepts a shortened or mixed-format address while another interprets it differently, the result can be inconsistent security decisions and hard-to-audit request paths.
Why Consistent Parsing Matters for Defenders
Defensive handling should treat the parsed address as the source of truth, not the original text. Gateways, reverse proxies, applications, and logging pipelines should all interpret the same input in the same way so that access decisions, telemetry, and incident review remain aligned.
That means normalising before comparison, rejecting ambiguous forms where possible, and ensuring every component in the request path uses the same address parser. Without that consistency, a request may be allowed by one layer, blocked by another, or recorded in logs in a form that obscures what actually happened.
Where This Shows Up in Attacks
Alternative encodings often appear in reconnaissance, SSRF payloads, open redirect abuse, proxy bypass attempts, and log evasion. The technique is most effective where controls rely on superficial string matching or where different services disagree about how to interpret the same address.
It is also useful when attackers want to reach internal or restricted network ranges indirectly. A weak control boundary can turn a harmless-looking string into a request that resolves to a sensitive destination once some downstream component parses it.
Risk and Threat Considerations
Alternative IP encodings create a validation gap: one layer may see an allowed value while another resolves the same input to a blocked or sensitive address. That mismatch can undermine filtering, routing controls, logging fidelity, and abuse detection.
Failure mechanism: Security checks are applied to the text form instead of the canonical parsed address, or different components parse the same input differently. An attacker exploits that inconsistency to bypass allowlists, reach internal targets, or disguise request origin in logs.
Impact: Access controls can be bypassed, SSRF and proxy abuse become easier, and investigations may miss the real destination or source because telemetry recorded an ambiguous representation rather than the effective address.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
MITRE ATT&CK addresses the attack and risk surface, while CIS Controls v8 and OWASP ASVS set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| CIS Controls v8 | CIS-16 — Application Software Security | Alternative encodings exploit weak input validation in request handling. |
| Recommendation — Validate and canonicalise IP inputs before policy checks and routing decisions. | ||
| OWASP ASVS | V4 — API and Web Service | API and web service inputs must be parsed consistently to prevent address-filter bypass. |
| V13 — Configuration | Secure configuration includes consistent handling of network-relevant inputs across components. | |
| Recommendation — Apply canonical parsing and reject ambiguous IP representations at API boundaries. Configure gateways and applications to use the same address-handling rules and parser. | ||
| MITRE ATT&CK | T1016 — System Network Configuration Discovery | Attackers often use address-format tricks during internal network discovery and targeting. |
| Recommendation — Map suspicious address-encoding activity to discovery behaviour and investigate follow-on targeting. | ||
Practitioner Guidance
What to watch for: Treat any IP literal that uses hexadecimal, octal, mixed notation, or unusual shortening as suspicious until it has been normalised by a trusted parser. The practical goal is not just to detect odd syntax, but to ensure every control evaluates the same canonical value.
Practitioner takeaway: If one layer validates the string and another layer uses the parsed address, you do not have a single policy decision, you have two potentially different ones.
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?
- Who is accountable when an AI credit model using alternative data produces an unfair outcome?
- How should security teams model access when a logical service cannot be tied to a single host or IP address?
Deepen Your Knowledge
Free weekly newsletter
Subscribe to the NHI & AI Identity Journal
The latest on NHI and Agentic AI security – articles, research, breaches, news and events every week.
Bonus 33% off our NHI Course when you subscribe.
Reviewed and updated by the NHIMG editorial team on October 17, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org