Tugtainer EUVD-2026-90195

Exploitation requires that the Tugtainer instance (prior to v1.31.3) has the OIDC login flow configured and enabled, with OIDC_CLIENT_ID/OIDC_REDIRECT_URI and a discovery document in use - instances using only local authentication are unaffected. The attacker must be able to cause a crafted or manipulated id_token (arbitrary email/sub/preferred_username claims) to be returned to the backend during the authorization-code token exchange, since the code accepts unverified claims directly; this is the AC:H limiting factor, as it is not a plain unauthenticated request to a public endpoint. The patched version additionally adds optional OIDC_ALLOWED_EMAILS / OIDC_ALLOWED_SUBJECTS allowlists, indicating that even post-fix, any validly-authenticated identity is accepted by default unless those allowlists are set.

The CVSS 3.1 base score of 8.1 (AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:H) reflects a network-reachable, pre-authentication authentication-bypass flaw (CWE-347) with full CIA impact once triggered - consistent with the confirmed code evidence showing jose.jwt.get_unverified_claims() being used in place of jwt.decode(), skipping signature, aud, iss, and exp checks before the claims become the session user_id. The AC:H rating is well-justified: an attacker cannot simply POST a forged JWT to an endpoint; they must get a crafted or manipulated id_token to be accepted during the server-side OIDC code exchange (e.g., via a rogue/attacker-influenced identity provider, a manipulated token-endpoint response, or algorithm/claim manipulation), which raises real-world difficulty above a trivial bug. No EPSS score, no CISA KEV listing, and no public exploit were provided, so this is no public exploit identified at time of analysis - meaning risk is driven by the flaw's severity and not by observed exploitation. Net assessment: a genuinely serious authentication flaw for any Tugtainer instance exposing OIDC login to attackers, but tempered by (a) niche/homelab deployment footprint, (b) the AC:H prerequisites, and (c) that exploitation only matters when OIDC login is actually configured and enabled. This is a legitimate high-severity issue to patch for affected deployments rather than a mass-exploitation emergency.

An operator configures Tugtainer with OIDC SSO exposed over the network. An attacker who can supply or influence the id_token returned during the code exchange (for example via a rogue/attacker-controlled OIDC provider the instance can be pointed at, or by manipulating the unverified token) presents a JWT carrying an arbitrary email/sub/preferred_username; because the backend never verifies the signature, issuer, audience, or expiry, those claims are accepted verbatim as the session user_id, granting authenticated access to Tugtainer's Docker container management. No public exploit code was identified at the time of analysis.