Security Vulnerabilities - How Flaws Get Exploited

About 2 min read

A vulnerability is a security flaw or weakness present in software or a system. Attackers exploit such vulnerabilities to carry out unauthorized access, data theft, denial of service, and more. Vulnerabilities arise from a variety of causes, including design flaws, implementation bugs, and misconfigurations. They are managed in public databases as CVEs (Common Vulnerabilities and Exposures), and the pace of vulnerability discovery is accelerating, with more than 30,000 new CVEs registered in 2024 alone.

What Must Be Decided and Verified After Discovery

A report that something has been found does not by itself determine what to address or in what order. A severity figure is a yardstick obtained by fixing the conditions so that items of differing natures can be lined up and compared; it is not a direct expression of how large the actual consequences would be. Even with the same figure, how easily the affected part can be reached differs depending on whether it sits where it can be reached from outside, where it can only be touched from within, or inside a feature that is not in use at all. Taking the figure as the sole criterion pushes items that rate low yet are easy to reach to the back of the line. Whether something has been fixed is likewise not settled by the record of the work. Even when a record shows the replacement finished, a process that keeps running may still hold the older content it loaded, and an environment copied from the same configuration may have received the change in only some of its instances; the record then reads as complete while the actual state persists. Placing the definition of completion on the number of items handled leaves what remains outside that count, and therefore out of view. And whether something is affected is not decided by a matching name. Even things called by the same name may or may not apply depending on the combination of which version it is and which settings it runs under, so counting targets by name alone both counts what does not apply and overlooks what does.

Historical Background

The history of vulnerability management dates back to the Morris Worm of 1988. That incident led to the establishment of CERT/CC (Computer Emergency Response Team), marking the beginning of organized vulnerability management. In 1999, MITRE created the CVE system, establishing a mechanism for assigning a unique identification number to each vulnerability. The 2021 Log4Shell (CVE-2021-44228) carried the maximum CVSS score of 10.0, affected a wide range of Java libraries, and forced organizations around the world into emergency response. This incident once again highlighted the importance of dependency management in open-source software.

Classification of Vulnerabilities

CVSS (Common Vulnerability Scoring System) is an international standard that rates the severity of vulnerabilities on a score from 0.0 to 10.0. Vulnerabilities come in many types, including buffer overflows, SQL injection, XSS, and privilege escalation. A zero-day vulnerability is a particularly dangerous one that is exploited before a fix patch is made available.

Countermeasures as a User

A common misconception is that "as long as I have security software installed, vulnerabilities are not a problem." Security software detects known malware, but it does not fix the vulnerabilities themselves. The basic measure is to promptly apply updates to your OS and applications to fix known vulnerabilities. To prepare for the risk that a vulnerability could be exploited to leak your passwords, it is important to set a unique random password for each service.