Security+ SY0-801 Vulnerability Types and Attack Surfaces

A vulnerability is a weakness that a threat can exploit, and the attack surface is the sum of every place an attacker can try to exploit one: each reachable service, account, device, interface, data store and integration. Security+ objective 2.4 lists the kinds of weakness and exposure you must be able to name from a short description. Most items give you one or two observable facts (is a fix available? did IT approve this? can the setting be changed?) and ask which label fits.

The list is easier to hold if you group it by the question each entry answers:

Scope matters. Objective 2.4 is about what is weak or exposed. How an attack is delivered (email, Bluetooth, supply chain as a vector) belongs to objective 2.3, the evidence that an attack is happening belongs to 2.5, and AI-specific attacks such as prompt injection belong to 2.6. When a scenario describes a weakness and asks what kind it is, you are in 2.4.

These four are separated by one question: does a fix exist for this system, and has it been installed? Read the scenario for that fact before anything else.

• Zero-day: a flaw that is being exploited (or is known to attackers) before the vendor has released a fix. Defenders have had zero days to patch. The label describes the flaw's disclosure status, not the age of the system.
• Unpatched system: a fix exists and is available, but it has not been applied. The vulnerability is the gap between release and installation, which is why patch management targets that window.
• Unsupported product: the vendor has ended support (end of life / end of support), so no further fixes will be issued for that version. A fully updated unsupported system is not "unpatched": there is nothing left to install, and every flaw found from now on stays open until the system is upgraded, replaced or isolated. A vendor that fixes a flaw only in newer versions while stating older ones get no more updates is telling you the older version is unsupported.
• Obsolete system: technology so outdated that it cannot meet current security requirements, for example a discontinued platform that cannot run modern encryption or the endpoint protection agent. Obsolete is about capability, not patch status: a system can still be receiving fixes and still be obsolete if its design cannot do what current policy requires, such as a controller whose processor is too limited to support certificate-based authentication.

The status of one flaw changes over time. A flaw that attackers use in spring, before the vendor has shipped anything, is a zero-day; once the vendor publishes a fix in summer, every system that has not installed it becomes an unpatched system. When attacks started does not decide the label; whether a fix exists at the moment you are asked about does.

These four describe assets and accounts that security cannot see or control, and they are separated by two facts: was it approved, and is it under central management?

• Unmanaged system: a known, approved asset (it may even be listed in the asset inventory) that sits outside the central configuration, patching and monitoring tools, either because it was never onboarded or because it later dropped out, for example when someone uninstalls the management agent. Its security state is unknown and it is missing from compliance reports. Unmanaged is often the cause of unpatched: installing today's missing updates by hand clears the scan, but the gap reopens with the next release until the system is brought back under management.
• Rogue device: unauthorized hardware attached to the network, such as a home-grade Wi-Fi router someone connects to an office port, or a small travel router bridged to the wired network. A rogue access point or modem can give an outsider a path that bypasses the perimeter. Network access control (NAC) and wireless scans are how they are found.
• Shadow IT: technology or services that staff adopt without IT approval or knowledge, usually to get work done faster: a marketing team collecting customer sign-ups through an online form builder nobody reviewed, or staff syncing meeting notes to a personal note-taking app. IT cannot secure, back up or monitor what it does not know exists.
• Unmanaged/stale credentials: accounts and secrets nobody is actively governing. Stale credentials outlive their purpose (enabled accounts of people who left, unused service accounts, passwords never rotated). Unmanaged credentials live outside the central identity system, such as a shared login for a vendor support portal kept in a spreadsheet; because the identity system does not know the credential exists, disabling a departing user there does not revoke it, so offboarding misses it.

Defences follow from the definitions: an accurate asset inventory reconciled against management-tool enrollment (unmanaged), NAC and wireless surveys (rogue), discovery tools such as a cloud access security broker plus an easy approval path (shadow IT), and access reviews, automated deprovisioning and SSO-only sign-in (credentials).

Every listening port and running service is attack surface, so a system should run only the services its role needs. A database server that also runs a web-based admin console and an SNMP agent nobody uses has two extra listeners an attacker can probe. The lasting fix is to remove or disable what the role does not need, because a service that is not running has no flaws to exploit. Anything that only limits who can reach a running service, or makes it harder to spot, reduces exposure without removing it: the code still runs, its flaws are unchanged, and a later change can expose it again. Treat those as compensating steps when a service genuinely cannot be removed, and when something still depends on an unneeded service, change the dependency so the service can go.

Misconfiguration is sound, supported, fully patched software set up insecurely. Common forms include default credentials left in place, a cloud security group allowing administrative traffic from every address when only the admin network needed it, management interfaces exposed to the internet, permissive file or share permissions, sample pages and test endpoints left enabled after installation, and storage set to public. When the software is current and supported, look for the setting that allowed the attack before reaching for a rarer label.

Misconfiguration has a near twin in the code group. The test is whether the customer can change it:

Objective 2.4 names two application weaknesses and two code weaknesses. Each describes a different mistake, so classify by what goes wrong.

Race conditions: time-of-check to time-of-use (TOCTOU)

A race condition is a flaw where the result depends on the timing of events. The tested form is TOCTOU: a program checks a condition at the time of check (TOC) and acts on it at a later time of use (TOU), and an attacker changes the resource in between. Examples: a ticketing site confirms a seat is free and reserves it in a separate step, so two buyers who click at the same instant are both sold the same seat; or a driver validates a length value in shared memory and then reads it again to use it, and another process changes it between the two reads (a "double fetch"). The fix is to make check and use one atomic operation (a lock, a transaction, a conditional update, or opening the file and then checking the open handle). Controls that inspect what a request contains, or how often requests arrive, leave the gap between check and use in place; only atomicity removes it.

Malicious update

A malicious update is attacker code delivered through a trusted update channel. It happens when a vendor's build or update infrastructure is compromised, or when control of a trusted component passes to an attacker (a widely used code library whose maintainer's publishing account is hijacked, so the next release carries a backdoor). Because systems install the update as designed, the victims are fully up to date, which is what separates it from an unpatched system. A valid digital signature proves who published the update, not that its contents are safe. Mitigations include vendor risk assessment, staged rollouts, monitoring for changed behaviour after updates and controlling which plug-ins, packages and auto-updating components are allowed.

Hardcoded secrets

A hardcoded secret is a password, API key, token or private key embedded in source code, a compiled app or firmware. Anyone who obtains the code can extract it: a desktop client's installer can contain a database connection string with its password, and every unit of a network appliance can share the same embedded SSH private key. Store secrets in a secrets manager or vault, inject them at run time, scan code for secrets before it is committed, and rotate any secret that was ever embedded.

Unsafe exception handling

Exception handling is what code does when something fails. It is unsafe in two ways:

• Information leakage: showing users internal details such as framework versions, database error text or internal paths. Errors should be logged in detail on the server and answered with a generic message.
• Failing open: treating an error as success, for example an order pipeline that ships the order when the fraud-scoring call throws an exception. Security checks must fail closed: if a check cannot complete, the answer is deny.

The tell is the error path itself: the weakness appears only when something the code depends on fails, and the code's response to that failure decides the outcome.

Classify these by where the flaw lives. An OS-based vulnerability is a flaw in the operating system itself: the kernel, a built-in service or a system library. Because the component ships with the OS, exposure follows the OS version rather than the software installed on top of it. Typical impact is local privilege escalation (a standard user gains root or SYSTEM) or remote code execution through a built-in network service. Patching, removing unneeded OS features and least privilege reduce it.

A virtualization vulnerability is a flaw in the hypervisor or the isolation it provides between virtual machines. The main forms are:

• VM escape: code in a guest breaks out to the host, and from there can reach every other guest on it. In a multi-tenant cloud that means other customers' instances.
• Resource reuse: memory or disk blocks passed from one VM to another without being wiped, so a new tenant can read fragments of the previous tenant's data.
• Hypervisor and management-plane flaws: compromising the hypervisor or its console controls every VM it hosts.

The deciding detail is the boundary that failed. A kernel flaw inside one guest is OS-based; a flaw that lets one guest reach the host or another guest is virtualization. A well-configured tenant cannot fix a broken isolation boundary with settings, which is also why these are not misconfigurations. Keep hypervisors patched, restrict management interfaces, and separate sensitive workloads onto dedicated hosts where the risk justifies it.

A cryptographic vulnerability is a weakness in how cryptography is chosen or used that lets an attacker read, forge or crack protected data. A strong cipher name does not guarantee strong protection; the weakness is often around it. The main forms are:

• Weak or deprecated algorithms: MD5 and SHA-1 for integrity or signatures, DES and 3DES, RC4, and old protocol versions such as SSL and early TLS.
• Poor password storage: storing passwords with fast, unsalted hashes such as MD5. Without a salt, identical passwords produce identical hashes and precomputed (rainbow table) lookups work. Use a slow, salted password-hashing function (bcrypt, scrypt, Argon2 or PBKDF2).
• Weak randomness: keys, IVs or nonces from a predictable generator. Password-reset tokens generated from a pseudo-random function seeded with the current time can be recreated by an attacker who knows roughly when they were issued. Keys must come from a cryptographically secure random number generator.
• Short keys and poor key management: insufficient key length, keys reused across systems, never rotated, or stored next to the data they protect.

Call it cryptographic when the algorithm, the key strength or the randomness is the weak point. Two near twins: a key fixed in code is a hardcoded secret (the problem is where it is stored), and a sound key stolen from the system that issues sign-ins is an identity provider exposure (the problem is control of a trust anchor).

Wireless and low-powered communications are radio links anyone in range can listen to or try to join, and constrained devices often trade security for battery life. Smart-lighting controllers, wireless door locks, asset tags and other IoT radios frequently ship with shared factory network keys, weak or no encryption and limited ability to update. The exposure is the radio link itself, whether or not the devices were properly authorized: an attacker nearby can eavesdrop, inject commands or join the network with the factory key. Defences are unique keys at install, encryption enabled wherever the protocol supports it, segmenting these devices from business systems, and choosing devices that can receive updates. (Radio-based delivery methods such as Bluetooth, RF and NFC are threat vectors under objective 2.3.)

Mobile devices carry corporate data and rely on the platform's security model: app sandboxing, store review and OS updates. Weaknesses come from removing or bypassing that model:

Devices that no longer receive OS updates are a further mobile risk. Mobile device management (MDM) can detect jailbroken or rooted devices, block sideloading and enforce minimum OS versions before granting access to corporate data.

Some components are dangerous because of how much they can reach. An identity provider (IdP) authenticates users once and issues signed assertions or tokens that every federated application trusts. Whoever controls the IdP, or steals its token-signing key, can mint sign-ins for any user in any connected app, with no password or MFA needed, because the forged assertions are validly signed. Protect the IdP as a tier-zero system: hardened servers or a managed service, signing keys in an HSM, tightly limited administrators, and monitoring of signing-key and federation-trust changes. The reverse also holds: any credential created outside the IdP is invisible to it (see unmanaged credentials).

A large language model (LLM) application becomes an attack surface as soon as it is connected to data and actions. A support assistant connected to the ticketing system that can read customer records and issue refunds is a new path to those records and that refund function for anyone who can influence what the model reads or is asked. Its attack surface is everything it can read plus every action it can take, so limit both: least-privilege access to data sources, narrow tool and API permissions, human approval for consequential actions, and logging of what the model retrieved and did. The specific AI attacks (such as prompt injection, poisoning, jailbreaking and code execution) are objective 2.6; 2.4 asks you to recognise the LLM as the exposure.

Both entries are data made reachable by anyone, but the container differs. A public repository is a source code repository (for example on a code-hosting platform) that anyone can read. It leaks more than secrets: deployment templates and configuration files reveal server names, IP addressing and security-group design, which together form a reconnaissance map. Version control also keeps history: every earlier commit stays retrievable, so a secret removed from the latest version is still in the repository. Public repositories are scraped by automated tools almost immediately, so any token or key that was ever public must be treated as compromised. The first step is to revoke or rotate it, because that makes every copy already taken worthless; cleanup of the repository comes afterwards, along with secret scanning so it does not happen again.

Public object storage is a cloud bucket, container or blob store whose access policy allows anonymous access. Anonymous read publishes everything in it (database backups, documents). Anonymous write is just as serious: if the bucket that hosts the installer customers download accepts uploads from anyone, an attacker can replace it with a trojanized copy that every new customer then runs. Block public access by default at the account level, grant access to named identities only, and monitor for policy changes.