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?
Steganography
Misconfiguration
Key stretching
Jamming
A vendor no longer releases security patches for a server operating system. Which mitigation is usually best long term?
Ignore the finding because it is internal
Disable all monitoring
Replace or upgrade the system
Share the local admin account
Which items are common cloud misconfigurations? Select two.
Select all that apply
Overly permissive IAM role
Public access to sensitive storage
Use of salted password hashes
A tested backup restore
Sections you finish are checked off in the contents.