The Carbonato Botnet's AI Agent Hermes Is Hijacking Docker Hosts

Botnets automating payload delivery is not new. What makes Carbonato's Hermes component worth a closer look is where the decision making actually sits. A conventional botnet's command and control server tells compromised machines what to run, and an operator decides the targeting logic ahead of time or adjusts it manually. Hermes instead performs its own reconnaissance on each newly compromised Docker host and makes the crypto mining versus lateral movement call itself, using signals it reads directly off that host. The Telegram channel security researchers found is used for exfiltration reporting and occasional operator override, not for routine payload decisions. The agent is doing the targeting work a human operator used to do by hand, at whatever speed it can enumerate a host.

How Hermes reads a compromised host

Once Carbonato has compromised a Docker host at the daemon layer, meaning it has gained the level of access the Docker daemon itself has, Hermes does not need elevated privileges to learn a lot about that host. The Docker API, once you are talking to it at that level, hands over container names, the environment variables each container was started with, its network connections, and open port profiles, all without an extra authentication step beyond the daemon access the initial compromise already achieved. Environment variable names in particular tend to leak a surprising amount: a variable named something like PROD_DB_CONNECTION or STRIPE_SECRET_KEY tells an automated reader a great deal about what that container is for and how valuable the host is, without the agent needing to understand the application logic at all.

That is the mechanism worth sitting with. This is not a sophisticated exploit against Docker itself. It is pattern matching against metadata that was already sitting there, readable, the moment the daemon was compromised, and historically that metadata was just not worth a human operator's time to review host by host across a botnet with potentially thousands of victims. An agent with no marginal cost per host to review changes that math completely. Reviewing container naming conventions and environment variable patterns one host at a time does not scale for a human operator running a botnet. It scales fine for an agent.

Why this is a container security problem, not just a malware problem

Most Docker and Kubernetes security guidance focuses, correctly, on preventing the initial compromise: patch the daemon, do not expose it to the internet without authentication, scan images for known vulnerabilities, restrict what the daemon socket can do. Carbonato's Hermes component is a reminder that the guidance stops short of a second question: once a daemon is compromised, how much does an attacker actually learn for free from what is already running there? The answer, based on this disclosure, is quite a lot, and almost none of it requires the attacker to understand your specific application architecture. Secrets passed as plain environment variables, verbose container and image naming that reveals environment and purpose, and open ports that map cleanly to known services are all metadata hygiene problems that exist independently of whether an AI agent is the one reading them. Hermes is simply the first disclosed case of an attacker automating the read and triage step at the scale a botnet operates at.

This connects to the same structural issue we raised in our look at the MCP STDIO remote code execution disclosure: agentic tooling, whether it is an AI coding assistant calling local tools or malware deploying an autonomous reconnaissance agent, inherits whatever access and metadata the host it is running on exposes. The fix in both cases is less about the agent itself and more about not handing an automated reader, benign or hostile, more context than the task in front of it actually needs.

What this changes for your container security checklist

A few practical implications follow directly from how Hermes operates, independent of whether Carbonato specifically ever reaches your infrastructure. Move secrets out of plain environment variables and into a proper secrets manager with short lived credentials, so a compromised container or host does not hand over a long lived key just by existing. Review container and image naming conventions for anything that telegraphs production status or data sensitivity to an automated reader, the same caution that applies to naming a database PROD_PAYMENTS applies here. Restrict what the Docker API can return to an authenticated caller where possible, and treat daemon level compromise as the real perimeter breach it is rather than assuming container boundaries alone contain the damage. None of this is new advice in isolation. What Hermes changes is the cost of an attacker acting on the gaps: a single compromised host used to require manual triage to exploit well, and an agent removes that bottleneck.

This also connects to the adoption data in the 2026 State of AI Agents report: as organizations deploy more autonomous agents internally, the infrastructure habits that make those agents safe, scoped access, clean secrets management, minimal standing metadata exposure, are the same habits that limit what a hostile agent like Hermes can do if it ever reaches your environment. Agent security is not a separate practice from container security hygiene; increasingly it is the same checklist applied from both sides.

When this applies to your stack

If you run Docker or Kubernetes workloads with any external exposure, the actionable response to Carbonato is not a new tool purchase, it is an audit of what a compromised daemon would actually hand over today: secrets in environment variables, naming conventions that reveal purpose, and Docker API access that is broader than any legitimate caller needs. That audit, and the work of moving secrets and access controls to match a zero standing trust model, is core infrastructure work we do for teams running production container platforms on GCP, AWS, or hybrid environments.

FAQ

What is the Carbonato botnet and what is Hermes? Carbonato is a malware family, disclosed September 28, 2026, that compromises exposed Docker hosts at the daemon layer. Hermes is the AI agent component it deploys onto compromised hosts to decide, on its own, whether to run crypto mining or lateral movement tooling, based on signals it reads from the host.

How does Hermes decide what to do on a compromised host? It reads container names, environment variable naming patterns, network connections, and open port profiles through the Docker API, which is reachable once the daemon itself is compromised. High compute hosts get crypto mining payloads; hosts that look connected to production networks get lateral movement tooling.

Does this mean Docker itself has a new vulnerability? No. Hermes does not exploit a new flaw in Docker. It automates triage of metadata, environment variables, naming conventions, port profiles, that was already exposed the moment the daemon was compromised through whatever initial access method Carbonato uses. The underlying exposure is a metadata hygiene problem, not a Docker bug.

What should a team running Docker or Kubernetes do first? Move secrets out of plain environment variables into a managed secrets store with short lived credentials, audit container and image naming for anything that reveals production status or data sensitivity, and restrict what the Docker API returns to any caller beyond what that caller legitimately needs.