Vulnerability Types and Misconfiguration
Key Takeaways
- A vulnerability is a weakness that can be exploited; misconfiguration is one of the most common vulnerability sources.
- Legacy systems, default settings, weak permissions, missing patches, exposed services, and insecure protocols create practical attack paths.
- Cloud and container vulnerabilities often come from identity, network, storage, image, and logging configuration errors.
- Supply chain vulnerabilities include vulnerable dependencies, untrusted packages, compromised updates, and weak vendor controls.
- The best mitigation depends on the weakness, the exposure, and the business constraints around the affected asset.
Last updated: April 2026
Vulnerability Types and Misconfiguration
Security+ vulnerability questions often hide the answer in the root cause. Do not only name the attack. Identify the weakness that made the attack possible.
| Vulnerability type | Example | Why it matters | Typical mitigation |
|---|---|---|---|
| Missing patch | Internet-facing VPN has known RCE | Known exploits may exist | Patch, isolate, or apply vendor workaround |
| Default configuration | Default admin password remains enabled | Easy unauthorized access | Change defaults, harden baseline |
| Open permissions | Everyone can write to shared folder | Tampering and data exposure | Least privilege and access reviews |
| Insecure protocol | Telnet used for admin access | Credentials and commands exposed | SSH or secure management plane |
| Weak encryption | Deprecated cipher enabled | Confidentiality or integrity risk | Disable weak protocols and ciphers |
| End-of-life system | Vendor no longer provides fixes | Unpatched known flaws persist | Upgrade, replace, segment, monitor |
| Unnecessary service | Test service exposed in production | Extra attack surface | Disable or restrict service |
| Exposed management port | Admin interface reachable from internet | Direct attack path | VPN, bastion, allow list, MFA |
Misconfiguration Patterns
| 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 sensitive object store | Block public access and explicit policies |
| Logging | Audit logs disabled or short retention | Central logging with protected retention |
| Endpoint | Users are local admins | Standard users and privileged elevation workflow |
| Database | Database exposed directly to internet | Private subnet and application-only access |
| Container | Runs as root with privileged mode | Non-root user, restricted capabilities |
| Cloud | Long-lived static access keys | Workload identity, short-lived credentials |
Cloud and Container Example
A containerized web app is breached. The image runs as root, includes a vulnerable package, and has an environment variable containing a cloud access key. Three weaknesses exist at once:
| Finding | Type | Mitigation |
|---|---|---|
| Vulnerable package | Software vulnerability | Rebuild with patched base image |
| Root container | Configuration weakness | Run as non-root, drop capabilities |
| Access key in env var | Secret exposure | Rotate key, move to secret manager or workload identity |
The best answer may include multiple controls. The exam often asks for the "best" or "most immediate" control, so consider urgency. If a key is already exposed, rotate it now. Then fix the build and secret handling process.
Supply Chain Weaknesses
| Weakness | Clue | Mitigation |
|---|---|---|
| Vulnerable dependency | SCA report flags library CVE | Update dependency and test |
| Typosquatting package | Package name almost matches popular library | Use trusted registries and package allow lists |
| Compromised update | Legitimate vendor channel delivers malicious code | Vendor validation, code signing, monitoring |
| Unpinned dependency | Build pulls latest unreviewed package | Pin versions and use lock files |
| Unverified artifact | Binary source cannot be trusted | Signature verification and hashes |
Common Traps
| Trap | Better exam reasoning |
|---|---|
| Treat a vulnerability scan as remediation | Scanning finds issues; remediation changes the risky condition |
| Patch a system that has no vendor patches | Use compensating controls while replacing or upgrading |
| Encrypt data but leave public access open | Encryption helps, but public exposure is still a configuration failure |
| Disable logs to improve performance | Logs are required for detection, investigation, and accountability |
Quick Drill
Name the weakness and the likely mitigation:
- A router still uses the vendor default password: default configuration; change credentials and apply hardening baseline.
- A payroll database accepts connections from any internet address: exposed service; restrict network access and require controlled admin path.
- A server uses an unsupported operating system: legacy/EOL system; replace or isolate with monitoring until replacement.
- A package-lock file is absent and builds pull unreviewed versions: supply chain weakness; pin and review dependencies.
Test Your Knowledge
A production object storage bucket containing internal reports allows anonymous public read access. What is the main weakness?
A
B
C
D
Test Your Knowledge
A vendor no longer releases security patches for a server operating system. Which mitigation is usually best long term?
A
B
C
D
Test Your KnowledgeMulti-Select
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