performing-zero-day-vulnerability-discovery

name	performing-zero-day-vulnerability-discovery
description	Systematic methodology for discovering novel vulnerabilities through manual code auditing, fuzzing, reverse engineering, and creative attack chaining during authorized security assessments.
domain	cybersecurity
subdomain	offensive-security
tags	["penetration-testing","zero-day","fuzzing","vulnerability-research","exploit-development","bug-bounty"]
version	1.0
author	xalgord
license	Apache-2.0
nist_csf	["PR.PS-01","ID.RA-01","DE.CM-01"]

Performing Zero-Day & Novel Vulnerability Discovery

When to Use

• When standard vulnerability scanners and known CVE checks return no results
• During deep-dive penetration tests where the client expects original research
• For custom-built applications with no public CVE history
• When testing proprietary software, APIs, or firmware
• During bug bounty hunting where unique/novel findings earn higher payouts
• After exhausting all known attack vectors in earlier phases

Most Often Missed & How to Confirm

• Business-logic and authorization flaws: scanners can't see them, so they're the highest-value miss. Confirm IDOR/BOLA by replaying a request with a second valid account's token and proving you read/modify the first user's data — never infer from status codes alone.
• Race conditions assumed, not proven: a "double-spend" needs evidence. Confirm with single-packet attack / Turbo Intruder, then show the post-condition (balance went negative, coupon applied twice) and that a sequential run does NOT reproduce it.
• Type confusion / NoSQL operator injection: sending {"id":{"$gt":""}} or arrays often slips auth, but a 200 isn't proof. Confirm it changed behavior — returned another user's record, bypassed a filter, or altered the query — by diffing against the well-typed baseline response.
• Reflection mistaken for execution: {{7*7}}→49 confirms SSTI, but a reflected {{7*7}} string does not. Confirm injection class with engine-specific payloads (${7*7}, <%= 7*7 %>, #{7*7}) and escalate to a benign command/read to prove impact.
• Request smuggling false leads: timing alone is noisy. Confirm CL.TE/TE.CL by poisoning the socket so a second, unrelated request receives your prefixed response, or by capturing another user's request — reproduce it at least twice.
• SSRF without impact: hitting 169.254.169.254 may return nothing on IMDSv2. Confirm by retrieving an actual credential/metadata document or reaching a known-internal-only host, and capture the response as proof.
• Chains scored as parts: confirm the full chain end-to-end with one PoC script and compute CVSS on the final impact, not the individual primitives.
• Fuzzer 500s ≠ vulns: triage each crash, reproduce the minimized input deterministically, and identify the root cause before reporting.

Prerequisites

• Authorization: Written agreement explicitly covering vulnerability research and fuzzing
• ffuf/wfuzz: HTTP fuzzing tools
• : With Intruder, Repeater, and extensions