Advisory Package Curation

LiteLLM: Authentication bypass via OIDC userinfo cache key collision ### Impact When JWT authentication is enabled (`enable_jwt_auth: true`), the OIDC userinfo cache uses `token[:20]` as the cache key. JWT headers produced by the same signing algorithm generate identical first 20 characters. This configuration option is not enabled by default. **Most instances are not affected.** An unauthenticated attacker can craft a token whose first 20 characters match a legitimate user's cached token. On cache hit, the attacker inherits the legitimate user's identity and permissions. This affects deployments with JWT/OIDC authentication enabled. ### Patches Fixed in v1.83.0. The cache key now uses the full hash of the JWT token. ### Workarounds Disable OIDC userinfo caching by setting the cache TTL to 0, or disable JWT authentication entirely.

LiteLLM: Authentication bypass via OIDC userinfo cache key collision When JWT authentication is enabled (`enable_jwt_auth: true`), the OIDC userinfo cache uses `token[:20]` as the cache key. JWT headers produced by the same signing algorithm generate identical first 20 characters. This configuration option is not enabled by default. **Most instances are not affected.** An unauthenticated attacker can craft a token whose first 20 characters match a legitimate user's cached token. On cache hit, the attacker inherits the legitimate user's identity and permissions. This affects deployments with JWT/OIDC authentication enabled.

LiteLLM: Authentication bypass via OIDC userinfo cache key collision ### Impact When JWT authentication is enabled (`enable_jwt_auth: true`), the OIDC userinfo cache uses `token[:20]` as the cache key. JWT headers produced by the same signing algorithm generate identical first 20 characters. This configuration option is not enabled by default. **Most instances are not affected.** An unauthenticated attacker can craft a token whose first 20 characters match a legitimate user's cached token. On cache hit, the attacker inherits the legitimate user's identity and permissions. This affects deployments with JWT/OIDC authentication enabled. ### Patches Fixed in v1.83.0. The cache key now uses the full hash of the JWT token. ### Workarounds Disable OIDC userinfo caching by setting the cache TTL to 0, or disable JWT authentication entirely.

LiteLLM: Authentication bypass via OIDC userinfo cache key collision ### Impact When JWT authentication is enabled (`enable_jwt_auth: true`), the OIDC userinfo cache uses `token[:20]` as the cache key. JWT headers produced by the same signing algorithm generate identical first 20 characters. This configuration option is not enabled by default. **Most instances are not affected.** An unauthenticated attacker can craft a token whose first 20 characters match a legitimate user's cached token. On cache hit, the attacker inherits the legitimate user's identity and permissions. This affects deployments with JWT/OIDC authentication enabled. ### Patches Fixed in v1.83.0. The cache key now uses the full hash of the JWT token. ### Workarounds Disable OIDC userinfo caching by setting the cache TTL to 0, or disable JWT authentication entirely.