fix(security): pin the JWT algorithm allowlist in compatibility mode#1298
Merged
Conversation
applyModernDefaults returned before assigning the default asymmetric-only algorithm allowlist whenever a protocol-version compatibility was set. A hub built with a bare key function (the JWKS path) and no explicit algorithms then let the parser accept whatever alg the token header declared, so a token forged as HS256 against an RSA/EC public key could be presented for algorithm confusion. Apply the allowlist in every mode; a relaxed protocol version must not relax the signature-algorithm check. Operators pinning a symmetric algorithm on a bare key function still opt in via WithPublisher/SubscriberJWTAlgorithms.
dunglas
force-pushed
the
fix/jwt-alg-allowlist-compat
branch
from
July 18, 2026 09:46
4cf5d85 to
e944c0b
Compare
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
From the 1.0 auth-surface security review.
Problem
applyModernDefaults(hub.go) returned early whenever a protocol-version compatibility was configured, before assigning the default asymmetric-only JWS algorithm allowlist. A hub built with a bare key function (the JWKS path,WithPublisher/SubscriberJWTKeyFunc) and no explicit algorithms therefore left the allowlist empty in compatibility mode, sojwtParserOptionsnever appliedjwt.WithValidMethods. The parser then accepted whateveralgthe token header declared.Failure scenario: an operator on compatibility mode (v7/v8) wiring a JWKS keyfunc that returns a parsed public key, with no explicit algorithms — an attacker forges an
HS256token signed with the RSA/EC public-key bytes as the HMAC secret. Not exploitable against the built-inWithPublisherJWT/WithSubscriberJWTconfigs (they always setalgs=[alg]) or a keyfunc that pinst.Method; it bites the bare-JWKS-in-compat-mode path.Fix
Apply the asymmetric-only default allowlist to every configured key function in all modes; a relaxed protocol version must not relax the signature-algorithm check. Operators pinning a symmetric algorithm on a bare key function still opt in explicitly via
WithPublisher/SubscriberJWTAlgorithms.Added
TestCompatModeDefaultJWTAlgorithms: a compat-mode hub with a bare HMAC keyfunc now rejects an HS256 token at parse time.Not changed
The review also flagged the per-detail
actionsarray as having no explicit element cap (INFO). The loop is O(n), bounded by the transport request-body limit, with no compilation or amplification, andmaxMercureDetails/maxDetailTopicsremain enforced. No change warranted.Tests pass with
-raceon both tag combos;go vetandgolangci-lintclean.