The application issues or accepts a JSON Web Token that carries no signature. Either the header declares the none algorithm or the signature part of the token is empty.

The signature is the only thing that stops a user from editing the claims of a token. If the server accepts an unsigned token, anybody can create one with any identity or role they like, which is a complete authentication bypass.

Even when the token that was observed is only one that the server issued for the current user, the fact that it is issued unsigned strongly suggests that unsigned tokens are accepted as well.

1. Reject unsigned tokens in every code path that reads a token. Treat a missing or empty signature as an invalid token.

2. Use an algorithm allow-list in the verifier and leave none out of it. Never select the algorithm from the token's own header.

3. Update the JWT library to a version that refuses none by default and review any custom parsing code.

4. Invalidate existing sessions if forged tokens may have been accepted.

• CWE-347: Improper Verification of Cryptographic Signature
• RFC 8725: JSON Web Token Best Current Practices