CWE-798: Use of Hard-coded Credentials
low-riskThe product contains hard-coded credentials, such as a password or cryptographic key.
Common Consequences
Detection Methods
Credential storage in configuration files is findable using black box methods, but the use of hard-coded credentials for an incoming authentication routine typically involves an account that is not visible outside of the code.
Automated white box techniques have been published for detecting hard-coded credentials for incoming authentication, but there is some expert disagreement regarding their effectiveness and applicability to a broad range of methods.
This weakness may be detectable using manual code analysis. Unless authentication is decentralized and applied throughout the product, there can be sufficient time for the analyst to find incoming authentication routines and examine the program logic looking for usage of hard-coded credentials. Configuration files could also be analyzed.
For hard-coded credentials in incoming authentication: use monitoring tools that examine the product's process as it interacts with the operating system and the network. This technique is useful in cases when source code is unavailable, if the product was not developed by you, or if you want to verify that the build phase did not introduce any new weaknesses. Examples include debuggers that directly attach to the running process; system-call tracing utilities such as truss (Solaris) and strace (Linux); system activity monitors such as FileMon, RegMon, Process Monitor, and other Sysinternals utilities (Windows); and sniffers and protocol analyzers that monitor network traffic. Attach the monitor to the process and perform a login. Using call trees or similar artifacts from the output, examine the associated behaviors and see if any of them appear to be comparing the input to a fixed string or value.
According to SOAR [REF-1479], the following detection techniques may be useful: Cost effective for partial coverage: Bytecode Weakness Analysis - including disassembler + source code weakness analysis Binary Weakness Analysis - including disassembler + source code weakness analysis
According to SOAR [REF-1479], the following detection techniques may be useful: Highly cost effective: Binary / Bytecode disassembler - then use manual analysis for vulnerabilities & anomalies
According to SOAR [REF-1479], the following detection techniques may be useful: Cost effective for partial coverage: Network Sniffer Forced Path Execution
According to SOAR [REF-1479], the following detection techniques may be useful: Highly cost effective: Focused Manual Spotcheck - Focused manual analysis of source Manual Source Code Review (not inspections)
According to SOAR [REF-1479], the following detection techniques may be useful: Highly cost effective: Source code Weakness Analyzer Context-configured Source Code Weakness Analyzer
According to SOAR [REF-1479], the following detection techniques may be useful: Cost effective for partial coverage: Configuration Checker
According to SOAR [REF-1479], the following detection techniques may be useful: Highly cost effective: Inspection (IEEE 1028 standard) (can apply to requirements, design, source code, etc.) Formal Methods / Correct-By-Construction
Real-World Examples (10)
| CVE | CVSS | EPSS | KEV |
|---|---|---|---|
| CVE-2022-26138 | 9.8 | 94.3% | Y |
| CVE-2022-26138 | 9.8 | 94.3% | Y |
| CVE-2024-28987 | 9.1 | 94.3% | Y |
| CVE-2024-3272 | 9.8 | 94.1% | Y |
| CVE-2019-16313 | 7.5 | 94.0% | — |
| CVE-2023-5074 | 9.8 | 92.6% | — |
| CVE-2023-5074 | 9.8 | 92.6% | — |
| CVE-2020-11854 | 9.8 | 92.4% | — |
| CVE-2024-7332 | 9.8 | 92.1% | — |
| CVE-2022-28810 | 6.8 | 91.8% | Y |