What we still need to verify : 2 points in this profile are not yet confirmed against vendor documentation.
- Current language and runtime coverage: confirm against vendor documentation
- Integration list and deployment options: verify
Treat these points as unconfirmed. They are open items in the catalog's verification queue, and this note stays until each is checked against the vendor's documentation.
What it does
Mayhem is a fuzzing platform rather than a crawler-based web scanner. It grew out of research that produced an autonomous system in DARPA's Cyber Grand Challenge, and the core technique is the same: combine coverage-guided mutational fuzzing, which mutates inputs and keeps the ones reaching new code paths, with symbolic execution, which reasons about branch conditions to construct an input satisfying a check the mutator would never hit by chance. The two loops feed each other, so the system gets past magic-value comparisons that stall a plain fuzzer.
Two workloads dominate in practice. Against compiled software you hand it a binary, typically packaged in a container, and it drives the program until it crashes, hangs or trips a sanitizer, producing a concrete reproducer file for every defect. Source is helpful for triage but not required, so third-party components and vendor firmware are in scope. Against services, Mayhem takes an OpenAPI or similar specification and fuzzes the live endpoints with malformed and boundary-case requests, flagging server errors and spec violations. Findings accumulate into a regression corpus that becomes a test suite you keep running.
Where it fits
This belongs in the build pipeline and in longer-running background jobs rather than at a pre-deploy gate. It runs continuously against a service or binary, with short time-boxed runs on pull requests to catch regressions and long soak runs elsewhere to find new defects. Teams building systems software, embedded code, parsers or protocol implementations get most from it. You need a target that runs headlessly and deterministically, plus enough compute for the fuzzer to explore.
Strengths
- Every finding comes with a reproducer input, so there is no argument about whether the defect is real.
- Symbolic execution lets it reach code behind narrow input constraints that pure mutation fuzzing rarely satisfies.
- Works on binaries without source, which brings third-party and vendor-supplied components into scope.
- The accumulated corpus doubles as a regression suite, so fixed defects stay fixed.
Limitations
- Fuzzing finds memory safety and robustness defects. It does not find authorization flaws, injection into a downstream interpreter, or business logic errors.
- Getting good results depends on a well-built harness and a sensible seed corpus, which is engineering work the tool cannot do for you.
- It is compute-hungry: meaningful campaigns run for hours or days, not minutes.
- Managed and interpreted language targets benefit less than native code, where memory corruption is the payoff.
Who it suits
A strong fit for teams shipping C and C++ software, embedded systems, parsers or network protocol code, and for API teams with accurate specifications. Much weaker value for a conventional web application team whose real risks are access control, injection and session handling.
Used Mayhem? Recommend it under your own name and title.
Recommend this tool