For teams building parsers, libraries, SDKs, protocols or application components that process untrusted input.
When malformed files, messages or inputs could expose a weakness.
What we examine
- Assess target feasibility, build requirements, entry points and test objectives.
- Set up and run the agreed testing approach for the selected component.
- Investigate and deduplicate failures, minimize useful examples and assess security relevance.
A clear start. A useful finish.
Tell me the problem
Share the product, stack, goal and deadline. A short overview is enough to start the conversation.
Agree the engagement
Receive a written scope, deliverables, acceptance criteria, price and schedule before we begin.
Review the work as it develops
For assessments, examine the evidence and priorities. For engineering, review agreed implementation milestones.
Put the result to work
Get a technical walkthrough and useful handoff. Agree any further implementation or verification your team needs.
I investigate down to the cause.
Facebook and Instagram research, 300+ Linux kernel reports and findings investigated, eight patches and two published CVEs. I connect a suspicious behavior to the code, the conditions that trigger it and the impact on your product.
See the kernel findings and fixesQuestions before we begin
What makes a useful fuzzing target?
A component with clear input boundaries and a build or execution environment we can exercise. Parsers, libraries and protocol handlers are useful candidates. We confirm suitability before committing to a campaign.
Can we start with a small pilot?
Yes. A paid feasibility phase can establish whether the target is practical, what setup it needs and what a larger campaign should include.
Will you deliver a harness or ongoing test setup?
We agree the artifacts during scoping. Depending on the target, these may include a harness, seed inputs, run instructions, reproducers or integration guidance. They are specified in the proposal.
Does every crash mean a vulnerability?
No. Failures need investigation. The report distinguishes observed behavior, confirmed security impact and unresolved questions; it does not promise a number of vulnerabilities or CVEs.
Useful lessons from security research
- After React2Shell: three security boundaries every server component review needs
- The 2026 Axios attack: why a clean dependency tree cannot clear a build runner
- CVE-2024-26855: when a missing attribute becomes a NULL dereference