CWE-1389: Incorrect Parsing of Numbers with Different Radices

Extended Description

Frequently, a numeric input that begins with "0" is treated as octal, or "0x" causes it to be treated as hexadecimal, e.g. by the inet_addr() function. For example, "023" (octal) is 35 decimal, or "0x31" is 49 decimal. Other bases may be used as well. If the developer assumes decimal-only inputs, the code could produce incorrect numbers when the inputs are parsed using a different base. This can result in unexpected and/or dangerous behavior. For example, a "0127.0.0.1" IP address is parsed as octal due to the leading "0", whose numeric value would be the same as 87.0.0.1 (decimal), where the developer likely expected to use 127.0.0.1. The consequences vary depending on the surrounding code in which this weakness occurs, but they can include bypassing network-based access control using unexpected IP addresses or netmasks, or causing apparently-symbolic identifiers to be processed as if they are numbers. In web applications, this can enable bypassing of SSRF restrictions.

Code Examples & CVEs

Demonstrative Examples

The below demonstrative example uses an IP validator that splits up an IP address by octet, tests to ensure each octet can be casted into an integer, and then returns the original IP address if no exceptions are raised. This validated IP address is then tested using the "ping" command.

If run_ping() were to be called with one or more zero-prepended octets, validate_ip() will succeed as zero-prepended numerical strings can be interpreted as decimal by a cast ("012" would cast to 12). However, as the original IP with the prepended zeroes is returned rather than the casted IP, it will be used in the call to the ping command. Ping DOES check and support octal-based IP octets, so the IP reached via ping may be different than the IP assumed by the validator. For example, ping would considered "0127.0.0.1" the same as "87.0.0.1".

BadPython

import subprocess 					   					  def validate_ip(ip: str): 					   					    split_ip = ip.split('.') 						if len(split_ip) > 4 or len(split_ip) == 0: 						 						  raise ValueError("Invalid IP length") 						 						 						for octet in split_ip: 						 						  try: 						   						    int(octet, 10) 						   						  except ValueError as e: 						   						    raise ValueError(f"Cannot convert IP octet to int - {e}") 						   						 						 						# Returns original IP after ensuring no exceptions are raised 						return ip  					   					   					  def run_ping(ip: str): 					   					    validated = validate_ip(ip) 						# The ping command treats zero-prepended IP addresses as octal 						result = subprocess.call(["ping", validated]) 						print(result)

This code uses a regular expression to validate an IP string prior to using it in a call to the "ping" command.

Since the regular expression does not have anchors (CWE-777), i.e. is unbounded without ^ or $ characters, then prepending a 0 or 0x to the beginning of the IP address will still result in a matched regex pattern. Since the ping command supports octal and hex prepended IP addresses, it will use the unexpectedly valid IP address (CWE-1389). For example, "0x63.63.63.63" would be considered equivalent to "99.63.63.63". As a result, the attacker could potentially ping systems that the attacker cannot reach directly.

BadPython

import subprocess 					  import re 					   					  def validate_ip_regex(ip: str): 					   					    ip_validator = re.compile(r"((25[0-5]|(2[0-4]|1\d|[1-9]|)\d)\.?\b){4}") 						if ip_validator.match(ip): 						 						  return ip 						 						else: 						 						  raise ValueError("IP address does not match valid pattern.") 						 					   					 					def run_ping_regex(ip: str): 				       						validated = validate_ip_regex(ip) 						# The ping command treats zero-prepended IP addresses as octal 						result = subprocess.call(["ping", validated]) 						print(result)

Consider the following scenario, inspired by CWE team member Kelly Todd. Kelly wants to set up monitoring systems for his two cats, who pose very different threats. One cat, Night, tweets embarrassing or critical comments about his owner in ways that could cause reputational damage, so Night's blog needs to be monitored regularly. The other cat, Taki, likes to distract Kelly and his coworkers during business meetings with cute meows, so Kelly monitors Taki's location using a different web site. Suppose /etc/hosts provides the site info as follows:

The entry for night.example.com has a typo "010" in the first octet. When using ping to ensure the servers are up, the leading 0 causes the IP address to be converted using octal. So when Kelly's script attempts to access night.example.com, it inadvertently scans 8.1.0.8 instead of 10.1.0.8 (since "010" in octal is 8 in decimal), and Night is free to send new Tweets without being immediately detected.

BadOther

taki.example.com 10.1.0.7 					  night.example.com 010.1.0.8

Observed CVE Examples (7)

CVE-2021-29662

Chain: Use of zero-prepended IP addresses in Perl-based IP validation module can lead to an access control bypass.

View Details

CVE-2021-28918

Chain: Use of zero-prepended IP addresses in a product that manages IP blocks can lead to an SSRF.

View Details

CVE-2021-29921

Chain: Use of zero-prepended IP addresses in a Python standard library package can lead to an SSRF.

View Details

CVE-2021-29923

Chain: Use of zero-prepended IP addresses in the net Golang library can lead to an access control bypass.

View Details

CVE-2021-29424

Chain: Use of zero-prepended IP addresses in Perl netmask module allows bypass of IP-based access control.

View Details

CVE-2016-4029

Chain: incorrect validation of intended decimal-based IP address format (CWE-1286) enables parsing of octal or hexadecimal formats (CWE-1389), allowing bypass of an SSRF protection mechanism (CWE-918).

View Details

CVE-2020-13776

Mishandling of hex-valued usernames leads to unexpected decimal conversion and privilege escalation in the systemd Linux suite.

View Details

Source-backed guidance

Additional facts reviewed against primary or authoritative security sources.

Verify controls for CWE-1389 with SSDF evidence

Use NIST SSDF verification and vulnerability-response practices to detect CWE-1389, Incorrect Parsing of Numbers with Different Radices, throughout the product lifecycle. Derive review questions, static or dynamic checks, and negative tests from the CWE's causal behavior; define the components and lifecycle stages each check covers; and retain findings with enough evidence to distinguish the root cause from symptoms and impacts. Track escapes and false negatives, then improve the verification plan after every confirmed occurrence.

NIST SP 800-218 Secure Software Development Framework — National Institute of Standards and Technology

Apply Enforcement by Conversion controls for Incorrect Parsing of Numbers with Different Radices

MITRE associates mitigation with Implementation; the listed strategies include Enforcement by Conversion, and Input Validation; documented detection approaches include Automated Static Analysis. Use these source-defined anchors to turn CWE-1389 into implementation, review, and verification checks for the affected component.

CWE-1389: Incorrect Parsing of Numbers with Different Radices — MITRE CWE

Triage CWE-1389 against known exploitation evidence

Use CISA's Known Exploited Vulnerabilities catalog to test whether a vulnerability mapped to CWE-1389, Incorrect Parsing of Numbers with Different Radices, has evidence of exploitation in the wild. Confirm the CVE-to-CWE root-cause mapping independently before attaching the example, then capture the affected product, required action, and remediation deadline. A missing KEV match is not evidence that the weakness is unexploited, and a KEV entry must not be generalized to every occurrence of this CWE.

Known Exploited Vulnerabilities Catalog — Cybersecurity and Infrastructure Security Agency

Apply precise root-cause mapping to CWE-1389

Apply MITRE's full root-cause mapping guidance when using CWE-1389, Incorrect Parsing of Numbers with Different Radices. Separate weakness language from attacker prerequisites and technical impact, check the entry's abstraction and vulnerability-mapping notes, and prefer the most specific Base or Variant supported by the evidence. Record the rejected alternatives and require an independent review before the mapping is used for remediation trends or program metrics.

CVE to CWE Root Cause Mapping Guidance — MITRE CWE

Validate CWE-1389 with root-cause mapping checks

Apply MITRE's root-cause mapping quick tips to CWE-1389, Incorrect Parsing of Numbers with Different Radices. Confirm the finding describes the causal weakness rather than an impact or attack pattern, compare the abstraction and mapping notes with plausible alternatives, and have a second reviewer challenge the selection. Preserve the evidence and reasoning so recurring defects can be measured against one consistent identifier.

CVE to CWE Root Cause Mapping Quick Tips — MITRE CWE

Frequently Asked Questions

What is CWE-1389: Incorrect Parsing of Numbers with Different Radices?+

CWE-1389: Incorrect Parsing of Numbers with Different Radices is a Common Weakness Enumeration (CWE) entry maintained by MITRE. The product parses numeric input assuming base 10 (decimal) values, but it does not account for inputs that use a different base number (radix). Frequently, a numeric input that begins with "0" is treated as octal, or "0x" causes it to be treated as hexadecimal, e.g. by the inet_addr() function. For example, "023" (octal) is 35 decimal, or "0x31" is 49 decimal. Other bases may be used as well. If the developer assumes decimal-only inputs, the code could produce incorrect numbers when the inputs are parsed using a different base. This can result in unexpected and/or dangerous behavior. For example, a "0127.0.0.1" IP address is parsed as octal due to the leading "0", whose numeric value would be the same as 87.0.0.1 (decimal), where the developer likely expected to use 127.0.0.1. The consequences vary depending on the surrounding code in which this weakness occurs, but they can include bypassing network-based access control using unexpected IP addresses or netmasks, or causing apparently-symbolic identifiers to be processed as if they are numbers. In web applications, this can enable bypassing of SSRF restrictions.

What are the security consequences of Incorrect Parsing of Numbers with Different Radices?+

If exploited, CWE-1389 (Incorrect Parsing of Numbers with Different Radices) it can compromise Confidentiality and Integrity, leading to outcomes such as Read Application Data, Bypass Protection Mechanism and Alter Execution Logic.

How do you prevent or mitigate Incorrect Parsing of Numbers with Different Radices?+

Recommended mitigations for CWE-1389 include: If only decimal-based values are expected in the application, conditional checks should be created in a way that prevent octal or hexadecimal strings from being checked. This can be achieved by converting any numerical string to an explicit base-10 integer prior to the conditional check, to prevent octal or hex values from ever being checked against the condition. If various numerical bases do need to be supported, check for leading values indicating the non-decimal base you wish to support (such as 0x for hex) and convert the numeric strings to integers of the respective base. Reject any other alternative-base string that is not intentionally supported by the application. If regular expressions are used to validate IP addresses, ensure that they are bounded using ^ and $ to prevent base-prepended IP addresses from being matched.

Which programming languages are affected by Incorrect Parsing of Numbers with Different Radices?+

CWE-1389 commonly affects Not Language-Specific. Note that weaknesses are often language-agnostic patterns, so secure coding practices apply broadly.

What are real-world examples of Incorrect Parsing of Numbers with Different Radices?+

MITRE documents real CVEs mapped to CWE-1389, including CVE-2021-29662, CVE-2021-28918, CVE-2021-29921, CVE-2021-29923 and CVE-2021-29424. You can look up the full details of each CVE, including CVSS scores and remediation guidance, on our CVE Lookup tool.

What is the difference between a CWE and a CVE?+

A CWE (Common Weakness Enumeration) like CWE-1389 describes a category of software weakness — the underlying flaw type. A CVE (Common Vulnerabilities and Exposures) identifies a specific, real-world vulnerability in a particular product. In short, a CWE is the kind of mistake, and a CVE is an instance of that mistake being found in software.

CWE-1389: Incorrect Parsing of Numbers with Different Radices

Extended Description

Technical Details

Applicable To

Security Consequences

Scope

Impact

Scope

Impact

Mitigation Strategies

Phase

Description

Strategy

Phase

Description

Strategy

Phase

Description

Strategy

Detection Methods

Code Examples & CVEs

Demonstrative Examples

Observed CVE Examples (7)

CWE Relationships

Parent Weaknesses

Source-backed guidance

Verify controls for CWE-1389 with SSDF evidence

Apply Enforcement by Conversion controls for Incorrect Parsing of Numbers with Different Radices

Triage CWE-1389 against known exploitation evidence

Apply precise root-cause mapping to CWE-1389

Validate CWE-1389 with root-cause mapping checks

Frequently Asked Questions

Learn More