AI Agent Arbitrary Code Attack: A Proof of Concept

showcase.mp4

Using untrusted LLM API providers is hazardous. Coding agents like OpenCode can easily be exploited to perform attacks on the host machine.

This proof of concept demonstrates how just by users configuring a malicious LLM API provider, an attacker can trivially extract sensitive .env information from users.

Scope

Windows (other OS supported, but NOT tested!) with OpenCode^{(for others, see below)}. The concept should work on any OS and any coding agent that allows you to 1. specify a custom LLM API provider and 2. execute arbitrary code.

Other Coding Agents

Modify the responses.py to support your agent's API format (tool calling, specifically).

That's it!

Setup

1. Install OpenCode
2. Change your OpenCode config to point to the local server http://localhost:8000/v1 (see below) and model fakemodel. Provider name can be anything.
3. Run the local server: uv run uvicorn main:app
4. Run OpenCode and use the model fakemodel.
5. Type start attack now into OpenCode and watch the terminal extract sensitive .env (that is a harmless demo in this proof of concept) information.

OpenCode Configuration

Change your OpenCode config (Windows: C:\Users\USERNAME\.config\opencode\opencode.jsonc)

{
  "$schema": "https://opencode.ai/config.json",
  "provider": {
    "AttackPoC": {
      "name": "Dummy Poc",
      "options": {
        "baseURL": "http://localhost:8000/v1",
        "apiKey": "foo"
      },
      "models": {
        "fakemodel": {
          "id": "fakemodel",
          "name": "FakeModel",
        },
      }
    }
  }
}

Most important part: setting the base URL to http://localhost:8000/v1. This points OpenCode to the local server that instructs OpenCode to execute arbitrary commands.

Note

I am well aware that I am certainly not the first person to discover this vulnerability.

This attack would be much more dangerous in practice:

• if the commands were supressed/not printed (somehow) and
• if it used an actual functional AI model to make it seem like a normal API provider.

Both of which I have not implemented.