New CVEs and security advisories land every single day, and on Semgrep's supply-chain team, someone has to actually read them. That someone is me. I pull the advisory, find the vulnerable code, work out exactly what an attacker controls, and boil it down to the essence of the mistake.
Do that long enough and you stop seeing individual bugs and start seeing shapes. The cryptographic advisories had a shape I couldn't unsee: over and over, the math was intact and the code had simply skipped a check. So I stopped reading them one at a time and pulled the entire GHSA dataset to find out whether the pattern held at scale.
I turned that pattern into a talk I'm giving at BSidesLV and DEF CON 34, walking through how these bugs happen and how you catch them in reviews before an attacker finds them first.
What the Data Says
I started from OWASP A04:2025 — Cryptographic Failures, the vulnerability category that covers everything from weak algorithms and bad key management to the implementation slip-ups that let an attacker walk past a check. I ranked every advisory in that category by CWE to look for a trend.
Advisory count by CWE under OWASP A04:2025 — CWE-347 and CWE-327 dominate
The top two weren't exotic math failures. Improper signature verification and algorithm confusion are code problems. A validation check that doesn't run can allow untrusted input.
Crypto's Reputation as a Hard Problem
Everyone assumes that crypto is the scary part, so nobody looks closely at the boring parts. The library is treated as a black box that you don't feel qualified to question -- and honestly, for the math inside it, that's fair. That deference leaks to the code around the algorithm when it shouldn't. The wrapper that checks input, compares two values, or picks which algorithm to use sails through reviews because everybody assumes it is over their head.
It isn't. That's where many security bugs live and should be scrutinized.
When I went through the advisories, yes, a few were genuine primitive failures like weak parameters, broken ciphers, and things that make headlines when they are wrong. Those were the minority. Nobody factored a 2048-bit RSA key or solved a discrete log over the weekend. The primitive did its job perfectly. The code just never checked whether the input deserved to be there. The software missed a validation check, or trusted an input they shouldn't have, or accepted an algorithm the attacker picked.
One Crypto Bug, Start to Finish
Let's look at an example the whole way through.
An ECDSA signature is not magic. It's two numbers, r and s. Everything else is the DER wrapper, base64, and packaging those integers.
An ECDSA signature
To check a signature, the library runs some modular arithmetic over r, s, and the signer's public key. It finishes with a single verify comparison: accept if r equals a value it recomputed.
In this next listing, you see that signature is passed to verify which can be supplied by an attacker (shown in red).
Attacker can manipulate both sides of the r,s equality check.
Now think like an attacker for ten seconds. What values would make that last comparison pass no matter what the message is?
Take a beat before you read on.
Thinking Like a FinTech Crypto Attacker
The answer is zero. Send r=0 and s=0 then the whole computation collapses to zero on both sides. The signature validates since 0==0. The signature is literally nothing.
This was a real CVE (CVE-2021-43572) found in a real FinTech signing library rated 9.8.
You didn't need any of the math to find it. You asked the laziest possible attacker question — "what's the dumbest input that might slip through?" — and tried it.
And the fix? Reject the signature unless 1 ≤ r ≤ n-1 and 1 ≤ s ≤ n-1. That's a simple range check, nothing more than confirming a number falls inside the band of values you're actually allowed to accept before you trust it. Four lines patch a 9.8 severity security bug.
Reject the signature unless full range check passes.
The crypto was fine, the code forgot a range check. You can catch issues like this by thinking about inputs instead of algebra.
Why It Keeps Happening
The part that got to me isn't any single bug but that they don't stay fixed.
If you attend one of my talks at Hacker Summer Camp, I explore multiple examples like this: signature bypasses, invalid-curve attacks, and JWT algorithm confusion. I close with a section labeled Déjà Vu because a handful of advisories published in 2026 are functionally the same bugs like the example above, just reappearing in additional libraries, in different languages, and written by people who'd not heard about the original advisory. We keep stepping on the same traps.
There is good news for defenders: you don't need a cryptography background to catch most of this. You need to know what an attacker can touch and you need to know what a range check is. If you can read code and think like an attacker, you can identify these in review the same way I do, one advisory at a time.
If you will be attending BSidesLV or DEF CON 34 come say hi.
Tuesday August 4th, 2026 at 10AM in the Proving Ground
Friday August 7th, 2026 at 4:30pm in the Crypto & Privacy Village (Creator Stage CS-2)
No crypto background required, just a healthy amount of skepticism. Slides and the CTF challenges will be shared on this post after the event.
