How I Found a JWT Signature Verification Flaw Vulnerability | by Samadhan Shimple

They help applications identify users and carry information between a client and a server. When implemented correctly, JWTs can provide a reliable way to manage authenticated sessions.

But there is one important rule: a server must never trust a JWT without properly verifying its signature.

While testing a username-change endpoint, I investigated whether the application correctly validated the JWT supplied with the request.

The behavior raised a serious security concern. If an application accepts unsigned or modified tokens, an attacker may be able to manipulate trusted identity information.

In this article, I'll explain the vulnerability, how JWT signature verification works, why this issue matters, and how developers can prevent it.

What Is a JWT?

A JSON Web Token is a compact format commonly used to transmit claims between two parties.

A typical JWT contains three parts:

• Header
• Payload
• Signature

These parts are separated by dots.

The header contains information about the token, such as its signing algorithm. The payload contains claims, which may include a user identifier, issuer, expiration time, or other information.

The signature helps the receiving server verify that the token has not been modified and was signed by an accepted key.

One important detail: Base64URL encoding is not encryption. The header and payload can generally be decoded and read by anyone who possesses the token.

That is why sensitive information should not be placed in a JWT unless the design specifically protects it.

Embedded content

Where I Started Testing

I focused on the username-change functionality.

The application exposed the following endpoint:

POST /api/user/change-username

The request used a JWT supplied through the Authorization header.

For example:

Authorization: Bearer <JWT>

I wanted to understand how the application validated the token before processing the username-change request.

The key question was simple:

Would the server reject a token if its signature was missing or its contents had been modified?

A secure application should reject such a token before performing any authenticated action.

Understanding the Vulnerability

JWT signature verification ensures that the token's signed contents have not been altered.

If a server verifies the signature correctly, changing a claim such as sub or user_id invalidates the original signature.

The server should reject the modified token.

However, if the server decodes the token and trusts its payload without verifying the signature, the application may accept identity information that has not been authenticated.

This can turn a small implementation mistake into a serious security vulnerability.

For example, an application might rely on a user identifier from the JWT to decide which account should be updated.

If that identifier is trusted without proper token verification and authorization checks, the application may process a request using an identity supplied by the requester rather than a verified identity.

The exact impact depends on how the application handles authentication and account ownership.

How I Investigated the Issue

I used Burp Suite to inspect the request sent to the username-change endpoint.

My testing process focused on the token validation behavior and the server's response.

Step 1: Capture the request

I logged in using a normal test account and opened the username-change functionality.

I captured the corresponding HTTP request in Burp Suite and sent it to Repeater for controlled testing.

Step 2: Inspect the JWT

I examined the JWT structure and identified its header and payload.

This helped me understand which claims the token contained and how the application might be using them.

Step 3: Test signature validation

I investigated whether the server required a valid signature.

A properly implemented authentication system must reject unsigned tokens and tokens whose signed contents have been changed.

Testing should be performed only on accounts and systems that you own or are explicitly authorized to assess.

Step 4: Observe the server's response

I checked whether the application rejected the request or continued processing it.

A successful response alone is not enough to establish a vulnerability. The important question is whether the server performed an authenticated action despite receiving an invalid token.

Step 5: Verify the security impact

The next step is to establish which identity the server actually uses when processing the request.

This means checking the result against the authorized test account and confirming whether the application enforced account ownership.

Any claim of cross-account access or account takeover should be supported by clear, reproducible evidence.

Why This Vulnerability Matters

The severity of a JWT signature-verification flaw depends on what an attacker can accomplish.

1. Authentication Bypass

If an application accepts unsigned JWTs as valid authentication credentials, a requester may be able to bypass the intended authentication mechanism.

This is particularly serious when the server treats claims in the token as trusted identity information.

2. Unauthorized Account Changes

A username-change endpoint should allow a user to modify only their own account, unless a properly authorized administrative action is intended.

If the application relies on unverified identity claims, that ownership check may become ineffective.

3. Privilege Escalation

Some applications store role-related claims in JWTs.

If a server accepts modified claims without validating the signature and independently enforcing permissions, an attacker may be able to influence authorization decisions.

Changing a claim to admin does not automatically grant administrative access. The impact must be verified against the application's actual authorization logic.

4. Potential Account Takeover

The most serious outcome may be account takeover.

However, a JWT validation flaw does not automatically prove that a victim's account can be taken over.

That conclusion requires evidence that an unauthorized person can gain control of another account or perform equivalent privileged actions.

The impact also depends on whether the application uses the affected username in account recovery, authentication, or other security-sensitive workflows.

Severity and Classification

The appropriate severity should be based on the demonstrated impact rather than the vulnerability name alone.

A JWT verification weakness that permits unauthorized access to sensitive functions may warrant a High severity rating. A confirmed authentication bypass affecting accounts or administrative functions could be more severe.

For reference, these are two different CVSS 3.1 scenarios:

• CVSS 8.8 — High: AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
• CVSS 9.8 — Critical: AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H

These scores assume substantial confidentiality, integrity, and availability impacts. They are illustrative, not final ratings for this finding.

The correct score depends on the privileges required and the actual impact demonstrated.

Relevant Security Classifications

• CWE-347: Improper Verification of Cryptographic Signature
• CWE-345: Insufficient Verification of Data Authenticity
• OWASP Top 10 2021: A07 — Identification and Authentication Failures
• OWASP API Security Top 10 2023: API2 — Broken Authentication

CWE-347 is particularly relevant when the application fails to verify a cryptographic signature that should establish the authenticity of the token.

How Developers Can Fix This Issue

The good news is that developers can prevent this class of vulnerability by implementing JWT validation correctly.

1. Always Verify the Signature

Every protected request must undergo server-side JWT signature verification.

The application should reject tokens with missing, invalid, or incorrectly formatted signatures.

2. Reject Unsupported Algorithms

The server should explicitly configure the algorithms it accepts.

It must not blindly trust the algorithm specified in the token header. In particular, unsigned tokens using alg: none must not be accepted as authenticated credentials.

3. Enforce Authorization Separately

A valid JWT does not automatically mean that a user can perform every action.

For a username-change operation, the server should derive the authenticated identity from a verified token or trusted session and confirm that the user is authorized to modify the requested account.

Permissions should be enforced on the server, not based solely on client-controlled claims.

Lessons From This Finding

This investigation highlights an important lesson about authentication testing.

A token may look valid, contain reasonable claims, and be correctly formatted while still being untrustworthy.

The server must verify the token's authenticity before relying on its contents.

For security researchers, the goal is not simply to modify a JWT and observe a response. The goal is to determine whether the application actually violates its authentication or authorization rules.

For developers, the lesson is equally clear: decoding a JWT is not the same as validating it.

Final Thoughts

JWTs are useful, but their security depends on correct implementation.

A missing signature check can undermine the authentication system and potentially expose sensitive functionality.

During authorized security testing, pay close attention to how applications validate tokens, establish user identities, and enforce account ownership.

If you discover this type of weakness, document the original request, the invalid-token behavior, the server's response, and the exact security impact you were able to reproduce.

Clear evidence makes a vulnerability report more useful to developers and helps them fix the underlying problem.

Always test within the scope of an authorized security assessment and avoid accessing other users' accounts or data without explicit permission.

AI assistance:_ I used an AI-powered grammar and spelling checker to review this article. The ideas, research, technical analysis, and final content are my own._

Have questions or want to share your own workflow? Drop a comment below or connect with me on :

🔗Linkdin: https://www.linkedin.com/company/sam-shield/

🔗Youtube: https://www.youtube.com/@sam_shield-w7l

🔗Medium: https://medium.com/@samadhanshimple