Detect blind vulnerabilities with OAST

A blind vulnerability produces no visible response: a server-side request that fires but returns nothing to you, an injection whose only effect is elsewhere. Out-of-band application security testing (OAST) catches these by making the target call a host you watch. cxg pentest supports two OAST modes, and the difference between them decides whether a finding can be confirmed or only suggested. Get this wrong and you will trust a confirmed=false finding as if it were proven.

One distinction to internalise before anything else

--oast cannot confirm. --oast-interactsh can. --oast injects a callback URL that cxg cannot read back, so every blind finding it produces stays confirmed=false. Only --oast-interactsh registers a canary cxg owns and polls, so a callback becomes a genuine confirmed=true finding. They are mutually exclusive at the CLI. If you take nothing else from this page, take this.

Before you start

• The web-application pentest setup. OAST is an addition to a cxg pentest run, not a separate command.
• Authorization to test the target for SSRF and injection. These probes make the target reach out to a third-party host.

--oast: inject only, you read the callback

--oast <HOST> hands templates a callback URL for a host cxg can inject into but cannot read, such as a Burp Collaborator address, a canary you host, or an interactsh domain you generated yourself:

cxg pentest run --codebase ./app --target https://staging.example.com \
  --auth pentest --ai --ai-provider claude \
  --oast c4ca4238a0b923820dcc.oastify.com \
  --goal "test SSRF on /proxy; check Collaborator for callbacks"

Templates build payloads that carry the callback URL. But cxg never learns whether it fired, so blind probes fall back to status-code and timing heuristics, and the AI is instructed to mark them confirmed=false. Reading the callback is your job, in Collaborator or in the tool that owns the host. If the host is an interactsh domain, you run interactsh-client in another terminal and watch there; that terminal is the only place these callbacks are visible.

The finding cxg writes is a lead to chase, not a confirmation. Treat it as confirmed=false, because that is what it is.

--oast-interactsh: cxg owns the canary and confirms

--oast-interactsh registers an interactsh session cxg owns and polls. Because cxg holds the correlation id, templates can read the interactions back in-band, and a callback becomes a confirmed=true finding with the interaction recorded as evidence:

cxg pentest run --codebase ./app --target https://staging.example.com \
  --auth pentest --ai --ai-provider claude \
  --oast-interactsh \
  --goal "verify SSRF on /proxy via OAST callback"

cxg is the interactsh client here, so you do not run one alongside it, and there is no second terminal to watch. The optional value is a server to register against (--oast-interactsh https://oast.example.internal); omit it for interactsh’s default public servers.

This is the mode to use when you want cxg to prove a blind vulnerability rather than hand you a lead.

They conflict on purpose

Passing both is a hard error:

cxg pentest run --codebase ./app --target https://staging.example.com \
  --oast example.oastify.com --oast-interactsh

error: the argument '--oast <HOST>' cannot be used with '--oast-interactsh [<SERVER_URL>]'

The conflict is deliberate. Two canaries would split payloads between a host cxg can poll and one it cannot, so “was this confirmed?” would have no single answer per finding. You pick one model of confirmation per run.

Which to reach for

You want	Flag	Result
cxg to confirm blind findings itself	--oast-interactsh	Callbacks polled in-band; a hit is confirmed=true.
To use your own Collaborator / canary and read hits yourself	--oast <host>	Payloads carry the URL; findings stay confirmed=false.

Default to --oast-interactsh when you can. Reach for --oast only when policy requires a specific external canary you already operate.

Related

• Pentest a web application is the run OAST attaches to.
• cxg pentest has the full --oast and --oast-interactsh descriptions.