JWTweak v2.1: A Guided, Offline Toolkit for Modern JWT Attacks

Paste a token, get a full attack plan — then execute it, entirely offline.

JSON Web Tokens sit at the heart of modern authentication. The catch: the token lives in the user’s hands, not the server’s. One weak validation check on the backend, and an attacker can hand themselves an admin session.

That’s the exact gap JWTweak was built to probe.

It started life as a small script for flipping a token’s algorithm and re-signing it — enough to go hunting for classic JWT Algorithm Confusion bugs. Version 2.1 is a full rewrite: a guided, menu-driven toolkit. You paste a token, it decodes and risk-scores it, tells you which attacks are worth trying, and walks you through each one step by step. No flags to memorize, no internet connection required.

In this post, I’ll walk through what’s new in the tool, then break into a deliberately vulnerable app using two live proof-of-concept attacks.

Requirements

# Python 3.8+ (tested on Kali and macOS)
pip3 install pyjwt cryptography rich

pyjwt and cryptography are required. rich is optional — it powers the enhanced terminal UI, but the tool degrades gracefully to plain text without it.

What’s New in v2.1

• Smart decoding & risk analysis — detects the algorithm, pretty-prints header/payload, and flags red flags automatically: none/empty algorithm, weak HMAC secrets, risky jku/jwk/x5u/kid headers, missing or expired expiry.
• **alg:none generation** in four casings (none / None / NONE / nOnE) — because plenty of parsers only check one.
• Algorithm Confusion attack — signs an HS256 token using the target’s RSA/EC public key as the HMAC secret.
• Full re-signing support across HS256/384/512, RS256/384/512, PS256/384/512, ES256/384/512, and EdDSA.
• Key-resolution header injection — jwk (CVE-2018-0114), jku, x5u, and x5c, with an optional built-in local server to host a malicious JWKS/cert entirely offline.
• **kid injection** — path traversal, SQLi, and command-injection payloads baked in.
• Interactive claim tampering that chains directly into any signing attack.
• Offline HMAC secret cracking with a wordlist, plus a one-click forge using the recovered secret.
• “Run recommended suite” — auto-generates every applicable attack token and saves them for replay in Burp or a fuzzer.

Get it:

• Script: JWTweak.py
• Full project: GitHub

Meet the Target: Aegis Cloud

The repo ships a small, deliberately vulnerable app in poc/ — "Aegis Cloud" — so you can watch each attack land against a realistic login → dashboard → admin console flow, safely and locally.

It makes two classic mistakes on purpose:

1. It trusts alg:none.
2. It verifies tokens with a single public key while also accepting HS*, which means that public key can be reused as an HMAC secret.

Spin it up:

cd poc
pip install -r requirements.txt
python3 vulnerable_server.py        # http://127.0.0.1:5000

Log in with the prefilled demo credentials. You’ll land on a dashboard showing your session token and your role: user.

Try clicking Open Admin Console with that normal token — you’ll correctly get bounced with a 403 Access Denied. That’s our baseline. Each attack below turns that refusal into a full admin session.

PoC 1 — The alg:none Trick

The oldest trick in the book still works against plenty of real implementations: set the algorithm to none, drop the signature, and see if the server verifies... nothing.

Launch JWTweak and paste in the session token from your dashboard:

python3 ../JWTweak.py

Then walk the menu:

1. a — claim tampering
2. c — make admin
3. s — finish
4. y — apply
5. n — emit an alg:none copy

Copy the forged token, drop it into the dashboard’s Session token field, and open the Admin Console. The server accepts an unsigned, self-issued admin token without blinking. We’re in.

PoC 2 — Algorithm Confusion (RS256 → HS256)

This is the attack JWTweak was originally built for. The server expects RS256 tokens, verified against its RSA public key — but its verification code also accepts HS256. When it does, it feeds that same public key in as the HMAC secret.

The public key is, by definition, public. So we grab it the way an attacker would (plenty of apps expose theirs at a /jwks or .pem endpoint):

curl -s http://127.0.0.1:5000/public_key.pem -o public_key.pem

Run JWTweak again, paste the session token, then work the menu:

1. a → c → s → y → skip (escalate to admin)
2. 3 (Algorithm confusion)
3. Provide public_key.pem when prompted

Paste the resulting HS256 token into the dashboard and open the Admin Console. Accepted again — except this time the signature is cryptographically valid, forged entirely from public information.

Why These Attacks Work

Both PoCs trace back to one root cause: the server let the token decide how it would be verified. The algorithm, the kid, the jku/jwk headers — all attacker-controlled, yet fed straight into the verification path by vulnerable code.

alg:none disables verification outright. Algorithm confusion swaps which algorithm gets checked, so the server validates the wrong thing against the wrong key. Either way, the attacker is quietly choosing the rules the server uses to check its own security.

How to Fix It

• Pin the algorithm. Pass an explicit allow-list to your verify call — never read the algorithm from the token’s own header.
• Never cross key types. Keep symmetric secrets and asymmetric keys strictly separate. A public key should never double as an HMAC secret.
• Reject none. Don't accept unsecured JWTs, full stop.
• Ignore untrusted key headers. Don’t honor jwk, jku, or x5u from incoming tokens. Resolve keys from a trusted server-side store and match kid exactly.
• Use strong secrets, enforce claims. Long, random HMAC secrets, and always validate expiry (plus nbf / aud / iss where relevant).

JWTweak is free and open source: github.com/rishuranjanofficial/JWTweak

For education and ethical security testing purposes only.

Originally published on SecureThy.