CWE-327: Use of a Broken or Risky Cryptographic Algorithm
The product uses a broken or risky cryptographic algorithm or protocol.
Last updated
Overview
Cryptographic algorithms are the methods by which data is scrambled to prevent observation or influence by unauthorized actors. Insecure cryptography can be exploited to expose sensitive information, modify data in unexpected ways, spoof identities of other users or devices, or other impacts. It is very difficult to produce a secure algorithm, and even high-profile algorithms by accomplished cryptographic experts have been broken. Well-known techniques exist to break or weaken various kinds of cryptography. Accordingly, there are a small number of well-understood and heavily studied algorithms that should be used by most products. Using a non-standard or known-insecure algorithm is dangerous because a determined adversary may be able to break the algorithm and compromise whatever data has been protected. Since the state of cryptography advances so rapidly, it is common for an algorithm to be considered "unsafe" even if it was once thought to be strong. This can happen when new attacks are discovered, or if computing power increases so much that the cryptographic algorithm no longer provides the amount of protection that was originally thought. For a number of reasons, this weakness is even more challenging to manage with hardware deployment of cryptographic algorithms as opposed to software implementation. First, if a flaw is discovered with hardware-implemented cryptography, the flaw cannot be fixed in most cases without a recall of the product, because hardware is not easily replaceable like software. Second, because the hardware product is expected to work for years, the adversary's computing power will only increase over time.
Real-world CVEs
316 recorded CVEs are caused by CWE-327 (Use of a Broken or Risky Cryptographic Algorithm). The highest-severity and most recent are shown first. 57 new CWE-327 CVEs have been recorded so far in 2026 (76 in 2025).
- CVE-2026-50086
Aqara unauthenticated AES oracle
Critical · CVSS 10.0 · EPSS 21th2026-06-12 - CVE-2026-21718
Copeland XWEB and XWEB Pro Use of a Broken or Risky Cryptographic Algorithm
Critical · CVSS 10.0 · EPSS 35th2026-02-27 - CVE-2025-54426
Polkadot Frontier contains silent failure in Curve25519 arithmetic precompiles with malformed points
Critical · CVSS 9.9 · EPSS 23th2025-07-28 - CVE-2024-51478
Use of a Broken or Risky Cryptographic Algorithm in YesWiki
Critical · CVSS 9.9 · EPSS 29th2024-10-31 - CVE-2025-69929Critical · CVSS 9.8 · EPSS 32th2026-01-29
- CVE-2026-22585Critical · CVSS 9.8 · EPSS 31th2026-01-24
- CVE-2024-30152Critical · CVSS 9.8 · EPSS 10th2025-04-25
- CVE-2022-3365Critical · CVSS 9.8 · EPSS 79th2025-01-28
- CVE-2024-28980Critical · CVSS 9.8 · EPSS 42th2024-12-13
- CVE-2024-39583Critical · CVSS 9.8 · EPSS 21th2024-09-10
- CVE-2023-34130Critical · CVSS 9.8 · EPSS 23th2023-07-13
- CVE-2022-36937Critical · CVSS 9.8 · EPSS 41th2023-05-10
Showing 12 of 316 recorded CWE-327 CVEs. Track new ones as they are published and get AI-written analysis and fixes.
Monitor CWE-327 vulnerabilitiesCommon consequences
What can happen when CWE-327 is exploited.
Read Application Data
Affects: Confidentiality
The confidentiality of sensitive data may be compromised by the use of a broken or risky cryptographic algorithm.
Modify Application Data
Affects: Integrity
The integrity of sensitive data may be compromised by the use of a broken or risky cryptographic algorithm.
Hide Activities
Affects: Accountability, Non-Repudiation
If the cryptographic algorithm is used to ensure the identity of the source of the data (such as digital signatures), then a broken algorithm will compromise this scheme and the source of the data cannot be proven.
How it happens
When it is introduced
Typically introduced during these phases of the software lifecycle.
Applies to
Languages
Technologies
How to prevent it
Practical mitigations for CWE-327, grouped by where in the lifecycle they apply.
When there is a need to store or transmit sensitive data, use strong, up-to-date cryptographic algorithms to encrypt that data. Select a well-vetted algorithm that is currently considered to be strong by experts in the field, and use well-tested implementations. As with all cryptographic mechanisms, the source code should be available for analysis.
For example, US government systems require FIPS 140-2 certification [REF-1192].
Do not develop custom or private cryptographic algorithms. They will likely be exposed to attacks that are well-understood by cryptographers. Reverse engineering techniques are mature. If the algorithm can be compromised if attackers find out how it works, then it is especially weak.
Periodically ensure that the cryptography has not become obsolete. Some older algorithms, once thought to require a billion years of computing time, can now be broken in days or hours. This includes MD4, MD5, SHA1, DES, and other algorithms that were once regarded as strong. [REF-267]
Ensure that the design allows one cryptographic algorithm to be replaced with another in the next generation or version. Where possible, use wrappers to make the interfaces uniform. This will make it easier to upgrade to stronger algorithms. With hardware, design the product at the Intellectual Property (IP) level so that one cryptographic algorithm can be replaced with another in the next generation of the hardware product.
Effectiveness: Defense in Depth
Carefully manage and protect cryptographic keys (see CWE-320). If the keys can be guessed or stolen, then the strength of the cryptography itself is irrelevant.
Use a vetted library or framework that does not allow this weakness to occur or provides constructs that make this weakness easier to avoid [REF-1482].
Industry-standard implementations will save development time and may be more likely to avoid errors that can occur during implementation of cryptographic algorithms. Consider the ESAPI Encryption feature.
When using industry-approved techniques, use them correctly. Don't cut corners by skipping resource-intensive steps (CWE-325). These steps are often essential for preventing common attacks.
How to detect it
Automated Analysis
Automated methods may be useful for recognizing commonly-used libraries or features that have become obsolete.
Effectiveness: Moderate
Manual Analysis
This weakness can be detected using tools and techniques that require manual (human) analysis, such as penetration testing, threat modeling, and interactive tools that allow the tester to record and modify an active session.
Automated Static Analysis - Binary or Bytecode
According to SOAR [REF-1479], the following detection techniques may be useful:
Effectiveness: SOAR Partial
Manual Static Analysis - Binary or Bytecode
According to SOAR [REF-1479], the following detection techniques may be useful:
Effectiveness: SOAR Partial
Dynamic Analysis with Automated Results Interpretation
According to SOAR [REF-1479], the following detection techniques may be useful:
Effectiveness: SOAR Partial
Dynamic Analysis with Manual Results Interpretation
According to SOAR [REF-1479], the following detection techniques may be useful:
Effectiveness: High
Manual Static Analysis - Source Code
According to SOAR [REF-1479], the following detection techniques may be useful:
Effectiveness: High
Automated Static Analysis - Source Code
According to SOAR [REF-1479], the following detection techniques may be useful:
Effectiveness: High
Automated Static Analysis
According to SOAR [REF-1479], the following detection techniques may be useful:
Effectiveness: SOAR Partial
Architecture or Design Review
According to SOAR [REF-1479], the following detection techniques may be useful:
Effectiveness: High
Code examples
Illustrative examples from MITRE showing how the weakness appears in code.
These code examples use the Data Encryption Standard (DES).
Vulnerable example
EVP_des_ecb();Vulnerable example
Cipher des=Cipher.getInstance("DES...");Vulnerable example
function encryptPassword($password){Once considered a strong algorithm, DES now regarded as insufficient for many applications. It has been replaced by Advanced Encryption Standard (AES).
Suppose a chip manufacturer decides to implement a hashing scheme for verifying integrity property of certain bitstream, and it chooses to implement a SHA1 hardware accelerator for to implement the scheme.
Vulnerable example
The manufacturer chooses a SHA1 hardware accelerator for to implement the scheme because it already has a working SHA1 Intellectual Property (IP) that the manufacturer had created and used earlier, so this reuse of IP saves design cost.Safe example
The manufacturer could have chosen a cryptographic solution that is recommended by the wide security community (including standard-setting bodies like NIST) and is not expected to be broken (or even better, weakened) within the reasonable life expectancy of the hardware product. In this case, the architects could have used SHA-2 or SHA-3, even if it meant that such choice would cost extra.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 OT products used weak cryptography.
Illustrative examples
Real CVEs that MITRE cites as examples of this weakness.
- CVE-2022-30273 — SCADA-based protocol supports a legacy encryption mode that uses Tiny Encryption Algorithm (TEA) in ECB mode, which leaks patterns in messages and cannot protect integrity
- CVE-2022-30320 — Programmable Logic Controller (PLC) uses a protocol with a cryptographically insecure hashing algorithm for passwords.
- CVE-2008-3775 — Product uses "ROT-25" to obfuscate the password in the registry.
- CVE-2007-4150 — product only uses "XOR" to obfuscate sensitive data
- CVE-2007-5460 — product only uses "XOR" and a fixed key to obfuscate sensitive data
- CVE-2005-4860 — Product substitutes characters with other characters in a fixed way, and also leaves certain input characters unchanged.
- CVE-2002-2058 — Attackers can infer private IP addresses by dividing each octet by the MD5 hash of '20'.
- CVE-2008-3188 — Product uses DES when MD5 has been specified in the configuration, resulting in weaker-than-expected password hashes.
- CVE-2005-2946 — Default configuration of product uses MD5 instead of stronger algorithms that are available, simplifying forgery of certificates.
- CVE-2007-6013 — Product uses the hash of a hash for authentication, allowing attackers to gain privileges if they can obtain the original hash.
Terminology & mappings
Mapped taxonomies
- CLASP: Using a broken or risky cryptographic algorithm
- OWASP Top Ten 2004: Insecure Storage (A8) — CWE More Specific fit
- CERT C Secure Coding: Do not use the rand() function for generating pseudorandom numbers (MSC30-C) — CWE More Abstract fit
- CERT C Secure Coding: Properly seed pseudorandom number generators (MSC32-C) — CWE More Abstract fit
- The CERT Oracle Secure Coding Standard for Java (2011): Generate strong random numbers (MSC02-J)
- OMG ASCSM (ASCSM-CWE-327)
- ISA/IEC 62443: Req SR 4.3 (Part 3-3)
- ISA/IEC 62443: Req CR 4.3 (Part 4-2)
Attack patterns
CAPEC attack patterns that exploit this weakness.
Frequently asked questions
Common questions about CWE-327.
- What is CWE-327?
- The product uses a broken or risky cryptographic algorithm or protocol.
- What CVEs are caused by CWE-327?
- 316 recorded CVEs are attributed to CWE-327, including CVE-2026-50086, CVE-2026-21718, CVE-2025-54426.
- Is CWE-327 part of the OWASP Top 10?
- CWE-327 maps to OWASP Top Ten 2004: Insecure Storage (A8) in the OWASP security taxonomy.
- How do you prevent CWE-327?
- When there is a need to store or transmit sensitive data, use strong, up-to-date cryptographic algorithms to encrypt that data. Select a well-vetted algorithm that is currently considered to be strong by experts in the field, and use well-tested implementations. As with all cryptographic mechanisms, the source code should be available for analysis.
- How is CWE-327 detected?
- Automated Analysis: Automated methods may be useful for recognizing commonly-used libraries or features that have become obsolete.
- What are the consequences of CWE-327?
- Exploiting CWE-327 can lead to: Read Application Data, Modify Application Data, Hide Activities.
- Is CWE-327 actively exploited?
- 316 recorded CVEs are caused by CWE-327; none are currently in CISA's KEV catalog of actively exploited flaws.
References
- MITRE CWE definition (CWE-327) (opens in a new tab)
- CWE-327 vulnerabilities on NVD (opens in a new tab)
- Learn: What is a CWE?
Weakness data is sourced from the MITRE CWE catalog (v4.20). CVE associations are aggregated and kept current by RadicalNotion.AI.
Stay ahead of CWE-327
Get alerted the moment a new CWE-327 vulnerability affects your stack, with AI-written analysis, severity context, and remediation guidance.