2.3 Types of vulnerabilities explained

Objective 2.3 is a catalogue of weakness types. Questions describe a flaw in a sentence or two and ask you to name it, or ask which weakness a situation represents. The trick is to identify where the weakness lives: in code, in configuration, in hardware, or in a process.

Application vulnerabilities live in code. Memory injection places malicious code inside the memory of a running, trusted process. A buffer overflow writes more data into a fixed-size memory area than it can hold, overwriting what sits next to it. A race condition happens when the result depends on timing; the time-of-check to time-of-use case is the classic one, where a file is checked and then swapped before it is used. A malicious update delivers attacker code through a legitimate update channel. Operating system vulnerabilities and web flaws follow: SQL injection lets input change a database query, and cross-site scripting lets input run as script in other users' browsers.

Hardware vulnerabilities include firmware flaws and devices that are end-of-life or legacy, which means no more security fixes. Virtualization adds VM escape, where code breaks out of a guest into the hypervisor, and resource reuse, where memory or storage from one tenant reaches another without being cleared. Cloud-specific issues are often customer-made, such as public storage or over-broad permissions.

Supply chain vulnerabilities come through service providers, hardware providers and software providers you depend on. Cryptographic vulnerabilities come from weak or broken algorithms such as MD5 or DES, short keys or poor key handling. Misconfiguration is one of the most common real-world weaknesses: default settings, open shares, unnecessary services. Mobile devices add side loading (installing apps from outside the official store) and jailbreaking or rooting (removing the manufacturer's restrictions). A zero-day is a vulnerability being exploited before a patch exists.

Knowing the category points to the fix. Code flaws are fixed in code, for example with bounds checking or parameterised queries. Configuration flaws are fixed by hardening. Hardware and end-of-life issues usually need replacement or compensating controls. Cryptographic weaknesses need a modern algorithm. When you see a question, name the category first; the right answer usually follows.