Vulnerability Types and Misconfiguration
Key Takeaways
- A vulnerability is a weakness that can be exploited; misconfiguration is the single most common source CompTIA tests, ahead of zero-days.
- SY0-701 objective 2.3 names application, OS, web, hardware, virtualization, cloud, supply-chain, cryptographic, and misconfiguration vulnerability families by name.
- Cloud and container weaknesses almost always trace to identity, network, storage, image, or logging configuration rather than novel exploits.
- Supply-chain vulnerabilities include vulnerable dependencies, typosquatting, compromised updates, and weak hardware-provider controls.
- On scenario questions, name the root-cause weakness first, then pick the control that closes that exact condition.
Why This Section Carries Weight
Domain 2 (Threats, Vulnerabilities, and Mitigations) is 22% of the SY0-701 exam, second only to Security Operations at 28%, and vulnerability concepts (objective 2.3) appear in scenario form across all five domains. The exam is a maximum of 90 questions in 90 minutes with a passing score of 750 on a 100-900 scale (roughly 83%), so you cannot afford to misread the question. CompTIA hides the answer in the root cause: do not just name the attack, name the weakness that made it possible.
A vulnerability is a weakness in an asset; a threat is the actor or event that could exploit it; risk is the probability and impact of that pairing. Misconfiguration is the most commonly tested vulnerability source because it is preventable, human-caused, and present in nearly every breach scenario CompTIA writes.
| Vulnerability type | Concrete example | Why it matters | Typical mitigation |
|---|---|---|---|
| Missing patch | Internet-facing VPN has a known RCE CVE | Public exploit code likely exists | Patch, isolate, or apply vendor workaround |
| Default configuration | Default admin/admin still enabled on a switch | Trivial unauthorized access | Change defaults, apply a hardening baseline |
| Open permissions | Everyone group has write on a share | Tampering and data exposure | Least privilege, periodic access reviews |
| Insecure protocol | Telnet or FTP used for admin access | Credentials sent in cleartext | SSH, SFTP, or a secure management plane |
| Weak/legacy cryptography | TLS 1.0 or RC4 still enabled | Decryption or downgrade attacks | Disable weak protocols and ciphers |
| End-of-life (EOL) system | Vendor no longer issues fixes | Unpatched known flaws persist forever | Upgrade, replace, segment, monitor |
| Unnecessary service | Test service left running in production | Extra attack surface | Disable or restrict the service |
| Exposed management port | RDP 3389 or SSH 22 reachable from the internet | Direct credential-stuffing path | VPN, bastion host, allow list, MFA |
Misconfiguration Patterns CompTIA Loves
Most objective 2.3 questions reduce to one of these. Memorize the "better state" column because that is usually the correct answer choice.
| Area | Common mistake | Better state |
|---|---|---|
| Identity | Overly broad admin roles | Least privilege, role reviews, just-in-time access |
| Network | Any-to-any firewall rules | Narrow source, destination, port, and protocol |
| Storage | Public read on a sensitive object store | Block-public-access plus explicit policies |
| Logging | Audit logs disabled or 1-day retention | Central logging with protected, longer retention |
| Endpoint | All users are local administrators | Standard users plus a privileged-elevation workflow |
| Database | Database listener exposed to the internet | Private subnet, application-only access |
| Container | Runs as root with --privileged | Non-root user, dropped Linux capabilities |
| Cloud | Long-lived static access keys | Workload identity, short-lived credentials |
Cloud and Container Worked Example
A containerized web app is breached. Investigation finds three weaknesses at once: the image runs as root, it bundles a vulnerable package (an outdated logging library with a known CVE), and an environment variable holds a cloud access key. CompTIA will ask for the best or most immediate control.
| Finding | Vulnerability category | Best mitigation |
|---|---|---|
| Vulnerable package | Software/dependency vulnerability | Rebuild from a patched base image |
| Root container | Configuration weakness | Run as non-root, drop capabilities |
| Access key in env var | Secret exposure | Rotate the key now, move to a secret manager or workload identity |
Urgency drives the answer: an exposed key that may already be in attacker hands is rotated first, because exposure is active. Then you fix the build pipeline and secret-handling process so the condition does not recur. Picking only "patch the package" would leave the live credential usable.
Supply-Chain Weaknesses
Objective 2.3 explicitly lists supply chain (suppliers, vendors, managed service providers). Look for the clue word in the stem.
| Weakness | Stem clue | Mitigation |
|---|---|---|
| Vulnerable dependency | An SCA report flags a library CVE | Update the dependency and re-test |
| Typosquatting package | Package name almost matches a popular one (reqeusts) | Trusted registries, package allow lists |
| Compromised update | A legitimate vendor channel delivers malware | Vendor validation, code signing, monitoring |
| Unpinned dependency | Build pulls "latest" unreviewed package | Pin versions, use lock files |
| Unverified artifact | Binary's origin cannot be confirmed | Signature verification and hash checks |
| Hardware/firmware trust | Counterfeit or tampered component | Trusted suppliers, attestation, firmware validation |
Common Traps
| Trap | Better exam reasoning |
|---|---|
| Treat a scan as remediation | Scanning finds; remediation changes the risky condition |
| Patch a system with no vendor patch | Use compensating controls while replacing or upgrading |
| Encrypt data but leave public access on | Encryption helps, but public exposure is still a config failure |
| Disable logs for performance | Logs are required for detection, investigation, accountability |
| Name the attack, not the weakness | The objective asks for the vulnerability, then the fix |
Quick Drill
Name the weakness, then the mitigation:
- A router still uses the vendor default password: default configuration; change credentials, apply hardening baseline.
- A payroll database accepts connections from any internet address: exposed service; restrict network reachability, require a controlled admin path.
- A server runs an unsupported OS: legacy/EOL system; replace or isolate with monitoring until replacement.
- A lock file is missing and builds pull unreviewed versions: supply-chain weakness; pin and review dependencies.
- A storage bucket holding reports allows anonymous reads: misconfiguration; block public access and apply explicit policy.
A production object storage bucket containing internal reports allows anonymous public read access. What is the main weakness?
A vendor no longer releases security patches for a server operating system. Which mitigation is usually best long term?
Which items are common cloud misconfigurations? Select two.
Select all that apply