CVEs and vulnerable dependencies: how to know if your application is exposed

Every day, new security flaws are published in software you probably use: your web framework, your web server, a transitive npm library you have never heard of. More than 40,000 vulnerabilities received a CVE identifier in 2024 alone.

The question is not whether one of your dependencies will have a flaw, but when, and whether you will know in time.

What is a CVE?

A CVE (Common Vulnerabilities and Exposures) is a unique identifier assigned to a public flaw, for example CVE-2025-55182. It comes with:

• a description of the flaw;
• the affected versions of the software;
• the fixed version;
• a severity score (CVSS), from low to critical.

As soon as a CVE is published, everyone can read it, including attackers, who automate the search for vulnerable servers.

A recent example: React2Shell

In December 2025, CVE-2025-55182, nicknamed React2Shell, was published in React Server Components, used notably by Next.js. It allowed remote code execution on the server with a single request.

Applications patched quickly were never at risk. Those left on a vulnerable version were scanned and attacked in the following days. The difference was not the team's skill: it was knowing that the installed version was vulnerable.

The three levels to check

1. System packages

On Debian or Ubuntu, list pending security updates:

sudo apt-get update && apt list --upgradable 2>/dev/null | grep -i security

Automatic updates cover this level, provided they are enabled and working.

2. Manually installed software

A runtime installed outside the package manager (Node.js through a version manager, a downloaded binary) is not updated automatically. Check its version against the vendor's security advisories.

3. Application dependencies

This is the most overlooked level. Your lock files (package-lock.json, requirements.txt, composer.lock, Gemfile.lock) describe exactly what runs in production.

Package managers offer an audit:

npm audit --omit=dev
pip-audit -r requirements.txt
composer audit

The catch: these commands run on the developer's machine, whenever they think of it. Production can run for months on a version that became vulnerable after deployment.

Prioritize: not all flaws are equal

A list of 80 vulnerabilities helps nobody. To prioritize:

1. Critical or high severity first.
2. Exposure: a flaw in the Internet-facing web framework comes before a flaw in a development tool.
3. Fix available: if the fixed version exists, the update is often quick.
4. Active exploitation: a flaw already exploited in the wild is an emergency.

Automate the watch

Best practice is to compare every day the versions actually installed on the server with a public database such as OSV or the NVD, and to be warned only when a flaw affects your server, with the fixed version to install.

Frequently asked questions

Does my hosting provider update my dependencies?

No. At best the provider manages the operating system in a managed offering. Your application's dependencies remain your responsibility.

Is a development dependency a risk?

Much less, if it is not deployed to production. Focus on what actually runs on the server.

Should I update as soon as a CVE is published?

For a critical severity on an exposed component, yes, within hours or days. For the rest, group updates in a regular cycle.

FondateurMode compares the versions of your system packages and npm, Python, PHP and Ruby dependencies with public vulnerability databases every day, and tells you the fixed version. See how it works.