48,000 CVEs and Counting: Why Understanding Vulnerabilities Has Never Been More Critical

Nehan Wijayagunarathna

16 Jan 2026 — 8 min read

A little while ago, I was playing a Hack the Box machine, and I got stuck completely. Couldn’t move forward at all. Luckily, it was a retired machine, which means walkthroughs were available ( normally, if HTB machines are live, according to their policies, players can’t publish any walkthroughs ). So when I first looked it up, the noticeable thing I saw was: CVE-NNNN-NNNN.

When I searched for that, I got a massive list of CVE entities. Why are there so many vulnerabilities (CVEs) out there?

SO, What is a CVE ?

Simply put, CVE stands for Common Vulnerability and Exposure. It's a standardized naming system maintained by MITRE Corporation. When someone, whether an individual researcher or an organization, discovers a security flaw, a general way to report it through the CVE system.

Think of it like this: CVE isn’t exploit code itself, it’s not malware, and it’s not a patch. It’s just a reference number, a unique identifier saying this specific vulnerability exists. These vulnerabilities can exist in software, hardware, or even firmware. The CVE system gives everyone a common language to talk about them.

Why are there so many CVEs?

Ok, here’s the thing. We live in a world filled with countless software applications, operating systems, hardware devices, and network configurations. Each of these has layers upon layers of code, components, and settings. While developing, they can make mistakes. Small errors slip through, and boom, vulnerabilities are born.

When CVEs are discovered, patches and updates are released to fix them. But here’s the catch: users don’t always update their products. Is there old software sitting on your computer? It might still have vulnerabilities that were patched years ago. Having a lot of CVEs doesn’t necessarily mean security is getting worse. In fact, it can mean the opposite: more vulnerabilities are being found and reported, which helps to fix those, but only if we use this information correctly.

What Kinds of Things Get CVEs?

Pretty much anything in the tech world can have vulnerabilities. We’re talking about software applications, web apps, operating systems, hardware, firmware, and even network configurations. If it runs code or handles data, it can potentially have a flaw that gets a CVE assigned to it. Let’s look at some real-world examples to make this clear:

CVE-2025–55182 (React Vulnerability)

CVE-2025–55182, named “React2shell”, is a critical remote code execution (RCE) vulnerability in React Server Components (RSC) and related packages. It was publicly disclosed on December 3, 2025, and carries the maximum severity score of 10.0 on the CVSS scale. In other words, it’s extremely dangerous and highly exploitable.

CVE-2025–32463 (Sudo Vulnerability)

CVE-2025–32463 is a critical local privilege escalation vulnerability affecting sudo versions 1.9.14 through 1.9.17. It allows an unprivileged local user to gain full root access on a system by abusing Sudo’s — chroot (-R) option. That’s the kind of vulnerability that keeps system administrators up at night.

CVE-2025–7027 (UEFI Firmware Vulnerability)

CVE-2025–7027 affects the Software System Management Interrupt (SMI) handler in UEFI firmware, particularly on certain Gigabyte motherboards. It stems from improper validation of pointers in the SwSmiInputValue 0xB2 handler. A local attacker with elevated privileges can manipulate read and write pointer values, leading to arbitrary memory writes in system Management RAM (SMRAM). This is a low-level, firmware-based attack vector.

CVE-2024–43451 (Windows NTLMv2 Hash Disclosure)

CVE-2024–43451 is a spoofing vulnerability in Microsoft Windows that allows an attacker to trick a target system into disclosing the user’s NTLMv2 authentication hash. This can lead to credential theft and impersonation attacks, essentially, someone pretending to be you on a network.

Let’s Get into the Real Thing

When assessing a system's security, the first thing to check is the software component versions. Older versions without updates can create serious loopholes.

version of the system is mentioned inside the source code

If you find an older version of any software, you might search for something like “<software name> CVE vulnerabilities”. And you will get something related cves. For example, when I search for the “CrushFTP v=11.w.657 CVE vulnerability”, I get CVE-2025–31161.

But wait: what do those numbers actually mean? The “2025” indicates the year of vulnerability was reported. The “31161” is essentially a serial number. Each CVE can be uniquely identified by this year-serial number combination. That’s how the CVE catalogue stays organized.

CVSS Scores

When you dig into a CVE, you’ll encounter something called a CVSS score (Common Vulnerability Scoring System). Think of it as a severity rating from 0 to 10:

None:0.0

Low:0.1–3.0

Medium:4.0–6.9

High:7.0–8.9

Critical:9.0–10.0

In our case, CVE-2025–31161 scored a 9.8, which is a critical-level vulnerability. It needed to be patched immediately.

Vulnerability vs Exposure (Yes, There’s a Difference)

Okay, let’s break this down because people often confuse these two terms.

A vulnerability is a flaw, bug, or weakness in code, configuration, or process. For example, unpatched software or a weak password policy.

An Exposure is the condition that makes the flaw accessible to an attacker. For instance, if your vulnerable software is internet-facing or a particular port is left open.

In other words, a vulnerability is the weakness itself; an exposure is what allows someone to actually exploit it.

A Closer Look at CVE-2025–31161

Let’s examine this vulnerability more closely. The flaw exists in the AWS4_HMAC authorization method of the HTTP component in CrushFTP’s server. A race condition in the login_user_pass() function allows authentication without password verification.

The vulnerability can be established by sending a malformed AWS4-HMAC header containing only a username and a forward slash. This triggers successful authentication but fails to complete session cleanup due to an index-out-of-bounds error. The results? An attacker can authenticate as any known user, including the default administrator account “crushadmin”.

Proof of Concept (PoC) — The Real Deal

Now let’s talk about something called a Proof of Concept, or PoC for short. This is a real-world demonstration of how a CVE actually works in practice. It’s a way to verify that a particular vulnerability is feasible and exploitable just theoretical.

A PoC is typically code, a script, or a series of actions that, when combined with the right conditions, demonstrate how to gain access through the vulnerability. “But isn’t that dangerous ?” you might think. Actually, PoCs are incredibly useful:

Validate vulnerability: They provide concrete proof to developers and the security team that a reported flaw is real and exploitable, not just a theoretical concern.
Facilitate communication: A working demonstration often explains complex security issues more effectively than a lengthy written report.
Drive resolution: In research and development, PoCs prove the feasibility of new security measures and motivate faster fixes.

PoCs are used across many areas: penetration testing, CTF competitions, academic research, and more. But here’s the critical point: the strength of a PoC lies in its ability to reveal weakness. Using PoC on systems you don’t own or don’t have explicit written permission to test is illegal and unethical.

Ethical hackers and security professionals always operate within the law (such as the Computer Fraud and Abuse Act in the US) and ensure all activities are authorised and documented. The goal of an ethical PoC is to improve security, not to cause damage or gain unauthorised access.

The Real-World Risk

Let’s see how PoC works in the real world: While those resources are available on the internet, anyone can access them. Some websites rely on ftp services from platforms like CrushFTP, which can be risky. Without proper mitigation, websites can be hacked, data can leak, or various cyber attacks can become possible.

This is why there should be a clear process: find vulnerabilities, create PoC files to validate them, and develop mitigations to address those vulnerabilities.

Mitigations

Since PoC files and related information are available online, security engineers work diligently to find solutions. This involves patching, updating systems, and releasing fixes for users to apply. Configuration changes, monitoring for security issues; it’s an ongoing process.

Why does this matter? because in this tech world, most critical systems depend on software, like hospitals, schools, and many more. Without proper mitigation, the consequences can be severe.

For CVE-2025–31161 specifically, CrushFTP has released patches to address the vulnerability. Users should immediately upgrade to version 10.8.4+ (for v10) or 11.3.1+ (for v11). If immediate patching isn’t possible, enabling the DMZ proxy instance of CrushFTP serves as a temporary mitigation, since the exploit doesn’t work with this configuration enabled.

The vulnerability has been added to CISA’s Known Exploited Vulnerabilities Catalog with a remediation deadline of April 28, 2025.

Who needs to Care About CVEs?

CVEs are crucial not just in cybersecurity, but also in software development and the whole IT industry. Here’s who really needs to stay on top of these CVEs:

SOC Teams: Security Operation Center teams are perhaps the most dependent on CVE updates. When new vulnerabilities are published, they need to update their monitoring system to be ready for potential attacks. CVE data helps prioritise responses and investigations, ensuring teams can act quickly to minimize risk.

Vulnerability Scanners: Vulnerability scanners are used to test and find the weaknesses in systems. If these scanners aren’t updated with newly discovered CVEs, vulnerabilities can remain undetected, living inside systems without the awareness of developers or penetration testers. Attackers, however, might find and exploit these hidden flaws.

Developers: If developers aren’t aware of security vulnerabilities, they might continue building on top of vulnerable systems. When these systems go live, the accumulated security debt can have serious consequences.

At the End

People across the IT industry need at least a basic understanding of CVEs and related concepts. With this knowledge, we can minimise attacks and reduce the risks. And as learners, we should use these tools responsibly, studying them to improve security, not to cause harm.