Path-based canary correlation on public oast.* servers (for IP-only OOB payloads that can't use a subdomain)

[phith0n]

Hi,

Public oast.* servers correlate interactions to a client only by subdomain
(r.Host), because they run with the default ScanEverywhere = false. So any
canary that can appear only in the URL path — never in a hostname — reaches
the server but is never attributed to a client, and polling returns nothing.
Self-hosting with -ip ... -scan-everywhere (which scans the whole request, path
included) works fine.

Use case: some OOB vectors can only address the collaborator by a bare IP and
reflect the token only in the path. Example: JVM jar:-protocol class loading
(reachable via a fastjson 1.2.83 RCE gadget) — the JVM does name.replace('.','/'),
so the host must be a dot-free decimal IPv4 (127.0.0.1 → 2130706433),
forcing jar:http://2130706433:50050/<token>!/POC. The target's request is
GET /<token> with Host: 2130706433:50050 — no subdomain, no DNS. This whole
family of IP-only bugs is detectable self-hosted but not on the public servers.

Question: any appetite for an opt-in way to catch path-only canaries on
the public servers (reserved path prefix, or a per-registration flag) — since
full -scan-everywhere globally is understandably costly? Or is self-hosting the
intended answer, and worth a short docs note?