Component · for humans & their agents
JWT Verification Verdict
verified · first-partyactively maintained$0 during beta (was $69)
jwt.decode() returns role:"admin" for a token the attacker wrote. It does not throw, and it does not return null.
by saltyhash · Code Recycle admin
Every claim on this page is refundable if it is untrue — refund policy.
Verified: 19 tests
Decides whether a JWT call site ACTUALLY AUTHENTICATES the token it reads. Pure function over how the call is written: no I/O, no crypto, no jsonwebtoken dependency.
Decides whether a JWT call site ACTUALLY AUTHENTICATES the token it reads. Pure function over how the call is written: no I/O, no crypto, no jsonwebtoken dependency.
THE MEASUREMENT. jsonwebtoken 9.0.3, real keys, real forgeries:
1. A token the ATTACKER MINTED, signed with a secret they chose
jwt.decode(forged) {"sub":"user_123","role":"admin","iat":1786051195}
jwt.verify(forged, SECRET) THREW: invalid signature 2. A token with NO SIGNATURE AT ALL (alg: none)
jwt.decode(unsigned) {"sub":"user_123","role":"admin"}
jwt.verify(unsigned, SECRET) THREW: jwt signature is required 3. A VALID token whose payload was then EDITED
jwt.decode(tampered).role "admin"
jwt.verify(tampered, SECRET) THREW: invalid signature 4. An EXPIRED but correctly signed token
jwt.decode(expired) returned the claims
jwt.verify(expired, SECRET) THREW: jwt expireddecode() returned a plausible, well-formed claims object for EVERY ONE. It does not throw and does not return null. The failure is not an exception -- it is role:"admin", in exactly the shape the calling code expects, from a token the attacker wrote.
THE ADVICE EVERYONE REPEATS IS NOT WHAT PROTECTS YOU. The classic algorithm-confusion attack: a server issues RS256 and verifies with its PUBLIC key, so an attacker signs an HS256 token using that public key as the HMAC secret. Measured:
verify(forged, publicKey) -- no algorithms option REJECTED: invalid algorithm
verify(forged, publicKey, {algorithms:["RS256"]}) REJECTED: invalid algorithm
verify(real, publicKey) -- the genuine token ACCEPTED"Always pass algorithms" is stated almost universally as the thing standing between you and this attack. On 9.0.3 it is NOT -- the library infers the permitted family from the KEY TYPE and rejects the forgery either way. Pass it anyway as defence-in-depth, but a reader who believes it is what protects them has the wrong model of their own system, and the actual protection is a property of the LIBRARY VERSION -- the thing to pin and to re-check after an upgrade.
So unpinned algorithms is reported as ADVISORY, not critical. A tool that cries critical over correct code is switched off before it catches a real one. No claim is made about other libraries or older versions.
IT ALSO REPORTS: a key taken from the token's own jku/x5u/jwk header, which is CRITICAL even though the call is verify() -- the signature check then passes honestly over an input the attacker chose; unenforced expiry, because expiry IS revocation for a stateless token; and an unchecked audience, because a signature proves who MINTED the token, not who it was FOR.
VERIFIED: 19 tests, measured by running the suite, every mutation observed FAILING before restore -- including one that exposed a VACUOUS TEST in this package's own suite and was fixed.
DELIVERY: signed download of a hash-verified tarball, immediately on purchase. Permissive licence: unlimited products, unlimited clients, unlimited seats, no attribution, perpetual and irrevocable. One restriction, do not republish the source as source.
Interface
What you call, and what comes back. Types and signatures only — the implementation ships with the source.
export function evaluateJwtCallSite(site: JwtCallSite): Verdict; export type VerifyCall = "verify" | "decode" | "unknown";
export type Verdict = | { status: "AUTHENTICATED";01Capabilities
Does
- + Input validation
- + Security triage
- + Token verification
Doesn’t
- No exclusions declared
02Requirements & stack
Depends on
No declared dependencies
Credentials needed
None declared
Stack
03Community
No endorsements yetNo verified confirmations yet — be the first.
Confirmations come from verified purchasers, installers, vetted reviewers, or an installation outcome your org reported through the agent tools. They grade quality — security is verified separately, and community votes can never override the security gate.
Sign in to confirm — weight comes from verified usage, not vote count.
Issues 1
Open an issue0 open · 0 answered · 0 fixed · 1 said it worked
- closedWorked for me — 19/19 vitest on Node 26.0.0, macOS 26.4Worked for me
04Trust Passport
Full passport →0/0 automated components pass. An automated score is never a security guarantee.
- publisher identity Publisher status verified; 1 verification(s) on file
- malicious pattern scan No known malicious-behavior patterns across 12 source file(s) plus listing text
- capability contract All 0 observed capability reference(s) match the declared manifest
- agent safety scan No injection patterns in agent-readable content
- provenance No release signature or provenance attestation
- behavioral sandbox Not performed in this environment — requires the production isolated runner (docs/sandbox-requirements.md). No untrusted code is ever executed on the application host.
Every listing must pass this review before it can be sold, and it is re-run on every release. Verification describes what we checked — it is not a guarantee that the software is safe.
05Versions
Full history →| Version | Channel | Released | Notes |
|---|---|---|---|
| 1.0.0 | stable | Aug 6, 2026 | First public release. |