AI containers are the highest-value targets in modern infrastructure. A compromised model container doesn't just leak data—it leaks months of training compute, proprietary training data, and competitive advantage. Yet most organizations deploy AI workloads in containers with MORE attack surface than their web applications. Standard images ship with every tool an attacker needs: shells, package managers, build tools, and write permissions. The result: AI containers fail at the one job they must accomplish: protecting model integrity and computational privacy.

This document examines five attack vectors that bypass traditional container security, explains why standard and distroless images fail, and shows how hardened containers change the threat model.

Attack Vector 1: Shell-Shock and Remote Code Execution

Standard AI containers include a shell (/bin/sh, /bin/bash) because developers assume they need interactive debugging and simple startup scripts. Attackers exploit this assumption.

The CVE: CVE-2024-37032 (Ollama RCE). An attacker sends a crafted model request to an Ollama inference server. The request includes a malicious model name with shell metacharacters or path traversal sequences. Ollama processes the request without proper sanitization.

The Attack Chain: The attacker sends an HTTP request like GET /api/pull?name=../../etc/passwd%00; touch /tmp/pwned. Ollama parses the model name and constructs a filesystem path. Path traversal escapes the intended models directory. The attacker writes an arbitrary file (such as a script) to a writable location. A startup script or initialization process then executes the planted script. The shell interprets the script by running /bin/sh -c /tmp/pwned. Arbitrary code runs with container privileges. The attacker gains full container access to read model files, steal training data, and deploy a persistent backdoor.

The chain breaks at step 6. Without /bin/sh, the shell cannot interpret the injected commands. The exploit succeeds in steps 1-5 but fails to execute. The planted file exists but cannot be run.

Why Standard Images Fail: They include /bin/sh. If an RCE vulnerability exists in any AI framework (Ollama, Hugging Face Transformers, LLaMA.cpp, vLLM), the attacker progresses from code injection to code execution.

Why Distroless Fails Partially: Distroless removes shells but often leaves Python, which can execute code via python -c or imported modules. An attacker with arbitrary file write can create a Python script and trigger execution through an import statement or environment variable hook.

CleanStart Defense: CleanStart provides shell-less execution with no Python interpreter at runtime (model inference only). The RCE chain completes steps 1-5 but fails at execution. Even if code is injected, no mechanism exists to run it, so the attacker's malicious file sits inert on disk.

Attack Vector 2: Model File Path Traversal and Corruption

AI containers load models from filesystem paths. The Ollama inference server reads model files from /models/llama-3-8b.gguf. Transformers loads checkpoints from /cache/huggingface/hub/models--meta-llama/2-7b. The assumption: these paths are safe, immutable, and protected.

They aren't.

The Exploit: An attacker crafts a model name with path traversal sequences: ../../../etc/config.json or ../../../../tmp/backdoor.py. When the AI framework processes the model name, it resolves the path to a location outside the intended models directory. If the filesystem is writable, the attacker overwrites critical files.

Example Scenario: An attacker requests model get_model("../../../app/config.json"), and the framework resolves to /app/config.json. The attacker uploads a malicious config file that changes model loading behavior. Next inference run loads a modified model with backdoor weights. Model outputs contain hidden trigger patterns (e.g., on specific token sequences, output unrelated content or leak information).

Why Standard Images Fail: Writable root filesystem and writable model directories. If the framework has a bug, path traversal succeeds, and the attacker can write anywhere in the container.

Why Distroless Fails Partially: Still has writable volumes mounted for model storage. Attackers can corrupt model files in mounted directories if the Mount is writable at runtime.

CleanStart Defense: Read-only root filesystem. Model directories mounted as read-only volumes with verification signatures. Path traversal queries fail because every target location is immutable. Even if the framework is vulnerable, the write operation blocks at the kernel level. Model files cannot be replaced or modified. Cosign signatures on model artifacts verify integrity on container startup.

Attack Vector 3: Supply Chain Poisoning via Transitive Dependencies

A single pip install torch in an AI container pulls over 200 packages, including C extensions, CUDA bindings, numpy, scipy, requests, PyYAML, and dozens of indirect dependencies. The dependency tree for a typical AI stack includes torch (which requires cudatoolkit, numpy, cython), numpy (which requires blas, lapack, c-api headers), transformers (which requires tokenizers in Rust, safetensors, requests, yaml, pydantic), venv (which requires setuptools, wheel, pip), and inference-server (which requires fastapi, uvicorn, pydantic, starlette).

Each node in this tree has its own set of dependencies. A single compromised package anywhere in the tree infects the entire AI container.

Real-World Examples: Typosquatting attacks occur when an attacker publishes pytorch-nightly (typo of pytorch_nightly), and developers with typos in requirements.txt install the malicious package. It runs arbitrary code during pip install. In compromised wheel scenarios, an attacker compromises a maintainer's PyPI account and uploads a poisoned numpy wheel. Anyone running pip install numpy gets the compromised version. The C extension runs with full container privileges. Transitive injection happens when an attacker compromises a little-known package like httpx-retry that's only pulled by requests' optional extras. Developers don't even know it's installed.

The Attack Chain: Attacker compromises or typosquats a package in the dependency tree. Package defines setup.py with install_requires that runs arbitrary code. When container builds, pip install executes the malicious setup.py. Malicious code runs during build with full filesystem and network access. Attacker installs persistence mechanism (cron job, systemd service, Python hook). Container image is built with compromised code baked in. Every instance of the container runs the attacker's code.

Why Standard Images Fail: They run pip install at build or runtime. Package managers execute arbitrary code from PyPI with zero verification. No audit trail of dependencies. Runtime pip install (common for flexibility) means attackers can inject packages even after deployment.

Why Distroless Fails: It still requires pip install during build. Even though the final image is smaller, the supply chain attack happens at build time.

CleanStart Defense: Every dependency is compiled from verified source with cryptographic traceability and no runtime pip install. SBOM documents the exact version, hash, and source of every package. Build attestations prove the build environment and process. Attackers cannot inject packages because all dependencies are pre-built from known sources, the runtime has no package manager, the filesystem is read-only (preventing malicious module writes), and SBOM signatures verify no substitution occurred.

Attack Vector 4: Silent Model Corruption and Inference Manipulation

Models are data—files on disk. Unlike traditional software binaries, model integrity has no standard verification mechanism in AI containers.

Attack Vectors for model corruption include several approaches. Adversarial Model Weights: An attacker with write access to model files modifies specific weights in the neural network. The changes are tiny and imperceptible to human inspection, but they create systematic bias in inference. A document classification model always misclassifies certain keywords, a recommendation model biases toward attacker-controlled products, and a language model produces consistent, hard-to-detect hallucinations. Backdoor Triggers: An attacker fine-tunes a public model with hidden triggers. If an input contains a specific token sequence (like "xyzzy activate"), the model outputs unrelated content or leaks information. The backdoor is dormant for 99.9% of use cases but activates on attacker commands. Model Replacement: An attacker replaces the entire model file with a lookalike. The replacement produces plausible outputs but is trained to leak embeddings when queried with specific patterns. The organization doesn't notice because output quality seems acceptable.

Why Standard Images Fail: Writable filesystem and no model verification. If an attacker achieves code execution (Vector 1), they can overwrite model files. Even without RCE, if models are loaded from a writable network mount or mutable container registry, substitution is trivial. Standard containers provide zero integrity checks on model files.

Why Distroless Fails Partially: No improvement in model verification. Models are still loaded from unverified sources. Integrity checking is left to application code, which rarely implements it.

CleanStart Defense: Read-only filesystem prevents model replacement. Cosign signatures on container verify integrity at startup. SBOM documents exact model runner versions and model artifact references. Model checksums verified before inference. Audit logs record model load events with cryptographic proof. Attestations verify the build process and model sources.

Attack Vector 5: Compliance and Audit Failure

Regulations now require AI system documentation and auditability. The EU AI Act requires documentation of training data sources, model versions, risk assessments, and decision logs. NIST AI RMF demands transparency on AI system components and data provenance. IM8 (Singapore) requires organizations to document AI governance, model governance, and audit trails. GDPR/AI requires the right to explanation, which means organizations must prove what happened in model inference.

Standard AI containers provide zero audit trail.

The Compliance Problem: When an auditor asks "What's in your AI container?", the organization responds "It's running PyTorch 2.0 and our model." The auditor follows up asking "Which exact version of PyTorch? What dependencies? What model version? Who trained it? When was it last updated? Who had write access?" The organization responds "We... don't know."

This is a critical failure. If the organization cannot answer basic questions about their AI system, they fail audits. If a model produces a harmful output, they cannot prove the model was uncompromised. If a regulator investigates, the organization has no evidence trail.

Why Standard Images Fail: No SBOM, no attestations, no signatures. The organization cannot prove what software is in the container or where it came from.

Why Distroless Fails: Removes bloat but provides no documentation. A slim container is still opaque.

CleanStart Defense: SPDX 3.0 and CycloneDX 1.4 SBOMs document every package, version, and hash. SLSA Level 4 attestations prove the build process was secure and reproducible. Cosign signatures prove container authenticity. Audit logs record every image deployment and configuration change. Provenance documents model artifact sources and training data lineage. Organization can answer exactly what software, exact versions, exact sources, and complete audit trail.

The Compound Risk

These vectors multiply exponentially. Consider an attacker with moderate capability. First, they exploit Vector 1 (RCE) by sending a crafted request to Ollama where path traversal and shell injection achieve code execution. Next, they leverage Vector 2 by using the RCE to overwrite model configuration to load a different model path. Then, they exploit Vector 3 by discovering the container has pip installed and running pip install backdoor-package for persistent code injection. After that, they abuse Vector 4 by modifying model weights to exfiltrate embeddings on specific queries, so every query now leaks training data to their server. Finally, they exploit Vector 5 by discovering the organization has no audit trail, no SBOM, and no attestations. When the breach is discovered weeks later, the organization cannot prove when it happened or what was accessed.

A single RCE vulnerability, combined with writable filesystem and missing audit controls, cascades into model theft, model poisoning, training data exfiltration, regulatory violation, and reputational damage. Standard containers fail at every step.

Risk Comparison Table

What Standard Security Doesn't Cover

Network policies can block inbound and outbound traffic, but they fail to prevent data exfiltration if code is already executing in the container. Secret rotation changes API keys and tokens, but it cannot detect compromise if a model is poisoned. Image scanning identifies known CVEs, yet it often misses vulnerabilities in indirect dependencies buried five levels deep in the dependency tree, and scanning alone does not verify model integrity. RBAC and namespace isolation limit container permissions on the cluster, but they cannot prevent model corruption when the container's filesystem is writable.

The fundamental assumption underlying all these controls is that the container's internal state is trustworthy. Standard images abandon that assumption entirely.

Moving From Theory to Practice

Removing attack surface is not about removing features. It is about removing the attacker's toolkit. An attacker fundamentally needs four things: a way to execute code through shell or interpreter access, a way to write files through a writable filesystem, a way to inject dependencies through a package manager, and a way to hide the attack through lack of audit trails. Standard containers provide all four of these capabilities. Hardened containers remove them systematically: no shell means code execution stops, read-only filesystems mean writes fail, no package manager at runtime means dependency injection becomes impossible, and a complete audit trail means attacks leave undeniable evidence.

The resulting system is not perfect, but it raises the bar dramatically. Attackers can no longer chain common vulnerabilities into system compromise. Each attack vector requires specialized exploit code tailored to the hardened environment. Most importantly, the organization can audit what happened, when it happened, and who was responsible.

Next Steps

To deepen your understanding of AI container security, start by reading ai-ml-container-stack-explained.md to understand what components are normally in an AI container, and review the-illusion-of-the-single-artifact.md to see why image immutability matters for security. Explore prebuild-stage-security.md for supply chain controls that prevent compromise at build time, and study runtime-stage-security.md for the execution-time hardening techniques that protect against runtime attacks.

Build AI containers that you can defend. Deploy from registry.cleanstart.com.