Types of Vulnerabilities: Where They Live, How They’re Found and Who Fixes Them

A vulnerability is any weakness an attacker can use to get in, move around or cause damage. That sounds like a single problem, but in practice it isn’t. A flaw in your code, an open port on a router, a public storage bucket and an employee who reuses passwords are all vulnerabilities. Each one is found by different tools and fixed by different people.

That’s why the types of vulnerabilities are worth understanding. The type tells you where to look, what will catch it and who needs to act. Here’s a breakdown of the main categories.

Software Vulnerabilities

Software vulnerabilities are flaws in code, whether it’s code your team wrote or the operating systems and applications you run. They include coding errors like injection, cross-site scripting and broken access control, as well as known flaws in software that hasn’t been patched. At the severe end, a single remote code execution vulnerability can let an attacker run commands on a system from anywhere.

Application security vulnerabilities make up a large share of this category, and they grow with every release and every new dependency.

How they’re found: SAST tools analyze source code before it ships, DAST tools test running applications, and authenticated host scans flag missing patches on servers and endpoints.

Who fixes them: Developers own code-level flaws. IT and infrastructure teams own operating system and application patching.

Network Vulnerabilities

Network vulnerabilities are weaknesses in the infrastructure that connects your systems. Common examples include unnecessary open ports, outdated protocols, unpatched routers, firewalls and VPN appliances, and flat networks with little segmentation. Edge devices are a frequent target because they face the internet and are often patched slowly.

How they’re found: A network vulnerability scanner covers internal infrastructure. External attack surface management tools show what’s visible and exploitable from the outside.

Who fixes them: Network and infrastructure teams.

Misconfigurations

A misconfiguration isn’t a bug in the software. It’s a setting. Examples include default credentials left in place, admin interfaces exposed to the internet, unnecessary services left running and permissions far broader than anyone needs. Configurations also drift over time as small changes pile up.

Misconfigurations are among the most common types of vulnerabilities and among the easiest to overlook, because nothing appears broken.

How they’re found: Configuration assessment and posture management tools, often measured against hardening benchmarks such as CIS.

Who fixes them: Whoever owns the affected system. That is often the hard part, because ownership of shared and legacy systems is frequently unclear.

Cloud Vulnerabilities

Cloud vulnerabilities are largely configuration problems at scale. Common examples include publicly accessible storage, over-privileged identities and roles, exposed access keys and workloads running on vulnerable images. Because resources can be spun up in minutes, new exposures can appear just as fast.

Under the shared responsibility model, the cloud provider secures the underlying infrastructure. Securing how you configure and use the services is up to you.

How they’re found: Cloud security posture management (CSPM) tools catch configuration and identity risks. Container and workload scanners check images for known flaws.

Who fixes them: Cloud, platform and DevOps teams.

Third-Party and Supply Chain Vulnerabilities

Much of a modern application is built from open-source components, so a flaw in one popular library can affect every application that uses it. Log4Shell showed how far a single dependency can reach. This category also covers compromised packages, vulnerable vendor software and SaaS applications with access to your data.

How they’re found: Software composition analysis (SCA) tools identify vulnerable dependencies. A software bill of materials (SBOM) gives you an inventory to check new disclosures against.

Who fixes them: Developers upgrade affected dependencies, but they often depend on the upstream maintainer releasing a fix first. Vendor risk usually runs through procurement and vendor management.

Zero-Day Vulnerabilities

A zero-day is a flaw that attackers know about or are exploiting before a patch exists. It can fall into any of the categories above. What sets it apart is timing.

With no patch available, the job shifts from remediation to vulnerability mitigation. That can mean restricting access, disabling affected features, adding compensating controls and increasing monitoring until a fix ships.

How they’re found: Usually not by your own scanners. Zero-days tend to surface through vendor advisories, threat intelligence and government alerts.

Who fixes them: Security leads the response. System and application owners apply mitigations, then patch once a fix is released.

Human and Physical Vulnerabilities

Not every weakness lives in a system. Human vulnerabilities include susceptibility to phishing, weak or reused passwords, missing MFA and insiders misusing their access. Physical vulnerabilities include unsecured devices, lost laptops and poorly controlled access to facilities.

How they’re found: Phishing simulations, access reviews, identity audits and physical security assessments, rather than scanners.

Who fixes them: Security awareness, identity and access management, and facilities teams, through training, policy and access controls.

Why Vulnerability Type Doesn’t Decide Priority

Knowing the type tells you where to look and who to involve. It doesn’t tell you what to fix first. A critical-rated software flaw on an isolated test server may matter less than a medium-rated misconfiguration on an internet-facing production system.

Effective vulnerability prioritization looks past category and severity score to questions like these:

• Is it being exploited? Known exploited vulnerabilities are one of the strongest signals of real risk.
• Is it reachable? A flaw an attacker can’t get to is far less urgent than one exposed to the internet.
• How important is the asset? Production systems and those holding sensitive data come first.
• Are compensating controls in place? Existing protections can lower the immediate risk.

There’s also a practical challenge. Each type tends to come from a different tool, with its own format and severity scale, and goes to a different team. That makes it hard to compare a cloud misconfiguration with an unpatched server on equal terms. Teams that bring findings together in one view can rank them by actual risk rather than by whichever tool reported them.

Know the Type, Fix What Matters

The types of vulnerabilities span code, networks, configurations, cloud environments, supply chains and people. Understanding each one helps you choose the right detection tools and route findings to the right owners. Deciding what to fix first comes down to real-world risk. The goal isn’t zero vulnerabilities in every category. It’s making sure the ones attackers can actually use get fixed first.