CWE-259 (使用硬编码的口令) — Vulnerability Class 126

126 vulnerabilities classified as CWE-259 (使用硬编码的口令). AI Chinese analysis included.

CWE-259 represents a critical security weakness where software embeds static credentials directly into its source code or configuration for both inbound authentication and outbound communications. Attackers typically exploit this vulnerability by reverse-engineering the application to extract these hardcoded passwords, granting them unauthorized access to sensitive systems or enabling them to impersonate legitimate services during external interactions. This bypasses standard authentication controls, often leading to complete system compromise or data exfiltration. To mitigate this risk, developers must avoid embedding secrets in code entirely. Instead, they should implement robust credential management solutions, such as using secure key vaults, environment variables, or hardware security modules. These approaches ensure that sensitive authentication data remains dynamic, encrypted, and isolated from the application logic, significantly reducing the attack surface and preventing accidental exposure through version control systems or decompiled binaries.

MITRE CWE Description

The product contains a hard-coded password, which it uses for its own inbound authentication or for outbound communication to external components. There are two main variations of a hard-coded password: Inbound: the product contains an authentication mechanism that checks for a hard-coded password. Outbound: the product connects to another system or component, and it contains a hard-coded password for connecting to that component.

Common Consequences (2)

Access Control Gain Privileges or Assume Identity

If hard-coded passwords are used, it is almost certain that malicious users can gain access through the account in question.

Access Control Gain Privileges or Assume Identity, Hide Activities, Reduce Maintainability

A hard-coded password typically leads to a significant authentication failure that can be difficult for the system administrator to detect. Once detected, it can be difficult to fix, so the administrator may be forced into disabling the product entirely.

Mitigations (5)

Architecture and Design For outbound authentication: store passwords outside of the code in a strongly-protected, encrypted configuration file or database that is protected from access by all outsiders, including other local users on the same system. Properly protect the key (CWE-320). If you cannot use encryption to protect the file, then make sure that the permissions are as restrictive as possible.

Architecture and Design For inbound authentication: Rather than hard-code a default username and password for first time logins, utilize a "first login" mode that requires the user to enter a unique strong password.

Architecture and Design Perform access control checks and limit which entities can access the feature that requires the hard-coded password. For example, a feature might only be enabled through the system console instead of through a network connection.

Architecture and Design For inbound authentication: apply strong one-way hashes to your passwords and store those hashes in a configuration file or database with appropriate access control. That way, theft of the file/database still requires the attacker to try to crack the password. When receiving an incoming password during authentication, take the hash of the password and compare it to the hash that you have saved. Us…

Architecture and Design For front-end to back-end connections: Three solutions are possible, although none are complete. The first suggestion involves the use of generated passwords which are changed automatically and must be entered at given time intervals by a system administrator. These passwords will be held in memory and only be valid for the time intervals. Next, the passwords used should be limited at the back end…

Examples (2)

The following code uses a hard-coded password to connect to a database:

... DriverManager.getConnection(url, "scott", "tiger"); ...

Bad · Java

javap -c ConnMngr.class 22: ldc #36; //String jdbc:mysql://ixne.com/rxsql 24: ldc #38; //String scott 26: ldc #17; //String tiger

Attack

The following code is an example of an internal hard-coded password in the back-end:

int VerifyAdmin(char *password) { if (strcmp(password, "Mew!")) { printf("Incorrect Password!\n"); return(0); } printf("Entering Diagnostic Mode...\n"); return(1); }

Bad · C

int VerifyAdmin(String password) { if (!password.equals("Mew!")) { return(0); } //Diagnostic Mode return(1); }

Bad · Java

CVE ID	Title	CVSS	Severity	Published
CVE-2016-9358	多款Marel产品安全漏洞 — Marel Food Processing Systems	9.8	-	2017-06-30
CVE-2017-6022	BD PerformA和KLA Journal Service 信任管理问题漏洞 — BD Kiestra PerformA and KLA Journal Service	9.4	-	2017-06-30
CVE-2017-6039	Phoenix Broadband PowerAgent SC3 BMS 安全漏洞 — Phoenix Broadband Technologies LLC PowerAgent SC3 Site Controller	9.8	-	2017-06-02
CVE-2014-5405	Hospira MedNet Use of Hard-coded Password — MedNet	8.8	-	2015-04-03
CVE-2014-2363	Morpho Itemiser 3 Hard-Coded Credential — Itemiser 3	9.8	-	2014-07-26
CVE-2012-5862	Sinapsi eSolar Hard-Coded Password — eSolar	9.8	-	2012-11-23

Vulnerabilities classified as CWE-259 (使用硬编码的口令) represent 126 CVEs. The CWE taxonomy describes the weakness; review individual CVEs for product-specific impact.