Review requirements, documentation, and product design to ensure that primitives are consistent with the strongest-available recommendations from trusted parties. If the product appears to be using custom or proprietary implementations that have not had sufficient public review and approval, then this is a significant concern.
CWE-1240 Base Draft
Use of a Cryptographic Primitive with a Risky Implementation
This weakness occurs when a product uses a custom, unverified, or non-compliant implementation of a cryptographic algorithm instead of a trusted, standard solution.
Definition
What is CWE-1240?
This weakness occurs when a product uses a custom, unverified, or non-compliant implementation of a cryptographic algorithm instead of a trusted, standard solution.
Cryptographic systems rely on proven building blocks like encryption, hashing, and digital signatures. These primitives are mathematically designed to withstand a specific number of attack attempts. When developers implement their own versions or use deprecated algorithms, they often introduce subtle flaws that cryptographers already understand, making the entire system vulnerable to data exposure or tampering.
Using risky implementations is especially dangerous in hardware, where fixes often require physical recalls. Cryptographic standards are continuously reviewed and updated as computing power grows and new attack methods emerge. Relying on non-standard or weakened primitives, even for a single component, can compromise the security of the entire application over its lifespan.
Real-world impact
Real-world CVEs caused by CWE-1240
-
software uses MD5, which is less safe than the default SHA-256 used by related products
-
Default configuration of product uses MD5 instead of stronger algorithms that are available, simplifying forgery of certificates.
-
identity card uses MD5 hash of a salt and password
-
personal key is transmitted over the network using a substitution cipher
-
product does not disable TLS-RSA cipher suites, allowing decryption of traffic if TLS 2.0 and secure ciphers are not enabled.
-
SSL/TLS library generates 16-byte nonces but reduces them to 12 byte nonces for the ChaCha20-Poly1305 cipher, converting them in a way that violates the cipher's requirements for unique nonces.
-
LDAP interface allows use of weak ciphers
-
SCADA product allows "use of outdated cipher suites"
How attackers exploit it
Step-by-step attacker path
- 1
Identify a code path that handles untrusted input without validation.
- 2
Craft a payload that exercises the unsafe behavior — injection, traversal, overflow, or logic abuse.
- 3
Deliver the payload through a normal request and observe the application's reaction.
- 4
Iterate until the response leaks data, executes attacker code, or escalates privileges.
Vulnerable code example
Vulnerable Other
Re-using random values may compromise security.
Suppose an Encryption algorithm needs a random value for a key. Instead of using a DRNG (Deterministic Random Number Generator), the designer uses a linear-feedback shift register (LFSR) to generate the value. Secure code example
Secure Other
While an LFSR may provide pseudo-random number generation service, the entropy (measure of randomness) of the resulting output may be less than that of an accepted DRNG (like that used in dev/urandom). Thus, using an LFSR weakens the strength of the cryptographic system, because it may be possible for an attacker to guess the LFSR output and subsequently the encryption key.
If a cryptographic algorithm expects a random number as its input, provide one. Do not provide a pseudo-random value. What changed: the unsafe sink is replaced (or the input is validated/escaped) so the same payload no longer triggers the weakness.
Prevention checklist
How to prevent CWE-1240
- Requirements Require compliance with the strongest-available recommendations from trusted parties, and require that compliance must be kept up-to-date, since recommendations evolve over time. For example, US government systems require FIPS 140-3 certification, which supersedes FIPS 140-2 [REF-1192] [REF-267].
- Architecture and Design Ensure that the architecture/design uses the strongest-available primitives and algorithms from trusted parties. For example, US government systems require FIPS 140-3 certification, which supersedes FIPS 140-2 [REF-1192] [REF-267].
- Architecture and Design Do not develop custom or private cryptographic algorithms. They will likely be exposed to attacks that are well-understood by cryptographers. As with all cryptographic mechanisms, the source code should be available for analysis. If the algorithm may be compromised when attackers find out how it works, then it is especially weak.
- Architecture and Design Try not to use cryptographic algorithms in novel ways or with new modes of operation even when you "know" it is secure. For example, using SHA-2 chaining to create a 1-time pad for encryption might sound like a good idea, but one should not do this.
- Architecture and Design Ensure that the design can replace one cryptographic primitive or algorithm with another in the next generation ("cryptographic agility"). Where possible, use wrappers to make the interfaces uniform. This will make it easier to upgrade to stronger algorithms. This is especially important for hardware, which can be more difficult to upgrade quickly than software; design the hardware at a replaceable block level.
- Architecture and Design Do not use outdated or non-compliant cryptography algorithms. 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].
- Architecture and Design / Implementation Do not use a linear-feedback shift register (LFSR) or other legacy methods as a substitute for an accepted and standard Random Number Generator.
- Architecture and Design / Implementation Do not use a checksum as a substitute for a cryptographically generated hash.
Detection signals
How to detect CWE-1240
Analyze the product to ensure that implementations for each primitive do not contain any known vulnerabilities and are not using any known-weak algorithms, including MD4, MD5, SHA1, DES, etc.
For hardware, during the implementation (pre-Silicon / post-Silicon) phase, dynamic tests should be done to ensure that outputs from cryptographic routines are indeed working properly, such as test vectors provided by NIST [REF-1236].
It needs to be determined if the output of a cryptographic primitive is lacking entropy, which is one clear sign that something went wrong with the crypto implementation. There exist many methods of measuring the entropy of a bytestream, from sophisticated ones (like calculating Shannon's entropy of a sequence of characters) to crude ones (by compressing it and comparing the size of the original bytestream vs. the compressed - a truly random byte stream should not be compressible and hence the uncompressed and compressed bytestreams should be nearly identical in size).
CWE-1240
Don't catalog this weakness. Prove it's reachable.
Plexicus turns CWE catalogs into evidence: every CWE-pattern is matched against your real code graph, reach is proven on a sandbox clone, and verified findings ship as reviewed PRs.
Frequently asked questions What is CWE-1240?
How serious is CWE-1240?
What languages or platforms are affected by CWE-1240?
How can I prevent CWE-1240?
How does Plexicus detect and fix CWE-1240?
Where can I learn more about CWE-1240?
Frequently asked questions
What is CWE-1240?
This weakness occurs when a product uses a custom, unverified, or non-compliant implementation of a cryptographic algorithm instead of a trusted, standard solution.
How serious is CWE-1240?
MITRE has not published a likelihood-of-exploit rating for this weakness. Treat it as medium-impact until your threat model proves otherwise.
What languages or platforms are affected by CWE-1240?
MITRE lists the following affected platforms: Not OS-Specific, Not Architecture-Specific, System on Chip.
How can I prevent CWE-1240?
Require compliance with the strongest-available recommendations from trusted parties, and require that compliance must be kept up-to-date, since recommendations evolve over time. For example, US government systems require FIPS 140-3 certification, which supersedes FIPS 140-2 [REF-1192] [REF-267]. Ensure that the architecture/design uses the strongest-available primitives and algorithms from trusted parties. For example, US government systems require FIPS 140-3 certification, which supersedes…
How does Plexicus detect and fix CWE-1240?
Plexicus's SAST engine matches the data-flow signature for CWE-1240 on every commit. When a match is found, our Codex Remedium agent opens a fix PR with the corrected code, tests, and a one-line summary for the reviewer.
Where can I learn more about CWE-1240?
MITRE publishes the canonical definition at https://cwe.mitre.org/data/definitions/1240.html. You can also reference OWASP and NIST documentation for adjacent guidance.
Related weaknesses
Weaknesses related to CWE-1240
CWE-327 Parent
Use of a Broken or Risky Cryptographic Algorithm
The software relies on a cryptographic algorithm or protocol that is either fundamentally flawed or considered too weak by modern security…
CWE-328 Sibling
Use of Weak Hash
This vulnerability occurs when software uses a hashing algorithm that is cryptographically weak, allowing attackers to feasibly reverse…
CWE-780 Sibling
Use of RSA Algorithm without OAEP
This vulnerability occurs when an application implements RSA encryption but fails to use Optimal Asymmetric Encryption Padding (OAEP),…
CWE-916 Sibling
Use of Password Hash With Insufficient Computational Effort
This vulnerability occurs when a system protects passwords by hashing them, but uses a hashing algorithm that is too fast or…
Resources
Further reading
- MITRE — official CWE-1240 https://cwe.mitre.org/data/definitions/1240.html
- FIPS PUB 140-2: SECURITY REQUIREMENTS FOR CRYPTOGRAPHIC MODULES https://csrc.nist.gov/files/pubs/fips/140-2/upd2/final/docs/fips1402.pdf
- Cryptographic primitive https://en.wikipedia.org/wiki/Cryptographic_primitive
- FIPS PUB 140-3: SECURITY REQUIREMENTS FOR CRYPTOGRAPHIC MODULES https://csrc.nist.gov/publications/detail/fips/140/3/final
- CAVP Testing: Individual Component Testing https://csrc.nist.gov/projects/cryptographic-algorithm-validation-program/component-testing
Ready to validate what matters?
Ready to validate what matters?
Plexicus is Proof-Driven AppSec: validated findings, contextual understanding, and reviewed remediation — anchored in evidence, scoped with you.