What Is a CVE? CVE, CVSS Scores and Zero-Days Explained for Developers

Security news is full of codes like CVE-2026-109618, scores like 9.2 and words like zero-day and KEV. If you have ever read a headline and wondered what any of it means for your own project, this guide is for you. We explain each term in plain words, using two real bugs from October 2026, PHP2Shell and Node2Shell, as examples. At the end you will have a simple routine to keep your projects safe.

💡 Quick answer: A CVE is a public ID number for one known security bug, such as CVE-2026-111497. A CVSS score rates how dangerous that bug is, from 0 to 10: 0.1–3.9 is low, 4.0–6.9 medium, 7.0–8.9 high and 9.0–10.0 critical. Developers use CVE IDs to check whether their software is affected and CVSS scores to decide what to fix first. Tools like npm audit, composer audit, pip-audit and GitHub Dependabot check your project's dependencies for known CVEs automatically.

💡 Who is this guide for? Students and beginner developers who want to understand security advisories and keep their projects updated, whatever language they use.

In this guide:

1. What Is a CVE?
2. How to Read a CVE ID
3. Who Gives Out CVE IDs?
4. What Is a CVSS Score?
5. Security Words You Will See Often
6. The Life of a CVE
7. Two Real Examples from October 2026
8. Why Your Project Has CVEs You Never Wrote
9. How to Check Your Projects for CVEs
10. A Simple Security Routine for Student Developers
11. Where to Follow Security News

---

What Is a CVE?

CVE stands for Common Vulnerabilities and Exposures. It is a public list of known security bugs, and each bug in it gets its own ID, like CVE-2026-109618.

The ID matters because it gives everyone the same name for the same bug. A PHP developer in India, a hosting company in Germany and a security scanner in the US can all say "CVE-2026-109618" and know they mean exactly the same problem. Without it, every company would describe the bug in its own words, and nobody could be sure they were talking about the same thing.

A CVE record is short. It usually includes:

• The ID
• A one-line description of the bug
• The affected products and versions
• Links to the official advisory and the fix

The CVE Program started in 1999 and is run by the MITRE Corporation, with support from the US Cybersecurity and Infrastructure Security Agency (CISA).

---

How to Read a CVE ID

Every CVE ID has three parts:

text
Copy
1CVE - 2026 - 109618
2 │     │       └── sequence number (4 or more digits)
3 │     └────────── year the ID was assigned or the bug was made public
4 └──────────────── always "CVE"

Two things surprise beginners:

1. The year is not always when the bug was found. It is usually the year the ID was reserved. A bug found in December can get the next year's ID if that is when it is reported.
2. A bigger number does not mean a worse bug. The sequence number is just a counter. CVE-2026-106070 (low severity) and CVE-2026-111497 (scored 9.2) were fixed in the same Node.js release.

---

Who Gives Out CVE IDs?

CVE IDs are given out by CNAs (CVE Numbering Authorities). These are organisations that the CVE Program allows to assign IDs, usually for their own products. Big software companies, open-source foundations, Linux distributions and platforms like GitHub are CNAs.

Other organisations then add more information. The NVD (National Vulnerability Database), run by NIST in the US, adds scores and product details. Security companies publish their own analysis, and vendors publish advisories with the fix.

When a CVE appears in your terminal or in a GitHub alert, it has usually passed through all of these steps.

---

What Is a CVSS Score?

CVSS stands for Common Vulnerability Scoring System. It gives each bug a score from 0.0 to 10.0 based on questions like:

• Can the attacker reach the bug over the internet?
• Do they need an account or a password?
• Does a user have to click something?
• What can they do after a successful attack: read data, change it, or crash the system?

The latest version, CVSS 4.0, was published by the organisation FIRST in November 2023. The score falls into one of five bands:

Figure 1: The CVSS severity bands. Both PHP2Shell and Node2Shell scored 9.2, in the critical band.

💡 Pro Tip: CVSS shows how bad a bug can be, not how risky it is for you. A critical bug in a feature you never use matters less than a medium bug in your login page. Always ask, "Does my app use the affected part?"

---

Security Words You Will See Often

The KEV catalog is especially useful. Tens of thousands of CVEs are published every year, and only a small share are ever used in real attacks. When a bug appears in KEV, it means attackers are actually using it, so it should go to the top of your list.

---

The Life of a CVE

Most serious bugs follow a similar path from discovery to fix:

Figure 2: The usual path of a security bug, from discovery to update.

1. Found. A researcher, a user or the project's own team finds the bug.
2. Reported privately. They tell the project's security team, not the public, so attackers do not learn about it first. This is called responsible or coordinated disclosure.
3. Fixed. The team builds and tests a fix, often with Linux distributions and big vendors, so patched packages are ready on day one.
4. Published. The project releases the fixed version and publishes an advisory, and the CVE record goes public.
5. Updated. Users install the fix. This is the step that depends on you.
6. Attacked. Once details are public, attackers try the bug on servers that have not updated. If this happens widely, the bug is added to KEV.

Sometimes the order breaks. In October 2026, details of PHP2Shell leaked online before the planned announcement, so the PHP team moved the release forward by a day.

---

Two Real Examples from October 2026

Both bugs follow the same pattern: critical score, no login needed, quick official fixes, and real attacks within days. In both cases, the people who stayed safe were the ones who updated quickly.

---

Why Your Project Has CVEs You Never Wrote

You might think, "My code is small, so it cannot have CVEs." But your project is much more than the code you wrote:

• Your dependencies. A typical React or Express project installs hundreds of npm packages. A bug in any of them is a bug in your app.
• Your runtime. PHP, Node.js and Python themselves can have bugs, as October 2026 showed.
• Bundled libraries. Many projects copy small libraries into their own code. The Brotli decoder behind Node2Shell was also inside Python packages, Bun, proxies like Envoy and PHP's Windows builds. Each copy needed its own update.
• Your operating system and Docker base images, which contain their own libraries.

This is why security is not only about writing careful code. It is also about keeping everything around your code up to date.

---

How to Check Your Projects for CVEs

Every major ecosystem has a free tool that compares your dependencies against known CVEs:

For npm, a typical session looks like this:

bash
Copy
1npm audit            # list known vulnerabilities
2npm audit fix        # update to safe versions where possible
3npm audit --omit=dev # only check packages used in production

On GitHub, open your repository's Settings, find the Dependabot options in the security section, and turn on Dependabot alerts and Dependabot security updates. Dependabot will then open pull requests that update unsafe packages for you.

💡 Pro Tip: These tools check your packages, not your runtime. npm audit could not warn anyone about Node2Shell, because the bug was inside Node.js itself. Check node -v, php -v and python --version against the latest security releases too.

---

A Simple Security Routine for Student Developers

You do not need to be a security expert to stay safe. A small, regular routine is enough:

Every week

• Merge Dependabot pull requests after a quick check that the build still passes.

Every month

• Run npm audit, composer audit or pip-audit on your active projects.
• Check that your runtime (Node.js, PHP or Python) is on a supported version with the latest patch.

When a big security release comes out

• Read the official advisory and check whether your version is affected.
• Update, restart your app and rebuild your Docker images.
• Check your deployments' build logs for the version actually used.

Always

• Never commit passwords or API keys. Keep them in .env files that are listed in .gitignore.
• Remove projects and servers you no longer use, because forgotten apps rarely get updates.

Our guide to updating Node.js on Windows, Mac and Linux has the exact commands for the runtime part of this routine.

---

Where to Follow Security News

Official sources are faster and more accurate than social media posts:

• Node.js: the Node.js vulnerability blog
• PHP: the news section on php.net
• Your packages: GitHub Security Advisories and Dependabot alerts
• Real attacks: the CISA KEV catalog
• Your operating system: your Linux distribution's security notices

You do not need to read every advisory. Follow the projects you actually use, and act quickly on anything that is critical, in KEV, or both.

---

Final Thoughts

A CVE is just a shared name for a security bug, and a CVSS score tells you how serious it can be. With those two ideas, security news becomes much easier to read: find the CVE, check if your version is affected, look at the score and the KEV status, and update. Tools like npm audit and Dependabot handle your packages, and a regular check of node -v or php -v handles your runtime.

Good security habits are one of the things that make a developer trustworthy in a team. If you want to build those habits on real projects with code reviews, you can do a free internship at MetaSkillGroup. Our online developer internship is open all year in six tracks, including backend development. It takes about 2 minutes to apply, and your first exam attempt is free.