An IP address in source code works on the day it is written. Later, the server moves, and the code still points at the old place.
CWE-1051 is the weakness where the product initializes data using hard-coded values that act as network resource identifiers, such as addresses or hostnames. MITRE lists it as a Base weakness in any language.
How it happens
Developers hard code endpoints during prototyping and never replace them.
// Hard coded identifier
private static final String API_HOST = "10.20.30.40";
// Read from configuration at deploy time
String apiHost = System.getenv("API_HOST");
if (apiHost == null || apiHost.isEmpty()) {
throw new IllegalStateException("API_HOST is not set");
}
MITRE's recorded consequence is reduced reliability. The product might not run reliably in an environment that does not use those identifiers. If the relevant code is reachable by an attacker, the reliability problem might introduce a vulnerability. No CVEs are observed.
One security angle follows from the nature of the identifier: if an address or name is fixed in code, changing it in a hurry, for example after a host is compromised or retired, requires a code change and a release. See also the related destination handling weakness in CWE-941.
How to find it
MITRE lists no detection methods. Search the code for IP address patterns and hostnames, and review configuration handling. Static analysis often flags literal addresses.
How to fix it
MITRE lists no formal mitigations. Reasonable steps:
- Move endpoints into configuration, environment variables or a service discovery mechanism.
- Fail clearly when required configuration is missing.
- Keep environment specific values out of the shared code base.
- Review configuration changes like code.
Quick check
What is the main effect MITRE lists?
Reduced reliability, since the product may not work in environments that do not use the same identifiers.