A file that describes the attack. A runtime that proves it.
Exploitmatic is a desktop workbench and a command line tool that read one plain text file: the solution. The file records the attack step by step and the test that must pass. The runtime validates the file, replays it against one target you name, and prints a result you can act on.
The solution file, read in a minute.
A solution has three parts. Here is what each one is for, on the Heartbleed example.
The header records where it came from
An id, a one-line summary, and the CVE the file reproduces. Provenance is part of the artifact, not a comment someone may delete.
Each block is one step
Identity names the protocol. English lines say what to send and what to read. The verb is the HTTP method; bytes are written as hex.
The expect line is the test
Text present, a regex, a flag, an out-of-band callback, or no response. Validation checks the grammar first; the run applies the tests.
id: openssl/heartbleed-mem-leak summary: CVE-2014-0160 Heartbleed ref: CVE-2014-0160 tls clienthello-heartbeat send hex "1603030125010001210303..." receive until "0e000000" receive 65536 bytes expect "0e000000" in the response tls malformed-heartbeat send hex "1803030003014000" receive 70000 bytes expect the response to match "18030[123]40"
Run it from the workbench.
Set the target
One URL or address, plus a timeout. The runtime keeps the session alive across the steps of the file.
Press run
The workbench or the CLI replays the file. Redirects, cookies, captures, and out-of-band callbacks are handled by the runtime.
Read the report
One line per step. Verified when every test passes, not verified when one fails. Exit codes make it usable in CI.
What the runtime does with the file.
Validation before replay
The file is checked against the grammar and the semantics at load. A bad directive is a clear error with a line number.
Replay, one target at a time
The runtime speaks the protocol, follows captures, and listens out of band for callbacks. It does not scan or sweep.
A result that comes from the run
The report is what the runtime printed. The same file becomes a regression test when you rerun it on a fixed build.
A file humans and LLMs share
The grammar is closed and documented. A person authors by hand; an agent drafts from the same grammar, and a human reviews the diff.
Verified against real targets.
These are run results from the lab. Each linked post shows the vulnerable build and the methodology, so the result can be checked.
Heartbleed
Leaked memory recovered from a vulnerable OpenSSL server.
Keycloak reset-credentials bypass
Unauthenticated account takeover; the victim password really changed.
Next.js RCE on Windows
Unauthenticated remote code execution via the filesystem cache.
What Exploitmatic is not.
The category is new, so the boundaries matter. Three things the tool deliberately does not do:
Not a scanner
It does not crawl, discover, or sweep a network. One run is one solution against one target you name.
Not an exploit framework
There is no console, no module library, and nothing to load at runtime. A solution is data the runtime reads.
Not an autonomous attacker
It replays what a file describes. It never decides what to attack. An agent may author the file; running it still needs a target you own and choose.
Give exploit research a common language.
Bring a PoC, a writeup, or an AI-generated draft into an Exploitmatic solution: inspect it, validate it, and replay it against a target you own. The runtime and the corpus are open source.