Notifications
Clear all
Topic starter
01/08/2026 10:47 pm
TL;DR: Cryptographic advisories in OWASP A04:2025 overwhelmingly cluster around implementation mistakes such as improper signature verification and algorithm confusion, according to Semgrep’s analysis of the GHSA dataset. The deeper lesson is that defenders can catch many high-severity crypto bugs by scrutinising input validation, range checks, and attacker-controlled branches rather than treating cryptography as a black box.
NHIMG editorial — based on content published by Semgrep: cryptographic failures are usually missing checks, not broken math
By the numbers:
- This was a real CVE ( CVE-2021-43572 ) found in a real FinTech signing library rated 9.8.
- 4th, sday August 4th, 2026 at 10AM in the Proving Ground
Questions worth separating out
Q: How should security teams review cryptographic code for hidden trust failures?
A: Start by mapping every input that can reach the verification decision, then ask which values the attacker can influence.
Q: Why do secure libraries still produce serious cryptographic vulnerabilities?
A: Because the library may perform the mathematics correctly while the application misuses the result.
Q: What do security teams get wrong about algorithm confusion attacks?
A: They often focus on the algorithm itself instead of the policy that selects it.
Practitioner guidance
- Review every verification path for attacker-controlled inputs Trace signature, token, and certificate verification from ingress to accept decision, and document exactly which fields the attacker can influence.
- Add boundary-value tests for cryptographic checks Create unit and integration tests that exercise zero values, malformed encodings, unexpected algorithms, and out-of-range parameters so the code fails before trust is granted.
- Pin expected algorithms and reject token metadata drift Enforce a fixed verification policy in code rather than trusting algorithm hints embedded in the token or message.
What's in the full article
Semgrep's full analysis covers the code-level examples and review approach this post intentionally leaves for the source:
- Walkthroughs of the specific advisory patterns that repeated across the GHSA dataset, including signature verification and algorithm confusion.
- The full ECDSA example showing how a missing range check turns a cryptographic proof into an invalid accept decision.
- Practical review heuristics for finding attacker-controlled inputs in wrapper code before an attacker does.
- Talk context from BSidesLV and DEF CON 34, including the broader set of examples referenced in the session.
👉 Read Semgrep's analysis of cryptographic failures and missing checks →
Cryptographic failures and missing checks: what reviewers miss?
Explore further
01/08/2026 10:56 pm
Missing validation, not broken cryptography, is the dominant governance failure. The article’s dataset review shows that the most common cryptographic failures are implementation mistakes around verification and algorithm choice, not exotic failures in the primitives themselves. That is a governance problem because teams often assign crypto review to specialists and stop interrogating the wrapper code. Practitioners should treat validation logic as part of the control surface, not as incidental implementation detail.
A question worth separating out:
Q: How can organisations prevent range-check failures in signature verification?
A: Bake boundary cases into code review, tests, and secure coding standards. Explicitly reject invalid values such as zero, negative numbers, malformed encodings, and any input outside the scheme’s allowed domain. The goal is to ensure the cryptographic proof cannot be reduced to a meaningless comparison by attacker-supplied values.
👉 Read our full editorial: Cryptographic failures are usually missing checks, not broken math
