Contextual Hacking
Hunt the context that creates vulnerabilities, not the vulnerability class.
The methodology gap
Most bug bounty education teaches isolated techniques: a video on SQL injection, a write-up on IDOR, a lab on XSS. The pieces are real, but nothing connects them into a process. The result is a familiar set of symptoms — scattered notes, bookmarked techniques you never revisit, and lab skills that never quite transfer to a live target.
The failure mode has a name: single-vulnerability tunnel vision. "Pick one vulnerability class and hunt it" is common advice, and well-intentioned — but without the missing step, it turns every input field into "the perfect spot for XSS," even in an application that handles input perfectly.
The missing step is context. The advice should be: stick to one vulnerability class, but learn the context that gives birth to it.
Vulnerabilities depend on context
Every vulnerability class has conditions it needs:
- An OAuth flaw only exists where OAuth exists and is misconfigured.
- A race condition needs asynchronous processing colliding with critical state.
- SSRF lives in applications that make outbound requests from user input.
None of these are lurking "everywhere." They are born from specific interactions between technologies, functionalities, gadgets, vectors, and quirks — the CAVET components.
So the working method inverts: instead of forcing a technique onto a target, you map the application's context and let it reveal the attack paths it actually supports.
Hunting for context lets the vulnerabilities find you.
This is what experienced hunters do instinctively: recon first, analyze patterns, choose techniques from evidence. Contextual hacking makes the instinct explicit — and makes a failed hypothesis productive, because the context you mapped is reusable knowledge regardless of which attack it eventually supports.
Map the context, then test
Contextual hacking has a practical loop:
- Map — technologies, functionalities, gadgets, vectors, quirks. The same five types used everywhere in Nimbus Vault.
- Probe — test the mapped surface for the properties (quirks) that decide exploitability.
- Reason — hold the context against your library of attack patterns.
- Test — apply the techniques the context supports, with probing, bypass, and exploitation techniques as your toolkit.
Techniques are still essential — they are how you probe, bypass, and exploit. What contextual hacking changes is when they enter: after the context says they apply, not before. ("Apply first, understand second" is how you waste an engagement; the loop above is the alternative.)
The team version
The same idea scales past one person. A shared context base — where every mapped component, confirmed quirk, and tested technique compounds — means knowledge stops being personal and starts being infrastructural:
- A teammate's earlier finding surfaces on your target because the components match.
- Nothing learned is forgotten, and nothing is relearned.
- The workspace gets smarter with every engagement, not just the individual.
That last property — knowledge that compounds relationally instead of accumulating as notes — is the "context engine" idea Nimbus Vault is built on.
What's next
- The CAVET Method — the formal ontology and workflow.
- Chain Recognition — what happens when findings compose.