Vulnerability

A vulnerability is a weakness in software, hardware, a network, or a process that lets an attacker do something they should not be able to do: read data, run code, escalate privileges, or take a service down. On its own a vulnerability is just potential risk. It becomes an incident only when someone builds an exploit for it and reaches the affected system.

Vulnerability, Exploit, and Threat

These three words get used interchangeably and shouldn’t be:

  • Vulnerability — the flaw itself (an unpatched service, a missing input check, a default password).
  • Exploit — the code or technique that turns that flaw into a working attack.
  • Threat — the actor or event with the motive and capability to use it.

Risk is the product of all three plus impact. A critical flaw on an internet-facing server with public exploit code is a live emergency; the same flaw on an isolated lab machine may be background noise. Context decides priority.

Common Types

Software flaws. Coding and design mistakes: buffer overflows, use-after-free, insecure deserialization, and injection bugs such as SQL injection. These map closely to the OWASP Top 10 2021, where Broken Access Control (A01) and Injection (A03) lead the list. A flaw that is unknown to the vendor and has no patch is a zero-day.

Configuration and network flaws. Weaknesses in how systems are deployed rather than coded: exposed management ports, weak or absent TLS, permissive firewall rules, default credentials, and public cloud storage. Many of the worst breaches trace back to a misconfiguration, not an exotic bug.

Human factors. People are part of the attack surface. Phishing, pretexting, and other social engineering techniques exploit trust and habit, bypassing technical controls entirely.

Physical flaws. Unlocked racks, unattended sessions, USB drops, and weak building access. Physical proximity often converts a “low” software issue into full compromise.

How Vulnerabilities Are Identified and Rated

The industry uses shared identifiers so everyone talks about the same flaw:

  • CVE (Common Vulnerabilities and Exposures) — a unique ID for a specific, publicly disclosed vulnerability, coordinated by MITRE.
  • CWE (Common Weakness Enumeration) — the underlying class of flaw (e.g. CWE-89 is SQL injection). Many CVEs share one CWE.
  • CVSS (Common Vulnerability Scoring System) — a 0–10 severity score. CVSS v4.0 is the current standard, though you will still see v3.1 scores widely in the wild.

Severity alone doesn’t equal urgency. Two data sources sharpen the picture: EPSS, which estimates the probability a flaw will be exploited in the near term, and CISA’s Known Exploited Vulnerabilities (KEV) catalog, which lists flaws confirmed to be under active attack. A KEV entry with a modest CVSS often deserves attention before a “critical” that no one is actually exploiting.

Finding Them: Scanning and Testing

Discovery ranges from automated scanning to hands-on testing:

  • Network and port scanning with Nmap maps live hosts, open ports, and service versions — the first read on your exposure.
  • Vulnerability scanners such as Nessus and OpenVAS/Greenbone compare discovered services against known-flaw databases.
  • Web scanners like Burp Suite and OWASP ZAP probe applications for injection, access-control, and logic issues.
  • Penetration testing validates whether findings are actually exploitable — automated tools flag potential problems, but a human confirms real risk and rules out false positives.

Nmap’s scripting engine can flag some known issues directly:

# Service/version detection plus default vulnerability scripts
nmap -sV --script vuln 192.168.56.0/24

Only run scans against systems you own or have written authorisation to test. Unauthorised scanning is illegal in most jurisdictions.

Managing Vulnerabilities

Vulnerability management is a continuous loop, not a one-off scan:

  1. Discover — inventory assets and scan them regularly. You can only protect what you know exists.
  2. Prioritise — rank findings by CVSS and real-world signals (EPSS, KEV, exposure, business impact) instead of chasing every high score.
  3. Remediate — patch, reconfigure, or apply compensating controls. Where a patch isn’t available, reduce exposure (segment the network, disable the feature, tighten access).
  4. Verify — rescan to confirm the fix landed and didn’t regress.
  5. Report — track metrics like time-to-patch so the process improves.

Prevention pushes this left. Secure coding practices, dependency and supply-chain checks, and hardened baseline configurations stop many flaws from ever shipping. When a serious exploit does land, a rehearsed incident response plan limits the damage.

Why It Matters

Attackers don’t need many openings — one unpatched, internet-facing service is enough. Off-the-shelf exploitation frameworks make weaponising known CVEs routine, which is exactly why disciplined patching, sensible configuration, and layered defence remain the highest-leverage work in security. The goal is not zero vulnerabilities, which is impossible, but a shrinking, well-understood attack surface where the flaws that remain are the ones least likely to hurt you.