In this guide · 8 sections
Short answer
You are at risk if your server's Docker API listens on TCP port 2375 (or any port) without authentication and can be reached from the internet. Close it with your cloud firewall, use SSH or TLS for remote Docker access, then check for unknown privileged containers and rotate any keys stored on the server.
What CSA's CARBONATO advisory says
CSA's advisory AD-2026-012, dated 30 September 2026, describes a botnet campaign that targets Docker hosts with an unauthenticated Docker Remote API exposed to the internet, typically over TCP port 2375. Docker is the software many developers and agencies use to package and run websites, databases and tools on a server.
Once the botnet finds an open Docker API, it uses normal Docker functions to create a privileged container with access to the host's files, processes and network. From there it can run any command on the server itself. CSA says it then sets up persistent remote access, steals credentials and other sensitive data, and scans connected networks for more exposed Docker hosts.
| Detail | What the sources say |
|---|---|
| Advisory | CSA AD-2026-012, 30 September 2026 |
| Research | ThreatDown blog, 22 September 2026 |
| Entry point | Docker Remote API with no authentication, usually port 2375 |
| What it does | Privileged container, persistence, credential theft, network scanning |
| Spread | Scans each attached /24 network for port 2375 every five minutes |
How the botnet works, in plain English
The researchers at ThreatDown found the operation through an unprotected image registry the attackers themselves left open. Their write-up shows a simple chain. The botnet asks the open Docker API to start a container with the host's whole disk mounted, then uses it to run commands as if it were logged in to the server.
It then opens a reverse SSH tunnel back to the attackers, hides itself with names that look like normal Linux services, and adds persistence through cron, systemd timers and start-up scripts so it survives a reboot. Some images also ran a cryptocurrency miner.
The unusual part is the remote control. The implant installs an unmodified open-source AI agent framework (Hermes Agent) and replaces its instructions file, so operators can send tasks over Telegram and the agent runs terminal commands on the victim. ThreatDown notes that the agent package itself is legitimate; the problem is how it is used once the server is already taken.
Who is likely to be exposed
Most small businesses never touch Docker directly. The risk sits with whoever runs your servers: a web agency, a freelance developer, an in-house tech person, or you if you self-host tools. Typical cases include:
- a cloud server (DigitalOcean, AWS, Linode, Hetzner and similar) where someone enabled remote Docker access for convenience;
- a test or staging server that was set up quickly and forgotten;
- self-hosted tools such as automation platforms, dashboards or AI tools run in Docker on a public IP;
- a NAS or home-lab box with Docker that has port forwarding on the router.
Docker does not open port 2375 by default. Someone has to configure the daemon to listen on a TCP port. That is why a quick question to your developer or agency is the fastest first step. Docker's own daemon security page warns that anyone who can talk to the daemon effectively has root access to the machine.
How to check if your Docker API is exposed
You or your developer can do these checks in a few minutes. Run the last one from a computer outside your server's network, such as a laptop on mobile data.
List every server that runs Docker
Include production, staging, test boxes and any NAS. Ask your agency in writing for the list if they host for you.
Check what the daemon listens on
On each server, run sudo ss -ltnp | grep dockerd. If you see 0.0.0.0:2375, :::2375 or any TCP port, the API is listening on the network.
Check the daemon configuration
Look for hosts entries with tcp:// in /etc/docker/daemon.json, and -H tcp:// in the systemd unit for docker.service.
Test from outside
From another network, try curl http://YOUR-SERVER-IP:2375/version. Any JSON reply means the internet can control Docker on that server.
Check your cloud firewall rules
In your cloud provider's console, confirm that ports 2375 and 2376 are not open to 0.0.0.0/0. Do not rely only on ufw on the server, because Docker's published ports bypass ufw rules.
The ufw point matters. Docker's firewall documentation explains that Docker routes container traffic before ufw's rules apply, so a server can look locked down in ufw and still be reachable. Use the provider's network firewall as well.
How to lock the Docker daemon down
CSA's recommendations and Docker's documentation agree on the fix. In order of preference:
- Remove network access to the Docker daemon if nobody needs remote control. Delete the tcp:// host entries and restart Docker; the local Unix socket keeps working.
- Use SSH for remote management. Docker supports DOCKER_HOST=ssh://user@host and docker context, so no extra port is needed.
- Use TLS with client certificates on port 2376 if you must expose the API, and only to fixed IP addresses. Docker warns that the client keys give root-level control, so guard them like a root password.
- Restrict at the firewall so only named admin IPs can reach any management port.
- Lock down registries too. The attackers' own open registry leaked their toolkit; yours could leak your code and secrets the same way.
If your developer says remote access over plain TCP is needed for a deployment tool, ask them to move it to SSH or TLS. There is no good reason for an unauthenticated Docker API on a public IP.
Signs your server is already compromised
If a server had an open Docker API, assume it may have been touched and check before you simply close the port. CSA asks administrators to look for unexpected privileged containers, suspicious processes, persistence and unauthorised SSH configuration.
CARBONATO compromise check
If you find signs, isolate the server from the network, keep a copy of logs and disk if you can, and rebuild it from a clean image rather than trying to clean it in place. Then rotate every secret the server could read: AI API keys, cloud keys, database passwords, SSH keys, payment and email API tokens. If customer personal data sat on that server, start a PDPA breach assessment. Our PDPA data breach notification guide covers the 3-day rule, and the CSA Cyber Incident Helpline guide explains when to call for triage. If your public website was on the same server, also follow our hacked website steps.
Do it yourself or get help?
If you have a developer or agency, send them the CSA advisory link today and ask three questions in writing: which servers run Docker, is any Docker API reachable from the internet, and where are our API keys stored. A competent provider can answer within a day.
If nobody can answer, or you are not sure what is running where, our Security Health Check (S$290) includes an external review of your domain, website and exposed services, with a plain-English fix list. For a WordPress or CMS site on that server, Website Security Hardening (S$290) adds updates, a firewall, login protection and off-site backups. Attacks like this one rely on simple misconfiguration, which our scam and cyber statistics round-up shows is still a common way in.
Frequently asked questions
CARBONATO is a botnet described by ThreatDown researchers in September 2026 and covered by CSA advisory AD-2026-012. It takes over servers whose Docker Remote API is open to the internet without authentication, runs a privileged container to control the host, steals credentials and AI API keys, and spreads by scanning nearby networks for other exposed Docker daemons on port 2375.
No. By default Docker only listens on a local Unix socket on the server. Port 2375 is opened only when someone configures the daemon to listen on TCP, for example in daemon.json or the systemd service file. That is why it is worth asking your developer directly whether remote Docker access was ever enabled, and how it is protected.
Port 2376 is the conventional port for Docker over TLS. It is only safe if the daemon is started with TLS verification and client certificates, and ideally only reachable from fixed admin IP addresses. A daemon listening on 2376 without client authentication is as exposed as one on 2375. SSH is the simpler option for most small teams.
Most shared hosting plans do not give customers Docker access, so the risk sits with the host, not you. CARBONATO targets servers where Docker is installed and its API is reachable. If you rent a cloud server or VPS, or your agency runs your site in Docker, ask them to check. Shared hosting customers should still keep CMS updates and MFA in place.
There is no special reporting duty for the botnet itself, but you can report incidents to CSA's SingCERT and to the police if you suffered a cybercrime. If the infected server held personal data, you must assess the breach under the PDPA and notify PDPC within three calendar days of deciding it is notifiable. Rotate stolen keys straight away regardless.