JWT Attack Surface Deep Dive: 8 Critical Vulnerabilities Every Penetration Tester Must Exploit + Video

By /

Listen to this Post

Featured Image

Introduction:

JSON Web Tokens (JWTs) have become the de facto standard for stateless authentication in modern web applications, offering a compact, self-contained mechanism for transmitting claims between parties. However, the security of JWT-based systems hinges entirely on proper cryptographic implementation and rigorous server-side validation — not on the JWT specification itself. When developers misconfigure signature verification, mishandle key management, or trust attacker-controlled header parameters, these tokens transform from secure authentication mechanisms into powerful vectors for privilege escalation and complete account takeover. This article dissects eight critical JWT vulnerabilities demonstrated through PortSwigger’s Web Security Academy labs, providing penetration testers and bug bounty hunters with a comprehensive technical roadmap for identifying, exploiting, and mitigating these authentication bypass scenarios.

Learning Objectives:

  • Master the exploitation of eight distinct JWT implementation flaws, from unverified signatures to algorithm confusion attacks
  • Develop hands-on proficiency with Burp Suite Professional, JWT Editor extension, and cryptographic signing/verification workflows
  • Understand the underlying cryptographic principles — symmetric vs. asymmetric algorithms, JWK/JWKS structures, and key injection vectors — that govern JWT security

You Should Know:

1. Unverified Signature & Flawed Signature Verification

The most fundamental JWT implementation failure occurs when servers accept tokens without validating their cryptographic signatures. By design, servers typically do not store information about issued JWTs; each token is a self-contained entity. This statelessness offers scalability advantages but introduces a critical vulnerability: the server has no inherent knowledge of the token’s original content.

What This Vulnerability Enables:

When a server fails to verify JWT signatures, an attacker can arbitrarily modify the payload claims — changing the `sub` (subject) claim from `wiener` to `administrator` — and the server will accept the tampered token as legitimate. The JSON Web Token specification provides cryptographic signing to ensure data integrity and robust user authentication, but improper verification completely nullifies these protections.

Step-by-Step Exploitation (Burp Suite):

  1. Intercept the JWT: Log into the application and capture the post-login `GET /my-account` request using Burp Proxy. Observe that the session cookie is a JWT.

  2. Decode the Token: Double-click the payload portion of the token in Burp’s Inspector panel to view its decoded JSON structure. Identify the `sub` claim containing your username.

  3. Test Admin Access: Send the request to Burp Repeater, change the path to /admin, and observe that the admin panel is only accessible to the administrator user.

  4. Forge the Token: Select the payload in the Inspector panel, change the `sub` claim value from your username to administrator, and click Apply Changes.

  5. Exploit: Send the modified request. The server accepts the token without verifying the signature, granting administrative access.

Verification Command (Linux/macOS):

 Decode JWT payload without verification (base64url decode)
echo "eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiJ3aWVuZXIifQ" | cut -d. -f2 | base64 -d 2>/dev/null || echo "eyJzdWIiOiJ3aWVuZXIifQ" | base64 -d

2. Weak Signing Keys

When applications use symmetric algorithms like HS256 (HMAC with SHA-256), the security of the entire authentication system collapses to the strength of a single secret key. Developers often choose weak, predictable secrets — secret, password, `secret1` — that can be brute-forced in seconds using publicly available wordlists.

Step-by-Step Brute-Force Exploitation:

  1. Capture the JWT: Log in with provided credentials and intercept the JWT in the `Authorization` header or session cookie.

  2. Brute-Force with Hashcat: Use Hashcat mode 16500 (JWT) with a comprehensive JWT secrets wordlist:

 Clone the JWT secrets wordlist
git clone https://github.com/wallarm/jwt-secrets
 Brute-force the JWT secret
hashcat -a 0 -m 16500 <YOUR-JWT> /path/to/jwt.secrets.list

Hashcat outputs the JWT followed by the discovered secret. In the PortSwigger lab, the weak secret is secret1.

  1. Encode the Secret: Use Burp Decoder to Base64-encode the brute-forced secret.

  2. Create a Symmetric Key in Burp: Navigate to the JWT Editor Keys tab, click New Symmetric Key, generate a new JWK, and replace the `k` property value with your Base64-encoded secret.

  3. Forge the Admin Token: In the JSON Web Token editor tab, change the `sub` claim to administrator, click Sign, select your symmetric key, and ensure “Don’t modify header” is selected.

  4. Access the Admin Panel: Send the request to `/admin` and delete user carlos.

3. JWK Header Injection

The `jwk` (JSON Web Key) header parameter allows the server to embed the verification key directly within the token itself. When the server fails to validate that this key originates from a trusted source, attackers can generate their own RSA key pair, embed the public key in the `jwk` header, and sign tokens with their corresponding private key.

Step-by-Step JWK Injection:

  1. Generate an RSA Key Pair: In Burp’s JWT Editor Keys tab, click New RSA Key and Generate a new key pair.

  2. Modify the Token: In the JSON Web Token tab, change the `sub` claim to administrator.

  3. Embed the JWK: Click Attack → Embedded JWK, select your RSA key, and click OK. Burp automatically adds a `jwk` header containing your public key.

  4. Send the Request: The server accepts the token signed with your private key and verifies it using the embedded public key.

Manual JWK Embedding (Alternative):

{
"alg": "RS256",
"jwk": {
"kty": "RSA",
"e": "AQAB",
"kid": "your-key-id",
"n": "your-public-key-modulus"
}
}

4. JKU Header Injection

The `jku` (JWK Set URL) header parameter specifies a URL from which the server should fetch the JSON Web Key Set for verification. When servers fail to validate that the URL belongs to a trusted domain, attackers can host a malicious JWK Set on an exploit server and point the `jku` header to it.

Step-by-Step JKU Exploitation:

  1. Generate an RSA Key Pair: In Burp’s JWT Editor Keys tab, create a new RSA key pair.

  2. Host a Malicious JWK Set: On the exploit server, create a JWK Set containing your public key:

{
"keys": [
{
"kty": "RSA",
"e": "AQAB",
"kid": "your-key-id",
"n": "your-public-key-modulus"
}
]
}
  1. Copy the Public Key as JWK: Right-click your RSA key in Burp, select Copy Public Key as JWK, and paste it into the `keys` array on the exploit server.

  2. Modify the JWT Header: Add a `jku` parameter pointing to your exploit server’s JWK Set URL. Update the `kid` parameter to match the `kid` of your hosted JWK.

  3. Change the Payload: Set the `sub` claim to administrator.

  4. Sign and Exploit: Sign the token with your RSA private key and send the request.

5. kid Header Path Traversal

The `kid` (Key ID) header parameter is intended to identify which key should be used for verification. When servers unsafely use `kid` as a filesystem path without sanitization, attackers can perform path traversal to force the server to use a predictable file — such as `/dev/null` (which is always empty) — as the verification key.

Step-by-Step Path Traversal Exploitation:

  1. Generate a Symmetric Key with Empty Secret: In Burp’s JWT Editor Keys tab, click New Symmetric Key, Generate a new key, then replace the `k` property with an empty string.

  2. Modify the JWT Header: Change the `kid` parameter to a path traversal sequence pointing to /dev/null: ../../../../../../../dev/null.

  3. Change the Payload: Set the `sub` claim to administrator.

  4. Sign the Token: Click Sign, select your symmetric key (with empty secret), and ensure “Don’t modify header” is selected.

  5. Exploit: The server reads `/dev/null` (empty content) as the verification key, accepts the token, and grants administrative access.

6. Algorithm Confusion (HS256 ↔ RS256)

Algorithm confusion attacks occur when attackers force the server to verify a JWT using a different algorithm than intended. This vulnerability typically arises when JWT libraries provide algorithm-agnostic verification methods that rely on the `alg` header parameter to determine the verification type.

The Cryptographic Flaw:

When a server expects RS256 (asymmetric RSA) but receives a token with `alg` set to HS256 (symmetric HMAC), the generic verification method treats the RSA public key as an HMAC secret. An attacker can therefore sign a token using HS256 and the server’s own public key, and the server will accept it as valid.

Step-by-Step Algorithm Confusion Exploitation (Exposed Key):

  1. Obtain the Server’s Public Key: Access the standard endpoint `/jwks.json` or `/.well-known/jwks.json` to retrieve the server’s public JWK.

  2. Import the Public Key as RSA: In Burp’s JWT Editor Keys tab, click New RSA Key, select the JWK option, and paste the copied JWK.

  3. Convert to PEM and Base64: Right-click the imported RSA key, select Copy Public Key as PEM. Use Burp Decoder to Base64-encode this PEM.

  4. Create a Symmetric Key with the Public Key: Click New Symmetric Key, Generate a new JWK, and replace the `k` property with the Base64-encoded PEM.

  5. Modify the Token: Change the `alg` header to `HS256` and the `sub` claim to administrator.

  6. Sign with the Symmetric Key: Sign the token using the symmetric key (which contains the server’s public key as the HMAC secret).

7. Algorithm Confusion with No Exposed Key

When the server does not expose its public key via a standard endpoint, attackers can exploit the fact that two JWTs signed with the same RSA key pair can be used to derive the public key through cryptographic analysis.

Step-by-Step No-Key Exploitation:

  1. Obtain Two Valid JWTs: Capture two different JWTs from the application (e.g., from two separate sessions or accounts).

  2. Derive the Public Key: Use the `sig2n` tool (available from PortSwigger) to calculate the RSA public key from the two signatures:

 Derive public key from two JWTs signed with the same RSA key
sig2n <token1> <token2>
  1. Import the Derived Public Key: In Burp’s JWT Editor Keys tab, import the derived RSA public key.

  2. Perform Algorithm Confusion: Follow the same steps as the exposed key scenario — create a symmetric key with the public key as the HMAC secret, change `alg` to HS256, modify the payload, and sign the token.

8. Algorithm Confusion with None Algorithm

Some JWT libraries support the `none` algorithm, which indicates that the token is not signed at all. When servers fail to reject tokens with alg: none, attackers can forge arbitrary tokens without any cryptographic key.

Exploitation:

{
"alg": "none",
"typ": "JWT"
}
{
"sub": "administrator",
"exp": 9999999999
}

What Undercode Say:

  • Key Takeaway 1: JWT vulnerabilities are fundamentally implementation flaws, not weaknesses in the JWT specification itself. Every vulnerability explored — from unverified signatures to algorithm confusion — stems from how developers integrate JWT libraries, validate tokens, and manage cryptographic keys. The security of JWT-based authentication is only as strong as the server-side validation logic.

  • Key Takeaway 2: Burp Suite Professional with the JWT Editor extension is an indispensable toolkit for JWT security testing. The extension’s ability to generate keys, modify headers, embed JWKs, and sign tokens streamlines exploitation workflows that would otherwise require manual cryptographic operations. Mastering these tools is essential for any web application penetration tester.

Analysis: The JWT attack surface continues to expand as more applications adopt stateless authentication. Recent CVEs — including CVE-2026-27962 (JWK Header Injection in Authlib), CVE-2026-23993 (unknown algorithm bypass in HarbourJwt), and multiple algorithm confusion vulnerabilities — demonstrate that JWT implementation flaws remain prevalent in production systems. The root cause is often the same: developers trust attacker-controlled header parameters and fail to enforce strict algorithm restrictions. Organizations must adopt defense-in-depth strategies: validate the `alg` parameter against an allowlist, never trust `jwk` or `jku` headers from untrusted sources, use sufficiently strong symmetric keys (≥256 bits), and implement key rotation policies. For penetration testers, mastering these eight attack vectors provides a comprehensive methodology for assessing JWT implementations in bug bounty programs and security assessments.

Prediction:

  • +1 Organizations will increasingly adopt JWT best practices — including algorithm allowlisting, strict key validation, and automated secret rotation — as awareness of these attack vectors grows through platforms like PortSwigger Academy.
  • +1 The demand for penetration testers with specialized JWT exploitation skills will surge, particularly in financial services, healthcare, and government sectors where authentication security is paramount.
  • -1 AI-assisted code generation may introduce new JWT implementation flaws as developers blindly trust generated code without understanding the cryptographic implications of algorithm confusion and key injection vulnerabilities.
  • -1 The proliferation of microservices and API-first architectures will expand the JWT attack surface, with misconfigured service-to-service authentication creating new exploitation opportunities.
  • +1 Security tooling — including Burp Suite extensions, automated scanners, and fuzzing frameworks — will continue to evolve, making JWT vulnerability discovery more accessible to security practitioners.
  • -1 Legacy JWT libraries with known vulnerabilities (e.g., algorithm confusion in pyjwt, JWK injection in Authlib) will remain in production environments for years, creating a long tail of exploitable systems.
  • +1 The shift toward asymmetric algorithms (RS256, ES256) with proper key management will reduce the prevalence of weak symmetric key brute-force attacks, though algorithm confusion will remain a significant threat.
  • -1 Bug bounty programs will see an increase in JWT-related submissions as more researchers complete PortSwigger’s JWT labs, potentially overwhelming triage teams with low-quality reports.
  • +1 Standardized JWT security frameworks — including OWASP’s JWT Cheat Sheet and NIST guidelines — will become mandatory references in secure development lifecycle (SDLC) processes.
  • -1 The complexity of JWT attack vectors — particularly algorithm confusion with no exposed key — will create a skills gap, with many security professionals lacking the cryptographic knowledge to identify and exploit these vulnerabilities effectively.

▶️ Related Video (82% Match):

🎯Let’s Practice For Free:

🎓 Live Courses & Certifications:

Join Undercode Academy for Verified Certifications

🚀 Request a Custom Project:

Secure, high-velocity infrastructure and disruptive technological engineering. Contact our engineering team for high-tier development and proprietary systems:
[email protected]
💎 Smart Architecture | 🛡️ Secure by Design | ⭐ Trusted by Thousands

IT/Security Reporter URL:

Reported By: Lokesh Khichar – 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

Related Posts: