Introduction

Let’s cut through the jargon. If you’ve ever left your front door unlocked by accident, you already understand the core idea of a vulnerability. It’s not the burglar, it’s not the stolen telly—it’s the weakness itself that made the whole thing possible. In cybersecurity, that weakness might be a dodgy line of code, a server sitting unpatched since the last ice age, or even Barbara in accounting who clicks every link that lands in her inbox.

I’ve lost count of the times I’ve seen organisations throw money at “next-gen threat detection” while ignoring the stack of known vulnerabilities they’ve been sitting on for months. That’s like installing a laser security grid on the roof while leaving the basement door wide open. Understanding vulnerability is the first step towards building a defence that actually makes sense.

📖 What Exactly Is a Vulnerability?

Stripped down to its simplest form:

A vulnerability is a flaw, gap, or weakness in a system, process, or person that can be exploited by a threat to cause harm.

Notice I didn’t just say “a bug in software”. That’s where a lot of people get it wrong. Vulnerabilities live everywhere:

• Software vulnerabilities – Coding errors, design flaws, or logic issues that let an attacker do something they shouldn’t. Think buffer overflows, SQL injection points, or broken authentication.
• Hardware vulnerabilities – Physical design weaknesses. Spectre and Meltdown, for instance, exploited how modern CPUs speculatively execute instructions.
• Configuration weaknesses – Default credentials left unchanged, cloud storage buckets set to public, overly permissive firewall rules. These are human-made vulnerabilities that scanners often miss because they’re technically “working as designed”.
• Human vulnerabilities – We’re beautifully flawed creatures. Lack of security awareness, susceptibility to social engineering, poor password habits—all ripe for exploitation.

The common thread? Each one creates an opportunity for a threat actor to compromise confidentiality, integrity, or availability. You’ll hear those three words a lot in this field, and while I won’t dive deep into the CIA triad here, just know that a vulnerability typically threatens one or more of those pillars.

🔍 The Anatomy of a Vulnerability

Not all weaknesses are equal, and understanding their lifecycle helps you prioritise. Here’s how they usually unfold:

1. Discovery – A researcher, vendor, or attacker finds the flaw. Sometimes it’s responsibly disclosed; sometimes it’s sold on a darknet forum before anyone’s patching it.
2. CVE Assignment – If it’s a widely recognised issue, it gets a Common Vulnerabilities and Exposures (CVE) identifier. That’s the “CVE-2024-XXXXX” you see in security advisories. It gives everyone a common language.
3. Scoring with CVSS – The Common Vulnerability Scoring System assigns a severity score from 0 to 10, based on exploitability, impact, and other metrics. A 9.8 critical is your “drop everything and fix” signal. But here’s the thing: CVSS doesn’t account for your specific context. A critical flaw in a publicly exposed server is an emergency; that same flaw on an air-gapped test box in a lab might not be.
4. Exploit Availability – At some point, proof-of-concept code appears, or weaponised exploits get added to frameworks like Metasploit. Once a vulnerability is trivially exploitable, the risk profile spikes.
5. Patch or Mitigation – Vendors release a fix, or you slap on a compensating control (a WAF rule, disabling a service, network segmentation). The window between exploit availability and patch application is where most breaches happen.

A vulnerability itself is passive. It’s the crack in the wall. It only becomes a full-blown incident when a threat (the thing that can exploit it) and a lack of adequate control align. That’s why we say risk = threat × vulnerability × impact. You can’t control the threat actor, but you can shrink the vulnerability.

🧠 Why Do Vulnerabilities Keep Happening?

Because humans write code, humans configure systems, and humans are tired, pressured, or simply unaware. I’ll give you a personal example. Years ago, I was auditing a web application for a mid-sized company. Found an admin panel accessible from the internet with the username “admin” and password “admin”. The developer had set it up that way on a Friday afternoon, meaning to change it, and then… well, life happened. That little oversight sat there for eight months.

The common root causes:

• Time pressure – “Ship it now, secure it later.” Later rarely comes.
• Complexity – Modern tech stacks are a tangled web of dependencies. A flaw in a library you’ve never heard of can bite you (hello, Log4Shell).
• Legacy systems – That Windows Server 2003 box still chugging along because “it just works” and nobody dares touch it.
• Lack of training – Developers who haven’t been taught secure coding, sysadmins who inherit a messy environment with no handover.
• Supply chain trust – We pull in open-source packages with hundreds of transitive dependencies, assuming they’re all benign.

Recognising that vulnerabilities are a people-and-process problem just as much as a technology problem is a game changer.

🌍 Real-World Example: EternalBlue and WannaCry

You can’t talk about vulnerabilities without mentioning EternalBlue. It was a flaw in Microsoft’s SMBv1 protocol (tracked as CVE-2017-0144), originally discovered by the US National Security Agency. When the Shadow Brokers hacking group leaked it in 2017, the clock started ticking.

Microsoft had actually released a patch in March 2017, but many organisations worldwide hadn’t applied it. In May, the WannaCry ransomware worm ripped across the globe, using EternalBlue to spread from machine to machine without any user interaction. The NHS in the UK was hit hard—appointments cancelled, patient records inaccessible, millions in damages.

What makes this example so painfully instructive:

• The vulnerability was in a decades-old protocol that many didn’t even realise was still enabled.
• A patch existed for two months before the worm hit. The vulnerability window was massive.
• The exploit was reliable, wormable, and devastatingly effective.
• The impact was amplified by poor network segmentation—once inside, the worm had free reign.

This wasn’t some exotic zero-day when it struck; it was a known vulnerability left unpatched. That’s the reality for the majority of breaches. The attacker didn’t have to be a genius; they just had to find the unlocked door.

🔑 Key Points

• A vulnerability is a weakness that can be exploited—it is not the attack itself.
• Vulnerabilities exist in software, hardware, configurations, and human behaviour.
• They are tracked using CVE identifiers and scored with CVSS to help prioritisation.
• Most incidents stem from known vulnerabilities with available patches that haven’t been applied.
• A vulnerability alone doesn’t guarantee disaster—it requires a threat and the absence of effective controls.
• Treating vulnerabilities as purely technical ignores their root: human factors and process failures.
• Timely patching, secure configuration, defence in depth, and user education are your best defences.

❓ Knowledge Check

Now, let’s see how well you’ve absorbed the core concepts. Here are three questions to test your understanding of vulnerabilities—no peeking back at the text!