al-ice.ai

No Secret Configured, No Authentication Required: Tugtainer’s 9.8 Fail-Open

AI Vulnerabilities & CVEs by al-ice.ai Editorial

CVE-2026-55494, published to NVD on 30 September 2026 hours before this briefing, is a one-line-class bug with maximum consequences. Tugtainer — Quenary's self-hosted tool for automating Docker container updates — protects its Agent API routes with request signatures keyed on AGENT_SECRET. But in agent/auth.py, the signature verification function returns successfully when Config.AGENT_SECRET is empty. Omit the secret from your configuration and every protected Agent API becomes accessible with no authentication at all. Versions before 1.30.4 are affected; 1.30.4 patches it. CVSS 3.1: 9.8 (AV:N/AC:L/PR:N/UI:N), CWE-284, with CISA-coordinated SSVC flags of exploitation: PoC, automatable: yes, technical impact: total.

The reason a Docker-management-API exposure rates a 9.8 rather than a shrug: unauthenticated access to Docker APIs is host-level code execution in practice. Anyone who can reach the Agent can drive container lifecycle operations — create, start, stop — and a freshly created container with a host path mounted or the privileged flag set is a root shell wearing a container costume. That is the same “containers are not a boundary” lesson as the AF_UNIX container escape covered here last week, arriving from the opposite direction: not a kernel bug defeating isolation, but an agent that hands out the control plane to whoever asks.

Fail-open on empty: the oldest pattern in the book

The mechanism deserves attention beyond this one product because it recurs constantly. Verification logic of the form “compute the expected signature, compare with the presented one” silently becomes “compare against nothing, accept everything” when the key material is empty — the same family as empty-password authentication bypasses and default-credential exposures. The design flaw underneath is making the secret optional: a security control that only exists when the operator remembers to configure it is a control that will be absent exactly where it is most needed, on the rushed self-hosted deploys this tool targets. Secure by default would mean refusing to start the Agent without a secret, not serving the API to the world without one.

Scope honestly: NVD still lists the record as Received, SSVC records a proof of concept rather than observed exploitation, and the CVE is not in CISA KEV. So this is a patch-now-before-it-weaponises disclosure, not an active-incident briefing. But the automatable flag plus a public PoC plus a 9.8 on network-reachable Docker infrastructure is precisely the combination that historically goes from advisory to mass scanning in days.

What to do

  • Upgrade to Tugtainer v1.30.4 immediately (advisory GHSA-wgw2-c96g-p7h7, fix commit 0052a55).
  • Set AGENT_SECRET to a strong random value on every deployment — patched or not, an exposed management API with a weak or missing secret is the same incident waiting to happen.
  • Do not expose the Agent port beyond its intended management network. The vulnerability is unauthenticated over the network; reachability is the whole ballgame.
  • Audit for unknown containers and images on hosts whose Agents were reachable without a secret — container creation is the expected post-exploitation artifact, and it persists across the upgrade.
  • Fail closed in your own services: grep your auth paths for verification functions that succeed on empty keys, empty secrets, or missing configuration. This bug class is trivially searchable and embarrassingly common.

Sources: