Types of Vulnerabilities
Explain the vulnerability families tested on Security+ — application, OS, web, hardware, virtualization, cloud, supply chain, cryptographic, misconfiguration, mobile, and zero-day.
A vulnerability is a weakness an attacker can exploit to violate confidentiality, integrity, or availability. It is not an attack — it is the condition that makes an attack possible. Security+ groups vulnerabilities by where they live (application, OS, web, hardware, virtualization, cloud, supply chain, mobile) and what kind of flaw they are (injection, memory safety, race condition, cryptographic weakness, misconfiguration). Your job on exam day is to read the symptom and name the class.
Three ideas tie the whole objective together. First, a zero-day is unknown to the vendor — it is not the same as an unpatched known CVE. Second, misconfiguration (default creds, open buckets, debug mode in production) is one of the most commonly exploited categories. Third, layer of the stack shapes the mitigation: application flaws need code fixes, OS flaws need patches, cloud flaws need IAM/config discipline, and hardware flaws may only be fixable by replacement.
Application vulnerabilities. Flaws in how code handles input or memory. Key types: memory injection (malicious code written into a running process), buffer overflow (writing past allocated memory, enabling code execution), race conditions (TOCTOU — Time-of-Check to Time-of-Use, where state changes between validation and action), and malicious update (attacker-inserted code delivered via a legitimate update channel). Fix path: secure coding, code review, SAST/DAST.
Operating system vulnerabilities. Kernel flaws, privilege-escalation bugs, local exploits that let a low-privileged user become root/SYSTEM. Patch cadence matters more than any other mitigation here — OS vendors release monthly fixes and attackers weaponize them within days.
Web-based vulnerabilities. The big two: SQL injection (SQLi), where unsanitized input breaks out of query context and runs attacker SQL; and cross-site scripting (XSS), where attacker JavaScript runs in a victim’s browser (reflected, stored, or DOM-based). Fix path: parameterized queries, output encoding, Content Security Policy.
Hardware vulnerabilities. Firmware flaws sit below the OS and are rootkit-friendly. End-of-life (EOL) hardware no longer receives firmware/security updates. Legacy systems are still in production but unsupported — often unpatchable. Fix path: replace, isolate, or wrap with compensating controls.
Virtualization vulnerabilities. VM escape is when a malicious guest breaks out to the hypervisor or another VM — the worst-case multi-tenant failure. Resource reuse is sensitive data left in memory pages or disk blocks reassigned to a different VM. Fix path: hypervisor patching, memory scrubbing, tenant isolation controls.
Cloud-specific vulnerabilities. Misconfigured storage buckets, exposed API keys in public repos, over-permissive IAM, missing MFA on root accounts, insecure APIs, and shared-responsibility misunderstandings (thinking the provider secured something you actually own). Fix path: CSPM tooling, IAM least-privilege, key rotation, baseline configs.
Supply chain vulnerabilities. The flaw is in something you consumed, not something you built. Service provider (SaaS vendor breach cascades to you), hardware provider (implanted or tampered components), software provider (poisoned npm/PyPI packages, compromised updates like the SolarWinds incident). Fix path: vendor assessment, SBOM, update integrity verification.
Cryptographic vulnerabilities. Weak ciphers (DES, RC4), deprecated hashes (MD5, SHA-1), short keys, poor key management, downgrade attacks, lack of Perfect Forward Secrecy. Fix path: enforce modern algorithm suites, deprecate weak ciphers at the protocol level, rotate keys.
Misconfiguration vulnerabilities. Default credentials never changed, unnecessary services enabled, open S3 buckets, permissive firewall rules, missing hardening, debug mode on in production. Not a code flaw — a settings flaw. Fix path: configuration enforcement (baselines, CIS benchmarks, GPOs, IaC).
Mobile device vulnerabilities. Side loading (installing apps outside official stores, higher malware risk) and jailbreaking/rooting (removing OS restrictions, which disables sandboxing and signature verification). Fix path: MDM policy, app allowlists, jailbreak detection.
Zero-day. A vulnerability unknown to the vendor with no patch available. Valuable on criminal and government markets; especially dangerous because signature-based defenses cannot detect what is not yet cataloged. Fix path: defense-in-depth — allow-listing, segmentation, behavioral EDR, least privilege.
| Symptom / Scenario | Likely Vulnerability Class | Fix Path |
|---|---|---|
| Input field dumps database rows | SQL injection | Parameterized queries, ORM, input validation |
| User session hijacked via reflected script | Cross-site scripting (XSS) | Output encoding, CSP, HttpOnly cookies |
| App crashes with memory-address error, then executes attacker payload | Buffer overflow | Safe languages, ASLR, DEP, code review |
| Check passes then state changes before the action runs | Race condition (TOCTOU) | Atomic operations, file locking, re-check after action |
| Legitimate vendor update delivers malicious code | Malicious update / supply chain | Code signing verification, SBOM, build-pipeline integrity |
| Guest VM reads host memory | VM escape | Hypervisor patching, tenant isolation |
| Open S3 bucket exposes customer data | Misconfiguration (cloud) | CSPM, bucket policies, block-public-access defaults |
| TLS negotiates down to SSLv3 | Cryptographic (downgrade) | Disable legacy protocols, HSTS, strict cipher suites |
| IoT device ships with admin:admin | Misconfiguration (default credentials) | Provisioning workflow, mandatory reset-on-first-use |
| App installed from third-party store exfiltrates contacts | Mobile side-loading | MDM allowlist, app-store-only policy |
| Exploit in the wild, no vendor patch exists | Zero-day | Defense-in-depth — allow-list, segment, EDR behavioral |
| Windows Server 2008 still in production | Legacy / EOL | Isolate, compensating controls, migration plan |
Zero-day = unknown to vendor. Unpatched CVE = known but not fixed. If the scenario says “no patch is available because the vendor is not yet aware,” it is a zero-day. If the scenario says “a patch exists but the team hasn’t applied it,” it is an unpatched known vulnerability — operationally a patching problem, not a zero-day problem.
A fintech company investigates a customer report: an attacker transferred money from another user’s account, but logs show the session was authenticated as the attacker and the transfer endpoint returned the expected 200 response. The transfer validated the source account ownership successfully, and the transfer executed milliseconds later. The AppSec Engineer and the DevOps Lead are reading the same evidence and naming different vulnerability classes.
The Transfer That Validated and Still Went Wrong
Fintech app · authenticated session · ownership check passed, wrong account debitedRate-limit and tokenize the transfer flow. Until the race is fixed, add a server-side one-shot transaction token issued at validation time that must be submitted with the action — so the account ID cannot be changed mid-flight. Add alerting for ownership-check-passes-for-A-but-action-runs-on-B patterns in logs.
Race conditions are hard to find and harder to reproduce. They do not fail fuzzing, they rarely fail code review, and they hide from most scanners. Teams often find them only after customers complain. On the job, the real value of naming the class correctly is that it drives the right fix. Fixing “injection” would not stop a TOCTOU bug.
On the exam: the word “timing” or “between check and action” or “state changed” is the TOCTOU fingerprint. Do not pick injection just because the flaw involves a parameter; pick injection only when attacker input is directly interpreted as code or query structure.
A manufacturing plant runs a Windows Server 2008 R2 file server that controls part-number metadata for the production line. The OS is past end-of-life and cannot be patched. The vendor application that depends on it is also out of support. Replacing the app requires a six-month OT-coordination project with line downtime. Which is the right short-term vulnerability-management move?
Isolate via microsegmentation + compensating controls
Place the legacy server on a restricted VLAN, allow only the specific OT protocols from specific hosts, wrap with HIDS and application allow-listing, and log every connection. Begin the migration project in parallel.
Emergency migrate the app to a supported OS in the next 72 hours
Treat EOL as an immediate blocker. Force the migration now, accept the line downtime, and get off the unsupported stack as fast as possible.
Option A is the stronger short-term fit — isolate plus compensating controls while migration proceeds
Option A: For legacy/EOL systems that cannot be patched, CompTIA frames the correct answer as compensating controls: segmentation, strict allow-listing of network paths, host-based monitoring, and logging. This reduces risk to acceptable levels while the long migration runs. It also keeps the business running, which vulnerability management always has to respect.
Option B’s kernel of truth: eventually you must migrate — EOL systems cannot be an indefinite state. But forcing a 72-hour migration on a production OT system without a tested cutover plan risks a far worse outage than the vulnerability itself. “Replace it today” is not realistic for every legacy system, and the exam rewards the compensating-controls answer for the short term.
On the exam: when the system “cannot be patched” and replacement takes time, the correct answer is almost always isolation + compensating controls + monitoring, paired with a migration plan.
Vulnerability questions describe a symptom and ask for the class. Read for: (1) where the flaw lives (code, config, hardware, hypervisor, cloud, mobile), (2) what the attacker did (inject input, race timing, break out of a VM, exploit default creds), and (3) whether the vendor has a patch (known CVE vs. zero-day). If the fix path is “change a setting,” it is misconfiguration; if the fix path is “update the vendor software,” it is a software vulnerability.
- A Unpatched CVE
- B Zero-day vulnerability
- C Cryptographic downgrade
- D Misconfiguration
Correct: B. The vendor has no prior knowledge and no patch exists — that is the definition of a zero-day. Active exploitation increases urgency but does not change the category.
A wrong: An unpatched CVE presupposes the CVE exists; this scenario says the vendor had no prior knowledge, so there is no published CVE yet.
C wrong: Downgrade is a specific cryptographic attack pattern, not the category for an unknown library flaw.
D wrong: Misconfiguration is about deployment settings, not a code flaw in a library.
Source: CompTIA SY0-701 Objectives v5.0 — 2.3 Types of Vulnerabilities
' OR 1=1 -- and retrieves every row in the users table. Which vulnerability class is this?- A SQL injection
- B Cross-site scripting (XSS)
- C Buffer overflow
- D Race condition (TOCTOU)
Correct: A. Unsanitized input breaks out of the intended query context and is interpreted as SQL. The ' OR 1=1 -- pattern is the classic SQLi fingerprint.
B wrong: XSS executes attacker JavaScript in a victim’s browser, not SQL against the database.
C wrong: Buffer overflow involves writing past allocated memory, usually in compiled languages, and leads to memory-corruption symptoms, not query-result leaks.
D wrong: Race conditions turn on timing between check and action, not on interpreted input.
Source: CompTIA SY0-701 Objectives v5.0 — 2.3 Types of Vulnerabilities
- A Memory injection
- B Cloud misconfiguration
- C Supply chain (software provider)
- D Mobile side-loading
Correct: C. A poisoned third-party dependency delivered through a legitimate package ecosystem is the textbook software supply-chain vulnerability. SBOM tracking and dependency integrity verification are the mitigations.
A wrong: Memory injection is a process-runtime attack, not a dependency-chain attack.
B wrong: The flaw is in a consumed package, not in the cloud account’s configuration.
D wrong: Side-loading is installing mobile apps outside official app stores.
Source: CompTIA SY0-701 Objectives v5.0 — 2.3 Types of Vulnerabilities