ACVE-2026-0201

The configuration

Configuration label

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

Affected entries

• Model: llama-3.3 — ECOSYSTEM (introduced 0)
• Model: llama-3.2 — ECOSYSTEM (introduced 0)

Matcher

• all
  • any
    • all
      • model.id exists
      • model.family in [ "llama-3.3", "llama-3.2" ]
    • some models
      • family in [ "llama-3.3", "llama-3.2" ]
  • 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

Llama 3.3 70B Instruct is not uniformly resistant to indirect prompt injection. In the SecAlign paper table, AgentDojo reports 14.7% targeted ASR and InjecAgent reports 53.8% ASR with no defence. WASP, which drives real Dockerised GitLab and Reddit applications, reports 20.2% intermediate ASR but 2.4% end-to-end ASR. Gray Swan ART 2025 reports 6.49% per-attempt ASR, the worst of its 22 models. The AgentDojo and InjecAgent tools are simulated; WASP is the important real-browser comparison.

Which configuration is exposed

The exposed shape is this family served at an unpinned HF or Ollama tag inside an agent that ingests email, web, repository, or MCP-returned text. At least one such tool has untrustedInput=true, at least one has sideEffect=true, and approval is auto, bypassPermissions, yolo, or trusted. A reader can recognise it as Ollama-served llama3.3 behind Open WebUI or Continue with shell or file tools and no approval prompt. Egress makes the same path useful for secrets, even when the immediate tool is only a file writer.

How ACVE detects it

The matcher accepts the model family on model.id or in models[], then requires separate tool witnesses for untrustedInput and sideEffect, followed by approval in never or allowlist. A pinned digest and visible tool inventory can make a match confirmed; a floating model tag makes the model predicate possible, and a model server whose tools are unknown keeps the tool predicate possible. The lock records safeguards only when discovery writes them into safeguards, so a server-side classifier or planner is invisible otherwise.

Fix

1. Change side-effecting calls to agent.approval=ask and keep the human decision at the call boundary. 2. Put LlamaFirewall Prompt Guard 2 and AlignmentCheck on the tool-result path, not only on the user prompt. 3. Where that defence cannot be deployed, move the agent to facebook/Meta-SecAlign-70B; its AgentDojo result is 1.9% versus Llama 3.3 at 14.7%. Rebuild the lock after recording the model revision and safeguards.

Grounding needed

A reproduction should pin the Llama 3.3 70B bf16 identity or exact quantised digest, the AgentDojo, InjecAgent, and WASP commits, released attack strings, seeds, tool inventory, auto-approval state, and classifier state. R7 marks the core paper numbers H because they are verified primary results, while ART is also primary but reports a competition per-attempt rate. Do not turn the simulated-tool results into a claim about real command execution without an in-harness reproduction.

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

Require approval and add tool-output defences for Llama 3.3 agents.

Validation

No validation entries recorded.

Grounding

No grounding checks recorded.

References

EVIDENCE

• https://arxiv.org/html/2507.02735
• https://www.grayswan.ai/blog/uk-aisi-x-gray-swan-agent-red-teaming-challenge-results-snapshot