EUVD-2026-90192Attack ChainAIDerived
Hypothetical attack flow derived from CVE metadata – not a confirmed exploit chain
-
ReconIdentify exposed Tugtainer with configured-but-disabled OIDC
-
DeliveryRequest /auth/oidc/login directly
-
ExploitReceive 302 and oidc_state cookie to IdP
-
InstallAuthenticate at still-configured OIDC provider
-
C2Complete /auth/oidc/callback flow
-
ExecuteObtain authenticated session
-
ImpactControl Docker container updates
Vulnerability Assessment
| Weakness |
CWE
OWASP Top 10:2025
A01:2025 - Broken Access Control
ASVS 5.0
V8 - Authorization Access control enforcement
MITRE ATT&CK
1 technique across 1 tactic: Defense Evasion The technique list with ATT&CK links and the kill-chain view is part of the Basic plan and up. |
| Exploitation Conditions | Requires that Tugtainer has a valid OIDC provider configured (well_known_url, client ID/secret, authorization endpoint populated) but toggled off via OIDC_ENABLED=false - the flaw only matters in that specific configured-then-disabled state, not on a default install that never set up OIDC. The attacker must also be able to authenticate successfully against that external identity provider to convert the initiated flow into an actual session; merely receiving the 302 redirect grants no access without valid IdP credentials. Limiting factors: the disabled-but-configured OIDC scenario is non-default, the app is network-reachable (AV:N) but is a self-hosted service typically behind a LAN/reverse proxy, and meaningful impact hinges on completing the callback, not just login initiation. |
| Impact | The vendor CVSS of 9.4 (AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:L, CWE-284 improper access control) presents this as a critical remote unauthenticated flaw, but the CVSS vector and the description are in tension and the raw score overstates real-world risk. The vulnerability is a bypass of the OIDC disable switch: with OIDC_ENABLED=false, /auth/oidc/enabled correctly reports disabled, yet /auth/oidc/login still returns HTTP 302, sets an oidc_state cookie, and redirects to the configured OIDC authorization endpoint. The confirming source-code evidence (commit 76371db) adds raise_of_disabled() guards to login, refresh, and callback, confirming the entire flow - not just login initiation - could proceed while disabled. Crucially, exploitation presupposes that a valid OIDC provider is still configured (well_known_url and client settings populated) and that the attacker can successfully authenticate against that external IdP; without valid IdP credentials the redirect alone yields no access. That is a non-default, operator-dependent precondition that PR:N/AC:L does not capture, so effective risk is materially lower than 9.4. There is no EPSS score, no CISA KEV listing, and no public POC in the provided data - only a patched release and advisory. Net: a legitimate access-control defect worth patching, but a targeted/config-specific issue rather than a broadly wormable critical. |
| Exploit ScenarioDerived | An administrator configures OIDC in Tugtainer, later sets OIDC_ENABLED=false believing the provider is fully disabled, and relies on local auth only. An attacker who holds a valid identity in the still-configured OIDC provider directly requests /auth/oidc/login (and the callback), completing the login flow that the disable switch was supposed to block, and gains authenticated access to the Docker-container management app. No public exploit code is identified at time of analysis, though the fixing commit is public. |
Get an e-mail when this CVE is exploited, patched or re-scored. Free account.
Alert meAnalysisAIv1 – Sep 30, 2026
Improper access control in Tugtainer before version 1.30.3 causes the OIDC login flow to start even when OIDC_ENABLED=false, so a direct request to /auth/oidc/login still returns HTTP 302, sets an oidc_state cookie, and redirects the browser to the configured OIDC authorization endpoint despite the disable switch. The vendor scores this 9.4 (CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:L), but real-world impact is narrower than that score implies: exploitation requires a deployment where OIDC was fully configured (well_known_url, client ID/secret, authorization endpoint) and then toggled off, and the attacker must still complete authentication against that external identity provider to turn the initiated flow into a session. No public exploit code and no confirmed active exploitation were identified at time of analysis; the issue is fixed in Tugtainer 1.30.3.
RemediationAI
Upgrade to Tugtainer 1.30.3, which is the vendor-released patch and contains commit 76371db679334b002d4af544b0f3b8587ad86f52; the release and advisory are at https://github.com/Quenary/tugtainer/releases/tag/v1.30.3 and https://github.com/Quenary/tugtainer/security/advisories/GHSA-rg7c-vpfp-2w43. If upgrading immediately is not possible, the most reliable mitigation is to remove the OIDC configuration entirely from the instance (clear well_known_url, client ID and client secret) so that /auth/oidc/login has nothing to redirect to; this is safe when OIDC is intended to stay off but must be re-entered if OIDC is later re-enabled. Alternatively, block requests to /auth/oidc/login, /auth/oidc/refresh, and /auth/oidc/callback at the reverse proxy or ingress and allow only /auth/oidc/enabled, accepting that this breaks OIDC for all clients if the provider is ever intentionally turned on. As a defense-in-depth measure independent of the patch, restrict the OIDC client's registered redirect URIs at the identity provider to the exact Tugtainer callback and disable or rotate the unused client secret, since converting the initiated flow into a session still requires valid IdP credentials. Where Tugtainer is only used on a trusted LAN, reducing network reachability to the web UI also lowers exposure, but the patch or configuration removal remains the primary fix because the underlying enforcement was centralized in 1.30.3.
Affected VersionsENISA
Affected Packages
Source: OSV (Open Source Vulnerabilities)
Affects your stack
Affects 1 package in euvd
Checking this CVE against your own stacks and servers is part of the Basic plan and up.
Technical ContextAI · show details
Tugtainer is a self-hosted Python application that automates Docker container updates, and it supports OIDC (OpenID Connect) as an alternative to local credentials over the OAuth 2.0 authorization-code flow (discovery document fetch, /auth/oidc/login redirect, oidc_state cookie for CSRF state, callback with code exchange, token validation via jwt, followed by session creation). The root cause is CWE-284 (Improper Access Control): the disabled state of the OIDC provider was enforced on some routes but not on the login, refresh, and callback handlers, so gating logic was inconsistent across the authentication surface. The /auth/oidc/enabled endpoint correctly reported OIDC as disabled, which created a false impression of enforcement. The upstream fix (commit 76371db679334b002d4af544b0f3b8587ad86f52) centralizes the check in a raise_of_disabled() helper invoked from is_authorized() and from the provider's login(), refresh(), and callback() methods, so that any request reaching an OIDC handler while the provider is disabled is rejected rather than being allowed to begin or continue the flow. The affected component is the OIDC auth provider in the backend auth module; the CPE string cpe:2.3:a:quenary:tugtainer:*:*:*:*:*:*:*:* indicates all Tugtainer releases prior to the fixed version are covered.
Know when Tugtainer gets its next vulnerability
- Watch products and get an email when something new is published
- Check this CVE against your own stack and servers
- Exploit and PoC references, threat intelligence from 22 sources
No credit card · 7-day full trial
Severity by source
AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:L
PR:N (no Tugtainer auth) but AC:H because it requires a configured-then-disabled OIDC provider plus attacker-held valid IdP credentials; successful login yields full container-management control (C/I/A High).
Primary rating from Vendor (GitHub_M).
CVSS VectorVendor: GitHub_M
Lifecycle Timeline
2DescriptionCVE.org
Tugtainer is a self-hosted app for automating updates of Docker containers. Prior to version 1.30.3, Tugtainer's OIDC authentication can still be initiated even when OIDC_ENABLED=false. The /auth/oidc/enabled endpoint correctly reports that OIDC is disabled. However, a direct request to /auth/oidc/login still starts the OIDC login flow, returns HTTP 302, sets an oidc_state cookie, and redirects the user to the configured OIDC authorization endpoint. This bypasses the intended OIDC disable switch. This issue has been patched in version 1.30.3.
Articles & Coverage 1
Technical POC Analysis
CWE-284: Improper Access Control.
Full technical POC analysis - root cause, step-by-step exploitation and patch breakdown - is part of the Pro and Business plans.
Executive ViewAI
Tugtainer, a container management tool used by platform and DevOps teams, contains an access-control flaw that lets an OIDC login flow start even after administrators have explicitly disabled OIDC, meaning a switch intended to shut off an external identity path can be bypassed. Impact is limited to deployments that fully configured OIDC and later turned it off, and an attacker must still authenticate successfully against that external identity provider, so exploitation is not possible against default or OIDC-never-configured installs. Because the affected system can manage containers and workloads, any successful bypass could expose significant control-plane access, but the narrow preconditions and the absence of observed exploitation keep near-term organizational risk moderate.
No vendor patch confirmed available in this record (an advisory-indicated fix exists in Tugtainer 1.30.3 - validate with the vendor and apply once confirmed). Interim mitigations: block or deny external access to /auth/oidc/login at the reverse proxy, load balancer, or WAF; restrict Tugtainer management interfaces to trusted networks or VPN; when OIDC is disabled, remove the stored client secret and clear well_known_url, client ID, and authorization endpoint settings so no usable client remains; rotate OIDC client secrets; and monitor logs and IdP telemetry for unexpected 302 redirects to the authorization endpoint or authorization requests originating from Tugtainer hosts.
Threat Intelligence Overview
NVD
CVE.org
EPSS
Vulnrichment
GitHub
How this decision was reached
The engine reads each signal below and applies a fixed list of rules from top to bottom. The first rule that matches sets the recommended action – like a statement, every line is shown.
What every action level means
SSVC AssessmentENISA
Priority Score
Attack Technique
Authentication bypass attacks exploit flaws in the verification mechanisms that control access to systems and applications.
Tugtainer versions before 1.16.1 transmit authentication credentials through URL query parameters rather than request bo
Server-side template injection in Tugtainer (self-hosted Docker container auto-update tool) versions before 1.30.2 lets
Unauthenticated attackers can reach the Tugtainer Agent's Docker management API and gain effectively full control over c
Authenticated server-side request forgery in Tugtainer before version 1.30.6 allows any logged-in user with access to no
Command argument injection in the Tugtainer agent API (POST api/command/run) lets remote attackers append or substitute
In Tugtainer versions before 1.31.3, the OIDC login flow accepts unverified JWT claims from the identity provider's id_t
Exploit-DB