I Changed One Value in a JWT and Became Admin: The 7 Deadliest JWT Attacks Every Developer Must Know

Listen to this Post

🐢▶️ Listen🚀

Introduction

JSON Web Tokens (JWTs) have become the de facto standard for authentication and authorization in modern web applications. However, their flexibility often leads to critical misconfigurations that attackers can exploit with nothing more than a text editor and a basic understanding of Base64. From missing signature verification to algorithm confusion, these flaws can grant unauthorized access, privilege escalation, and full account takeover. This article dissects the seven most dangerous JWT attack vectors, provides step‑by‑step exploitation guides, and arms you with the commands and tools to test and secure your own implementations.

Learning Objectives

• Understand the structure of a JWT and how to decode its parts.
• Identify and exploit common JWT vulnerabilities such as algorithm “none”, weak secrets, and header injection.
• Apply practical testing techniques using tools like jwt_tool, Burp Suite, and hashcat.
• Implement robust mitigation strategies to protect JWT‑based authentication systems.

You Should Know

1. Anatomy of a JWT and Base64 Decoding

A JWT consists of three Base64URL‑encoded parts separated by dots:

`HEADER.PAYLOAD.SIGNATURE`

Step‑by‑step guide

1. Capture a JWT from a request (e.g., via browser dev tools or Burp Suite).
2. Decode the header and payload separately using the command line:

   Decode header (first part)
   echo 'eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9' | base64 -d 2>/dev/null
   Decode payload (second part)
   echo 'eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkpvaG4gRG9lIiwiaWF0IjoxNTE2MjM5MDIyfQ' | base64 -d 2>/dev/null
   

On Windows (PowerShell):

3. Observe the plaintext JSON. Any modification to the payload will invalidate the signature unless the server fails to verify it.

2. Attack 1: Missing Signature Verification

Some servers decode the JWT but never check the signature, trusting the client‑supplied data blindly.

Step‑by‑step exploitation

1. Intercept a request containing a JWT (e.g., in Burp Suite).

2. Copy the token and decode the payload.

1. Change a claim value, for example, `”role”: “user”` to "role": "admin".
2. Re‑encode the modified payload to Base64URL (remove padding `=` and replace +// with -/_).
3. Reassemble the token: keep the original header and signature, but insert the new payload.
4. Send the request. If the server grants admin access, the signature was never verified.

Command‑line example (Linux)

 Original token (split parts)
HEADER="eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9"
PAYLOAD="eyJzdWIiOiIxMjM0Iiwicm9sZSI6InVzZXIifQ"
SIG="abc123..."

Decode payload, modify with jq, re-encode
echo "$PAYLOAD" | base64 -d | jq '.role="admin"' | base64 | tr -d '\n=' | tr '/+' '_-'
NEWPAYLOAD="eyJzdWIiOiIxMjM0Iiwicm9sZSI6ImFkbWluIn0"
NEWTOKEN="$HEADER.$NEWPAYLOAD.$SIG"
curl -H "Authorization: Bearer $NEWTOKEN" https://victim.com/admin

3. Attack 2: Algorithm “None”

The JWT specification allows the `”alg”:”none”` header to indicate unsecured tokens. Misconfigured servers may accept such tokens without any signature.

Step‑by‑step exploitation

1. Decode the header of a valid JWT.

1. Change the algorithm from `”HS256″` or `”RS256″` to "none".

3. Encode the modified header (Base64URL).

1. Remove the signature part entirely, leaving the token as `newheader.newpayload.` (note the trailing dot).
2. Submit the token. If accepted, the server trusts unsigned tokens.

Example

Original header: `{“alg”:”HS256″,”typ”:”JWT”}`

Modified header: `{“alg”:”none”,”typ”:”JWT”}`

Token: `eyJhbGciOiJub25lIiwidHlwIjoiSldUIn0.eyJyb2xlIjoiYWRtaW4ifQ.`

(No signature after the second dot.)

4. Attack 3: Weak Secret Brute‑Force (HS256)

If the server uses a symmetric HMAC algorithm (HS256) with a weak secret, an attacker can crack the secret offline and forge arbitrary tokens.

Step‑by‑step guide

1. Obtain a valid JWT (e.g., from a login response).

2. Extract the signature and the message (`header.payload`).

1. Use hashcat with mode 16500 (JWT) to brute‑force the secret:

   echo "eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiIxMjM0In0.signature" > jwt.txt
   hashcat -m 16500 jwt.txt /path/to/wordlist.txt --force
   

2. Once cracked, use the secret to generate a new token with elevated privileges.
   Online tool: jwt.io with the secret.

5. Attack 4: Algorithm Confusion (RS256 to HS256)

When a server expects an RSA‑signed token (RS256) but fails to enforce the algorithm type, an attacker can force the use of HMAC (HS256) and sign the token with the server’s own public key (which is often accessible).

Step‑by‑step exploitation

1. Retrieve the server’s public key (commonly from /jwks.json, .well-known/jwks.json, or even embedded in the client).
2. Convert the public key to the format suitable for HMAC (it becomes the secret).
3. Create a new token with the header changed to `{“alg”:”HS256″,”typ”:”JWT”}` and the payload modified.
4. Sign the token using the public key as the HMAC secret.
5. Send the token. The server will verify it using its public key as the HMAC secret, succeeding.

Tool: `jwt_tool` has a module for this:

python3 jwt_tool.py <JWT> -X a -pk public_key.pem

6. Attack 5: Header Injection (jwk, jku, kid)

The JWT header can contain fields that point to the key used for verification. Attackers can inject malicious values.

• jwk (JSON Web Key): Embed a public key directly in the header. If the server accepts it, the attacker can sign tokens with the corresponding private key.
• jku (JSON Web Key Set URL): Point to an external URL hosting a malicious JWK set.
• kid (Key ID): Used to look up the key. If the server uses the `kid` in a file path or database query, it may lead to path traversal or SQL injection.

Step‑by‑step (jwk injection)

1. Generate a new RSA key pair.

1. Embed the public key as a JWK in the header.

3. Sign the token with the private key.

1. Submit the token. If the server trusts the embedded key, the signature validates.

Tool: `jwt_tool` can automate this:

python3 jwt_tool.py <JWT> -I -hc header -hv jwk -pk private_key.pem

7. Attack 6: Claim Tampering (Privilege Escalation)

Beyond simply changing role, many applications store critical data in the JWT payload, such as is_admin, user_id, or email. If the signature is not verified, any claim can be forged.

Step‑by‑step guide

1. Decode the payload and look for interesting claims.
2. Modify them (e.g., `”admin”: false` → "admin": true).

3. Re‑encode and submit.

1. For a more subtle test, change the `user_id` to another user’s ID to impersonate them.
2. If the server uses the JWT for authorization without additional checks, you gain unauthorized access.

Burp Suite tip: Use the “JSON Web Token” extension to automatically decode, edit, and re‑encode tokens within the proxy.

8. Attack 7: Token Lifetime Abuse

Many JWTs include `exp` (expiration) and `nbf` (not before) claims. If the server does not validate these, tokens can be replayed indefinitely.

Step‑by‑step exploitation

1. Capture a valid token.

1. Remove the `exp` claim or set it to a far‑future date.

3. Submit the modified token.

1. Also, check if the server accepts tokens before their `nbf` time.
2. If successful, the token never expires, allowing persistent access.

Testing with curl

 Modify exp to year 2030
 Re-encode and send
curl -H "Authorization: Bearer <modified_token>" https://victim.com/protected

9. Mitigation and Best Practices

• Always verify the signature using a trusted library. Never skip validation.
• Enforce a strict algorithm whitelist (e.g., reject `none` and algorithm confusion).
• Use strong secrets (at least 32 bytes random) for HMAC.
• Rotate keys regularly and implement short token lifetimes.
• Validate all claims – exp, aud, iss, etc.
• Avoid embedding sensitive data in the payload; use server‑side sessions if needed.
• Employ bound tokens (e.g., include client IP or fingerprint) to prevent replay.
• Test your implementation with tools like `jwt_tool` and automated scanners.

What Undercode Say

• Key Takeaway 1: JWT attacks often stem from a fundamental misunderstanding: tokens are not “magic” – they are just data. Without cryptographic verification, they are as trustworthy as a URL parameter.
• Key Takeaway 2: The most severe flaws (algorithm none, missing signature check) are trivially easy to exploit yet remain pervasive because developers rely on client‑side validation or incomplete library defaults.

Analysis: The simplicity of these attacks underscores a gap between JWT adoption and secure implementation. While the specification provides flexibility, it also leaves room for dangerous misconfigurations. Security training must emphasize that JWTs are bearer tokens – possession alone should not imply authorization. Continuous testing, both automated and manual, is essential. Platforms like webverselabs.com offer realistic labs to practice these attacks in a safe environment, bridging the knowledge gap for developers and pentesters alike.

Prediction

As JWT usage expands into microservices, serverless, and IoT, we will see a surge in automated tools that specifically target these seven vectors. AI‑driven security testing will soon be able to fuzz JWT headers and payloads intelligently, detecting misconfigurations before they reach production. However, attackers will also leverage AI to generate more convincing malicious tokens and discover novel bypasses. The arms race will force the industry to adopt stronger, context‑aware token validation – possibly moving toward ephemeral, one‑time‑use tokens and binding tokens to device fingerprints. The next generation of authentication protocols (like PASETO) may eventually replace JWT, but until then, understanding and mitigating these seven attacks remains a critical skill for every security professional.

🎯Let’s Practice For Free:

IT/Security Reporter URL:

Reported By: Leighlin Gunner – Hackers Feeds
Extra Hub: Undercode MoN
Basic Verification: Pass ✅

🔐JOIN OUR CYBER WORLD [ CVE News • HackMonitor • UndercodeNews ]

💬 Whatsapp | 💬 Telegram

📢 Follow UndercodeTesting & Stay Tuned:

𝕏 formerly Twitter 🐦 | @ Threads | 🔗 Linkedin | 🦋BlueSky