Skip to main content

Tugtainer Agent CVE-2026-55494

| EUVDEUVD-2026-90193 CRITICAL
Improper Access Control (CWE-284)
2026-09-30 GitHub_M
9.8
CVSS 3.1 · Vendor: GitHub_M
View

Attack ChainAIDerived

Hypothetical attack flow derived from CVE metadata – not a confirmed exploit chain

  1. Access
    Reach exposed Agent port (default empty AGENT_SECRET)
  2. Delivery
    Send unsigned request to protected API
  3. Exploit
    Signature check returns success
  4. Execution
    Invoke Docker management API
  5. Persist
    Deploy/modify containers
  6. Impact
    Compromise Docker host

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 two conditions to align: (1) AGENT_SECRET is unset/empty - this is the default, causing verify_signature_headers in agent/auth.py to return success for any request; and (2) the Tugtainer Agent port (default 127.0.0.1:8001) is network-reachable to the attacker. By default the Agent is bound internally within the main image and its port is not exposed, so remote unauthenticated exploitation specifically requires a deployment that exposes the Agent (e.g., agent on a separate host/network) while leaving AGENT_SECRET blank. Limiting factors: the non-default port exposure requirement significantly narrows real-world reachability; deployments that set AGENT_SECRET or upgrade to v1.30.4 (which rejects requests with HTTP 401 when the secret is unset) are not affected.

Impact

The CVSS 9.8 (AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H) reflects worst-case impact: unauthenticated network access to Docker management APIs yields effectively full control of containers and, by extension, the Docker host. The root cause is confirmed by the fix commit (0052a5544e) - in agent/auth.py the signature check short-circuits to success when Config.AGENT_SECRET is empty, and empty is the documented default. However, the raw 9.8 overstates real-world exposure: the vendor's own .env.example notes the agent 'is used internally in the main image and does not expose its port,' binding to 127.0.0.1:8001 by default. So the network-reachable, unauthenticated condition only materializes when an operator exposes the agent port (common in multi-host setups) while leaving AGENT_SECRET unset. No EPSS score, KEV listing, or public PoC was provided, so there is no evidence of active exploitation - this is a high-impact, easy-to-trigger flaw but not a confirmed widespread-exploitation priority. SSVC-style read: technical impact is total, exploitation is trivial once reachable and likely automatable, but the affected product footprint is small. Missing data: EPSS/KEV/POC status not supplied - treat exploitation likelihood as inferred, not confirmed.

Exploit ScenarioDerived

An operator deploys Tugtainer in a multi-host configuration and exposes the Agent port on the network without setting AGENT_SECRET. An unauthenticated remote attacker who can reach that port sends requests to the protected Agent API without any valid signature - the verification passes because the secret is empty - and issues Docker management commands to pull, start, or reconfigure containers, pivoting to full host compromise. No public PoC was identified, but the fix commit publicly documents the exact flawed check, making a working exploit trivial to reconstruct.

Act Now Prioritize within 24-48h. Why: CRITICAL severity.
Patch available 0.8% exploitation probability (EPSS)

Get an e-mail when this CVE is exploited, patched or re-scored. Free account.

Alert me

AnalysisAIv1 – Sep 30, 2026

Unauthenticated attackers can reach the Tugtainer Agent's Docker management API and gain effectively full control over containers and the underlying Docker host, because the agent's request-signature check in agent/auth.py returns success whenever Config.AGENT_SECRET is left empty - which is the shipped default. All Tugtainer versions prior to 1.30.4 are affected (CPE cpe:2.3:a:quenary:tugtainer with a wildcard version), though exploitation requires the agent's port (default 127.0.0.1:8001) to be network-reachable, meaning deployments that place the agent on a separate host or otherwise expose it without setting a secret are the realistic victims; deployments that keep the agent internal or set AGENT_SECRET are not reachable. The CVSS 3.1 score is 9.8 (AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H), no public exploit code or confirmed active exploitation (CISA KEV) has been identified at time of analysis, and the issue is fixed in vendor release 1.30.4, which rejects such requests with HTTP 401.

RemediationAI

Upgrade to Tugtainer v1.30.4 (vendor-released patch: 1.30.4, https://github.com/Quenary/tugtainer/releases/tag/v1.30.4), which makes AGENT_SECRET mandatory and returns HTTP 401 when the secret is unset; the upstream fix is visible in commit 0052a5544e187a4d12f771838a8a23ca4afb61cd, which also updates .env.example, README.md and the compose files to ship a CHANGE_ME! AGENT_SECRET value. In parallel, set AGENT_SECRET to a long random value on both the main instance and the Agent and restart them - this requires coordinated configuration changes and clients using unsigned requests will break, which is the intended behavior. If the Agent must remain reachable across hosts or networks, do not rely on the network boundary alone: restrict port 8001 with host firewall rules or Docker network policies so only the main Tugtainer instance can reach it (side effect: breaks cross-host agent deployments unless the traffic is tunneled), or front it with a reverse proxy enforcing TLS client certificates or HTTP authentication (side effect: added component to maintain and possible latency). Never enable the new ALLOW_UNAUTHENTICATED_AGENT=true flag outside isolated development, since it re-introduces the bypass by design; audit for any existing AGENT_SECRET-less deployment that had its agent port exposed, as compromise of Docker management APIs implies the Docker host and its mounted socket should be treated as potentially compromised. Full details are in the GitHub advisory GHSA-wgw2-c96g-p7h7.

Affected VersionsENISA

tugtainer < 1.30.4

Affected Packages

euvd tugtainer fix: 1.30.4

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 Docker container auto-updater split into a main instance and a lightweight Agent that talks to the Docker daemon; the Agent exposes API routes used to list, start, stop, and update containers. Rather than credentials, the Agent authenticates its callers with signed requests: the main instance computes a signature over the HTTP method, path, query parameters, timestamp and body and sends it in X-SIGNATURE alongside an X-TIMESTAMP header, with a short signature TTL (default 5 seconds) to limit replay (see shared/util/signature.py). The bug is a classic CWE-284 improper access control pattern: verify_signature_headers() in agent/auth.py began with an early return when Config.AGENT_SECRET was falsy, so with the parameter omitted (the documented default, where the agent is assumed to be internal-only and its port unexposed) every protected route was served without any signature verification at all. The patch inverts this default: AGENT_SECRET is now mandatory unless the new, development-only ALLOW_UNAUTHENTICATED_AGENT flag is explicitly set to true, and an unset secret now raises HTTP 401 UNAUTHORIZED with a warning log instead of silently permitting the request; it also validates that X-TIMESTAMP and X-SIGNATURE headers are present before verification and stops emitting unsigned requests when no secret is configured. The CPE for this CVE uses a wildcard version, indicating the vendor treats every release before 1.30.4 as vulnerable.

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

Vendor (GitHub_M) PRIMARY 9.8 CRITICAL
AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H
vuln.today AI 9.8 CRITICAL

When the Agent is exposed, an unauthenticated remote attacker reaches the Docker API with a trivial unsigned request, yielding full container/host control (C/I/A:H); AV:N/PR:N reflect the bypass despite the common non-default exposure caveat.

3.1 AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H
4.0 AV:N/AC:L/AT:N/PR:N/UI:N/VC:H/VI:H/VA:H/SC:N/SI:N/SA:N

Primary rating from Vendor (GitHub_M).

CVSS VectorVendor: GitHub_M

Attack Vector
Network
Attack Complexity
Low
Privileges Required
None
User Interaction
None
Scope
Unchanged
Confidentiality
High
Integrity
High
Availability
High

Lifecycle Timeline

2
Patch available
Sep 30, 2026 - 18:05 EUVD
CVE Published
Sep 30, 2026 - 16:58 cve.org
CRITICAL 9.8

DescriptionCVE.org

Tugtainer is a self-hosted app for automating updates of Docker containers. Prior to version 1.30.4, Tugtainer Agent allows unauthenticated access to Docker management APIs when AGENT_SECRET is not configured. The Agent uses request signatures to protect its API routes. However, in agent/auth.py, the signature verification function returns successfully if Config.AGENT_SECRET is empty. This causes protected Agent APIs to become accessible without authentication. This issue has been patched in version 1.30.4.

Technical POC Analysis

The vulnerability is Improper Access Control (CWE-284), specifically a fail-open authentication check in agent/auth.py.

Full technical POC analysis - root cause, step-by-step exploitation and patch breakdown - is part of the Pro and Business plans.

Executive ViewAI

Why It Matters

Tugtainer container-management agents running versions earlier than 1.30.4 can be fully taken over by an unauthenticated attacker who can reach the agent's Docker management API, handing over control of every container and the underlying Docker host. The realistic exposure is deployments where the agent port (default 8001) is reachable beyond the local host and the agent secret was left at its shipped, empty default; agents kept internal or configured with a secret are not reachable. With no public exploit code or confirmed active exploitation identified at time of analysis, leadership should treat this as an urgent configuration-and-exposure problem concentrated in externally reachable or flat-network container estates.

Business Impact: High
Compensating Controls

Apply vendor patch (upgrade to 1.30.4 or later); until then, set a non-empty AGENT_SECRET on every agent and restrict the agent port (default 8001) to localhost or an isolated management network with no external reachability.

Threat Intelligence Overview

EPSS Score
0.8%
Top 47% exploitable
Prevalence
Low
niche self-hosted homelab/hobby Docker tool, small deployment footprint
Social Media
10
Sightings
Data Quality
5 sources
Confidence: Medium

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.

SignalValue
Severity CRITICAL
CISA KEV No
Public POC No
EPSS 0.8%
Patch available Yes
Active threat No
Deciding rule
CRITICAL severity
What every action level means
Emergency Immediate action required. Criteria: CRITICAL + in CISA KEV (actively exploited) without patch, OR CRITICAL + EPSS > 30% without patch, OR CRITICAL + active threat signals without patch.
Act Now Prioritize within 24-48h. Criteria: in KEV with patch available, OR CRITICAL + public POC, OR HIGH + EPSS > 10%, OR CRITICAL + active threat, OR any CRITICAL severity.
This Week Schedule remediation this week. Criteria: HIGH severity (CVSS 7.0-8.9). Patch within normal change window.
This Month Plan within 30 days. Criteria: MEDIUM severity (CVSS 4.0-6.9), lower exploitation probability. Include in regular patch cycle.
Monitor Track and reassess. Criteria: LOW severity (CVSS 0.1-3.9), minimal exploitation risk. No immediate action needed.

SSVC AssessmentENISA

SSVC Decision
Scheduled
Exploitation
Poc
System Exposure· derived
Open
Automatable
Yes
Human Impact
High
Technical Impact
Total

Priority Score

50
Low Medium High Critical
KEV: 0
EPSS: +1
CVSS: +49
PoC: 0
Weaponized: 0
Threat intel: 0
Gov advisory: 0

Attack Technique

Authentication bypass attacks exploit flaws in the verification mechanisms that control access to systems and applications.

This site uses cookies essential for authentication and security. No tracking or analytics cookies are used. Privacy Policy