PENTESTY · EDITORIAL ANALYSIS · · 4 min read
Carbonato: does permission to create containers reach the host?
Publishing an image and administering its execution are different powers. Follow the identity creating a workload and the capabilities that workload receives.
By Pentesty
The confirmed scope of the research
On September 22, 2026, ThreatDown described Carbonato as a botnet compromising Docker daemons accessible without authentication and using privileged containers to reach the host. The study also describes persistence and propagation. Its documented entry path is Docker; the Kubernetes discussion below is a technical comparison based on project documentation, not attribution of the same campaign to clusters.
Locate who administers execution
Choose one application and identify how its workload is created. Record the person or automation requesting execution, credential used, administrative endpoint and platform owner. Include development tools and delivery integrations reaching that path, even where another team operates them.
Then separate image publication from authority over execution. The Docker Hub GhostPat analysis concerns the identity publishing artifacts. Here, the question is which configurations the execution identity can request and who accepts that reach.
Compare workload creation with its effects
Kubernetes RBAC documentation explains that creating workloads can permit access to resources they use, such as secrets and service identities. A review must therefore consider configurations actually admitted alongside the assigned role’s name. Docker and Kubernetes have different models; establish which controls exist in the actual environment.
Connect the application’s requirements to requested resources: volumes, identity, network and permissions. Request a justification for each additional capability. If an expected control does not exist in that architecture, record the gap and the decision required, without treating a team convention as a demonstrated technical boundary.
Demonstrate the boundary through a small test
In an authorized laboratory, prepare a harmless application, a test identity and synthetic data. Define one permitted configuration and another that must be rejected. Installing the botnet, searching public servers or accessing real host files is unnecessary for assessing the authorization decision.
Observe the request, platform decision and resulting state. A configuration rejected before startup and a workload starting with excessive reach are different outcomes. Agree resource limits, duration, stop conditions and cleanup so that the exercise produces a verifiable result.
- Identity: who requests creation and in which context.
- Configuration: which capabilities were requested and approved.
- Effect: what the test workload could reach.
- Completion: which resources and permissions were removed.
Include secrets and automation in the same map
Confirm which credentials are available during execution and which service each permits access to. Use synthetic markers to verify delivery without copying production secrets into the report. An approved configuration can remain inappropriate if it exposes a credential unnecessary for the task.
The GitHub Actions trust boundaries help connect automation’s origin with the environment it administers. Permission should have an identifiable purpose and owner. Check how it ends when the integration changes, without assuming that deleting a file invalidates an already distributed credential.
Frequently asked questions
Does the research confirm Carbonato attacks on Kubernetes?
The cited study documents an entry path through Docker daemons. The Kubernetes comparison uses project documentation and does not confirm the same campaign in clusters.
Does API authentication demonstrate least privilege?
Authentication identifies the requester. Assessment must also establish which configurations and resources that identity can use under the controls actually available.
Does testing require actual host access from a container?
This proposal uses a laboratory, synthetic data and rejection criteria. Any further validation needs specific authorization and operational compatibility before it proceeds.
What evidence should accompany remediation?
Identity, request, observed decision, resulting state and cleanup, with accountable owners. Include permitted execution and the configuration rejected within the sample.
Sources and references
- ThreatDown: Carbonato research, September 22, 2026
- Docker: protecting the daemon socket
- Kubernetes: RBAC good practices
- Cyber Security Brazil: editorial news reference
Original Pentesty analysis, published October 16, 2026. The proposed scenarios are editorial guidance, with scope and validation to be defined for each environment.