Build 1 publisher2 min readPublished September 17, 2026 at 5:46 PM PDT

Passing $header['alg'] to the verifier lets the token choose which algorithm checks it

A JWT signature only proves integrity when the verifier and the application already agree on algorithm, key and validity window, and in the vulnerable pattern all three are settled by input the attacker sent.

The Engineer · Build desk

Illustration accompanying Passing $header['alg'] to the verifier lets the token choose which algorithm checks it

What happened

A dev.to writeup argues that a JWT signature establishes integrity only if the verifier and the application agree on which algorithm was used, which key should verify it, and whether the token is still valid.
Because the header carries its own algorithm identifier, the server has to decide whether that algorithm is acceptable instead of accepting whatever the token names.
In the vulnerable pattern the application decodes the header, sees alg set to none, and returns the decoded payload without running a signature check at all.
The post's remedy is that the application determines the accepted algorithm server-side, so the token never gets a vote in how it is verified.

Compiled by The EngineerSomething wrong?How this is made

Why it matters

exposure JWT verification sits on the boundary for API authentication, SSO, mobile sessions, password resets and service-to-service calls, so a single call site that trusts the header is reachable from every one of those flows.
constraint Until verification succeeds the payload is attacker-controlled input, so a role check or an expiry check read from a decoded claim before that point has no security value.
decision With explicit algorithm and key configuration now part of library APIs, the code worth reviewing is the application's own decode call sites, not the dependency version in the lockfile.

The two decode calls in the post differ by one array lookup. In the safe one, the second argument to `new Key(...)` is the literal string `'HS256'`, written in the application's own source ^[10]. In the unsafe one it is `$header['alg']`, read straight out of the segment the client sent ^[18]. Both return a decoded payload ^[1]. The library is not being tricked. It verifies with the algorithm and the key the call handed it.

How bad that gets depends on the key types. With RS256 the issuer signs with a private key and the verifier checks the signature with the corresponding public key ^[12]. That public key is not meant to be secret, and it may be published through a JWKS endpoint ^[13]. The vulnerable shape has two conditions: the token influences which algorithm is selected, and the verification code is willing to use the same configured key material across incompatible algorithm families ^[14]. Change RSA verification to HMAC verification on an attacker-controlled `alg`, and the RSA public key may be interpreted as an HMAC secret, so an attacker who knows that public value could construct an HMAC-signed token ^[15]. I would keep the accepted algorithm in configuration next to the key it belongs with, so that rotating a key cannot widen the set of algorithms that verify.

The `none` case is blunter. JWT defines `none` as an algorithm meaning the token has no digital signature, which the post says can be legitimate in narrowly controlled scenarios ^[5]^[6]. What gets submitted is a modified header and payload with an empty third segment ^[8]. The first two segments are encoded, not encrypted, so the sample token in the post decodes for anyone holding it to a payload containing `"admin": true` ^[2]. The post says the important security flaw "isn't the existence of none" but "allowing untrusted token input to determine whether signature verification happens at all" ^[9].

The subheading names five failures: algorithm confusion, the `none` algorithm, weak signing secrets, missing expiration checks, and improper claim validation ^[19]. The published text stops inside the algorithm-confusion example, so the sections on weak secrets, expiry and claim validation are not in the excerpt.

What to watch

The rest of the post: its subheading promises weak signing secrets, missing expiration checks and claim validation, and the published text stops before them.
Whether any mainstream JWT library removes the ability to pass a token-derived algorithm into its verifier API at all.
Advisories naming a shipped product where the RSA-to-HMAC swap was reachable from an unauthenticated request.

Claim ledger

Ranked by verification strength, evidence, and original report placement.

[17]
The token header carries its own algorithm identifier, so the server has to decide whether that algorithm is acceptable and should not blindly accept whatever the token claims.
ReportedSupported2 sources— sign in to open View cited source
[7]
The vulnerable pattern decodes the header, checks whether alg equals 'none', and returns the decoded payload without any signature verification.
ReportedSupported2 sources— sign in to open View cited source
[20]
The application should determine the accepted algorithm server-side.
ReportedSupported2 sources— sign in to open View cited source
[10]
With firebase/php-jwt, the post's safe example calls JWT::decode($token, new Key($secret, 'HS256')), so the verifier is explicitly configured to use HS256 and the token does not get to select a different verification algorithm.
ReportedSupported2 sources— sign in to open View cited source
[18]
The post's unsafe example passes new Key($key, $header['alg']) into JWT::decode, so the token influences which verification algorithm is used.
ReportedSupported2 sources— sign in to open View cited source
[14]
The dangerous implementation pattern is one where the token can influence the selected algorithm and the verification code is willing to use the same configured key material across incompatible algorithm families.
ReportedSupported2 sources— sign in to open View cited source
[15]
If an implementation changes from RSA verification to HMAC verification based on an attacker-controlled alg value, the public RSA key may be interpreted as an HMAC secret, and because the public key is not secret an attacker who knows it could potentially construct an HMAC-signed token using that public value.
ReportedSupported2 sources— sign in to open View cited source
[8]
The attack submits an unsigned token of the form modified-header.modified-payload. with an empty third segment.
ReportedSupported2 sources— sign in to open View cited source
[3]
A signature only establishes integrity if the verifier agrees with the application about which algorithm was used, which key should verify it, and whether the token is still valid in context.
ReportedSupportedSource: dev.to post, 'JWT Vulnerabilities: The Auth Bugs Hiding Behind a Green Checkmark'View cited source
[16]
JWTs are used for API authentication, SSO, mobile sessions, password-reset flows and service-to-service authentication, which makes JWT verification logic part of a security boundary.
ReportedSupportedView cited source
[4]
The payload is attacker-controlled until the signature has been successfully verified; a decoded claim is data, not authentication.
ReportedSupportedView cited source
[12]
Algorithm confusion primarily affects implementations using asymmetric algorithms such as RS256, where the issuer signs with a private key and the verifier checks the signature with the corresponding public key.
ReportedSupportedView cited source
[13]
The public key is intentionally not secret and may even be published through a JWKS endpoint.
ReportedSupportedView cited source
[5]
JWT defines none as an algorithm meaning that the token has no digital signature.
ReportedSupportedView cited source
[6]
Using none can be legitimate in narrowly controlled scenarios, but an application using signed JWTs for authentication should not allow an attacker to switch a token into an unsigned mode.
ReportedSupportedView cited source
[2]
The first two segments of a JWT are encoded, not encrypted, and anyone holding the token can decode them without the signing key; the post's example token decodes to a payload of {"sub":"1234","admin":true}.
ReportedSupportedView cited source
[9]
The post says: "The important security flaw isn't the existence of none. It's allowing untrusted token input to determine whether signature verification happens at all."
ReportedSupportedSource: dev.to post, 'JWT Vulnerabilities: The Auth Bugs Hiding Behind a Green Checkmark'View cited source
[19]
The post's subheading lists algorithm confusion, the none algorithm, weak signing secrets, missing expiration checks and improper claim validation as the ways a cryptographically signed token becomes a path to unauthorized access.
ReportedSupportedView cited source
[1]
A JWT consists of three base64url-encoded segments joined by dots: header.payload.signature.
ReportedSupportedView cited source
[d1]
The safe and unsafe decode calls in the post differ only in the second argument to the Key constructor, a literal 'HS256' against $header['alg'], and both assign a decoded payload from JWT::decode.
DerivedSupported1 source— sign in to open
[11]
Modern JWT libraries have significantly reduced this class of vulnerability by making explicit algorithm and key configuration part of their APIs, and the remaining risk is usually application code that bypasses those protections or reintroduces dynamic algorithm selection.
ReportedInsufficientView cited source

Sources

Publishers with included, body-backed reporting in this cluster.

dev.to
1 article · September 17, 2026
JWT Vulnerabilities: The Auth Bugs Hiding Behind a Green Checkmark

Ask Clarity

Have a question this piece left open? The answer comes from its reporting and claim ledger — nothing else.

Try

Clarity analysis

How the coverage leans and what the record actually supports. Read the methodology

Perspective Coverage

How much of the coverage speaks to builders, operators and investors. It measures emphasis, not whether the story is right.

For a PHP developer the whole story is one argument in one call. JWT::decode($token, new Key($secret, 'HS256')) pins the algorithm. JWT::decode($token, new Key($key, $header['alg'])) hands that choice to whoever sent the token. The author's line about the none case covers both: "It's allowing untrusted token input to determine whether signature verification happens at all." Two strings locate the problem in a codebase: $header['alg'] passed into a verifier, and a default secret such as env('JWT_SECRET', 'changeme'). Where more than one algorithm is genuinely needed, the dev.to guidance keeps an explicit table instead of a lookup, RS256 to an RSA public key, ES256 to an EC public key, HS256 to an HMAC secret.

Reality

Evidence, adoption, hype gap, incentives and confidence, each read independently from the current record on the scale shown beneath it. How these are measured.

Evidence52

0100

One author's code, checkable elsewhere

A single dev.to post carries the story, but most of what it asserts does not depend on the author's authority. The token layout, the none algorithm and the firebase/php-jwt decode signature are matters of published specification and library API, and the vulnerable and safe snippets can be run. Two things are asserted without support: that modern libraries have significantly reduced this bug class, and that weak defaults remain common. No CVE, advisory or affected product appears anywhere in the piece.

AdoptionInsufficient

No deployment or exploitation record

The PHP in this post is illustrative. It does not identify a codebase found using the pattern, a service that was breached, or a library release that closed it, so there is nothing to count on either side of the mechanism.

Hype gap+12

Topics and entities

Follow any of these and your For You feed starts watching them — no settings page required.

Topics

Entities

build
Thirty lines of Doctrine filter, and the query paths where it is simply not there
1 publisher
build
Jenkins static AWS keys work from anywhere; the OIDC replacement fails in four known ways
1 publisher
build
The image proxy fetches 169.254.169.254 as readily as it fetches a cat photo
1 publisher
build
Upwork Scout signs its 15-minute login link and year-long unsubscribe token with one secret
1 publisher

What happened

Why it matters

What to watch

Claim ledger

Sources

Let Clarity write the post for you.

Topics and entities

Topics

Entities

Related stories

Claim ledger

Let Clarity write the post for you.

Topics and entities

Topics

Entities

Perspective Coverage

Reality

Related stories

Sources