logo

Use of Hard-coded Cryptographic Key

Draft Variant
Structure: Simple
Description

This vulnerability occurs when an application embeds a fixed, unchangeable cryptographic key directly within its source code or configuration files.

This vulnerability occurs when an application embeds a fixed, unchangeable cryptographic key directly within its source code or configuration files.
Extended Description

Hard-coding cryptographic keys is a common but dangerous practice that undermines the security of encrypted data. Since the key is the same in every instance of the application and cannot be changed without modifying the code, an attacker who discovers the key (e.g., by inspecting the source code, binaries, or configuration files) can decrypt any sensitive data the application protects. This flaw effectively renders encryption useless, as the secret is no longer secret. To fix this, developers should use secure key management systems that allow keys to be stored externally, rotated regularly, and accessed securely at runtime. While SAST tools can detect the hard-coded pattern, Plexicus uses AI to suggest the actual code fix—such as integrating with a secrets manager or environment variables—saving hours of manual refactoring and helping you enforce secure key handling across your entire application portfolio.
Common Consequences 1
Scope: Access Control

Impact: Bypass Protection MechanismGain Privileges or Assume IdentityRead Application Data

If hard-coded cryptographic keys are used, it is almost certain that malicious users will gain access through the account in question. The use of a hard-coded cryptographic key significantly increases the possibility that encrypted data may be recovered.
Detection Methods 1
Automated Static AnalysisHigh
Automated static analysis, commonly referred to as Static Application Security Testing (SAST), can find some instances of this weakness by analyzing source code (or binary/compiled code) without having to execute it. Typically, this is done by building a model of data flow and control flow, then searching for potentially-vulnerable patterns that connect "sources" (origins of input) with "sinks" (destinations where the data interacts with external components, a lower layer such as the OS, etc.)
Potential Mitigations 1
Phase: Architecture and Design
Prevention schemes mirror that of hard-coded password storage.
Demonstrative Examples 2

ID : DX-92

The following code examples attempt to verify a password using a hard-coded cryptographic key.

Code Example:

Bad
C
c

Code Example:

Bad
Java
java

Code Example:

Bad
C#
c#
The cryptographic key is within a hard-coded string value that is compared to the password. It is likely that an attacker will be able to read the key and compromise the system.

ID : DX-153

In 2022, the OT:ICEFALL study examined products by 10 different Operational Technology (OT) vendors. The researchers reported 56 vulnerabilities and said that the products were "insecure by design" [REF-1283]. If exploited, these vulnerabilities often allowed adversaries to change how the products operated, ranging from denial of service to changing the code that the products executed. Since these products were often used in industries such as power, electrical, water, and others, there could even be safety implications.
Multiple vendors used hard-coded keys for critical functionality in their OT products.
Observed Examples 4
CVE-2022-29960Engineering Workstation uses hard-coded cryptographic keys that could allow for unathorized filesystem access and privilege escalation
CVE-2022-30271Remote Terminal Unit (RTU) uses a hard-coded SSH private key that is likely to be used by default.
CVE-2020-10884WiFi router service has a hard-coded encryption key, allowing root access
CVE-2014-2198Communications / collaboration product has a hardcoded SSH private key, allowing access to root account
References 2
The CLASP Application Security Process
Secure Software, Inc.
2005
https://cwe.mitre.org/documents/sources/TheCLASPApplicationSecurityProcess.pdf(2024-11-17)
ID: REF-18
OT:ICEFALL: The legacy of "insecure by design" and its implications for certifications and risk management
Forescout Vedere Labs
20-06-2022
https://www.forescout.com/resources/ot-icefall-report/
ID: REF-1283
Likelihood of Exploit

High

Applicable Platforms
Languages:
Not Language-Specific : Undetermined
Technologies:
ICS/OT : Undetermined
Modes of Introduction
Architecture and Design
Related Weaknesses
ChildOf: Use of Hard-coded Credentials (CWE-798)
ChildOf: Use of Hard-coded Credentials (CWE-798)
ChildOf: Use of Hard-coded Credentials (CWE-798)
Taxonomy Mapping
  • CLASP
  • OWASP Top Ten 2007
  • OWASP Top Ten 2007
  • OWASP Top Ten 2004
  • Software Fault Patterns
  • ISA/IEC 62443
  • ISA/IEC 62443
  • ISA/IEC 62443
  • ISA/IEC 62443
  • ISA/IEC 62443
  • ISA/IEC 62443
  • ISA/IEC 62443
Notes
OtherThe main difference between the use of hard-coded passwords and the use of hard-coded cryptographic keys is the false sense of security that the former conveys. Many people believe that simply hashing a hard-coded password before storage will protect the information from malicious users. However, many hashes are reversible (or at least vulnerable to brute force attacks) -- and further, many authentication protocols simply request the hash itself, making it no better than a password.
MaintenanceThe Taxonomy_Mappings to ISA/IEC 62443 were added in CWE 4.10, but they are still under review and might change in future CWE versions. These draft mappings were performed by members of the "Mapping CWE to 62443" subgroup of the CWE-CAPEC ICS/OT Special Interest Group (SIG), and their work is incomplete as of CWE 4.10. The mappings are included to facilitate discussion and review by the broader ICS/OT community, and they are likely to change in future CWE versions.