CWE-798 is Use of Hard-coded Credentials. The flaw arises when the product contains hard-coded credentials, such as a password or cryptographic key. The database currently holds 180 vulnerabilities mapped to CWE-798 and none of them are in the CISA Known Exploited Vulnerabilities catalog.
A short verification protects the official data source and prevents automated AI abuse.
Verifying...
No vulnerability data in CISA KEV for CWE-798
The product contains hard-coded credentials, such as a password or cryptographic key.
There are two main variations:
Inbound: the product contains an authentication mechanism that checks the input credentials against a hard-coded set of credentials. In this variant, a default administration account is created, and a simple password is hard-coded into the product and associated with that account. This hard-coded password is the same for each installation of the product, and it usually cannot be changed or disabled by system administrators without manually modifying the program, or otherwise patching the product. It can also be difficult for the administrator to detect.
Outbound: the product connects to another system or component, and it contains hard-coded credentials for connecting to that component. This variant applies to front-end systems that authenticate with a back-end service. The back-end service may require a fixed password that can be easily discovered. The programmer may simply hard-code those back-end credentials into the front-end product.
| Impact | Scope | Explanation |
|---|---|---|
| Bypass Protection Mechanism | Access Control | If hard-coded passwords are used, it is almost certain that malicious users will gain access to the account in question. Any user of the product that hard-codes passwords may be able to extract the password. Client-side systems with hard-coded passwords pose even more of a threat, since the extraction of a password from a binary is usually very simple. |
| Read Application Data, Gain Privileges or Assume Identity, Execute Unauthorized Code or Commands, Other | Integrity, Confidentiality, Availability, Access Control, Other | This weakness can lead to the exposure of resources or functionality to unintended actors, possibly providing attackers with sensitive information or even execute arbitrary code. If the password is ever discovered or published (a common occurrence on the Internet), then anybody with knowledge of this password can access the product. Finally, since all installations of the product will have the same password, even across different organizations, this enables massive attacks such as worms to take place. |
| Method | Approach | Effectiveness |
|---|---|---|
| Black Box | 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. | Moderate |
| Automated Static Analysis | 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. | - |
| Manual Static Analysis | 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.These may be more effective than strictly automated techniques. This is especially the case with weaknesses that are related to design and business rules. | - |
| Manual Dynamic Analysis | 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. | - |
| Automated Static Analysis - Binary or Bytecode | 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 | SOAR Partial |
| Manual Static Analysis - Binary or Bytecode | 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 | High |
| Dynamic Analysis with Manual Results Interpretation | According to SOAR [REF-1479], the following detection techniques may be useful: ``` Cost effective for partial coverage: ``` Network Sniffer Forced Path Execution | SOAR Partial |
| Manual Static Analysis - Source Code | 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) | High |
| Automated Static Analysis - Source Code | 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 | High |
| Automated Static Analysis | According to SOAR [REF-1479], the following detection techniques may be useful: ``` Cost effective for partial coverage: ``` Configuration Checker | SOAR Partial |
| Architecture or Design Review | 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 | High |
Below are representative vulnerabilities related to this CWE, prioritized by severity.
CWE™ Program, operated by The MITRE Corporation. Copyright © 2006–2026, The MITRE Corporation. The MITRE Corporation hereby grants you a non-exclusive, royalty-free license to use CWE for research, development, and commercial purposes. CWE Terms of Use.
CyStack VulnScan continuously discovers assets, validates vulnerabilities, and helps security teams prioritize remediation across the organization.
Review CyStack's security rating and practical recommendations for websites and edge assets.
Explore cybersecurity research from our team of security specialists.
Browse practical cybersecurity knowledge across CyStack's articles and guides.
en
