Exploitation Basics
Exploitation is turning a vulnerability into control — making software do something it was not supposed to, from reading data it should protect to running the attacker's code. A defender does not need to write exploits, but does need to understand what classes of bug become what kind of compromise, why memory-safety and injection bugs are so dangerous, and what an exploit actually buys the attacker.
This topic demystifies exploitation enough to prioritize patching and reason about severity — the difference between a queue of undifferentiated CVEs and a triage that fixes the one being exploited today first.
Vulnerability to Impact
A bug is only as dangerous as what it grants: information disclosure, denial of service, or the crown jewel, remote code execution. CVSS scores try to capture this, and understanding the mapping is how you triage a patch queue — an authentication bypass and a minor info leak both score, but they demand very different urgency depending on what they reach.
Memory-Safety Bugs
Buffer overflows, use-after-free, and their kin let attacker-controlled input overwrite what the program executes — the classic path to remote code execution. They are why memory-safe languages and platform mitigations (ASLR, DEP/NX, stack canaries) exist, and why C and C++ services get so much scrutiny. They are devastating but comparatively hard to write.
Injection and Logic Bugs
Many high-impact web exploits are not memory corruption at all but injection (Chapter 6) or broken logic: the program trusts input it should not, or skips a check. These dominate modern web compromise, need no memory tricks, and are usually easier to exploit — a string-concatenated SQL query or a missing authorization check hands over data with none of the difficulty of a memory exploit.
Exploit Chains and Prioritization
Real intrusions chain bugs: a web vulnerability for initial code execution, then a local privilege-escalation bug (Chapter 7) for root. A "medium" bug that completes a chain can be as decisive as a "critical" one, which is why patching by CVSS alone is a mistake. Triage by exploitability and exposure — a known-exploited medium on an internet host beats a theoretical critical on an isolated one — and assume any internet-facing RCE is being exploited right now.
Memory-safety (overflows, use-after-free) — low-level, language-dependent, mitigated by ASLR/DEP and safe languages; devastating (often RCE) but harder to write.
Injection / logic (SQLi, auth bypass, IDOR) — high-level, language-agnostic, needs only input the app mistrusts; the dominant cause of web breaches and usually easier to exploit. Both can end in full compromise.
- Triaging patches by CVSS alone and ignoring real-world exploitability and exposure — a known-exploited medium on an internet host beats a theoretical critical on an isolated one.
- Assuming memory-safe languages remove exploitation risk, when injection and logic flaws do not care about memory safety.
- Under-rating chain-enabling bugs because each is individually "not critical," when together they reach root.
- Treating a single strong control as sufficient, so one exploit is game over instead of one layer defeated.
- Ignoring internet-facing RCE on a normal patch cycle, when it should be treated as actively exploited now.
- Prioritize patching by exploitability (known-exploited lists), exposure, and impact — not by raw CVSS number.
- Assume internet-facing remote code execution is actively exploited and respond on that timeline — hours, not the quarterly cycle.
- Use memory-safe languages and platform mitigations for new code, and keep defense in depth so no one bug is total.
- Reduce what an exploit can reach — least privilege and segmentation (Chapters 3 and 4) shrink the value of any single foothold.
- Account for exploit chains, giving weight to "medium" bugs that enable a path to root.
Knowledge Check
Why should patch prioritization use more than the CVSS score?
- Real exploitability and exposure often outweigh the number
- CVSS scores are assigned at random and are essentially meaningless
- Only critical-scored bugs are ever exploited
- CVSS measures exploit chains directly
Why doesn't a memory-safe language eliminate exploitation risk?
- Injection and logic flaws don't depend on memory safety
- Memory-safe languages run too slowly to be secure
- Memory-safe languages cannot use encryption or hashing libraries at all
- They reintroduce buffer overflows by design
Why can a "medium"-severity bug be as decisive as a "critical" one?
- It may be the link that turns a foothold into root
- Medium bugs are always easier to find than critical ones
- Severity labels are assigned at random
- Medium bugs cannot be patched
You got correct