JWT “alg”:”none” Attack

What this attack does

A JWT "alg":"none" attack forges trust in an unsigned token. The attacker changes the header to claim no signature algorithm, and a vulnerable verifier accepts the payload as authentic instead of rejecting the token outright.

The core issue is not the header change itself, but a verification failure. A correct implementation must treat the algorithm as an enforcement decision, not a user-controlled hint, and must never let an unsigned JWT stand in for a verified one.

Why it is dangerous

This attack matters because JWTs often carry identity, session, role, or API access claims. If a verifier accepts an unsigned token, an attacker can fabricate privileges, impersonate a user or service, or bypass downstream authorization checks that assume the token was validated first.

It is especially dangerous in systems that mix bearer tokens, single sign-on, and service-to-service calls, because one weak verification path can undermine the trust model for an entire application or integration layer.

Good JWT handling depends on strict algorithm allowlisting, signature verification, issuer and audience checks, and rejection of tokens that do not meet the expected format for the specific trust context. Guidance in JWT Security Guide and Token and Session Security Guide is directly relevant here.

How defenders should assess exposure

Exposure review starts with finding every place JWTs are accepted, especially API gateways, web apps, mobile backends, SSO integrations, and internal services. Teams should check whether any component accepts tokens from untrusted clients, performs custom JWT parsing, or relies on defaults that may have changed across libraries.

It is also important to trace where tokens are generated and consumed, because one insecure verifier can become the weak link even if the issuer is sound. For broader token hardening and validation patterns, the JWT Security Guide is a useful reference point.

When the token also functions as a session or API bearer credential, exposure should be reviewed alongside session handling, replay resistance, and revocation strategy. The relevant control question is whether the application rejects any token whose trust properties are weaker than the application expects.

Remediation and validation steps

Remediation begins by removing any acceptance of unsigned JWTs and enforcing a strict expected algorithm per trust relationship. Verifiers should pin allowed algorithms, validate the signature before reading claims, and fail closed when the token header does not match the expected policy.

Teams should also validate issuer, audience, expiry, and key selection logic, because algorithm confusion is often paired with weak claim validation or unsafe key lookup. The Digital Signatures Guide helps explain why signature verification is the trust anchor, not the token payload.

After a fix, review logs and authentication events for tokens accepted through the vulnerable path, then rotate any credentials, signing keys, sessions, or API tokens that may have been exposed during exploitation. If the token was used to access user or service accounts, treat the incident as an authentication compromise, not just a parsing bug.

Risk and Threat Considerations

This weakness is attractive to attackers because it can turn a forged token into a trusted identity artifact without needing the signing key. In practice, that can enable immediate privilege abuse, session impersonation, or unauthorized access to APIs and back-end services.

Failure mechanism: The verifier treats a caller-controlled header as policy, skips or weakens signature validation, and then trusts attacker-supplied claims as if they were issued by a legitimate authority.

Impact: Attackers may gain unauthorized access, escalate privileges, impersonate users or services, and persist through trusted token-based flows until the validation defect is removed and affected sessions are invalidated.

Practitioner Guidance

Common misunderstanding: Many teams assume JWTs are “secure by format” or that parsing the payload is enough. It is not. The security property comes from verified integrity, not from the presence of a token-shaped string.

What to watch for: Any code path that accepts a token before signature verification, supports multiple algorithms without strict allowlisting, or has library defaults that silently change verification behaviour deserves immediate review. A secure implementation should be opinionated, explicit, and fail closed.

Related resources from NHI Mgmt Group

• Attack Surface Management
• Who is accountable when a JWT token replay attack succeeds across services?
• Why does supporting legacy JWT tokens without kid or alg claims increase security risk?
• How should security teams prevent JWT none algorithm abuse in authentication flows?