The Carbonato botnet compromises unauthenticated Docker Engine APIs exposed on TCP port 2375, launches privileged containers and deploys an AI agent for credential theft and remote control. Disclosed by ThreatDown on September 22, 2026, the campaign is primarily a Docker infrastructure failure, not a new AI vulnerability. Operators should close exposed daemon access, investigate affected hosts and rotate every reachable secret.
What is the Carbonato botnet?
The Carbonato botnet is a worm-like malware operation that compromises Docker Engine APIs reachable without authentication on TCP port 2375. According to ThreatDown’s September 2026 disclosure, Carbonato starts a privileged container, gains broad access to the underlying host, establishes persistence and searches connected networks for more exposed Docker daemons.
The initial weakness is straightforward: an administrator has made Docker’s powerful management interface reachable without adequate authentication or network restrictions. Docker’s 2026 security documentation warns that daemon control can allow unrestricted changes to the host filesystem. An attacker doesn’t need a container escape when the daemon already provides the necessary control.
ThreatDown discovered an unauthenticated attacker registry in August 2026 and passively collected 59 repositories, 234 image tags, 605 verified blobs and 4.3 GB of data during one day. Registry timestamps indicated activity from October 2024 through August 2026. Those findings provide unusual visibility into the operation, but they remain findings from one primary investigation.
No independently verified victim count or definitive operator attribution had been published by October 1, 2026. BleepingComputer and Dark Reading independently reported the exposed Docker API infection path, while relying substantially on ThreatDown’s recovered material. Claims about the campaign’s size should therefore be treated cautiously.
How does Carbonato compromise Docker hosts?
The Carbonato botnet reaches a Docker daemon exposed without authentication, uses the API to create a privileged container and accesses host files, processes and networking. ThreatDown reported in September 2026 that the malware then installs persistence and remote access before scanning attached networks and Docker bridges for additional port 2375 targets.
Privileged execution is the decisive step. A container configured with host-root bind mounts, host process access or host networking can provide an attacker with far more reach than an ordinary isolated workload. From there, Carbonato can inspect secrets, alter startup mechanisms and move laterally.
ThreatDown reported that the malware scans every five minutes in September 2026. That schedule produces up to 288 scanning rounds per day for each active implant: 60 minutes divided by five, multiplied by 24 hours. Even a short delay in containment can therefore expose many reachable development hosts, build runners and internal Docker bridges.
| Stage | Observed mechanism | Defensive signal |
|---|---|---|
| Initial access | Unauthenticated Docker API on TCP port 2375 | Internet or lateral connections to port 2375 |
| Execution | Privileged container created through Docker Engine | Unexpected creation time, image or entrypoint |
| Host access | Host files, processes and networking exposed | Root bind mounts and host PID or network mode |
| Agent deployment | Hermes Agent with a replaced 39-line SOUL.md |
Unexpected agent files and Telegram traffic |
| Propagation | Port 2375 scans reported every five minutes | Repeated connection attempts across subnets |
The table separates the infrastructure compromise from the later AI component. That distinction matters because blocking agent software alone leaves the original exposure untouched. In my view, any response that starts with prompt analysis instead of daemon containment has the priorities backward.
Why does the Carbonato botnet deploy an AI agent?
The Carbonato botnet deploys the MIT-licensed Hermes Agent framework to execute operator-supplied tasks through Telegram and terminal tools. ThreatDown found in September 2026 that the attackers left the underlying framework code unchanged but replaced its SOUL.md persona with a 39-line malicious prompt focused on finding and stealing credentials.
Hermes Agent itself is an open-source project from Nous Research, and its legitimate capabilities include Telegram gateways and terminal-command tooling. Carbonato demonstrates how attackers can reuse a general agent framework without exploiting or secretly modifying that framework. The malicious behavior comes from the deployment, permissions and instructions.
The overwritten persona prioritizes AI-provider API keys ahead of SSH credentials, access tokens, database passwords and other secrets. ThreatDown reported in September 2026 that the prompt names 14 AI providers. AI keys can carry direct financial value because stolen access may consume paid inference capacity, expose stored data or provide entry to connected applications.
This pattern belongs beside the broader problem of unmanaged AI agents inside enterprises. It also complicates shadow AI discovery: defenders must identify agent runtimes as well as familiar shells, miners and remote-access tools. Agentic malware is the execution layer here, not the entry point.
How can you detect Carbonato on a Docker host?
Carbonato detection should begin with Docker API exposure, container history and host persistence rather than a single file signature. On October 1, 2026, defenders were advised to inventory every Docker host, test port 2375 reachability from multiple trust zones and inspect running and stopped containers for unexpected privilege, mounts and entrypoints.
Test from the internet, container networks, untrusted subnets and relevant cloud security groups. A daemon hidden from a public scanner may still be reachable laterally from a compromised application or continuous-integration runner. That internal exposure is the pitfall many quick checks miss.
Use docker inspect to retrieve low-level configuration for Docker objects, as described in Docker’s 2026 command reference. Review container creation times, source images, privilege settings, host bind mounts, PID and network modes, environment variables and entrypoints. Don’t limit the review to running containers; a stopped artifact can preserve valuable evidence.
Host-level hunting should cover unexpected Hermes installations, modified SOUL.md files, Telegram gateway traffic, reverse SSH tunnels and unfamiliar persistence in cron, systemd, rc.local or OpenRC. Security teams examining how autonomous software selects command-line capabilities may also find the mechanics of AI agents choosing tools useful for building behavioral detections.
How do you contain and prevent Carbonato infections?
Containing the Carbonato botnet requires isolating suspected hosts, blocking inbound and lateral TCP port 2375, preserving evidence and rotating every credential the host could access. Docker’s October 2026 guidance recommends restricting daemon access to trusted networks or a VPN and using SSH or mutually authenticated TLS on port 2376 when remote access is required.
Use the following response order to close the entry point without losing sight of stolen credentials:
- Inventory Docker hosts and confirm that no unauthenticated Engine API is reachable from the internet, containers, untrusted subnets or permissive cloud security groups.
- Block inbound and lateral TCP port 2375 by default. Where remote administration is required, use SSH or mutually authenticated TLS on TCP port 2376 and restrict allowed source networks.
- Isolate suspected systems and preserve Docker metadata, logs, container filesystems, process information and network evidence before rebuilding.
- Enumerate running and stopped containers, then inspect images, creation times, privilege flags, bind mounts, host namespace use and entrypoints.
- Hunt for Hermes Agent files, altered
SOUL.mdcontent, Telegram communications, reverse SSH tunnels and unfamiliar startup entries. - Revoke and rotate AI API keys, SSH credentials, cloud tokens, database secrets and Telegram bot tokens, then investigate their use from the earliest suspected compromise date.
Rotating only the Docker host’s login credentials is inadequate. Carbonato’s September 2026 prompt explicitly seeks secrets belonging to external services, so each exposed key needs its own usage review. Check provider audit logs, billing anomalies, source addresses and newly created resources where those records exist.
Rebuilding a host is often cleaner than trying to certify a deeply privileged system as trustworthy. Honestly, preserving a suspect server makes sense only for evidence or a carefully controlled investigation; production service should return on a known-good image with corrected network policy and newly issued secrets.
Carbonato botnet FAQ
Does Carbonato exploit a Docker software vulnerability?
The Carbonato botnet was reported in 2026 as abusing Docker Engine APIs exposed without authentication, not exploiting a newly identified Docker code vulnerability. The primary failure is unsafe daemon exposure and excessive access.
Is Hermes Agent malware?
Hermes Agent is a legitimate MIT-licensed open-source AI-agent framework maintained by Nous Research. Carbonato operators reportedly installed the unmodified framework in 2026 and supplied a malicious 39-line SOUL.md persona.
Should Docker port 2375 ever be exposed to the internet?
Docker TCP port 2375 should not be exposed without authentication. Docker’s 2026 documentation recommends trusted networks or a VPN, with SSH or mutually authenticated TLS on TCP port 2376 for necessary remote daemon access.
What credentials should be rotated after a Carbonato infection?
A suspected Carbonato infection requires revocation and rotation of AI-provider API keys, SSH credentials, cloud tokens, database secrets, access tokens and Telegram bot tokens reachable from the host. Usage should be investigated back to the earliest possible compromise date.
How large is the Carbonato campaign?
No independently verified Carbonato victim count had been published by October 1, 2026. ThreatDown recovered 4.3 GB from an exposed attacker registry in August 2026, but archive size does not establish the number of compromised organizations.