I Fed Claude Broken Crypto. What It Found Should Scare You
> **Bottom line:** I ran 40 real-world cryptographic implementations — pulled from client audits and public GitHub repos — through Claude Sonnet 5 and asked it to find the vulnerabilities.
It correctly diagnosed the core flaw in 37 of 40 samples (92.5%), including a padding oracle in a payment library that's been live since 2019 and a nonce-reuse bug in AES-GCM code shipped by a company with a nine-figure valuation.
Average diagnosis time: under 5 seconds per file.
The scary part isn't that Claude found the bugs — it's that anyone with API access can now run this exact scan against any public repo, for pennies, today.
I've spent twelve years finding broken crypto in production systems, and it usually takes me half a day per codebase. Claude Sonnet 5 did it in less time than it takes to brew coffee.
I fed it 40 real cryptographic implementations — some from paid audits, some scraped from public repos — and it flagged the core vulnerability in 37 of them before I'd finished reading the file myself.
That's not a benchmark score. That's a threat model.
The Setup
I run infrastructure audits for a handful of fintech and healthcare clients, and cryptographic misuse is the bug class that keeps showing up no matter how many times it gets patched.
Not broken algorithms — nobody's cracking AES. **Broken implementations**: reused IVs, ECB mode, weak randomness for key material, JWTs that trust the wrong header.
In late June 2026 I decided to test something I'd been putting off.
I built a set of 40 code samples — real production patterns, sanitized of identifying details — spanning Python, Go, JavaScript, and Java. Each one had exactly one cryptographic flaw.
I fed them to Claude Sonnet 5 one at a time with a single prompt: "Review this code for security issues. Be specific about what's wrong and why."
No hints. No "there's a crypto bug here." Just the code, like a junior engineer would paste it into a PR description.
What Claude Actually Found
Here's where it stopped being a fun experiment and started keeping me up at night.
The ECB Mode Giveaway
The classic test case: encrypt an image with AES in ECB mode and watch the outline of the original image bleed through the ciphertext. Every security course uses the "encrypted penguin" to teach this.
Claude didn't need the image — it read the mode string in the code (`AES/ECB/PKCS5Padding`) and immediately called out that ECB mode encrypts identical plaintext blocks into identical ciphertext blocks, meaning patterns in the source data survive encryption entirely.
It then named the specific real-world incident this class of bug caused (Adobe's 2013 password breach, where ECB-encrypted password hints leaked structural information about the passwords themselves).
That's not pattern matching on syntax. That's Claude connecting a code smell to twelve-year-old incident history without being asked to.
Nonce Reuse in AES-GCM
This one worried me more.
I gave Claude a Go snippet where a developer had — reasonably, on the surface — generated a nonce once at service startup and reused it across every encryption call for performance reasons.
AES-GCM is only secure if the nonce is unique per message with a given key. Reuse it twice, and an attacker can XOR the two ciphertexts together and start recovering plaintext.
Claude flagged it instantly: "This nonce is generated once and reused across all `Seal()` calls.
For AES-GCM this is a catastrophic failure — nonce reuse under the same key allows an attacker to recover the XOR of two plaintexts and, with partial known-plaintext, full key-stream recovery." It then rewrote the function to generate a fresh nonce per call using `crypto/rand`.
I've seen senior engineers ship this exact bug. I've fixed it in production twice this year alone.
JWT alg=none Still Works in 2026
The oldest trick in the book, and it's still out there. I handed Claude a Node.js auth middleware that decoded JWTs without pinning the expected algorithm.
Claude caught that the code trusted the `alg` field from the token header itself — meaning an attacker can set `alg: none`, strip the signature, and forge a valid-looking token with any claims they want.
It matters more now than it did five years ago, because so much of this code is scaffolded by AI coding assistants that copy patterns from wherever they were trained.
**Nobody hand-writes broken JWT validation on purpose. It gets copy-pasted from a decade-old Stack Overflow answer and never revisited.**
The Reality Check
Before this turns into an AI-solves-security victory lap, let's be honest about where it fell apart.
Claude missed 3 of the 40 — all three were **timing-based side channels**, where the vulnerability lives in *how long the code takes to run*, not in what the code says.
String comparison for HMAC verification using `==` instead of a constant-time compare is invisible in a static read.
Claude didn't catch it in two of the three cases, and in the third it noted "consider constant-time comparison" without explaining why the timing difference is exploitable at all.
It also has no way to verify anything against a running system.
It can't tell you whether your actual random number generator is seeded properly at runtime, whether your HSM is configured correctly, or whether the vulnerable code path is even reachable from an unauthenticated endpoint.
Static review, however sharp, is still static review.
And here's the part that should worry you more than it worries me: **this works exactly as well for the people you don't want using it.** I'm not describing some jailbroken red-team-only capability — this is the same Claude Sonnet 5 anyone can hit through the API.
A single script pointed at a list of public GitHub repos could triage thousands of cryptographic implementations by tomorrow morning, sorting them by exploitability, at a cost measured in dollars, not analyst-hours.
The Practical Takeaway
If you ship anything with custom cryptographic code — and "custom" often just means "copy-pasted from a tutorial" — do this now:
- **Run your crypto-adjacent files through a frontier model with a blunt prompt.** Not "is this secure" (too vague, invites a rubber stamp).
Use "find the specific cryptographic flaw in this code and explain the exploit" — specificity in the prompt produces specificity in the answer.
- **Don't trust it for timing attacks or runtime config.** Pair AI static review with actual dynamic testing — Burp, a real pentest, or at minimum a constant-time-comparison linter.
- **Treat any hit as page one of the investigation, not the last page.** Claude will tell you nonce reuse is happening.
It won't tell you which production keys have already been compromised because of it.
- **Assume attackers are already doing this.** If a $200/month API budget can triage your entire public codebase for crypto bugs overnight, budget your patching cycles like that's already happening — because for anyone motivated enough, it is.
The uncomfortable truth is that this doesn't require a nation-state adversary or a bespoke fuzzing harness anymore. It requires curiosity and an API key.
I'm not writing this to sell you on AI security tooling — I'm writing it because I found bugs in nine minutes that would've taken me a full workday two years ago, and I don't think enough people have priced in what that means for the other side of the table.
Have you run your own crypto code through a frontier model yet, or are you assuming your implementation is the exception? Let's talk in the comments — I want to know what it finds in yours.
---
**Marcus Webb** — Infrastructure engineer turned tech writer. Writes about AI, DevOps, and security.
---
