AML.T0049Exploit Public-Facing Applicationview on ATLAS ↗Adversary exploits a vulnerability in an internet-facing service to gain initial access. For AI systems this often means the inference API or its surrounding web application.
← Atlas · ThreatsCritical
T20 · Helmwart ID · OWASP MAS Guide source
Framework Vulnerability Leading to Code Injection
An attacker exploits a security flaw in the agent framework software itself to run arbitrary code inside the agent's process.
ExtendsT11: Unexpected RCE and Code Attacks · base threat in OWASP v1.1 catalog
Definition
A vulnerability in the agent framework allows code injection into the agent’s execution context. This is the framework-layer manifestation of T11 Unexpected Remote Code Execution (RCE) and Code Attacks. Where T11 focuses on LLM-generated code paths, T20 targets a security flaw in the framework software itself, exploited to execute arbitrary code within the agent’s process.
What it looks like in practice
In the RPA expense reimbursement context: an attacker identifies a deserialization vulnerability in the agent framework’s inter-agent message handler. A crafted malformed JSON-RPC message causes the framework to execute arbitrary code, granting the attacker the agent’s full process permissions: access to the financial system API credentials, the email integration, and the audit log.
In the ElizaOS (an open-source multi-agent operating system built on Solana) context: the framework vulnerability is the entry point for T11-class RCE, exploited through plugin loading or message handling that runs without adequate sandboxing. Because ElizaOS agents hold Solana wallet keys and on-chain transaction authority, framework-level RCE translates directly into wallet key exfiltration.
Why it’s dangerous in multi-agent context
Agent frameworks run with the same broad credentials the agent uses to access all its integrated systems. A code injection at the framework layer grants the attacker those permissions immediately, without further privilege escalation. In a multi-agent deployment, the compromised framework process has network access to peer agents and shared message buses, enabling lateral movement through the agent fleet. T31 (Insufficient Isolation Between Agent Actions) compounds the risk: if agents share a runtime, a single compromised process can reach another agent’s key material through shared memory.
Detection signals
Framework-layer code injection produces distinctive runtime anomalies: processes that spawn unexpected child processes, access credential files they have never touched before, or emit unusual outbound network connections.
- A new child process spawned from the agent framework’s message-handler process (e.g.
sh,python, or any interpreter not listed in the framework’s expected process tree): monitor via OS-level process-creation events (Linuxexecveaudit rule or macOSEndpointSecurity) and alert on any unexpected child PID. - An outbound network connection from the agent process to an IP or hostname not in the pre-approved egress allow-list, initiated within seconds of receiving an inter-agent JSON-RPC message. Correlate process-level network events with the message receipt timestamp.
- A file-open event on a credential file (e.g.
credentials.json,.env, or any path in the secrets mount) from the framework’s message-handler thread, when no scheduled credential refresh is in progress. Alert on any such access outside the defined refresh window. - A deserialization exception logged by the framework’s message parser followed immediately by elevated CPU usage in the same process. The exception may indicate a failed payload; elevated CPU may indicate a successful one being executed.
- An unexpected spike in outbound data volume (bytes sent) from the agent host in the 60 seconds following an inbound JSON-RPC message of unusual size. This is a potential credential exfiltration event triggered by the injected payload.
Mitigations
- Pin the agent framework version and audit its dependency chain for known Common Vulnerabilities and Exposures (CVEs); apply the Software Bill of Materials (SBOM) practice to all framework components.
- Sandbox plugin loading and inter-agent message parsing in isolated execution contexts (separate processes, containers, or V8 isolates).
- Validate and reject malformed inputs at the framework’s message-handling boundary before deserialization.
- Run each agent process under a dedicated service account with the minimum permissions required; do not share credentials across agents.
Relation to base threat (T1–T17)
T20 extends T11 Unexpected RCE and Code Attacks. T11 addresses LLM-generated malicious code; T20 addresses the framework layer as an independent injection surface. T29 (Plugin Vulnerability Leading to Agent Compromise) is the companion threat in the ElizaOS context where the injection vector is a third-party plugin rather than the framework message handler.
OWASP Top 10 for Agentic Applications 2026
The Agentic Top 10 (ASI01 through ASI10) is a separate practitioner-facing publication that maps onto the master Threats & Mitigations threat numbering. T20 is covered by the following Top 10 entries:
ASI04Agentic Supply Chain Vulnerabilitiesprimary Third-party components that agents depend on (models, MCP servers, plug-ins, datasets, peer-agent descriptors, and update channels) may be malicious, compromised post-approval, or tampered with in transit. Unlike software supply-chain risk, this is a live exposure: every new session the agent fetches and trusts components whose state may have changed since they were last reviewed.
OWASP LLM Top 10:LLM04:2026ASI05Unexpected Code Execution (RCE)primary In an agentic system, code generation and code execution happen in the same turn: the model emits an instruction and a tool runs it, with no human review step between. Attackers exploit this by injecting execution payloads into the agent's inputs; the realistic defence is at the runtime boundary (sandboxing, capability restriction, egress control), not at the generation step.
Source: OWASP Top 10 for Agentic Applications 2026 (Dec 2025) · the Top 10 is a compass into the master Threats & Mitigations taxonomy, not a replacement for it.
Design principles at stake
When T20 is present, these security design principles are the ones being violated or tested. Each links to the full principle; the mitigations below are how you restore them.
- Defence-in-DepthA deserialization vulnerability in the framework's message handler grants the attacker the agent's full process permissions immediately: credentials for the financial API, the email integration, and the audit log, without any further exploitation step. Depth means the blast radius of a single framework flaw is contained by independent layers: malformed inputs are rejected at the framework's message-handling boundary before deserialization, each agent process runs under a dedicated service account with the minimum permissions required, plugin loading executes in a sandboxed isolated context rather than the main process, and the framework version is pinned with a known SBOM so that a known-CVE component cannot reach production undetected. Each of these layers fails independently; a successful deserialization exploit still finds that lateral movement through the agent fleet requires defeating per-agent credential isolation as a separate step.
Recommended mitigations
Auto-generated from the mitigation catalog: every mitigation whose coverage map includes T20, sorted by maturity tier (Tier 1 production-canonical first, then Tier 2, then Tier 3 research-stage).
- Tier 1Kernel-isolated sandbox(Kernel-isolated sandbox — agent-executed code runs against its own kernel, not the host's)
When an agent executes generated or retrieved code, that code runs as a process with access to the host kernel. A vulnerability in the generated code, or a deliberate exploit injected through the agent's prompt, can reach the kernel and affect other workloads or the host itself. A kernel-isolated sandbox removes that path by giving the workload a kernel of its own: gVisor interposes a user-space kernel so syscalls reach the Sentry rather than the host, and Kata Containers runs the pod in a lightweight VM with a separate kernel. Which one is available is a property of the platform, not of the control — AKS ships Kata as Pod Sandboxing and does not support gVisor; GKE ships gVisor.
why it helps Framework vulnerability exploitation requires that malicious code running inside the agent's execution environment can reach the host OS or interact with other workloads. gVisor's syscall interception boundary limits that reach: code exploiting an unpatched framework vulnerability runs inside the Sentry's isolation layer, and the set of host operations it can invoke is restricted to those the Sentry forwards.
- Tier 2Code review gate(Code-generation review gate — human approval before AI-generated code executes or merges)
An AI coding agent produces code that can be executed or merged to a production branch without a human ever reading it. If the agent has been manipulated, its generated code can contain hidden payloads, backdoors, or privilege-escalating logic. A code-generation review gate prevents that: every change attributable to an AI agent must pass automated static analysis and receive explicit human approval before it can merge or execute, and the agent identity that authored the change is structurally barred from also approving it.
why it helps OWASP T20 Framework Vulnerability Code Injection is the scenario where an agent is caused to generate code that calls a known-vulnerable framework API. SAST scanning of AI-attributed diffs detects known-vulnerable patterns before merge; human review catches semantic-level injection that SAST cannot, such as code that looks structurally correct but exfiltrates data through a misconfigured output.
Red-team pivot: MITRE ATLAS techniques
MITRE ATLAS catalogues adversary techniques against AI systems. Where this OWASP threat has an attacker-perspective counterpart, the ATLAS technique is shown below. That is what a red team would actually be doing on the wire. Use this for detection-signal anchoring, threat-hunting hypotheses, and IR runbooks. Source: mitre-atlas/atlas-data v5.6.0.
© 2026 The MITRE Corporation. ATLAS content is reproduced and distributed with the permission of The MITRE Corporation.
AML.T0050Command and Scripting Interpreterview on ATLAS ↗Adversary executes commands, scripts, or binaries via a legitimate interpreter the system already exposes (Python, shell, JavaScript).
Agentic angle: Code-executing agents and "vibe-coding" tools turn this into a routine path for attackers. A single prompt injection can pivot to RCE.
AML.T0072Reverse Shellview on ATLAS ↗Adversary causes the victim system to initiate an outbound connection to attacker-controlled infrastructure, granting interactive control.
Agentic angle: A code-executing agent that hits a malicious tool can trivially be coerced into opening a reverse shell.
References
- OWASP MAS Threat Modelling Guide v1.0 (April 2025) §3 RPA Expense Reimbursement Agent — Layer 3 Agent Frameworks; §4 ElizaOS — Layer 3 Agent Frameworks.
Sources
- OWASP-MAS-Guide ↗ · 1.0 (Apr 2025) · §3 RPA Expense Reimbursement Agent — Layer 3 Agent Frameworks; §4 Eliza OS — Layer 3 Agent Frameworks
Adapted by Helmwart from the OWASP source(s) above underCC BY-SA 4.0(changes: normalized IDs, added MAESTRO-layer, agentic-factor, and mitigation mappings). This entry is licensed CC BY-SA 4.0.