Vulnerabilities, Risks & Exploits

In January 2021, a water treatment plant in Oldsmar, Florida was remotely accessed by an unknown attacker who briefly raised the sodium hydroxide level in the water supply to 111 times the safe limit. The operator caught it within minutes and reversed it. The entry point? A shared TeamViewer account with no password set — a vulnerability that had been sitting there for months, completely unnoticed. It wasn't sophisticated. It didn't need to be.

Three words that mean three different things

Security writing throws around vulnerability, risk, and exploit as if they're interchangeable. They aren't. Confusing them leads to muddled thinking — and muddled thinking leads to spending money defending against the wrong things.

A vulnerability is a weakness — a flaw in code, a misconfigured system, a process nobody thought to secure. It sits there doing nothing on its own. Every piece of software ships with vulnerabilities; the question is whether anyone finds them and whether there's anything worth stealing on the other side.

A risk is what happens when a vulnerability meets context. It's the probability that the weakness gets found and used, multiplied by the damage that would cause. A critical SQL injection flaw in an offline test machine carries near-zero risk. The same flaw in a live payment portal carries enormous risk. Same vulnerability, completely different risk profile.

An exploit is the mechanism — the code, technique, or sequence of steps that turns a vulnerability into something an attacker can actually use. It's the bridge between "weakness exists" and "attacker got in." Some vulnerabilities sit unnoticed for years. The moment a working exploit is released publicly, every server running that software becomes a target within hours.

The four sources of vulnerabilities

Vulnerabilities don't arrive from nowhere. They fall into a few consistent categories, and knowing which category you're dealing with changes how you fix it.

Software bugs are the most common source. Developers write thousands of lines of code under deadline pressure, and some of it will have mistakes. Buffer overflows, unchecked inputs, logic errors — these are coding mistakes that, under the right conditions, an attacker can trigger deliberately. The Heartbleed bug in OpenSSL let anyone on the internet read the memory of servers they had no business touching. It had been sitting in the codebase for two years before anyone noticed.

Misconfigurations are arguably more common than software bugs, and almost entirely avoidable. A database left open to the internet with default credentials, a storage bucket set to public when it shouldn't be, an admin interface exposed with no authentication. These aren't code flaws — they're setup mistakes. The Capital One breach in 2019 that exposed over 100 million customer records came down to a misconfigured web application firewall, not a zero-day exploit.

Unpatched software is what turns yesterday's fixed vulnerability into today's active threat. When a patch is released, the vendor is effectively publishing the location of the flaw to anyone who reads the release notes — including attackers. Organisations that lag on patching give those attackers an open window.

Design weaknesses are baked in at the architectural level and harder to fix than bugs — you can't just patch a protocol. Early versions of WEP wireless encryption were fundamentally broken by design, not implementation. Fixing it required replacing the entire protocol.

CVE — the industry's tracking system

When a vulnerability is discovered and disclosed, it gets assigned a CVE number — Common Vulnerabilities and Exposures. Think of it as a serial number for a flaw. CVE-2021-44228 is Log4Shell. CVE-2017-0144 is EternalBlue, the exploit that WannaCry weaponised. The number is just a reference handle; what matters is the severity score attached to it.

Severity is calculated using CVSS — the Common Vulnerability Scoring System — on a scale from 0 to 10. The score accounts for how easy the vulnerability is to exploit, whether it requires authentication, whether it can be triggered remotely, and how much damage it causes. A score of 9.8 means someone can fire it at your server from the internet with no credentials and get code execution. Those patches are not optional.

Zero-days and the vulnerability lifecycle

The most dangerous category of vulnerability is one that nobody knows about except the attacker. A zero-day is a flaw with no patch because the vendor has had zero days to fix it. Attackers who discover zero-days have a window of complete advantage — every target running the affected software is exposed and there's nothing defenders can do at the software level.

Zero-days are rare and expensive. Nation-state intelligence agencies pay millions for reliable ones. Criminal groups buy and sell them on private markets. When one leaks — as happened with the NSA's arsenal in 2017 — it creates an immediate global crisis because the exploit is now available to anyone with an internet connection.

The vulnerability lifecycle runs roughly like this: flaw exists in software → researcher or attacker finds it → either responsible disclosure to vendor or silent exploitation → vendor releases patch → organisations apply patch → vulnerability window closes. The gap between patch release and widespread application is where most real-world attacks happen.

Vulnerability scanning in practice

Security teams don't manually inspect every system for weaknesses — they use scanners. Tools like Nmap identify open ports and running services; Nessus and OpenVAS cross-reference those services against databases of known CVEs and flag anything exposed. Here's what a basic Nmap service scan output looks like when run against a target host:

# Service version detection scan against a target host
# -sV detects service versions; -sC runs default scripts
nmap -sV -sC 192.168.1.105

Starting Nmap 7.94 ( https://nmap.org )
Nmap scan report for 192.168.1.105
Host is up (0.0014s latency).
Not shown: 993 closed tcp ports (conn-refused)

PORT     STATE SERVICE     VERSION
21/tcp   open  ftp         vsftpd 2.3.4
|_ftp-anon: Anonymous FTP login allowed
22/tcp   open  ssh         OpenSSH 4.7p1 Debian 8ubuntu1 (protocol 2.0)
80/tcp   open  http        Apache httpd 2.2.8 ((Ubuntu) DAV/2)
|_http-title: Metasploitable2 - Linux
139/tcp  open  netbios-ssn Samba smbd 3.X - 4.X (workgroup: WORKGROUP)
445/tcp  open  netbios-ssn Samba smbd 3.0.20-Debian
3306/tcp open  mysql       MySQL 5.0.51a-3ubuntu5
5432/tcp open  postgresql  PostgreSQL DB 8.3.0 - 8.3.7

Nmap done: 1 IP address (1 host up) scanned in 12.42 seconds

Vulnerability chaining — one finding rarely stays small

Security reports from penetration testers often get dismissed when they flag "low severity" vulnerabilities. This misses how attacks actually work. Attackers rarely rely on a single critical flaw — they chain smaller weaknesses together until the combined result is catastrophic.

A publicly visible error message that reveals a software version (low severity) + that version having a known authenticated vulnerability (medium severity) + a user account with a reused password from a previous breach (low severity) = full application compromise. Three individually dismissible findings, one very bad outcome.

Risk isn't just about individual vulnerabilities — it's about the paths they create when combined. Thinking in attack chains rather than isolated findings is one of the main shifts between beginner and intermediate security thinking.

Practice Questions

Quiz