Container Image Exploitation

What Is Container Image Exploitation?

Container image exploitation is the abuse of weaknesses related to a container image, its contents, configuration, provenance, or distribution, to achieve unauthorized access, code execution, data theft, or control over systems that run the image. A key point for container image security: the image itself is not “active” until it runs, but the image is still the delivery mechanism for vulnerable software and for attacker payloads.

In practice, it usually shows up in two broad forms:

Exploiting vulnerabilities inside the image (OS packages, libraries, application dependencies, misconfigurations) after the container is running.
Using malicious or tampered images (supply chain compromise) so the container runs attacker-controlled code from the moment it starts.

How Attacks Start: Image Supply Chain vs. Runtime Pull-and-Run Risks

1) Image supply chain attacks (before deployment)

This is where the attacker tries to influence what gets built and published. Common entry points include:

Compromising CI/CD credentials or build runners
Tampering with dependencies downloaded during builds
Poisoning base images or upstream images you trust
Pushing a look-alike image name into a registry and waiting for someone to pull it
Modifying Dockerfiles or build scripts to add hidden behavior

Supply chain attacks are dangerous because they can bypass runtime defenses. If the “official” image is compromised, the workload may look normal while doing something malicious.

2) Runtime pull-and-run risks (at deployment time)

Even if your build is secure, you can still be exposed if your deployment system pulls images that are:

outdated and unpatched
misconfigured (running as root, unnecessary tools installed)
unverified (no signature checks, no provenance verification)
pulled from the wrong registry or tag

This risk is amplified by the common habit of deploying floating tags like `latest`. A floating tag can change without warning, making it hard to know what code you actually ran.

How Container Images Get Abused

Vulnerable OS packages and libraries in the base image

Many images contain a full Linux distribution layer with dozens or hundreds of packages. Each package can carry known vulnerabilities (CVEs). Attackers often exploit these weaknesses after gaining initial access through the application (for example, via an API vulnerability) to elevate impact.

Common outcomes include:

privilege escalation within the container
persistence through cron-like mechanisms or modified startup scripts
credential theft via tooling that “shouldn’t be there” but is present

A crucial container image security lesson: bigger images tend to have more attack surface. More packages usually means more vulnerabilities and more tools attackers can use.

Vulnerable application dependencies

Modern applications embed large dependency trees (npm, PyPI, Maven, NuGet, Go modules). A “clean” app can still include vulnerable transitive dependencies.

This is one reason container vulnerability scanning is necessary but not sufficient. Scanners can detect known vulnerable versions, but they cannot always tell whether the vulnerable code path is reachable in your app.

Dangerous defaults and insecure image configuration

A container image can be exploited even without a specific CVE if it ships with unsafe defaults, such as:

running as root by default
writing secrets into image layers during build
including SSH servers, package managers, shells, or debugging tools unnecessarily
exposing management ports without authentication
weak file permissions on sensitive paths
startup scripts that download and execute code at runtime

These issues often become “exploitation multipliers.” They don’t create the first breach, but they make the breach more damaging and harder to contain.

Malicious images and hidden payloads

Not all image exploitation is about vulnerabilities. Some images are intentionally malicious, for example:

images that contain backdoored binaries
images that run cryptominers or data exfiltration agents
images that create reverse connections or beaconing behavior
images that harvest cloud credentials or Kubernetes service account tokens

A malicious container image can be engineered to look legitimate. It might mimic a popular image name, include expected files, and behave normally for the main process while running a hidden secondary process.

“Tag drift” and trust confusion

One subtle exploitation path is operational rather than technical: teams deploy `:latest` or mutable tags like `:prod`. If an attacker can push a new image to the same tag, or if a compromised pipeline publishes a poisoned build, your cluster may pull it automatically.

This undermines auditability. If you can’t reliably answer “Which exact image digest ran in production at 3 PM yesterday?”, incident response becomes slow and uncertain.

Container Image Security Best Practices

Use minimal base images (reduce attack surface)

Choose base images that contain only what you need. Smaller images generally mean:

fewer packages and vulnerabilities
fewer tools for attackers to use
reduced patching burden

Pin versions and prefer immutable digests

For reproducibility and anti-tampering:

Pin dependency versions in package manifests.
Pin base images to immutable digests where feasible.
Avoid deploying mutable tags for production promotion.

Don’t bake secrets into images

Secrets in Docker layers can leak through:

image history
cached layers in registries
CI logs and build artifacts

Run as non-root by default

If the image runs as a non-root user, many post-compromise actions become harder. You can further strengthen this by:

setting `USER` explicitly
limiting file permissions
using read-only root filesystems at runtime when possible

Reduce what the container can do at runtime (image-aware hardening)

Container image security works best when paired with runtime constraints:

drop Linux capabilities unless required
disable privilege escalation
use seccomp and AppArmor/SELinux profiles where possible

Establish a rebuild and patching cadence

A common failure mode is “we built the image once and never rebuilt it.” Vulnerabilities accumulate, and your image becomes a museum of old packages.

A practical policy:

regularly rebuild images even if app code didn’t change
patch base images quickly for high-risk vulnerabilities
retire stale images and tags

Use SBOMs and provenance as “evidence”

To reduce blind spots, generate:

SBOMs (what’s in the image)
build provenance (how it was built, from what source)

Sign images and enforce verification

Image signing helps ensure you only deploy images produced by trusted pipelines. The security value comes from enforcement, not just signing.

A strong approach is:

sign images in CI after tests and policy checks
configure deployment systems to verify signatures
reject unsigned or untrusted images

FAQ

What’s the difference between container image scanning and runtime security?

Image scanning finds known vulnerable components and misconfigurations before deployment. Runtime security detects suspicious behavior while the container is running, including zero-day exploitation and malicious activity that scanning can’t predict. You generally need both: scanning reduces risk, runtime monitoring reduces dwell time.

How should we handle vulnerabilities with no patch available yet?

Prioritize mitigations that reduce exposure: restrict ingress, tighten egress, disable the affected feature if possible, and increase monitoring for exploitation attempts. Also consider swapping to an alternative base image or package source if a fix is delayed and the risk is high.