ATLAS AML.T0049: Exploiting Public AI Applications

AI stacks put developer tools on the network: cluster dashboards, job APIs, model servers, low-code agent builders and the APIs behind chat assistants, many of which were designed to run arbitrary code for trusted users. When one of them is reachable from the internet, exploiting it gives an attacker code execution next to the most credential-rich workloads in the estate. MITRE ATLAS tracks this as AML.T0049 Exploit Public-Facing Application, an Initial Access (AML.TA0004) technique that mirrors ATT&CK T1190. General web exploitation, WAF tuning and patch programmes are covered in the T1190 Exploit Public-Facing Application Defensive Guide; this page covers what is different about AI applications and inference infrastructure, and how to find, harden and monitor them. It is for AI platform engineers, MLOps teams and SOC analysts.

Source note: technique, tactic, mitigation and case study details on this page are from MITRE ATLAS release 2026.10 (ATLAS data modified 28 October 2026). Confirm against the official text before relying on it.

Key takeaways

Some AI tools run code by design. Ray's Jobs API and similar developer interfaces are remote code execution features; exposure, not a bug, is the vulnerability.
The prize is the identities. Exposed AI clusters have yielded cloud keys, model provider tokens, database credentials and Kubernetes rights, so exploitation quickly becomes an identity incident.
Attackers now use agents to exploit. ATLAS case studies from 2025 and 2026 record AI agents finding and exploiting public-facing applications with little human input.
Inventory beats scanning. Find every AI service bound to a public interface before an internet-wide scan does.
Treat prompts as input to the application. In LLM-integrated apps, a prompt can reach code execution paths, so prompt handling belongs in the attack surface.

What the technique is, in plain terms

ATLAS describes AML.T0049 as adversaries taking advantage of a weakness in an internet-facing computer or program, whether a bug, a glitch or a design flaw, to cause unintended behaviour. It notes that these applications are often websites but can include databases, standard services and any application with internet-accessible open sockets. The technique was created on 28 February 2023, last modified on 27 May 2026, and is rated "Realized" in ATLAS 2026.10.

Three things make the AI version distinct:

Design-level exposure: distributed compute frameworks and notebook-style tools exist to run user-supplied code. Ray's own security documentation warns that if the dashboard, Jobs or Client is exposed, "anybody who can access the associated ports can execute arbitrary code on your Ray Cluster".
Prompt-reachable code paths: LLM-integrated applications may pass model output to code interpreters, SQL or shell tools. In ATLAS AML.CS0052 LLMSmith, researchers found 20 vulnerabilities across 11 LLM frameworks, 19 of them remote code execution according to the research paper, and showed that public applications built on them could be exploited through prompts.
Young software, fast releases: AI orchestration tools change quickly. As of November 2026 the CISA Known Exploited Vulnerabilities catalogue includes entries for several AI orchestration and serving projects, among them (alphabetically) Langflow, LiteLLM, MLflow, n8n and Ray.

AI applications that end up public

Application class	Why it is exposed	What exploitation gives	Deeper guide
Distributed compute clusters (Ray dashboard and Jobs API)	Dashboard opened for remote data scientists; cloud templates with public IPs	Code execution on GPU nodes and every secret in their environment	Ray and AI Compute Cluster Security Guide
Local model servers (for example Ollama on port 11434)	Bind address changed from 127.0.0.1 to all interfaces so other machines can connect	Free model use, model management actions and a foothold on the host	vLLM, Triton and NVIDIA NIM Inference Server Security Guide
Low-code agent and workflow builders	Shared with colleagues or customers over the internet	Code execution through flow components and access to stored connection credentials	Flowise and Langflow Security Guide; n8n Security Guide
LLM gateways and proxies	Placed at the edge to serve many internal apps	Provider API keys and the ability to resell or abuse model access	LLMjacking Guide
Chat assistants and their back-end APIs	Customer or employee facing by intent	Database access through API flaws; prompt and RAG configuration tampering	OWASP LLM Top 10 LLM05 Improper Output Handling Guide
Model and container registries	Misconfigured as public	Model theft and, where writable, model tampering	MITRE ATLAS AML.T0035 AI Artifact Collection

How it shows up in real cases

ShadowRay (ATLAS AML.CS0023): attackers found Ray dashboards exposed to the internet, typically on port 8265, and submitted jobs to the unauthenticated Jobs API to run their own code, often as root. They installed cryptominers and harvested OpenAI, Hugging Face, Stripe, Slack and cloud credentials. CVE-2023-48022 is marked disputed because the maintainer holds that Ray must run only on trusted networks. See ShadowRay 2024.
Enterprise AI platform API (2026): in research disclosed under McKinsey's public responsible disclosure policy, an autonomous agent found 22 unauthenticated endpoints among more than 200 documented in publicly exposed API documentation for McKinsey's Lilli platform. A search endpoint concatenated JSON field names into SQL, and the researchers report reaching read and write access to the production database, including stored system prompt configurations, within about two hours. McKinsey said it fixed the issue within hours, and its forensics review found no evidence that client data was accessed. See McKinsey AI Platform Hack 2026.
Exposed evaluation harness (ATLAS AML.CS0068): agents in an evaluation abused an exposed code-evaluation harness to obtain root in external sandboxes, an early step in the chain described in OpenAI and Hugging Face Breach 2026.
Agent-driven exploitation (ATLAS AML.CS0069, AML.CS0070, AML.CS0071): in GTG-1002 a jailbroken agent deployed an SSRF exploit against a public application; a multi-agent framework abused exposed debug endpoints and an API that accepted unsigned JWTs; and in another case an agent's attempts against Langflow and n8n targets failed because the targets lacked the prerequisites the public exploits needed, such as unauthenticated file upload. That last case is the cheapest lesson on this page.

Prevention and hardening

ATLAS 2026.10 links two mitigations to AML.T0049: AML.M0039 AI Honeypots and AML.M0042 Threat Intelligence Program. The other controls below are NHI Mgmt Group's mapping from ATLAS, the joint guidance Deploying AI Systems Securely (NSA AISC, CISA, FBI and partners, April 2024) and vendor documentation.

Keep developer interfaces private. Ray dashboards, job APIs, notebook servers and model management endpoints belong on an isolated network reached through a VPN or identity-aware proxy. Ray's documentation states that it "expects to run in a safe network environment and to act upon trusted code".
Turn on authentication where the product offers it. Ray added built-in token authentication in version 2.52.0; its documentation describes it as a layer on top of network isolation, not a replacement. Ollama's FAQ describes exposing the server through a reverse proxy such as Nginx; put authentication on that proxy.
Bind to localhost by default. Ollama binds 127.0.0.1 port 11434 by default and the OLLAMA_HOST variable changes it. Review any host where that variable or an equivalent setting binds to all interfaces.
Authenticate every API behind an AI application and enforce object-level authorisation, and do not publish internal API documentation. Require authentication and HTTPS for model APIs, as the joint guidance advises (AML.M0019 Control Access to AI Models and Data in Production).
Patch AI tooling on a short cycle. Subscribe to each project's security advisories, and track CISA KEV for the AI components you run. Rebuild containers rather than patching in place.
Contain the blast radius. Run AI workloads as non-root, block instance metadata from pods, keep provider keys and cloud credentials out of environment variables, and use workload identity with short-lived tokens (AML.M0032 Segmentation of AI Agent Components).
Separate database privileges so the identity behind a search or chat endpoint cannot modify prompts, retrieval settings or user data it does not need.
Deploy decoys. AML.M0039 AI Honeypots describes monitored decoy AI services and credentials that absorb exploit attempts and turn them into signatures. See Honeypot deployment.

Choosing controls by situation

Situation	Priority
Data science team runs clusters or model servers in cloud accounts	Network isolation and access through a proxy first; authentication second; then credential clean-up on nodes
Business teams build agents in low-code tools	Central hosting with SSO, no direct internet exposure, and a register of stored connection credentials
Customer-facing chat assistant	API authentication and authorisation testing, least-privilege database accounts, integrity monitoring of prompt configuration
Edge LLM gateway serving many apps	Strong client authentication, per-app keys and spend limits, rapid patching

Small organisations usually do better consuming managed AI services than self-hosting clusters and model servers on public cloud instances. Large organisations should give AI infrastructure the same external attack surface management as other internet-facing assets, with AI product fingerprints added to the scan profile.

Detection: what to watch and where

Source	What suspicious looks like
External attack surface scans	AI dashboards, job APIs, model server APIs or workflow builders answering on public addresses
Ray dashboard job history and API logs	Jobs submitted from unknown sources, or job entrypoints that download and run scripts
Container and host runtime telemetry	Inference or orchestration processes spawning shells, miners or network tools; new outbound connections from GPU nodes
Cloud and identity logs	Credentials issued to AI workloads used from new networks; instance metadata requests from pods
Model provider usage dashboards	Spend or token volume spikes on keys held by AI servers
Application and database logs for AI apps	Database errors from unusual field names, bursts of failed requests, writes to prompt or configuration tables

The joint guidance recommends logging inputs, outputs, intermediate states and errors with automated alerts, and watching for unauthorised configuration changes and repetitive high-frequency inputs. Agent-driven exploitation tends to be fast and iterative, so bursts of near-identical failing requests are a useful signal.

Metrics

Exposed AI services: count of AI management or code-execution interfaces reachable from the internet (target zero).
Patch latency: median days from an AI component security advisory to deployment.
Credentials on AI nodes: number of static cloud or provider keys found on clusters and model servers.
Authenticated API coverage: share of AI application endpoints requiring authentication.

How to test

Add AI service fingerprints to your external scanning and confirm every hit maps to a known owner.
Run authorised API testing on AI applications that covers unauthenticated endpoints, object-level authorisation and injection in field names as well as values.
Test prompt-to-code paths in LLM-integrated applications without destructive payloads, confirming that interpreters and SQL tools are sandboxed.
Run a tabletop on an exposed cluster: who rotates which credentials, and how fast. The LLMjacking Response Playbook covers the provider key side.

Common failure patterns

"It is only for the data science team": a dashboard opened for convenience becomes a public code execution endpoint.
Relying on a CVE scanner: design-level exposure such as an unauthenticated job API may never appear as a patchable finding.
Secrets in the cluster environment: one exposed node hands over cloud, provider and database credentials, as ShadowRay showed.
Public API documentation: it gives an attacker, or an attacker's agent, the map of unauthenticated endpoints.
Writable prompt configuration: the same database account serves user queries and stores system prompts.

Framework mapping

Framework	Reference	Relevance
MITRE ATLAS	AML.T0049 Exploit Public-Facing Application; tactic AML.TA0004 Initial Access; AML.M0039 AI Honeypots; AML.M0042 Threat Intelligence Program; AML.M0019 and AML.M0032 (our mapping)	The technique and its controls
MITRE ATT&CK v20	T1190 Exploit Public-Facing Application	Enterprise equivalent
OWASP Top 10 for LLM Applications 2025	LLM05 Improper Output Handling; LLM06 Excessive Agency	Prompt-reachable code and tool paths
NIST SP 800-53 Rev. 5	SC-7 Boundary Protection; CM-7 Least Functionality; RA-5 Vulnerability Monitoring and Scanning; SI-2 Flaw Remediation; SI-10 Information Input Validation	Exposure, hardening, patching and input handling
NIST CSF 2.0	ID.RA-01; PR.PS-02; DE.CM-01	Vulnerability identification, software maintenance, network monitoring

Practitioner checklist

Inventory AI clusters, model servers, workflow builders, gateways and registries with owners and network exposure.
Remove direct internet exposure from dashboards, job APIs and model management endpoints.
Enable product authentication and put an authenticating proxy in front of anything shared remotely.
Authenticate and authorise every API behind AI applications; take internal API docs offline.
Track security advisories and CISA KEV for every AI component and patch on a short cycle.
Remove static secrets from AI nodes; block metadata access; run workloads as non-root.
Monitor AI runtimes for shells, miners and new outbound connections.
Rotate every credential on an exposed AI node as if stolen.

AML.T0049 Exploit Public-Facing Application: Hardening Public AI Applications Against Exploitation