Interactsh: an OOB interaction server and client for blind vulnerability testing

The blind-spot problem Interactsh was built for

A large share of real vulnerabilities never send a byte back to the tester. A server-side request forgery that fetches an internal URL, an XML parser that resolves an external entity, a mail library that connects to an attacker-controlled host: the application returns a normal page in every case. The only evidence is a connection that arrives somewhere you control. Interactsh exists to be that somewhere. It generates a unique payload hostname, hands it to whatever you are injecting into, and then reports the DNS, HTTP(S), SMTP(S) and LDAP interactions that come back, tagged with the payload they belong to. The audience is penetration testers, bug bounty hunters and application security engineers who already know what a callback is and want a collector that speaks more than HTTP. The project also ships as a Go library, so scanner authors can embed the client rather than shelling out to a binary.

How the correlation ID ties a payload to an interaction

Every payload is a subdomain of an Interactsh domain, and the leftmost label is a correlation ID. The client flags expose its two halves: -correlation-id-length defaults to 20 and -correlation-id-nonce-length defaults to 13, with a documented minimum of 3 for each. That identifier is what lets the server attribute a later DNS query or HTTP request to the session that generated it, and the client prints the ID in brackets in front of each event. The client does not sit on a socket waiting. It polls the server for interaction data on an interval controlled by -poll-interval, which defaults to 5 seconds. Registration normally goes over the server protocol, with an HTTP fallback that -no-http-fallback disables. The README describes the server side as AES encrypted with zero logging, which matters because the payload and the interaction data pass through infrastructure you may not own. On a self-hosted server the feature list adds multiple domains, NTLM/SMB/FTP(S) and Responder listeners, wildcard and protected interactions, customisable index and file hosting, configurable payload length and a custom SSL certificate. Those capabilities are marked self-hosted in the README, so they are not available on the public servers.

Installing the Interactsh client and reading a first callback

The README states that the CLI client requires go1.20 or later. Installation is a single go install against the cmd path, which places interactsh-client in your Go bin directory.

go install -v github.com/projectdiscovery/interactsh/cmd/interactsh-client@latest

Running the binary with no arguments generates one payload and starts polling. The README's default run shows the banner, a line listing one payload for OOB testing, the payload hostname itself, and then bracketed interaction lines as DNS, HTTP and SMTP events arrive.

interactsh-client

If you need more than one payload for a batch of injection points, -number controls how many are generated, and -server takes a comma-separated list of servers. The default server list in the help output is oast.pro,oast.live,oast.site,oast.online,oast.fun,oast.me.

interactsh-client -n 5 -server oast.pro

To keep a session alive across restarts, pass a session file. The README says this stores and reads the current session information so you can resume polling the same session after the client stops.

interactsh-client -sf interact.session

For machine-readable output, -json writes JSONL and -o sends interaction data to a file. The filter flags -match, -filter, -dns-only, -http-only and -smtp-only narrow what the CLI prints, which is useful when a noisy target produces a stream of DNS lookups you do not care about. Protected servers take an authentication token via -token.

The public servers are a shared dependency, not a private channel

The default configuration points the client at six project-operated domains. That is convenient and it is also the main operational weakness. Your payloads and the resulting interaction metadata travel through infrastructure you do not control, and the README's zero-logging claim is a statement about server behaviour rather than something a client can verify. The domain list itself is a target: if a tester's payload hostname is widely known, a defender or a filtering proxy can block the whole suffix. Anyone testing against an environment with egress filtering will see callbacks stop arriving, and the client gives no signal that distinguishes a blocked callback from a payload that was never used. The self-hosted path addresses this, but it moves the problem rather than removing it: you now need a domain, DNS control, and a working ACME setup, since the server relies on certmagic for wildcard TLS with automatic renewal. There is also a rate-limiting dependency in the module list, which is a hint that the public service is not sized for high-volume fuzzing. The README does not document per-account quotas or rollback behaviour for a failed registration.

Interactsh compared with running your own webhook collector

The obvious alternative is a small HTTP endpoint you write yourself, or a hosted request-bin style service. The difference is protocol coverage and attribution. A hand-rolled endpoint sees HTTP requests only; it will never tell you that a target resolved your hostname over DNS, opened an SMTP session, or sent an LDAP bind. Interactsh's listeners cover DNS, HTTP(S), SMTP(S) and LDAP, and the self-hosted build extends that to NTLM/SMB/FTP(S) and a Responder listener. The second difference is correlation. With a plain webhook you typically encode an identifier in the path and parse it back out; Interactsh builds the identifier into the hostname itself, which is what makes it usable in places where you can only supply a domain, such as an XML external entity or a JNDI lookup string. The trade-off is dependency: a self-written endpoint is a dozen lines you fully understand, while Interactsh is a Go module with a substantial dependency tree and a client that polls rather than pushes, so detection latency starts at the poll interval.

Licence, maintenance and what upgrading costs you

Interactsh is MIT licensed, which permits commercial use, modification and redistribution provided the copyright notice and permission notice are retained. The repository ships a LICENSE.md, and the README carries the MIT badge. For teams embedding the client library, that is about as permissive as it gets, but it does not cover the public oast.pro style services, which are separate infrastructure rather than licensed code. On maintenance, the last push to the default branch was on 2026-09-22, and the most recent tagged release is v1.3.1 from 2026-03-10, following v1.3.0 in January 2026 and v1.2.4 in February 2025. The gap between v1.2.4 and v1.3.0 is roughly eleven months, so release cadence is not uniform. The module declares go 1.24.0 with toolchain go1.24.2, which is a higher floor than the go1.20 the README gives for installing the CLI, so anyone building from source should read go.mod rather than the README line. Upgrading the client is handled by the -update flag, and the automatic update check can be turned off with -disable-update-check. There is no documented migration guide between minor versions, so treat a minor bump as something to test against your own payload flow.

What the Interactsh CLI will not do for you

The client reports interactions; it does not interpret them. Nothing in the README suggests it decides whether a callback means a vulnerability, and the -match and -filter flags are pattern filters over interaction text, not detection rules. If a target resolves your payload hostname for unrelated reasons, such as a security appliance doing DNS prefetching, you will get a DNS interaction that looks identical to a real one. Distinguishing the two is your job. The CLI output also does not carry the full request context for every protocol in a form you can replay; -json gives you structured lines, and -o writes them to a file, but the README does not document a built-in way to reconstruct the original injection point from an interaction beyond the correlation ID. Finally, the tool is a collector, not a scanner. It will not crawl a target, generate injection points, or manage a campaign. Pairs like the Burp and ZAP integrations exist for that reason, and the README lists them as clients rather than as part of the CLI.

Editorial conclusion

Adopt Interactsh if you test for blind SSRF, blind SQL injection, XXE or log4j-style callbacks and need DNS, HTTP, SMTP and LDAP listeners in one place, or if you need to host the collector on your own domain. Do not adopt it if you only need a single HTTP webhook, or if you cannot run a server and cannot accept the default public oast.pro style domains. Before relying on it, verify which server flags your build exposes, whether the client defaults still point at the public servers, and whether a session file is enough to resume a long engagement.

Frequently asked questions

Official sources

1. License: MIT
2. projectdiscovery/interactsh on GitHub
3. Project website
4. README
5. Releases