JWT Exploitation

JWT exploitation forges tokens with modified claims (elevated roles, different user IDs, or admin flags) by exploiting weaknesses identified in JWT vulnerability testing. The goal is accepting a forged token that grants higher access than the original. Before forging, decode the original token and map every claim. The payload often contains role, sub, admin, user_id, or group fields. Know which claims the application uses for access control before choosing an attack path.

JWT token forgery exploitation techniques covered here:

• None algorithm forgery to strip the signature entirely
• Weak secret cracking with hashcat and resigning with the recovered key
• Algorithm confusion (RS256 to HS256) using the public key as HMAC secret
• User ID and role claim modification for privilege escalation

JWT Token Forgery via None Algorithm

Create a token with alg:none and no signature. Modify the payload to escalate privileges before encoding. The forged token has two dots and no third segment. That absent signature is the attack. Send it in the Authorization header and observe the response. A 200 with elevated data confirms the server accepted the unsigned token. A 401 or 403 means the library rejects alg:none. Some libraries block only the exact lowercase string none. Try None, NONE, and mixed-case variants if the first attempt fails. jwt_tool generates all case variations automatically with -X a.

Weak Secret: Resign with Cracked Key

After cracking the HMAC secret with hashcat, resign a modified token using the recovered key. The hashcat output format is token:secret. Everything after the colon is the signing secret. If --show returns nothing, the secret is not in rockyou. Try a wordlist built from the application name, the domain, and version strings found during enumeration. A cryptographically random secret of sufficient length cannot be cracked this way. Once you have the secret, jwt_tool resigns the modified payload with a valid HS256 signature. The server accepts the forged token because the signature verifies correctly. With signing control you can modify any claim freely.

Algorithm Confusion: RS256 to HS256

When the server uses RS256 and the public key is accessible, sign an HS256 token using the public key as the HMAC secret. The server expects RS256 but receives a token claiming HS256. A vulnerable library then verifies the HS256 signature using the public key as the HMAC secret. You sign with that same public key. Signatures match. The JWKS endpoint at /.well-known/jwks.json is the most common source. Also check /api/keys, /jwks, and the application's OAuth metadata URL. If no JWKS endpoint exists, look for a PEM in the application source or documentation. The attack fails when the library enforces a fixed expected algorithm regardless of the token header. PyJWT and jsonwebtoken patched this class of vulnerability in recent major versions. Older deployments and custom validation middleware remain viable targets.

Modify User ID Claim

When the token contains a user ID or sub claim, forge a token with the admin user's ID after discovering it through IDOR testing or user enumeration. User ID 1 is the most common admin identifier. It is typically the first account created. If that fails, try 0, 2, and 3. Some applications use UUIDs in the sub claim rather than integers. Find a valid admin UUID through IDOR or exposed API responses before forging. A successful response returns data belonging to the target account, confirming the server trusts the forged claim without secondary validation. This technique requires a cracked or otherwise known HMAC secret. Without a valid key the forged signature will be rejected.

When none of these techniques succeed, the application likely enforces algorithm pinning or uses a patched library. Not all endpoints apply the same validation. Check mobile API routes, legacy paths, and password-reset flows. They sometimes use a different token parsing path with weaker controls. Also verify the token is consumed by the endpoint you are targeting. Swap the payload to nonsense values and check whether behavior changes. No change means the token is ignored there. When algorithm confusion fails, confirm the JWKS key matches the key currently active for signing. Key rotation breaks the attack until you fetch the updated key.