> ## Documentation Index
> Fetch the complete documentation index at: https://aspex.mintlify.site/llms.txt
> Use this file to discover all available pages before exploring further.

# aspex-attack

> Red-team a live MCP server with adversarial inputs. Advanced, opt-in, only against servers you own.

<Warning>
  **Authorization required.** `aspex-attack` calls real tools with malicious payloads. Only run it against servers you own or have explicit written permission to test. Unauthorized probing may violate computer-misuse law. The tool asks you to confirm before sending anything.
</Warning>

`aspex scan` tells you what a server *could* do. `aspex-attack` checks whether it actually falls for it: it connects to your configured servers, enumerates their tools, sends adversarial inputs to matching parameters, and inspects the responses for signs of success (reflected injection text, file contents that should not be readable, cloud metadata, stack traces).

```sh theme={"dark"}
aspex-attack                          # every configured server, after a y/N confirmation
aspex-attack --server filesystem      # one server
aspex-attack --categories ssrf,path-traversal
aspex-attack --json --fail-on high    # CI
```

## Flags

| Flag                  | Description                                                                                                         |
| --------------------- | ------------------------------------------------------------------------------------------------------------------- |
| `--server <name>`     | Probe only this configured server                                                                                   |
| `--clients <list>`    | Only servers configured in these clients (default: all supported clients)                                           |
| `--categories <list>` | Comma-separated: `prompt-injection`, `path-traversal`, `ssrf`, `error-disclosure`, `schema-abuse`, `prompt-leakage` |
| `--timeout <seconds>` | Per-probe timeout (default 10)                                                                                      |
| `--json`              | Machine-readable output                                                                                             |
| `--fail-on <sev>`     | Exit 1 when findings reach this severity: `critical`, `high`, `medium`, `low`, `off` (default `high`)               |
| `--no-color`          | Plain-text output                                                                                                   |

There is no positional target. `aspex-attack` probes servers it discovers in your client configs, the same way `aspex scan` does. To test a server that is not configured yet, add it to a client config first (or to a project `.mcp.json`).

## What it sends

Payloads are chosen per tool parameter from the tool's input schema, so a path parameter gets traversal payloads, a URL parameter gets SSRF payloads, and a free-text parameter gets injection and leakage payloads. 18 payloads across 6 categories:

| Category           | Payloads | Tests                                                                               |
| ------------------ | -------- | ----------------------------------------------------------------------------------- |
| `prompt-injection` | 4        | Instruction overrides and role changes reflected back by the tool                   |
| `path-traversal`   | 4        | `../` escapes and encoded variants returning file contents outside the allowed root |
| `ssrf`             | 4        | Cloud metadata endpoints (`169.254.169.254`), localhost, internal addresses         |
| `error-disclosure` | 3        | Oversized and malformed inputs that leak stack traces or internal paths             |
| `schema-abuse`     | 1        | Prototype-pollution style object injection                                          |
| `prompt-leakage`   | 2        | Elicitation of embedded system prompts or credentials                               |

Each payload comes with detectors that decide whether the response indicates the attack landed. A finding is only raised on a positive detector, not on the mere act of accepting the input.

## Reading results

```
aspex-attack --server filesystem

  Only run against servers you own or have explicit written permission to test.

  Proceed? [y/N] y

  filesystem  4 tools, 22 probes

  CRITICAL  path-traversal/dotdot-etc-passwd   read_file   response contained /etc/passwd contents
  MEDIUM    error-disclosure/oversized-string  search      stack trace with internal path in error

  2 findings  (1 critical, 1 medium)
```

Exit code is 1 when a finding reaches `--fail-on` (default `high`).

## In CI

Only against a staging or test deployment, never production.

```yaml theme={"dark"}
- name: Red-team the MCP server
  run: aspex-attack --server my-server --categories ssrf,path-traversal --json --fail-on high
```

## Relationship to aspex scan

`aspex scan redteam` runs the same probes from inside the scanner and is kept for compatibility; `aspex-attack` is the standalone binary with the confirmation prompt and its own exit code. Use `aspex scan` for everyday auditing and reach for `aspex-attack` when you need proof, not a score.
