Famous vulnerabilities look different but repeat a few patterns: software trusted input it should have checked, the affected component was hidden inside other things, patches arrived faster than teams could apply them, and the damage grew through identity or data access. Seeing the patterns helps you prepare for the next one before it has a name.
Pattern 1: trusted input
- Heartbleed copied as many bytes as a sender claimed, per the Heartbleed site, without checking the claim against what was received.
- Log4Shell resolved lookups found in log text, according to the Apache Log4j security page.
- MOVEit's CVE-2023-34362 was a SQL injection, per CISA.
- Shellshock ran text that followed a function definition in an environment variable, per the CVE record.
Four different bugs, one habit: input crossed a boundary and was believed. Secure coding practice that checks input at every boundary addresses the pattern.
Pattern 2: hidden or indirect presence
Log4j was embedded in many products, which is why CISA's advisory begins with inventory. In the xz case, Andres Freund's analysis shows that OpenSSH did not use liblzma directly, yet builds linked with libsystemd loaded it. In both cases the vulnerable code sat one or two steps away from what teams thought they ran.
Pattern 3: a window between fix and exposure
Microsoft released MS17-010 on 14 March 2017, and WannaCry spread on 12 May, per the Microsoft bulletin and CISA. Heartbleed's fixed release appeared the same day the bug went public, 7 April 2014. Fixes existed. The delay was in deployment.
Patterns 4 and 5: damage that continues, and fixes that are incomplete
SolarWinds shows it best. CISA describes persistence through cloud service principals, federation trusts and forged SAML tokens. MOVEit's advisory warns that attacker accounts can survive a server rebuild if the database is kept. Removing the first foothold did not end the incident.
Fixes can also be incomplete. Shellshock needed a second CVE after the original patch was found incorrect, and Log4j had two more CVEs inside a week. See why the first fix is sometimes incomplete.
A team checklist built from the patterns
- Boundaries: is input validated where it enters, including logs and headers?
- Inventory: can you list every component, direct and transitive, across code, containers and vendor products?
- Speed: what is your median time from a published fix to deployment for internet facing systems?
- Reach: which systems can an attacker move to from each internet facing one?
- Identity: do you track service accounts, trusts and signing keys, and alert on changes?
- Follow-ups: do you keep patch tickets open for a week after a major disclosure?
Click through it at your own pace, or open it full screen.
Where Safeguard fits
Safeguard covers several rows of that checklist: SBOM and dependency scanning for inventory, reachability analysis for ranking, policies and gates for speed and control, and asset discovery. Try a free scan at gold.safeguard.sh/scan.
Quick check
Which pattern shows up most often?
Trusted input and hidden dependencies show up repeatedly in the cases above, but pick the pattern that fits your own gaps first.
Do these cases mean old bugs are irrelevant?
No. CISA's Known Exploited Vulnerabilities catalog still lists Shellshock, added in January 2022.
Sources
- Heartbleed.com
- Apache Log4j security page
- CISA advisory AA21-356A
- CISA advisory AA23-158A
- CISA advisory AA20-352A
- Andres Freund on oss-security
- CVE-2014-6271 record (GCVE mirror)
- CISA alert on WannaCry
- Microsoft Security Bulletin MS17-010
Last reviewed: 19 October 2026.
