Explain various types of vulnerabilities

A vulnerability is a weakness that can be exploited by a threat actor. This objective covers the categories of vulnerabilities you’ll encounter across applications, systems, hardware, and humans.

Application Vulnerabilities

Memory Injection

Injecting malicious code into a running process’s memory space.

• DLL injection: Forcing a process to load an attacker-controlled library
• Process hollowing: Starting a legitimate process, replacing its code in memory with malware
• Used for privilege escalation and defense evasion

Buffer Overflow

Writing data beyond the boundaries of allocated memory, corrupting adjacent data.

• Stack overflow: Overwriting the return address on the stack to redirect execution
• Heap overflow: Corrupting dynamically allocated memory structures
• Integer overflow: Arithmetic that wraps around, producing an unexpectedly small buffer
• Prevention: Input validation, bounds checking, ASLR, DEP/NX, stack canaries

Race Conditions

When the outcome depends on the timing of events, and an attacker can manipulate that timing.

• TOCTOU (Time of Check, Time of Use): Exploit the gap between a security check and the action it authorizes
• Example: File permission check passes, attacker swaps the file before it’s read
• Prevention: Atomic operations, proper locking mechanisms

Injection Attacks

Untrusted input interpreted as code or commands.

• SQL injection: Manipulating database queries through user input
• Command injection: Executing OS commands through application inputs
• LDAP injection: Manipulating directory service queries
• XML injection / XXE: Exploiting XML parsers to read files, perform SSRF
• Prevention: Parameterized queries, input validation, output encoding. Never trust user input.

CSRF (Cross-Site Request Forgery)

Tricks a user’s browser into making an unintended request to a site where they’re already authenticated.

• Attacker crafts a page/link that triggers an action on the target site (transfer funds, change email, modify settings)
• The user’s browser sends the request with valid session cookies — the server sees it as legitimate
• Does not steal data — it performs actions on behalf of the victim
• Prevention: Anti-CSRF tokens (unique per-session token in each form), SameSite cookie attribute, requiring re-authentication for sensitive actions

Exam distinction: XSS executes code in the user’s browser. CSRF makes the user’s browser perform actions on a target site. Different attacks, different defenses.

SSRF (Server-Side Request Forgery)

Tricks the server into making requests to unintended destinations.

• Attacker supplies a URL that the server fetches — but the URL points to internal resources (metadata endpoints, internal APIs, localhost services)
• Classic cloud exploit: http://169.254.169.254/latest/meta-data/ on AWS retrieves instance credentials
• Can bypass firewall rules because the request originates from the trusted server, not the attacker
• Prevention: Whitelist allowed destinations, block internal IP ranges, disable unnecessary URL fetching, use metadata service v2 (IMDSv2) on AWS

Insecure Deserialization

Exploiting the process of converting serialized data back into objects.

• Applications serialize objects for storage or transmission (JSON, XML, binary formats like Java’s ObjectInputStream)
• If the application deserializes untrusted data without validation, an attacker can craft a malicious serialized object
• Can lead to remote code execution, privilege escalation, or denial of service
• Prevention: Don’t deserialize untrusted data. If you must, use allowlists of permitted classes, integrity checks on serialized data, and isolated deserialization environments.

XSS (Cross-Site Scripting)

Injecting client-side scripts into web pages viewed by other users.

• Reflected: Malicious script in URL parameter, reflected back in the response
• Stored: Script saved to the server (database, comment field), executed for all visitors
• DOM-based: Script manipulates the page’s DOM without server involvement
• Prevention: Output encoding, Content Security Policy (CSP), input sanitization

Privilege Escalation

Gaining higher permissions than authorized.

• Vertical: Normal user → admin
• Horizontal: User A accesses User B’s resources
• Exploited through misconfigurations, vulnerable services, kernel exploits

Mobile Vulnerabilities

CompTIA expects knowledge of mobile-specific attack vectors. This wasn’t addressed in 4.1 (hardening) — this is the vulnerability perspective.

Jailbreaking / Rooting

• Removing manufacturer/carrier restrictions to gain full OS access
• Security impact: Disables app sandboxing, bypasses code signing, allows installation of unsigned apps, removes security updates
• Jailbroken/rooted devices should be prohibited from accessing corporate resources (MDM jailbreak detection)

Insecure Data Storage

• Apps storing credentials, tokens, or sensitive data in plaintext on the device
• Android: SharedPreferences in plaintext, unencrypted SQLite databases, data on external storage (world-readable)
• iOS: Data not stored in Keychain, plist files with sensitive data, unencrypted Core Data
• Prevention: Use platform-provided secure storage (Android Keystore, iOS Keychain), encrypt at rest

Inter-Process Communication (IPC) Vulnerabilities

• Android Intents: Implicit intents can be intercepted by malicious apps. Exported activities/services accessible to any app on the device.
• iOS URL Schemes: Custom URL schemes can be hijacked by malicious apps registering the same scheme.
• Content Providers: Improperly exported content providers expose application data to other apps.
• Prevention: Use explicit intents, don’t export components unnecessarily, validate all IPC input

App Sandboxing Bypass

• Each mobile app runs in its own sandbox with limited access to other apps and system resources
• Malware that escapes the sandbox can access data from other apps, intercept communications, or persist across app removals
• Sandbox escapes often chain with kernel vulnerabilities for full device compromise
• This is the technique Pegasus and similar state-level spyware use

Sideloading

• Installing apps from outside the official app store
• Bypasses the (limited) security review process of app stores
• Common attack vector: fake “enterprise” apps, trojanized versions of popular apps
• Android: “Install from unknown sources” setting. iOS: Enterprise developer certificates, AltStore.

API Vulnerabilities

Dedicated coverage because APIs are an increasingly dominant attack surface — and CompTIA tests it.

Common API Vulnerabilities

Vulnerability	Description
Broken authentication	Missing or weak API key validation, JWT signature not verified, no rate limiting on auth endpoints
Broken object-level authorization (BOLA)	Changing an ID parameter to access another user’s data (/api/users/123 → /api/users/456)
Excessive data exposure	API returns more data than the client needs — relies on client to filter
Lack of rate limiting	No throttling enables brute force, credential stuffing, and denial of service
Mass assignment	API accepts fields the client shouldn’t control ({"role": "admin"} in a profile update)
Injection	SQL, NoSQL, command injection through API parameters
Improper asset management	Old API versions still accessible, undocumented endpoints, shadow APIs

Prevention

• Authentication on every endpoint (not just the frontend)
• Authorization checks at the object level, not just the endpoint level
• Input validation and output filtering
• Rate limiting and throttling
• API versioning with deprecation of old versions
• API gateway for centralized policy enforcement

Supply Chain Vulnerabilities

Covered in 2.2 from the threat actor perspective — here from the vulnerability perspective, which is how CompTIA tests it in this objective.

Software Supply Chain

• Dependency vulnerabilities: Your application inherits vulnerabilities from every library it uses. SCA tools (Syft, Grype, Snyk, Dependabot) scan for known CVEs in dependencies.
• Typosquatting: Malicious packages with names similar to popular libraries (colourama vs colorama)
• Compromised maintainers: Legitimate package maintainer account compromised, malicious update pushed to all downstream users
• Build system compromise: Attacker compromises CI/CD pipeline to inject code during build (SolarWinds pattern)

Hardware Supply Chain

• Counterfeit components: Fake chips with modified firmware or backdoors
• Interdiction: Hardware intercepted during shipping, modified, then forwarded to the target
• Firmware implants: Malicious code embedded at the factory or distribution level

Managed Service Provider (MSP) Risk

• MSPs have privileged access to multiple client environments
• Compromise of one MSP = potential compromise of all their clients (Kaseya VSA attack)
• Vet MSP security practices, require MFA, limit access scope

Mitigation

• Software Bill of Materials (SBOM) — inventory of all components in your software
• Vendor security assessments and questionnaires
• Code signing and signature verification on all updates
• Diversity of suppliers where practical (don’t single-source critical components)
• Monitor for known compromises in your supply chain (CISA advisories, vendor notifications)

Operating System Vulnerabilities

Unpatched Systems

Known vulnerabilities with available fixes that haven’t been applied.

• Most breaches exploit known CVEs, not zero-days
• Patch management process failures = vulnerability accumulation

Misconfigurations

• Default settings left unchanged (default passwords, unnecessary services enabled)
• Overly permissive file/directory permissions
• Debug mode or verbose error messages exposed in production
• Open network shares with sensitive data

End-of-Life (EOL) Software

Operating systems and applications no longer receiving security updates.

• Windows Server 2012, Windows 7, older Linux kernels
• Any vulnerability discovered after EOL will never be patched
• Compensating controls required: Network isolation, enhanced monitoring, application whitelisting

Hardware Vulnerabilities

Firmware

Software embedded in hardware that operates below the OS layer.

• Firmware vulnerabilities persist across OS reinstalls
• BIOS/UEFI attacks can survive disk wipes
• Supply chain firmware implants are difficult to detect

Side-Channel Attacks

Extracting information from the physical implementation of a system.

• Timing attacks: Measuring operation timing to infer secret values
• Power analysis: Monitoring power consumption patterns during cryptographic operations
• Spectre/Meltdown: CPU speculative execution leaking data across security boundaries
• Electromagnetic emanations: Capturing signals from hardware components

Hardware Root of Trust

• TPM (Trusted Platform Module) provides a hardware-based security anchor
• Secure boot chain: each component verifies the next before loading
• If hardware root of trust is compromised, nothing above it can be trusted

Virtualization Vulnerabilities

VM Escape

Breaking out of a virtual machine to access the hypervisor or other VMs on the same host.

• Critical because it breaks the isolation that virtualization promises
• Rare but devastating — access to the hypervisor means access to everything

Resource Reuse

• Memory not properly cleared between VM allocations
• Potential for data leakage between tenants in cloud environments

VM Sprawl

• Unmanaged proliferation of virtual machines
• Forgotten VMs running outdated, unpatched software = shadow attack surface

Cloud-Specific Vulnerabilities

Misconfigured Cloud Storage

• S3 buckets, Azure Blobs, GCS buckets exposed to public access
• One of the most common sources of data breaches in cloud environments
• Exam tip: Cloud misconfiguration questions are almost guaranteed

Insecure APIs

• Cloud services managed via API — misconfigurations in API permissions have outsized impact
• Overly permissive IAM roles, exposed API keys, lack of rate limiting

Shared Responsibility Model

• Cloud provider secures the infrastructure; customer secures their configuration, data, and access
• Misunderstanding this boundary is itself a vulnerability

Cryptographic Vulnerabilities

Weak/Deprecated Algorithms

• MD5, SHA-1, DES, RC4 — known broken, should not be used
• Exam focus: Know which algorithms are deprecated and why

Improper Implementation

• Using ECB mode (patterns preserved in ciphertext)
• Hardcoded encryption keys in source code
• Insufficient key length (RSA < 2048, AES < 128)

Certificate Issues

• Expired certificates breaking trust chain
• Self-signed certificates in production
• Wildcard certificate compromise = all subdomains compromised

Zero-Day Vulnerabilities

• Vulnerability unknown to the vendor with no available patch
• Highest value to attackers (nation-states stockpile zero-days)
• Defense: assume-breach posture, behavior-based detection, network segmentation
• Once disclosed and patched, it becomes a known vulnerability (but many orgs still don’t patch promptly)

Human Vulnerabilities

Social Engineering Susceptibility

• Lack of security awareness training
• Authority bias (blindly following requests from “executives”)
• Urgency manipulation (“your account will be locked in 30 minutes”)

Misconfiguration by Operators

• Human error in system configuration
• Copy/paste mistakes in firewall rules, IAM policies
• “Temporary” exceptions that become permanent

Offensive Context

Vulnerability assessment from the offensive side is about prioritization, not just enumeration. An attacker doesn’t care about your CVSS 10.0 vulnerability on an air-gapped system — they care about the CVSS 7.0 vulnerability on your internet-facing VPN concentrator. Thinking about vulnerability exploitation chains (combine a medium-severity SQLi with a medium-severity privilege escalation for a critical-impact breach) is what separates checkbox scanning from real security assessment.