Zero-Day Research Methodology: From Target Selection to CVE Publication

Cybersecurity

How professional vulnerability researchers approach zero-day discovery — target selection, automated fuzzing, manual code audit, crash triage, exploit development, and responsible disclosure.

By Arjun Raghavan, Security & Systems Lead, BIPI · May 12, 2025 · 17 min read

Zero-day research is systematic engineering, not magic. The researchers who consistently find critical vulnerabilities do so through repeatable workflows: choose targets with large attack surfaces and weak historical security records, automate the boring parts with fuzzing, and focus human attention on logic and complexity.

Target selection criteria

• High deployment: widely used software means high impact per CVE
• Complex input parsing: file parsers, protocol implementations, and query engines have high bug density
• C/C++ codebase: memory unsafe languages with manual allocation
• Poor historical CVE record: suggests weak security culture and low previous research
• Bug bounty or CVE credit: ensures effort is recognised and incentivised

Automated fuzzing setup

AFL++ and libFuzzer cover the majority of fuzzing use cases. Instrument with ASAN and UBSAN to catch memory errors on first trigger. Build a seed corpus from real-world input files — the larger and more diverse the corpus, the faster coverage grows.

1. Instrument with AFL_USE_ASAN=1 afl-clang-fast++ for sanitiser-enabled builds
2. Minimise corpus: afl-cmin before starting long campaigns
3. Use cmplog mode for comparison coverage in parsers
4. Run on multiple cores: afl-fuzz -M master + afl-fuzz -S slave1..N
5. Monitor with afl-plot and corpus size growth rate to detect stalled campaigns

Manual code audit approach

Fuzzing misses logic bugs, integer overflows in deep call chains, and use-after-free in complex state machines. Manual audit starts at the attack surface — all input parsing code — and follows data flow through allocation, copy, and free operations.

Crash triage and root cause analysis

A fuzzer that runs for a week produces thousands of crashes, most of them duplicates triggered by the same root cause. Use afl-tmin to minimise crashing inputs, then GDB with ASAN output to identify the exact vulnerable instruction. Deduplicate by stack trace signature.

Exploit development for research purposes

A proof-of-concept exploit that demonstrates full control (arbitrary code execution or equivalent) is required for critical/high CVSS scores in most bug bounty programs. Start with a controlled crash, build a write-what-where primitive, then chain to code execution. Modern mitigations (ASLR, CFI, shadow stacks) require technique stacking.

Responsible disclosure process

1. Identify vendor security contact: security.txt, HackerOne, Bugcrowd, or security@vendor.com
2. Submit report with: vulnerability description, root cause, PoC, CVSS score
3. Agree on 90-day disclosure timeline per Google Project Zero standard
4. Coordinate CVE assignment through MITRE or vendor CNA
5. Publish advisory after patch is available, or at day 90 regardless

Fuzzing finds the low-hanging fruit. Manual audit finds the bugs that win Pwn2Own.

Ethics and legal framework

Vulnerability research must stay within legal boundaries: only test on systems you own or have explicit permission to test. Never deploy exploits against production systems. Responsible disclosure protects both the researcher and the public — hoarding zero-days benefits only adversaries.

Read more field notes, explore our services, or get in touch at info@bipi.in. Privacy Policy · Terms.