What Are Vulnerabilities in Cyber Security? Types, Examples, and How to Find Them

Vulnerabilities in cyber security are weaknesses in software, hardware, configuration, or human process that an attacker can exploit to gain unauthorized access, steal data, or disrupt operations, and the problem keeps growing: the National Vulnerability Database logged more than 40,000 new CVEs in 2024, and Verizon’s Data Breach Investigations Report found that attackers exploiting vulnerabilities as their initial way into a network nearly tripled year over year, so if you run a website, an API, or a network exposed to the internet, some of those flaws apply to you.

Key Takeaways

• A vulnerability is a weakness; a threat is who might exploit it; risk is the potential damage when both meet.
• Publicly disclosed vulnerabilities get a CVE ID and a CVSS severity score from 0.0 to 10.0.
• The five main types are network, operating system, web application, human/process, and zero-day vulnerabilities.
• Attackers scan for newly disclosed CVEs within minutes; quarterly scanning leaves months of exposure open.

What Are Vulnerabilities in Cyber Security?

A vulnerability is any flaw an attacker can use as a way in. That flaw can live in code, such as a SQL injection bug in your login form; in configuration, such as an admin panel left open to the internet; in unpatched software, such as a WordPress plugin running a version with a known exploit; or in people, such as an employee who reuses one password across six services. NIST defines a vulnerability as a weakness in an information system, security procedures, internal controls, or implementation that a threat source could exploit or trigger.

Three identifiers track a vulnerability from discovery to fix, and each one does a different job:

1. Identifies the flaw with a CVE (Common Vulnerabilities and Exposures) ID, a unique tag assigned by MITRE the moment a vulnerability is publicly disclosed. For example: CVE-2021-44228.
2. Scores the flaw’s severity through the NVD (National Vulnerability Database), the U.S. government’s enriched CVE catalog maintained by NIST, which adds a CVSS rating and lists the affected products.
3. Classifies the flaw’s underlying weakness type using CWE (Common Weakness Enumeration), the taxonomy MITRE uses to group flaws into categories. CWE-89 is SQL injection as a class, while a CVE is one specific instance of it in one specific product.

A concrete example makes the definition real. In December 2021, researchers disclosed Log4Shell (CVE-2021-44228), a flaw in the Log4j logging library that scored the maximum CVSS 10.0. The vulnerability itself did nothing. It sat in millions of applications for years. The damage started when attackers weaponized it, launching remote code execution attacks within hours of disclosure. That gap between a weakness existing and a weakness getting exploited is exactly where the next section’s distinction matters.

Vulnerability vs. Threat vs. Risk: Why the Difference Matters

Most explainers blur these three terms together, and the confusion costs money: teams that treat every vulnerability as an active threat burn their patching budget on flaws nobody will ever exploit, while genuinely dangerous exposures sit open for months. The unlocked-door analogy sorts it out. A vulnerability is the unlocked door. A threat is the burglar walking your street, whether or not they ever try your house. Risk is the chance that burglar tries your specific door, multiplied by what you’d lose if they got in: your customer database, your uptime, your compliance standing. You can’t patch a threat, and you can’t arrest a vulnerability; you close vulnerabilities to shrink the risk that a threat you don’t control ever turns into a breach you do.

Types of Cyber Security Vulnerabilities

Security teams group vulnerabilities into five broad classes. Most real-world breaches chain two or more together: a phishing email steals credentials, the attacker logs in, then exploits an unpatched server to escalate further.

Network Vulnerabilities

Network vulnerabilities are weaknesses in the infrastructure connecting your systems: open ports running services that shouldn’t face the internet, firewall misconfigurations, unencrypted protocols like FTP or Telnet still enabled, and outdated firmware on routers and VPN appliances. VPN gateways have become a favorite target. Attackers exploited Citrix Bleed (CVE-2023-4966) to hijack authenticated sessions on NetScaler appliances at hundreds of organizations, including Boeing’s parts business. Once inside through a network vulnerability, attackers move laterally toward higher-value systems, which is why network segmentation and disabling legacy protocols matter as much as patching the appliance itself. If your team manages firewall and VPN infrastructure without a formal change-management process, assume some port or service is exposed that shouldn’t be.

Operating System Vulnerabilities

Operating system vulnerabilities live inside Windows, Linux, and macOS themselves: kernel flaws, privilege escalation bugs, and unpatched system services. The canonical case is EternalBlue (MS17-010), a Windows SMB flaw that powered the WannaCry ransomware outbreak in 2017, infecting over 200,000 machines across 150 countries. Microsoft had shipped the patch two months before the outbreak started. Every infected organization was running systems nobody had updated, which is the pattern behind most OS-level breaches: the fix already existed, but the patch cycle didn’t catch up in time. Endpoint detection tools help catch exploitation after the fact, but a disciplined patch management cadence closes the window before an attacker ever gets a chance to try.

Web Application Vulnerabilities

Web application vulnerabilities are flaws in the sites and apps you expose to the public: SQL injection (SQLi), cross-site scripting (XSS), server-side request forgery (SSRF), cross-site request forgery (CSRF), insecure direct object references (IDOR), and broken access control, the classes cataloged in the OWASP Top 10. These matter disproportionately for SMBs because your website is usually your most exposed asset, sitting on the open internet 24/7 with no analyst watching it in real time. The Cl0p ransomware group’s MOVEit campaign (CVE-2023-34362) started with a SQL injection flaw in a file-transfer web app and ended with data stolen from more than 2,700 organizations. A single unpatched form field or misconfigured access-control check is often the entire gap between a normal Tuesday and a breach disclosure.

Human and Process Vulnerabilities

Not every vulnerability is technical. Weak passwords, credential reuse, missing MFA (multi-factor authentication), and susceptibility to phishing are all exploitable weaknesses, and attackers exploit them more often than they exploit code flaws. Verizon’s DBIR consistently attributes over 60% of breaches to a human element. A perfectly patched server doesn’t help when an employee hands their password to a fake Microsoft 365 login page, or when a shared admin account never gets rotated after someone leaves the company. Closing this category takes less code and more process: enforce MFA everywhere, especially on admin and VPN accounts, and run phishing-awareness training often enough that it’s a habit, not an annual checkbox.

Zero-Day Vulnerabilities

A zero-day is a vulnerability attackers discover and exploit before the vendor knows it exists. The vendor has had zero days to build a patch. Zero-days grab headlines, but they’re rare and expensive to develop or buy; most attackers don’t need one. The Ivanti Connect Secure VPN zero-days (CVE-2024-21887 and CVE-2023-46805) let attackers run unauthenticated remote code on appliances months before a patch shipped, and CISA’s Known Exploited Vulnerabilities (KEV) catalog is still full of years-old CVEs that work today only because organizations never patched them. The uncomfortable truth is that your biggest exposure is almost never a zero-day. It’s the known, scored, patchable flaw nobody on your team has gotten to yet.

Read More: 12 Types of Website Security Vulnerabilities (and How to Fix Each One).

How Vulnerabilities Get Discovered and Cataloged

Vulnerabilities surface through four main channels: security researchers probing products, bug bounty programs paying hackers to report flaws legally, vendors auditing their own code, and, worst case, incident responders finding a flaw only because someone already exploited it. Once a flaw is found, it moves through a fixed pipeline before it ever reaches a scanner’s database:

1. Report the flaw privately to the vendor. A researcher follows responsible disclosure, typically under a 90-day deadline before going public.
2. Assign a CVE ID. A CVE Numbering Authority (CNA), either MITRE or an authorized vendor, issues the identifier once the flaw is confirmed.
3. Enrich the record. NIST’s NVD analysts add a CVSS severity score, the affected product versions (CPE data), and a CWE classification.
4. Publish the advisory and ship the fix. The vendor releases a patch, the advisory goes live, and scanners add a detection signature the same day.

Step four is where defenders and attackers start racing. Publication tells you exactly what to patch, and it tells every attacker on earth exactly what to exploit.

How Vulnerabilities Get Exploited: The Attack Lifecycle

Attackers follow a repeatable sequence, mapped in detail by the MITRE ATT&CK framework, and understanding it shows you exactly where scanning breaks the chain:

1. Scan your external attack surface. Attackers enumerate domains, subdomains, open ports, and software versions at internet scale; Palo Alto’s Unit 42 measured attackers scanning for newly disclosed CVEs within 15 minutes of publication.
2. Match what they found against known exploits. Public proof-of-concept code for a fresh CVE often appears on GitHub within days of disclosure.
3. Fire the exploit for initial access. A SQLi payload hits your web app, a malicious login attempt hits your VPN, or a phishing email hits your staff.
4. Escalate privileges and persist. Once inside, attackers exploit further vulnerabilities to gain admin rights and plant backdoors that survive a reboot or a password reset.
5. Extract the impact. Attackers steal data, deploy ransomware, or maintain quiet long-term access they later sell to another crew.

Steps one through three depend entirely on vulnerabilities you could have found first. The attacker’s reconnaissance scan and your defensive vulnerability scan look at the exact same surface. The only question is who runs theirs first.

Read more: How to Check Vulnerability of a Website Manually? (Step-by-Step)

How to Find Vulnerabilities Before Attackers Do

Three practices close the gap, in order of effort:

1. Run vulnerability scanning as your baseline. A DAST (Dynamic Application Security Testing) scanner tests your running website and APIs from the outside, exactly as an attacker sees them, with no source code required, and flags known CVEs, misconfigurations, and OWASP Top 10 flaws with evidence for every finding. Scans are automated, repeatable, and cheap enough to run weekly. This is what ScanTitan’s website vulnerability scanner does.
2. Commission penetration testing annually or after major changes. A hired, legal attacker chains findings together, exploits business logic, and proves real-world impact in ways automated tools can’t. A yearly pentest with no scanning in between still leaves eleven months of blindness.
3. Deploy attack surface management to answer the question scanning can’t. EASM tools continuously discover forgotten subdomains, shadow IT, and staging servers your team forgot were public. You can’t scan an asset you don’t know exists.

If you’re a two-person IT team, start with automated scanning of your known assets. It catches the unpatched-CVE and misconfiguration classes that account for most opportunistic breaches, without requiring a dedicated security hire.

Here’s the stance most vendors won’t take: CVSS alone is a poor prioritization signal. A CVSS 7.0 on your public payment page, with exploit code circulating and the CVE listed in CISA’s KEV catalog, is more urgent than a CVSS 9.0 on an internal dev server nothing external can reach. Prioritize by three factors together: severity (CVSS), exposure (is it internet-facing?), and exploitation evidence (KEV listing, public proof-of-concept code). Don’t rely on the score alone.

Fixing follows a standard patch management loop: patch or upgrade the affected component, apply a compensating control such as a WAF rule or a disabled feature if no patch exists yet, then rescan to confirm the fix actually closed the flaw. That last step gets skipped constantly, and a “patched” vulnerability that still responds to an exploit is worse than an open one, because nobody’s watching it anymore.

Read More: Vulnerability Scanning vs Penetration Testing: What’s the Difference (and Which Do You Need)?

Common Questions About Cyber Security Vulnerabilities