ACVE-2026-0203

The configuration

Configuration label

model.family llama-4 | family llama-4 + untrustedInput=true + sideEffect=true + approval never|allowlist

Affected entries

• Model: llama-4 — ECOSYSTEM (introduced 0)

Matcher

• all
  • any
    • all
      • model.id exists
      • model.family in [ "llama-4" ]
    • some models
      • family in [ "llama-4" ]
  • all
    • some tools
      • untrustedInput eq true
    • some tools
      • sideEffect eq true
  • approval in [ "never", "allowlist" ]

Threat

Attacker

content-author

Vector

prompt-injection

Outcome

arbitrary-command

Evidence

Why it is exploitable

What the vulnerability is

ChatInject shows that Llama 4 is unusually sensitive to role and turn markers embedded in tool output. InjecAgent reports 50.1% ASR in its baseline and 79.4% when the ChatInject format forges chat-template turns. R7 also lists an inferred AgentDojo change from 1.0% to 19.8%, but flags that value as an unverified search excerpt. The tools are simulated in InjecAgent; the result measures whether the agent follows the injected instruction, not real-world command execution. Llama 4 Scout and Maverick are not distinguished in the source.

Which configuration is exposed

The vulnerable shape is a Llama 4 API or local deployment whose raw tool result is concatenated into the next prompt without role-token sanitisation. It becomes actionable when a browser, repository, mail, or MCP tool accepts untrustedInput and another tool has sideEffect, while approval is auto or never. A recognisable example is a Llama 4 endpoint behind an agent framework that prints a fetched README containing fake assistant or user delimiters and then lets the model invoke shell or file tools without asking.

How ACVE detects it

The matcher checks the Llama 4 family through the selected model or models[] and then looks for separate untrustedInput and sideEffect tools plus approval never or allowlist. A known model and complete tool list can confirm the configuration. An API alias without a dated identity is possible rather than confirmed; an agent server that omits tool metadata is also possible. ACVE cannot tell whether the application stripped template tokens or ran Prompt Guard unless that runtime defence was captured in safeguards.

Fix

1. Enable a template-token sanitiser that treats tool output as data and removes role, turn, and assistant-boundary markers before rendering it. 2. Run Prompt Guard 2 on tool output and log its decision. 3. Require agent.approval=ask for side-effecting calls until the sanitiser is demonstrated on the exact template. 4. Keep the template and tokenizer digest with the model record because ChatInject changes with that layer even when weights do not.

Grounding needed

Pin the Llama 4 model identity and chat template, InjecAgent and ChatInject commits, attack strings, prompt serialization, seeds, and whether tools were simulated. R7 confidence is M: the primary ChatInject source verifies the 50.1% and 79.4% values, but the model size and Scout/Maverick selection are unstated. Treat the 1.0% to 19.8% AgentDojo comparison as secondary-source context, not as a replacement for a reproducible full-suite run.

Underlying CVEs / aliases

No CVE assigned. behavioural — no code defect; evidence is an evaluation

Detect

npx @pickbitsai/acve audit

For CI, emit SARIF with npx @pickbitsai/acve audit --format sarif --out acve.sarif --apply and upload it with GitHub code scanning.

Fix

Sanitise tool-output turns and require approval for Llama 4 actions.

Validation

No validation entries recorded.

Grounding

No grounding checks recorded.

References

EVIDENCE

• https://arxiv.org/html/2509.22830