Zero-Day: Vulnerability Research & Discovery

Systematic methodology for finding novel, undisclosed vulnerabilities in source code, compiled binaries, and live systems. This skill guides the research process from intelligence gathering through proof-of-concept development to responsible disclosure.

This is the discovery skill - it finds vulnerabilities nobody has catalogued yet. For exploiting known weaknesses on live systems, use lockpick. For scanning code against known vulnerability patterns, use security-audit.

Target versions: May 2026 snapshot. Read references/target-versions.md before pinning static analysis, reversing, fuzzing, or debugger tooling.

When to use

• Hunting for undisclosed vulnerabilities in a codebase, binary, or running service
• Variant analysis after a CVE is published (finding similar bugs in related code)
• Patch diffing - analyzing what a security update fixed to find nearby issues
• Developing proof-of-concept exploits for discovered vulnerabilities
• Attack surface mapping before a focused security engagement
• Gathering threat intelligence on a target's technology stack
• Preparing responsible disclosure reports
• Bug bounty target assessment and prioritization
• Auditing your own projects for novel vulnerability classes
• Hunting for cloud-native vulnerabilities (IAM, IMDS, cross-tenant isolation, serverless)

When NOT to use

• Scanning for known vulnerability patterns or OWASP top 10 (use security-audit)
• Post-exploitation privilege escalation or lateral movement (use lockpick)
• General code correctness review or bug finding (use code-review)
• Hardening containers, Kubernetes, or infrastructure (use kubernetes, docker, terraform)
• Network firewall configuration or tuning (use firewall-appliance)
• Without authorization from the target owner (own repos, bug bounty scope, or written permission)

AI Self-Check

Before reporting any vulnerability or generating exploit code, verify:

• Authorization confirmed: own repo, active bug bounty program, or written permission
• Scope respected: target is within authorized boundary (specific repos, domains, IPs)
• Novel finding: verified this isn't already a known CVE or public advisory (cross-check Phase 0 intelligence gathering - NVD, oss-security, GitHub advisories, searchsploit)
• Reproducible: PoC demonstrates the issue reliably, not a theoretical concern
• Impact assessed: clear description of what an attacker gains (not just "crash")
• Root cause identified: the underlying flaw, not just the symptom
• No collateral damage: PoC doesn't destroy data, DoS production, or affect other users
• Disclosure plan: findings destined for responsible disclosure, not public dump
• Evidence preserved: all analysis steps documented for reproducibility
• Complexity honest: if exploitation requires unlikely conditions (specific config, race window, chained bugs), state that clearly - don't inflate impact
• Current source checked: dated versions, CLI flags, API names, and support windows are verified against primary docs before repeating them
• Hidden state identified: local config, credentials, caches, contexts, branches, cluster targets, or previous runs are made explicit before acting
• Verification is real: final checks exercise the actual runtime, parser, service, or integration point instead of only linting prose or happy paths
• Routing overlap checked: overlapping skills, trigger terms, and "When NOT to use" boundaries are checked before returning guidance
• Spec claims verified: claims about tool behavior, output contracts, or repo conventions are checked against current docs, scripts, or skill files
• PoC safety reviewed: proof code demonstrates impact without avoidable persistence, exfiltration, or wormable behavior, and stays within the authorized disclosure scope

Performance

• Minimize repro cases before deep fuzzing so crashes triage quickly.
• Deduplicate crashes by stack, root cause, and patch reachability before reporting counts.
• Use coverage and corpus metrics to guide fuzzing time instead of running blind indefinitely.

Best Practices

• Capture exact versions, build flags, inputs, logs, and debugger state for every candidate finding.
• Separate exploitability analysis from speculation; mark uncertainty clearly.
• Follow the target project's disclosure policy and avoid publishing operational exploit detail prematurely.

Workflow

Phase 0: Intelligence Gathering

Before touching code or binaries, understand what you're looking at and what the community already knows. This phase determines where to focus.

Advisory and feed monitoring:

# Recent CVEs for a specific product/vendor
# NVD API (no key needed for basic queries)
curl -s "https://services.nvd.nist.gov/rest/json/cves/2.0?keywordSearch=TARGET_NAME&resultsPerPage=20" | python3 -m json.tool | head -100

# GitHub Security Advisories for a repo
# Adapt ecosystem param: NPM, PIP, GO, MAVEN, NUGET, RUBYGEMS, RUST, etc.
gh api graphql -f query='{ securityVulnerabilities(first:20, ecosystem:NPM, package:"TARGET") { nodes { advisory { summary severity publishedAt } vulnerableVersionRange } } }'

# Exploit-DB search
searchsploit TARGET_NAME 2>/dev/null || echo "searchsploit not installed (apt install exploitdb)"

Community sources to check (use web search):

• oss-security mailing list - where researchers post before/alongside CVEs
• Full Disclosure - uncoordinated disclosures, PoCs
• r/netsec, r/ReverseEngineering, Hacker News - community discussion, writeups, early signal
• Project-specific bug trackers - Chromium, Firefox, Linux kernel, etc.
• Vendor security bulletins - Microsoft Patch Tuesday, Apple security updates, etc.
• Twitter/X - #0day, #bugbounty, researcher accounts, vendor security teams

What to extract:

• Recently patched vulnerability classes (variant analysis targets)
• Components receiving security attention (hot areas)
• Researcher writeups describing methodology (technique inspiration)
• Unfixed issues in bug trackers marked as security-sensitive

Proceed to Phase 1 when: you have a clear picture of recent CVEs, active research, and community attention on the target or its ecosystem. If nothing comes up, that's still useful - it means fewer known attack patterns to build on, so original research matters more.

Phase 1: Target Profiling

Understand the target before looking for bugs. The goal is to build a mental model of the attack surface.

For source code repos:

# Language and framework breakdown
tokei . 2>/dev/null || (find . -name '*.py' -o -name '*.js' -o -name '*.ts' -o -name '*.c' \
  -o -name '*.cpp' -o -name '*.go' -o -name '*.rs' -o -name '*.java' | head -50)

# Dependencies (attack surface via supply chain)
cat package.json requirements.txt go.mod Cargo.toml pom.xml 2>/dev/null | head -80

# Entry points - where external input enters the system
grep -rn 'app\.\(get\|post\|put\|delete\|patch\|use\)\|@app\.route\|@RequestMapping\|func.*http\.Handler\|#\[.*route\]' --include='*.py' --include='*.js' --include='*.ts' --include='*.go' --include='*.rs' --include='*.java' . 2>/dev/null | head -30

# Parser/deserializer locations (high-value targets)
grep -rn 'parse\|deserialize\|unmarshal\|decode\|from_bytes\|read_struct\|unpack' --include='*.py' --include='*.c' --include='*.cpp' --include='*.go' --include='*.rs' . 2>/dev/null | head -30

# Security-sensitive operations
grep -rn 'exec\|system\|popen\|eval\|spawn\|crypto\|encrypt\|decrypt\|hash\|sign\|verify\|auth\|token\|session\|cookie\|jwt' --include='*.py' --include='*.js' --include='*.ts' --include='*.go' --include='*.rs' . 2>/dev/null | head -40

# Git history - recent security-related changes
git log --oneline --all --grep='CVE\|vuln\|security\|fix\|patch\|overflow\|i