Post cover image

November 2, 2026

Common JWT Vulnerabilities and How to Test Them (Safely)

Free Link

By Vipul Sonule

8 min read

Hi, I'm Vipul — the human behind TheHackersLog.

I spend a lot of time exploring cybersecurity, ethical hacking, reconnaissance, web security, AI, and the tools that make security research more practical.

JWTs are one of those things that look deceptively simple. Three base64 blobs separated by dots, and suddenly your app has "stateless auth." But the number of real-world bug bounty reports that boil down to "the server trusted the token too much" is honestly kind of wild. Most JWT bugs aren't cryptographic breakthroughs — they're implementation shortcuts that nobody double-checked.

This article is for developers who want to understand how their own auth system could fail, and for security researchers who want a structured way to test JWT implementations in authorized environments — labs, CTFs, or in-scope bug bounty targets.

⚠️ Ethical Testing Note: Only test these techniques against systems you own, CTF/lab environments, or targets where you have explicit written authorization. Never test production auth flows you don't control.

1. What a JWT Actually Is (Quick Refresher)

A JWT (JSON Web Token) has three parts:

header.payload.signature

Each part is base64url-encoded, not encrypted. That distinction matters more than people realize — anyone who intercepts a JWT can read the payload instantly.

bash

echo "eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9" | base64 -d

What this does: base64 -d decodes the header segment. You'll usually see something like:

json

{"alg":"HS256","typ":"JWT"}

That alg field is the first thing a researcher looks at, because it tells the server which algorithm to use to verify the signature — and that's exactly where a lot of these vulnerabilities live.

None

2. The "alg: none" Vulnerability

This is the classic one, and it still shows up in poorly maintained systems.

Some JWT libraries historically accepted "alg": "none" as a valid algorithm — meaning the server would accept a token with no signature at all, as long as the structure looked right.

Lab Example:

bash

# Decode the header
echo '{"alg":"none","typ":"JWT"}' | base64 | tr -d '='
# Decode the payload (edit role/user fields here)
echo '{"user":"admin","role":"admin"}' | base64 | tr -d '='

Combine them with a trailing dot and an empty signature:

eyJhbGciOiJub25lIiwidHlwIjoiSldUIn0.eyJ1c2VyIjoiYWRtaW4iLCJyb2xlIjoiYWRtaW4ifQ.

If the server's verification logic doesn't explicitly reject none, this gets accepted as a valid token with a forged payload.

Why this happens: Developers often use generic "decode" functions instead of "verify" functions, or they allow the algorithm to be dynamically read from the token header instead of hardcoding what's expected.

What to check as a researcher: Does the server let the client dictate the algorithm? If yes, that's a design flaw worth flagging regardless of whether none specifically works.

3. Algorithm Confusion (RS256 → HS256)

This one trips people up because it sounds abstract until you see it in action.

Many apps use RS256 (asymmetric — public/private key pair) for signing. The server has a private key to sign tokens and a public key to verify them. The public key is, by definition, public — it might be exposed via a /jwks.json endpoint, embedded in client-side JS, or just guessable.

Here's the issue: if the server's verification code doesn't strictly check which algorithm is being used, an attacker can:

  1. Grab the server's public key
  2. Craft a new token with "alg": "HS256"
  3. Sign that token using the public key as the HMAC secret

If the backend library just says "verify this signature with whatever key I have," and that key happens to be the public RSA key being used as an HMAC secret, the forged token verifies as legitimate.

bash

# Fetch the public key (if exposed)
curl -s https://target-lab.example/.well-known/jwks.json | jq .

What jq does here: it pretty-prints the JSON Web Key Set so you can actually read the key material instead of a single long string.

Tools like jwt_tool automate this attack:

bash

python3 jwt_tool.py <token> -X k -pk public_key.pem

This tells jwt_tool to attempt the RS256-to-HS256 confusion attack using the provided public key.

🔗 jwt_tool:

GitHub — ticarpi/jwt_tool: :snake: A toolkit for testing, tweaking and cracking JSON Web Tokens snake: A toolkit for testing, tweaking and cracking JSON Web Tokens — ticarpi/jwt_tool

Defensive takeaway: always pin the expected algorithm on the server side. Never derive trust from a field the attacker controls.

4. Weak Signing Secrets (Brute-Forceable HMAC)

If a server uses HS256 with a weak, short, or guessable secret (secret123, changeme, the app name, etc.), you can brute-force it offline.

bash

hashcat -a 0 -m 16500 jwt.txt rockyou.txt

Breaking this down:

  • -a 0 — straight dictionary attack mode
  • -m 16500 — hashcat's module for JWT (HS256) cracking
  • jwt.txt — the captured token
  • rockyou.txt — common wordlist

If the secret is in the wordlist, hashcat recovers it, and now you can forge arbitrary valid tokens.

You can also do this manually with Python for smaller, targeted wordlists:

python

import jwt
token = "eyJhbGciOiJIUzI1NiIs..."
wordlist = ["secret", "changeme", "mysecretkey", "admin123"]
for word in wordlist:
    try:
        decoded = jwt.decode(token, word, algorithms=["HS256"])
        print(f"[+] Secret found: {word}")
        print(decoded)
        break
    except jwt.InvalidSignatureError:
        continue

What this script does: it tries each candidate secret against the token until one produces a valid signature. This is slow compared to hashcat's GPU-accelerated cracking, but it's useful for quick manual checks during a lab exercise.

🔗 PyJWT docs:

Welcome to PyJWT — PyJWT 2.15.1 documentation is a Python library which allows you to encode and decode JSON Web Tokens (JWT). JWT is an open, industry-standard (…

5. kid (Key ID) Header Injection

The kid field tells the server which key to use for verification — useful when multiple keys are in rotation. The problem is when the server trusts the kid value without sanitizing it.

Two common abuse paths:

SQL Injection via kid:

json

{"alg":"HS256","kid":"1' UNION SELECT 'attacker_secret'-- -"}

If the server builds a SQL query using the kid value to fetch the key, this can inject a secret the attacker already knows.

Path traversal via kid:

json

{"alg":"HS256","kid":"../../../../dev/null"}

Some implementations read the key from a file path derived from kid. If /dev/null resolves and an empty string is treated as a valid HMAC secret, you can forge a token with an empty secret.

What a researcher should look for: does changing kid cause different error messages, delays, or behavior? That's a signal the value is being used somewhere sensitive (database lookup, file path, cache key) without validation.

6. jku / x5u Header Injection

jku points to a URL hosting a JSON Web Key Set; x5u points to a URL hosting an X.509 certificate chain. If the server fetches the key from whatever URL is in the token header — without restricting it to trusted domains — an attacker can:

  1. Host their own JWKS on a server they control
  2. Sign a forged token with their own private key
  3. Set jku to point at their hosted key
  4. The server fetches and trusts the attacker's key, verifying the forged signature as valid

Lab Example:

bash

# Host a fake JWKS
python3 -m http.server 8000

Then craft a header like:

json

{"alg":"RS256","typ":"JWT","jku":"http://attacker-lab.local:8000/jwks.json"}

What a defender should enforce: a strict allowlist of trusted jku/x5u domains, and ideally avoid trusting externally-supplied key URLs at all.

7. Missing Expiration / Replay Issues

A lot of JWT implementations forget to actually check exp (expiration) server-side, relying only on the client to "expire" naturally. This means a captured token (via XSS, logs, proxy history, etc.) can be replayed indefinitely.

bash

curl -s -I https://target-lab.example/api/account \
  -H "Authorization: Bearer <captured_token>"

What to check: does the request still succeed hours or days after the token should have expired? Is there any server-side revocation mechanism, or is the token valid purely based on its own claims until the signature check?

Why this matters: stateless auth is convenient, but it also means there's often no central place to revoke a compromised token before its natural expiry.

8. Sensitive Data Stored in the Payload

Because JWTs are only encoded, not encrypted, I still see payloads with things like:

json

{
  "user_id": 1092,
  "email": "user@example.com",
  "role": "admin",
  "internal_notes": "flagged for review",
  "password_hash": "..."
}

That last one happens more than you'd think — someone serializes an entire user object into the token without thinking about what "encoded" versus "encrypted" actually means.

bash

echo "<payload_segment>" | base64 -d | jq .

This instantly reveals anything stuffed into the token. If you find PII, internal flags, or hashes in there, that's worth reporting even without a signature bypass.

🧠 Questions I Ask When Testing JWT Implementations

  • Can I change alg to none and have it accepted?
  • Can I flip RS256 to HS256 using the public key as the secret?
  • Is the signing secret weak enough to brute-force offline?
  • Does kid get used in a query, file path, or cache key without sanitization?
  • Does the server fetch jku/x5u from an arbitrary URL?
  • Is exp actually enforced server-side, or just assumed?
  • What's sitting in the payload that shouldn't be readable by anyone with the token?
  • Is there a revocation/blacklist mechanism for logout or password changes?

Tools generate leads. Deciding which of these actually matters for the target's business logic is still a human job.

⚠️ Common Mistakes

  • Testing alg: none and stopping there. Most modern libraries block it by default — don't assume the whole app is secure just because this one check passes.
  • Assuming RS256 is automatically safe. It's only safe if the server strictly enforces which algorithm it expects.
  • Treating a readable payload as "not a vulnerability." Sensitive data exposure is still a valid, reportable finding even without signature forgery.
  • Ignoring expiration testing. It's easy to skip because it's "boring," but replay windows are a real issue.
  • Not checking kid behavior. This one gets missed constantly because it doesn't look like an obvious attack surface at first glance.
  • Forgetting to check revocation. A token being "technically valid" post-logout or post-password-change is a legitimate finding.

🛡️ Defensive Perspective

If you're building or maintaining a system that uses JWTs:

  • Hardcode the expected algorithm server-side. Never trust the alg field from the token itself.
  • Use strong, high-entropy secrets for HMAC (32+ random bytes, not a dictionary word).
  • Validate kid against a known, fixed set of key identifiers — never use it directly in a query or file path.
  • Restrict jku/x5u to an explicit allowlist of trusted hosts, or avoid supporting them entirely.
  • Always enforce exp server-side, and consider short-lived access tokens with refresh token rotation.
  • Avoid putting sensitive data in the payload — treat it as readable by anyone who holds the token.
  • Maintain a revocation strategy for logout, password resets, or compromised sessions (a short-lived token plus a server-side session check, for example).
None

🛠️ Tools Worth Exploring

jwt_tool — A dedicated JWT testing toolkit that automates algorithm confusion, none attacks, kid injection testing, and more. 🔗 https://github.com/ticarpi/jwt_tool

Burp Suite (JWT Editor extension) — Lets you intercept, decode, and re-sign JWTs directly inside Burp's proxy history, which is extremely useful for manual testing during a live assessment. 🔗 https://portswigger.net/burp

hashcat — GPU-accelerated password/secret cracking, including a dedicated module for JWT HMAC secrets. 🔗 https://hashcat.net/hashcat/

jq — Command-line JSON processor, useful for quickly reading decoded JWT payloads and JWKS responses. 🔗 https://jqlang.github.io/jq/

PyJWT — Python library for encoding/decoding JWTs, useful for scripting custom test cases. 🔗 https://pyjwt.readthedocs.io/

OWASP JWT Cheat Sheet — A solid reference for secure implementation patterns and known pitfalls. 🔗 https://cheatsheetseries.owasp.org/cheatsheets/JSON_Web_Token_for_Java_Cheat_Sheet.html

If you're building a structured recon and testing workflow around authentication mechanisms like this, I put together a more complete reference in my Advanced Bug Bounty Recon Mastery resource — it covers methodology beyond just JWTs. 🔗 https://thehackerslog.gumroad.com/l/advancedbugbountyreconmastery

And if you want a compact, no-fluff reference of commands you can pull up mid-assessment instead of digging through old notes, I keep one in my Hacker's Recon Cheat Sheet (150+ Commands). 🔗 https://thehackerslog.gumroad.com/l/reconcheetsheet

👋 Keep Exploring With TheHackersLog

TheHackersLog covers practical, hands-on content around cybersecurity, ethical hacking, bug bounty methodology, reconnaissance, web security, network security, AI security, OSINT, and programming.

📝 Substack: https://thehackerslog.substack.com/ ✍️ Medium: https://medium.com/@vipulsonule71 💼 LinkedIn: https://www.linkedin.com/company/thehackerslog/ 🐦 X: https://x.com/VipulSonule 🛒 Gumroad: https://thehackerslog.gumroad.com/

📣 Final Thoughts

JWT vulnerabilities aren't usually about breaking cryptography — they're about servers trusting fields they shouldn't, and researchers knowing exactly which fields to poke at.

If this guide helped you understand JWT testing a bit better, follow TheHackersLog for more practical cybersecurity, ethical hacking, AI, and technology content.

And if you've run into a JWT implementation quirk I didn't cover here, drop it in the comments — I'm always interested in seeing how other researchers approach the same problem. 🔐