JWT Verification Review: test results

Verdicts

Date

2026-10-26

Strong · claude-sonnet-5-5 (Claude Code alias "sonnet")

Right on all 3 cases, read by hand. On the orders middleware it found the expiry check switched off and the secret typed into the source, and left out the algorithm list fixed to one name and the audience compared in a second step. On the session reader it found the algorithm taken from the token header and the admin decision read with decode, and left out the header read for the key id and the audience and issuer already passed to verify. On the clean billing verifier it answered exactly No findings.

Weak · claude-haiku-5-5 (Claude Code alias "haiku")

Right on all 3 cases, read by hand. It matched the strong model on both planted modules, with sound fixes, and kept every safe look-alike out of its list: the fixed algorithm list, the second-step audience check, the key-id read and the key loaded from a file. On the clean verifier it answered exactly No findings.

Note

Light test: three cases (two planted, one clean), one run per model; no comparison without the skill. The three inputs were written by us in Node with the jsonwebtoken library; each planted one carries a safe look-alike and neither planted case has a comment pointing at the defect. The rule that an expiry check must not be switched off is the skill's own policy, because the standards do not demand an exp claim. Facts come from RFC 8725 and RFC 7519, read on 26 October 2026; there are no owner-measured facts.

What was not measured

• Models other than the two named above were not run.
• Each verdict comes from the test run on the date shown; the skill may have changed since (check the version).
• Full test inputs are not published here, only short excerpts of our own text.
• Results on your own texts, languages and domains can differ.