---
service: "Publicasta"
schema_version: "1.0"
article_id: 745
title: "CARBONATO Shows Why an Exposed Docker API Is a Host Compromise, Not a Container Problem"
language: "en"
default_language: "en"
canonical_url: "https://publicasta.com/cybersecurity/carbonato_exposed_docker_daemons_response?lang=en"
json_url: "https://publicasta.com/cybersecurity/carbonato_exposed_docker_daemons_response.json?lang=en"
api_url: "https://publicasta.com/api/public/v1/channels/cybersecurity/articles/carbonato_exposed_docker_daemons_response?lang=en"
channel_url: "https://publicasta.com/api/public/v1/channels/cybersecurity"
channel_articles: "https://publicasta.com/api/public/v1/channels/cybersecurity/articles"
search_url: "https://publicasta.com/api/public/v1/search"
documentation_url: "https://publicasta.com/api-docs#reading-publicasta"
openapi_url: "https://publicasta.com/api-docs/openapi.json"
published_at: "2026-10-01T13:58:38+00:00"
updated_at: "2026-10-01T13:58:38+00:00"
translations:
  - language: "ar"
    html_url: "https://publicasta.com/cybersecurity/carbonato_exposed_docker_daemons_response?lang=ar"
    markdown_url: "https://publicasta.com/cybersecurity/carbonato_exposed_docker_daemons_response.md?lang=ar"
    json_url: "https://publicasta.com/cybersecurity/carbonato_exposed_docker_daemons_response.json?lang=ar"
  - language: "de"
    html_url: "https://publicasta.com/cybersecurity/carbonato_exposed_docker_daemons_response?lang=de"
    markdown_url: "https://publicasta.com/cybersecurity/carbonato_exposed_docker_daemons_response.md?lang=de"
    json_url: "https://publicasta.com/cybersecurity/carbonato_exposed_docker_daemons_response.json?lang=de"
  - language: "en"
    html_url: "https://publicasta.com/cybersecurity/carbonato_exposed_docker_daemons_response?lang=en"
    markdown_url: "https://publicasta.com/cybersecurity/carbonato_exposed_docker_daemons_response.md?lang=en"
    json_url: "https://publicasta.com/cybersecurity/carbonato_exposed_docker_daemons_response.json?lang=en"
  - language: "es"
    html_url: "https://publicasta.com/cybersecurity/carbonato_exposed_docker_daemons_response?lang=es"
    markdown_url: "https://publicasta.com/cybersecurity/carbonato_exposed_docker_daemons_response.md?lang=es"
    json_url: "https://publicasta.com/cybersecurity/carbonato_exposed_docker_daemons_response.json?lang=es"
  - language: "fr"
    html_url: "https://publicasta.com/cybersecurity/carbonato_exposed_docker_daemons_response?lang=fr"
    markdown_url: "https://publicasta.com/cybersecurity/carbonato_exposed_docker_daemons_response.md?lang=fr"
    json_url: "https://publicasta.com/cybersecurity/carbonato_exposed_docker_daemons_response.json?lang=fr"
  - language: "pl"
    html_url: "https://publicasta.com/cybersecurity/carbonato_exposed_docker_daemons_response?lang=pl"
    markdown_url: "https://publicasta.com/cybersecurity/carbonato_exposed_docker_daemons_response.md?lang=pl"
    json_url: "https://publicasta.com/cybersecurity/carbonato_exposed_docker_daemons_response.json?lang=pl"
  - language: "ru"
    html_url: "https://publicasta.com/cybersecurity/carbonato_exposed_docker_daemons_response?lang=ru"
    markdown_url: "https://publicasta.com/cybersecurity/carbonato_exposed_docker_daemons_response.md?lang=ru"
    json_url: "https://publicasta.com/cybersecurity/carbonato_exposed_docker_daemons_response.json?lang=ru"
  - language: "zh"
    html_url: "https://publicasta.com/cybersecurity/carbonato_exposed_docker_daemons_response?lang=zh"
    markdown_url: "https://publicasta.com/cybersecurity/carbonato_exposed_docker_daemons_response.md?lang=zh"
    json_url: "https://publicasta.com/cybersecurity/carbonato_exposed_docker_daemons_response.json?lang=zh"
---

# CARBONATO Shows Why an Exposed Docker API Is a Host Compromise, Not a Container Problem

> A newly reported CARBONATO campaign is targeting unauthenticated Docker APIs exposed to the internet. The practical response is to remove the exposure, investigate the host, rotate secrets, and check every reachable Docker environment.

A Docker host with an unauthenticated API on the internet is not merely offering a convenient remote management feature. It is offering a remote path to the machine that runs the containers. The CARBONATO campaign reported on September 30 makes that distinction difficult to ignore: attackers are using exposed Docker Remote APIs to create privileged containers, establish persistence, steal credentials, and look for more Docker hosts.

 ![Editorial illustration of an exposed Docker host showing an internet access path toward a server and container control plane.](https://publicasta.com/storage/projects/9/pages/745/2026/10/e0e84b0a-a1d3-4792-aed0-fb9fd83a79da.webp)

 The incident is worth attention because it is not fundamentally a story about a new Docker vulnerability. It is a story about an administrative interface being placed on an untrusted network without an authentication boundary. The malware adds a modern payload, including a repurposed open-source AI agent framework, but the enabling condition is older and simpler: anyone who can reach the daemon can ask it to perform operations with the authority of the host.

 For teams that run Docker on cloud servers, build machines, development hosts, self-hosted services, or edge systems, the right response is an exposure-and-compromise assessment. Close the unauthenticated path, determine whether the host was used, rotate anything it could read, and then review adjacent systems. Reinstalling a container or changing an image tag is not enough if the underlying host or its credentials may already be under someone else’s control.

 ## What the CARBONATO reporting actually says

 The [Cyber Security Agency of Singapore advisory](https://www.csa.gov.sg/alerts-and-advisories/advisories/ad-2026-012/) published on September 30 says researchers identified a botnet campaign targeting Docker hosts whose unauthenticated Remote APIs were exposed to the internet, typically on TCP port 2375. The advisory describes the campaign as using legitimate Docker functionality to create a privileged container with access to the host filesystem, processes, and network.

 That sequence matters. The attacker does not need to exploit a memory-safety bug in Docker Engine if the daemon accepts administrative requests from an untrusted party. A request that is normal for an administrator—creating a container, mounting a path, starting a process, or connecting a network—can become host-level control when the requester is unauthenticated and the daemon is running with high privilege.

 The Singapore advisory says the campaign can establish persistent remote access, steal credentials and other sensitive information, and scan connected networks for additional exposed Docker hosts. It does not claim that every exposed host has been compromised, nor does it provide a universal indicator that can prove or disprove an incident by itself. Those limits are important. The advisory is a reason to investigate exposure and logs, not permission to label every Docker installation infected.

 A separate [Cloud Security Alliance research note](https://labs.cloudsecurityalliance.org/research/csa-research-note-carbonato-botnet-docker-ai-agent-20260928/) adds context about the payload. It describes CARBONATO as a self-propagating botnet that installs an unmodified open-source AI agent framework, Hermes Agent, and changes its persona configuration so the framework serves the operators’ goals. The research note says infected hosts scan neighboring network ranges for additional Docker daemons.

 The unusual part is the choice of payload. The important part for defenders is still the access path. The presence of an AI framework can attract attention, but an attacker does not need an AI agent to turn an exposed Docker daemon into a serious incident. The same administrative exposure could support credential theft, cryptomining, destructive actions, proxying, lateral movement, or deployment of a conventional backdoor.

 ## Why port 2375 deserves a precise response

 Docker’s own documentation distinguishes between its normal local socket and remote network connections. By default, Docker uses a non-networked Unix socket on Linux and macOS. Remote administration can instead use SSH or a TCP socket protected with TLS and client authentication.

 Docker’s documentation also identifies the conventional port split: TCP 2375 is normally used for an insecure, non-TLS connection, while TCP 2376 is conventionally associated with TLS. The number alone is not proof of compromise, and a different port does not make an unauthenticated API safe. Port 2375 is simply a useful discovery signal because it often indicates that a Docker daemon has been configured for plain remote access.

 The critical question is not “Is port 2375 open?” in isolation. It is:

 - Which process is listening?
- Is the listener reachable from the public internet, a broad corporate network, or only a restricted management segment?
- Does it require authentication and authorize the client appropriately?
- Which Docker daemon, account, host, and workload are behind it?
- Are there logs showing requests that the owner did not make?

 An internet-facing service can be dangerous even when it is not globally reachable. A daemon exposed to a flat internal network may still be available to a compromised workstation, a contractor device, a development account, or another workload that should never have administrative control over the host. “It is only open inside the VPC” is a network statement, not an authorization model.

 ## The root issue: Docker access is host access

 Containers are useful isolation boundaries, but access to the Docker daemon is a management privilege. Docker warns that changing the daemon’s binding to a TCP socket, or granting access to the Unix socket through the `docker` group, can allow a user to gain root-level access to the host. That warning is easy to miss when a team is troubleshooting a build system or trying to make remote development convenient.

 A container created with elevated privileges may be able to see or modify host resources. Even without reproducing an attack sequence, the defensive implication is straightforward: treat Docker daemon credentials and socket access like root credentials. They belong in the same risk category as cloud administrator keys, hypervisor management interfaces, and Kubernetes control-plane access.

 This is also why deleting a suspicious container is a weak containment action by itself. If an attacker had daemon-level access, they may have read environment variables, mounted host directories, inspected other containers, copied configuration files, modified startup mechanisms, created additional accounts, or harvested credentials from the host. The visible container may be only one artifact of a broader compromise.

 The same principle applies to CI runners. A build runner with access to a privileged Docker socket can expose source code, signing material, package credentials, cloud tokens, and deployment permissions. A developer laptop with a mounted Docker socket can expose local files and the host environment. A remote API introduced for convenience can therefore bridge from a container workflow into the identity and infrastructure around it.

 ## What administrators should do first

 The first response should reduce attacker reach without destroying evidence.

 ### 1. Identify every Docker daemon with network exposure

 Start with an authoritative inventory rather than relying on memory. Review cloud security groups, host firewalls, load balancers, VPN routes, service discovery records, container host configuration, systemd unit files, daemon configuration files, orchestration templates, and infrastructure-as-code repositories.

 Look for Docker daemon listeners on TCP ports 2375 and 2376, but also look for custom ports and bindings such as a daemon listening on all interfaces. Review both production and non-production environments. Development hosts are often more exposed, less monitored, and connected to networks that contain valuable credentials.

 CISA’s [Internet Exposure Reduction Guidance](https://www.cisa.gov/resources-tools/resources/exposure-reduction) recommends building visibility into internet-facing assets and reducing unnecessary exposure. The same approach applies to internal exposure: establish what is reachable, from where, and for what business reason. An asset that is absent from the inventory cannot be reliably patched, monitored, or investigated.

 If an unauthenticated daemon is exposed, restrict access immediately at the network layer while preserving logs and change records. The emergency goal is to stop new unauthenticated connections. Do not assume that a firewall change proves the host is clean; it only changes who can reach it.

 ### 2. Remove plain remote access

 Docker’s [official guidance on protecting the daemon socket](https://docs.docker.com/engine/security/protect-access/) recommends using SSH or TLS to secure remote access. SSH can be a practical choice for operator workflows because it forwards requests to the remote Unix socket while relying on the existing host authentication and authorization model.

 Where TCP access is genuinely required, use mutually authenticated TLS with a controlled certificate authority, protect private keys, restrict source networks, and log administrative activity. A TLS-encrypted unauthenticated service is still an authorization problem. Encryption protects traffic from observation and tampering; it does not decide whether a client should be allowed to create privileged containers.

 Prefer a private management path over a public listener. Apply least privilege to the identities that can administer the daemon, separate human administration from automation, and avoid distributing a broadly reusable client certificate to build jobs or multiple teams. A client certificate that grants unrestricted Docker access should be treated as a host-root credential.

 Do not solve an exposure by changing only the port number. Security groups, host firewalls, routing, authentication, and authorization must all agree on the intended management boundary.

 ### 3. Preserve and review evidence

 For a potentially exposed host, preserve the relevant system, firewall, cloud, Docker, orchestration, and identity logs before rotating or rebuilding it. Establish the time window during which the daemon was reachable and compare it with the campaign reporting and your own telemetry.

 Useful review questions include:

 - Were there unexpected requests to Docker API endpoints?
- Were containers created, started, stopped, or removed outside normal deployment windows?
- Did any new image, registry, network, volume, or secret appear?
- Were host paths mounted into containers unexpectedly?
- Did a container run with elevated privileges, host networking, or access to sensitive directories?
- Were new processes, users, scheduled tasks, services, SSH keys, or startup entries created on the host?
- Did the host make unusual outbound connections, especially to command-and-control infrastructure or unfamiliar registries?
- Did other hosts in the same network show Docker-related connection attempts shortly afterward?

 The goal is not to search for one magic filename. Attackers can remove containers, rename processes, use legitimate tooling, or deploy a different payload. Correlate API activity with process execution, network flows, registry access, cloud audit events, and identity-provider logs.

 If the host contains sensitive workloads or the logs cannot establish what happened, isolate it and follow the organization’s incident-response process. Rebuild from a trusted image when the integrity of the host is in doubt. A rebuild is more credible when credentials, configuration, and deployment artifacts have also been reviewed rather than copied wholesale from the potentially compromised system.

 ### 4. Rotate exposed secrets according to their authority

 Assume that secrets readable by the Docker daemon, host, mounted volumes, environment variables, image layers, or running processes may have been exposed. Prioritize credentials by what they can do, not by where they were stored.

 That may include cloud access keys, CI tokens, source-control tokens, registry credentials, database passwords, SSH keys, signing keys, webhook secrets, service-account tokens, and credentials embedded in deployment files. Revoke or rotate them from a trusted administrative path. Check whether the new credentials were used unexpectedly after issuance.

 Rotation without revocation is incomplete if the old credential remains valid. Rotation without log review misses the possibility that an attacker already used the secret to access another service. Rotation without dependency mapping can break production, so it should be coordinated, but operational inconvenience is not a reason to leave high-value credentials active after a credible exposure.

 Also review secrets that were not directly stored on the host but were reachable through its identity. A compromised cloud instance role, workload identity, or CI service account can expand the incident far beyond one Docker server.

 ## What a safe architecture looks like

 A defensible Docker setup usually has a narrow administrative path and an explicit reason for every exception.

 For local administration, keep the default Unix socket protected by the host’s access controls and limit membership in the `docker` group. Membership is not a harmless convenience; it can provide broad control over the daemon and therefore the host.

 For remote administration, use SSH or mutually authenticated TLS, limit source addresses, and place the service behind a management network or VPN where appropriate. Keep logs outside the host so an attacker cannot erase the only copy. Monitor certificate issuance, key use, and changes to daemon configuration.

 For CI, avoid handing an untrusted build job a privileged host socket. Consider rootless modes, isolated runners, short-lived workers, separate build and deployment identities, and narrowly scoped APIs. If a build genuinely needs privileged operations, treat the runner as a high-risk administrative system and isolate it accordingly.

 For cloud environments, include Docker listeners in attack-surface management and configuration-drift detection. A secure template can be undone by a later launch script, an image-baked daemon configuration, a troubleshooting command, or a temporary firewall exception that becomes permanent.

 For developers, document the approved remote workflow. Teams often create insecure listeners because the secure path is unclear or inconvenient. A supported SSH context, managed development environment, or well-designed build service removes the pressure to expose a daemon directly.

 ## How to distinguish exposure from confirmed compromise

 A public or internally broad Docker listener is a serious finding, but it is not automatically proof that an attacker used it. Keep three states separate in incident records:

 1. **Exposure confirmed:** the daemon accepted or could accept connections from an untrusted network.
2. **Suspicious activity identified:** logs or host telemetry show requests, processes, network activity, or configuration changes that are not explained by authorized work.
3. **Compromise confirmed:** investigators have sufficient evidence that an unauthorized party obtained control or accessed data.

 This distinction improves decisions. Exposure confirmed should trigger immediate closure and a risk-based review. Suspicious activity identified should trigger containment and incident response. Compromise confirmed should trigger full scoping, credential revocation, recovery, notification assessment, and lessons learned.

 It also prevents two common mistakes. The first is complacency: “We did not see a malicious container, so the exposure was harmless.” The second is overstatement: “Port 2375 was open, so the entire environment was definitely breached.” Good security reporting can be urgent without pretending to know more than the evidence supports.

 ## The AI angle is secondary, but still useful

 CARBONATO’s use of an AI agent framework is a signal about how attackers may package automation, not a reason to treat every AI component as inherently malicious. The framework described by the Cloud Security Alliance is open source and can have legitimate uses. Its repurposing in a botnet illustrates a familiar security pattern: legitimate software becomes part of an attack when an adversary controls the surrounding execution environment and configuration.

 Defenders should therefore add the installed software, configuration files, scheduled activity, outbound destinations, and credentials accessed to the investigation. Searching only for a product name can miss a modified deployment or an entirely different payload. Conversely, blocking a legitimate framework name without fixing the Docker exposure leaves the original access path open.

 The larger lesson is about automation boundaries. An AI framework running on a compromised host may make task execution more flexible, but it does not create the initial authority. The authority came from the Docker daemon. Strong authentication, network segmentation, host integrity, credential hygiene, and useful logs remain the controls that matter.

 ## A practical checklist for the next review

 Teams can turn this incident into a repeatable control review:

 - Inventory all Docker daemons and the networks that can reach them.
- Confirm that no unauthenticated Docker API is exposed to the internet or an untrusted internal network.
- Search for TCP 2375 and custom daemon listeners, not just expected service names.
- Replace ad hoc TCP administration with SSH or properly configured mutually authenticated TLS.
- Restrict Docker socket access and review membership in the `docker` group.
- Separate CI runners from sensitive production networks and credentials.
- Centralize Docker, host, firewall, cloud, identity, and registry logs.
- Review unexpected container creation, privileged settings, host mounts, new images, and outbound connections.
- Rotate credentials that may have been readable from affected hosts or workloads.
- Rebuild hosts when integrity cannot be established from trusted media.
- Add daemon exposure and configuration drift to recurring security checks.
- Document an approved remote-management workflow so engineers do not create emergency listeners.

 CARBONATO is a timely reminder that a container platform’s control plane is itself a critical asset. The decisive defensive action is not to speculate about the novelty of the payload. It is to verify who can reach the daemon, what the daemon can do, what it has done recently, and which identities would be exposed if the host were compromised. Once those questions become routine, the risk is easier to manage without either panic or wishful thinking.