CVSS Scoring Explained for Developers in 2026: v3.1 vs v4.0, EPSS & When to Actually PatchLe Score CVSS Expliqué aux Développeurs en 2026 : v3.1 vs v4.0, EPSS & Quand Vraiment Patcher

You open your terminal, run a dependency audit, and see it: CVSS 9.8 — Critical. Your heart rate spikes. You drop everything to investigate. Thirty minutes later, you realize the vulnerable function is never called in your code. Meanwhile, that CVSS 6.5 you've been ignoring for weeks? It's in your authentication middleware, and it's being actively exploited in the wild.

Vous ouvrez votre terminal, lancez un audit de dépendances et vous voyez : CVSS 9.8 — Critique. Votre rythme cardiaque s’accélère. Vous lâchez tout pour investiguer. Trente minutes plus tard, vous réalisez que la fonction vulnérable n’est jamais appelée dans votre code. Pendant ce temps, ce CVSS 6.5 que vous ignorez depuis des semaines ? Il est dans votre middleware d’authentification, et il est activement exploité en production.

This is the CVSS paradox that every developer faces in 2026. With 43,002 CVEs published in 2025 alone and a record-breaking April 2026 Patch Tuesday from Microsoft (163 new CVEs in one release), understanding vulnerability scores isn't optional anymore — it's a survival skill. This guide breaks down how CVSS actually works, what changed in v4.0, why scores can be misleading, and how to build a prioritization strategy that doesn't waste your time.

C’est le paradoxe du CVSS auquel chaque développeur fait face en 2026. Avec 43 002 CVE publiées rien qu’en 2025 et un Patch Tuesday record de Microsoft en avril 2026 (163 nouvelles CVE en une seule release), comprendre les scores de vulnérabilité n’est plus optionnel — c’est une compétence de survie. Ce guide détaille comment le CVSS fonctionne réellement, ce qui a changé dans la v4.0, pourquoi les scores peuvent être trompeurs, et comment construire une stratégie de priorisation qui ne gaspille pas votre temps.

What Is CVSS? The 60-Second Version

Qu’est-ce que le CVSS ? La version en 60 secondes

CVSS stands for Common Vulnerability Scoring System. Maintained by FIRST.org, it's the global standard for rating vulnerability severity on a 0 to 10 scale. When you see a CVE like CVE-2025-55182 labeled "CVSS 10.0 Critical," that score comes from CVSS.

CVSS signifie Common Vulnerability Scoring System. Maintenu par FIRST.org, c’est le standard mondial pour évaluer la sévérité des vulnérabilités sur une échelle de 0 à 10. Quand vous voyez une CVE comme CVE-2025-55182 étiquetée « CVSS 10.0 Critical », ce score vient du CVSS.

Here's what the severity brackets mean in practice:

Voici ce que les tranches de sévérité signifient en pratique :

Score Range  │ Label     │ Developer Action
─────────────┼───────────┼──────────────────────────────────
  9.0 – 10.0 │ Critical  │ Patch immediately — drop everything
  7.0 –  8.9 │ High      │ Patch this sprint — don't let it slip
  4.0 –  6.9 │ Medium    │ Schedule it — next maintenance window
  0.1 –  3.9 │ Low       │ Track it — fix when convenient
       0.0   │ None      │ Informational only

Plage Score  │ Niveau    │ Action Développeur
─────────────┼───────────┼──────────────────────────────────
  9.0 – 10.0 │ Critique  │ Patcher immédiatement — tout arrêter
  7.0 –  8.9 │ Haut      │ Patcher ce sprint — ne pas laisser glisser
  4.0 –  6.9 │ Moyen     │ Planifier — prochaine fenêtre de maintenance
  0.1 –  3.9 │ Bas       │ Suivre — corriger quand c'est possible
       0.0   │ Aucun     │ Informatif uniquement

But here's the critical insight that most developers miss: CVSS measures how bad a vulnerability could be — not how likely it is to be exploited, and not how bad it is in your specific environment. FIRST itself explicitly states that base scores alone should not be used for prioritization.

Mais voici l’insight critique que la plupart des développeurs ratent : le CVSS mesure à quel point une vulnérabilité pourrait être grave — pas la probabilité qu’elle soit exploitée, ni sa gravité dans votre environnement spécifique. FIRST lui-même déclare explicitement que les scores de base seuls ne devraient pas être utilisés pour la priorisation.

How CVSS Scores Are Calculated: The Base Metrics

Comment les Scores CVSS Sont Calculés : Les Métriques de Base

A CVSS base score is computed from two groups of metrics: Exploitability (how easy is it to exploit?) and Impact (what damage can it cause?). Here's each metric explained with real examples:

Un score de base CVSS est calculé à partir de deux groupes de métriques : Exploitabilité (est-ce facile à exploiter ?) et Impact (quels dégâts peut-il causer ?). Voici chaque métrique expliquée avec des exemples réels :

Exploitability Metrics

Métriques d’Exploitabilité

Attack Vector (AV) — How does the attacker reach the vulnerability?

Vecteur d’Attaque (AV) — Comment l’attaquant atteint-il la vulnérabilité ?

Network (N)  → Remote, over the internet. Most dangerous.
               Example: CVE-2025-55182 (Next.js React2Shell) — any HTTP request
Adjacent (A) → Same network segment (Wi-Fi, LAN).
               Example: ARP poisoning attacks
Local (L)    → Attacker needs system access (SSH, local user).
               Example: privilege escalation bugs
Physical (P) → Requires physical device access.
               Example: USB firmware attacks

Network (N)  → À distance, via Internet. Le plus dangereux.
               Exemple : CVE-2025-55182 (Next.js React2Shell) — toute requête HTTP
Adjacent (A) → Même segment réseau (Wi-Fi, LAN).
               Exemple : attaques ARP poisoning
Local (L)    → L'attaquant doit avoir un accès système (SSH, utilisateur local).
               Exemple : bugs d'escalade de privilèges
Physical (P) → Accès physique nécessaire.
               Exemple : attaques firmware USB

Attack Complexity (AC) — Does the exploit require special conditions? Low means the exploit works reliably every time. High means specific conditions must be met (race condition, non-default config, etc.).

Complexité d’Attaque (AC) — L’exploit nécessite-t-il des conditions spéciales ? Low signifie que l’exploit fonctionne de manière fiable à chaque fois. High signifie que des conditions spécifiques doivent être réunies (race condition, config non standard, etc.).

Privileges Required (PR) — What access level does the attacker need? None (unauthenticated), Low (basic user), or High (admin/root).

Privilèges Requis (PR) — Quel niveau d’accès l’attaquant a-t-il besoin ? None (non authentifié), Low (utilisateur basique), ou High (admin/root).

User Interaction (UI) — Does someone need to click a link or open a file? None means fully automated. Required means a user action triggers it (clicking a phishing link, opening a crafted file).

Interaction Utilisateur (UI) — Quelqu’un doit-il cliquer sur un lien ou ouvrir un fichier ? None signifie totalement automatisé. Required signifie qu’une action utilisateur le déclenche (cliquer un lien de phishing, ouvrir un fichier piégé).

Impact Metrics

Métriques d’Impact

Impact is measured across the classic CIA triad — Confidentiality, Integrity, and Availability — each rated None, Low, or High. A vulnerability that lets an attacker read all database records (High Confidentiality impact) but can't modify or delete anything (None Integrity, None Availability) scores differently from one that crashes your server (High Availability only).

L’impact est mesuré sur la triade classique CIA — Confidentialité, Intégrité, et Disponibilité — chacune notée None, Low, ou High. Une vulnérabilité qui permet à un attaquant de lire tous les enregistrements de la base (impact Confidentialité High) mais ne peut rien modifier ni supprimer (Intégrité None, Disponibilité None) se note différemment de celle qui plante votre serveur (Disponibilité High uniquement).

Let's decode a real CVSS vector string:

Décodons un vrai vecteur CVSS :

CVE-2025-55182 (Next.js React2Shell)
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:H → Score: 10.0

AV:N  → Network — exploitable from anywhere on the internet
AC:L  → Low complexity — no special conditions needed
PR:N  → No privileges — unauthenticated
UI:N  → No user interaction — fully automated
S:C   → Scope Changed — impacts beyond the vulnerable component
C:H   → Full confidentiality loss
I:H   → Full integrity loss
A:H   → Full availability loss

Every metric at maximum severity = a perfect 10.0. In practice, most vulnerabilities you encounter in dependency audits will score between 5.0 and 8.0 — the average across all 2025 CVEs was 6.60 with a median of 6.50.

Chaque métrique à sa sévérité maximale = un parfait 10.0. En pratique, la plupart des vulnérabilités que vous rencontrerez dans les audits de dépendances auront un score entre 5.0 et 8.0 — la moyenne de toutes les CVE 2025 était de 6.60 avec une médiane de 6.50.

CVSS v4.0: What Changed and Why It Matters

CVSS v4.0 : Ce Qui a Changé et Pourquoi C’est Important

CVSS v4.0, released by FIRST in November 2023, is the current standard — but adoption remains slow. As of early 2026, only 25.9% of CVEs published in 2025 include a v4.0 score. Most organizations still primarily use CVSS v3.1. Here's what changed:

CVSS v4.0, publié par FIRST en novembre 2023, est le standard actuel — mais l’adoption reste lente. Début 2026, seuls 25,9 % des CVE publiées en 2025 incluent un score v4.0. La plupart des organisations utilisent encore principalement CVSS v3.1. Voici ce qui a changé :

1. Scope Is Gone

1. Le Scope a Disparu

The Scope (S) metric was the most confusing part of CVSS v3.1. It was supposed to capture whether a vulnerability in one component could impact other components (e.g., a container escape affecting the host). In practice, different vendors interpreted it differently, leading to inconsistent scores. CVSS v4.0 retires Scope entirely and uses separate impact sub-metrics for the vulnerable system vs. the subsequent system.

La métrique Scope (S) était la partie la plus confuse de CVSS v3.1. Elle devait capturer si une vulnérabilité dans un composant pouvait impacter d’autres composants (ex. : évasion de conteneur affectant l’hôte). En pratique, les différents fournisseurs l’interprétaient différemment, menant à des scores incohérents. CVSS v4.0 supprime complètement le Scope et utilise des sous-métriques d’impact séparées pour le système vulnérable vs. le système suivant.

2. Attack Complexity Is Split in Two

2. La Complexité d’Attaque Est Divisée en Deux

CVSS v3.1 lumped everything into Attack Complexity. V4.0 separates it into:

CVSS v3.1 regroupait tout dans la Complexité d’Attaque. La v4.0 la sépare en :

• Attack Complexity (AC) — effort the attacker must expend (exploit development, bypassing ASLR, etc.)
• Attack Complexity (AC) — effort que l’attaquant doit fournir (développement d’exploit, contournement ASLR, etc.)
• Attack Requirements (AT) — conditions that must exist in the target environment but are outside the attacker's control (specific configuration, race condition timing, etc.)
• Attack Requirements (AT) — conditions qui doivent exister dans l’environnement cible mais sont hors du contrôle de l’attaquant (configuration spécifique, timing de race condition, etc.)

3. User Interaction Gets Granularity

3. L’Interaction Utilisateur Gagne en Granularité

Instead of just "None" or "Required," CVSS v4.0 introduces:

Au lieu de simplement « None » ou « Required », CVSS v4.0 introduit :

• Passive (P) — user does something normal (visits a page, receives an email) and is exploited without realizing
• Passive (P) — l’utilisateur fait quelque chose de normal (visite une page, reçoit un email) et est exploité sans s’en rendre compte
• Active (A) — user must deliberately interact (download a file, submit a form, change a setting)
• Active (A) — l’utilisateur doit interagir délibérément (télécharger un fichier, soumettre un formulaire, modifier un paramètre)

4. Temporal Becomes Threat

4. Temporal Devient Threat

The "Temporal Metrics" from v3.1 were renamed to "Threat Metrics" in v4.0. The Remediation Level and Report Confidence metrics were retired (they were rarely used). Only Exploit Maturity remains — which is actually the most useful signal: is there a working exploit in the wild?

Les « Métriques Temporelles » de la v3.1 ont été renommées « Métriques de Menace » dans la v4.0. Les métriques Remediation Level et Report Confidence ont été retirées (elles étaient rarement utilisées). Seule l’Exploit Maturity reste — qui est en réalité le signal le plus utile : existe-t-il un exploit fonctionnel dans la nature ?

5. New: Supplemental Metrics

5. Nouveau : Métriques Supplémentaires

CVSS v4.0 adds an optional Supplemental group with metrics like Automatable (can the exploit be automated at scale?), Recovery (can the system self-heal?), and Safety (could there be physical harm?). These don't affect the numeric score but provide critical context.

CVSS v4.0 ajoute un groupe Supplémentaire optionnel avec des métriques comme Automatable (l’exploit peut-il être automatisé à grande échelle ?), Recovery (le système peut-il se réparer ?), et Safety (pourrait-il y avoir des dommages physiques ?). Elles n’affectent pas le score numérique mais fournissent un contexte critique.

Key Takeaway for Developers

Point Clé pour les Développeurs

CVSS v4.0 base scores tend to be slightly higher than v3.1 for the same vulnerability. This is by design — the new model creates a bigger gap between the base score and the threat-adjusted score, making the distinction between "theoretically severe" and "actually being exploited" much clearer. Don't panic if you see higher numbers in v4.0 — look at the threat metrics to calibrate your response.

Les scores de base CVSS v4.0 tendent à être légèrement plus élevés que ceux de la v3.1 pour la même vulnérabilité. C’est voulu — le nouveau modèle crée un écart plus grand entre le score de base et le score ajusté par les menaces, rendant la distinction entre « théoriquement sévère » et « activement exploité » beaucoup plus claire. Ne paniquez pas si vous voyez des chiffres plus élevés en v4.0 — regardez les métriques de menace pour calibrer votre réponse.

Why the Same CVE Gets Different Scores (And Why It Matters)

Pourquoi la Même CVE Obtient Des Scores Différents (Et Pourquoi C’est Important)

Here's something most developers don't realize: CVSS scores are not objective facts. They're opinions — informed opinions from trained analysts, but opinions nonetheless. Different organizations independently score the same CVE, and they sometimes disagree dramatically.

Voici quelque chose que la plupart des développeurs ne réalisent pas : les scores CVSS ne sont pas des faits objectifs. Ce sont des opinions — des opinions informées d’analystes formés, mais des opinions quand même. Différentes organisations notent indépendamment la même CVE, et elles sont parfois en désaccord dramatique.

Research from VulnCheck documented a striking example: a Linux kernel vulnerability was scored CVSS 9.8 Critical by CISA-ADP (network attack vector, no privileges required) but only CVSS 4.4 Medium by IBM X-Force (local attack vector, high privileges required). Same CVE, same vulnerability, two completely different risk assessments. Over 39 unique organizations contribute scores to the NVD with notable discrepancies between them.

Des recherches de VulnCheck ont documenté un exemple frappant : une vulnérabilité du noyau Linux a été notée CVSS 9.8 Critical par CISA-ADP (vecteur réseau, aucun privilège requis) mais seulement CVSS 4.4 Medium par IBM X-Force (vecteur local, privilèges élevés requis). Même CVE, même vulnérabilité, deux évaluations de risque complètement différentes. Plus de 39 organisations uniques contribuent des scores au NVD avec des divergences notables entre elles.

This matters for developers because if you're using CVSS scores to make patch/no-patch decisions, which score you read could change your conclusion entirely. Our recommendation: always check who scored the CVE and consult multiple sources when the score drives a high-stakes decision.

Cela compte pour les développeurs car si vous utilisez les scores CVSS pour prendre des décisions de patch/pas-de-patch, le score que vous lisez pourrait changer entièrement votre conclusion. Notre recommandation : vérifiez toujours qui a noté la CVE et consultez plusieurs sources quand le score guide une décision à fort enjeu.

Beyond CVSS: EPSS and the Exploit Probability Approach

Au-delà du CVSS : EPSS et l’Approche par Probabilité d’Exploitation

If CVSS answers "how bad could this be?", EPSS (Exploit Prediction Scoring System) answers "how likely is this to actually be exploited?" Also maintained by FIRST, EPSS uses machine learning to estimate the probability that a vulnerability will be exploited in the wild within the next 30 days.

Si le CVSS répond à « à quel point cela pourrait-il être grave ? », EPSS (Exploit Prediction Scoring System) répond à « quelle est la probabilité que cela soit réellement exploité ? » Également maintenu par FIRST, EPSS utilise le machine learning pour estimer la probabilité qu’une vulnérabilité soit exploitée dans la nature dans les 30 prochains jours.

EPSS scores range from 0 to 1 (0% to 100%). Unlike CVSS, they are updated daily as new threat intelligence becomes available. Here's how they compare:

Les scores EPSS vont de 0 à 1 (0 % à 100 %). Contrairement au CVSS, ils sont mis à jour quotidiennement au fur et à mesure que de nouvelles informations sur les menaces deviennent disponibles. Voici comment ils se comparent :

                    CVSS                    EPSS
────────────────────────────────────────────────────────────
Measures            Severity (how bad)      Probability (how likely)
Scale               0 – 10                  0 – 1 (0% – 100%)
Updates             Static once assigned    Daily
Model               Expert assessment       Machine learning
Best for            Understanding impact    Prioritizing patches
Version             v4.0 (current)          v4 (March 2025)

                    CVSS                    EPSS
────────────────────────────────────────────────────────────
Mesure              Sévérité (gravité)       Probabilité (vraisemblance)
Échelle              0 – 10                  0 – 1 (0% – 100%)
Mise à jour          Statique une fois fixé  Quotidienne
Modèle               Expertise humaine       Machine learning
Idéal pour           Comprendre l'impact     Prioriser les patchs
Version             v4.0 (actuelle)         v4 (mars 2025)

The most powerful approach combines both: a vulnerability with CVSS 9.0+ AND EPSS > 0.5 is your real emergency. A vulnerability with CVSS 9.0 but EPSS 0.01 is theoretically severe but almost never exploited in practice — it can wait for a scheduled maintenance window. And a vulnerability flagged in CISA's Known Exploited Vulnerabilities (KEV) catalog? That one is confirmed actively exploited and should be patched regardless of CVSS score.

L’approche la plus puissante combine les deux : une vulnérabilité avec CVSS 9.0+ ET EPSS > 0.5 est votre vraie urgence. Une vulnérabilité avec CVSS 9.0 mais EPSS 0.01 est théoriquement sévère mais presque jamais exploitée en pratique — elle peut attendre une fenêtre de maintenance planifiée. Et une vulnérabilité signalée dans le catalogue KEV (Known Exploited Vulnerabilities) de CISA ? Celle-là est confirmée activement exploitée et doit être patchée quel que soit le score CVSS.

A Developer's Decision Framework: When to Actually Patch

Le Framework Décisionnel du Développeur : Quand Vraiment Patcher

Here's a practical flowchart you can use every time a CVE hits your dependency audit:

Voici un organigramme pratique utilisable à chaque fois qu’une CVE apparaît dans votre audit de dépendances :

Step 1: Is it in CISA KEV?
  └─ YES → Patch NOW. Confirmed active exploitation.
  └─ NO  → Continue to Step 2.

Step 2: Is the CVSS ≥ 9.0 (Critical)?
  └─ YES → Check EPSS score.
     └─ EPSS > 0.1  → Patch this sprint. High severity + real exploitation.
     └─ EPSS < 0.1  → Check reachability (Step 3).
  └─ NO  → Continue to Step 3.

Step 3: Is the vulnerable code reachable?
  └─ Is the package in your PRODUCTION dependencies (not devDependencies)?
  └─ Is the vulnerable function/endpoint actually called in your code?
  └─ Is the attack vector relevant? (Network vuln in a CLI tool = lower risk)
     └─ YES to all → Prioritize based on CVSS severity.
     └─ NO to any  → Schedule for next maintenance window.

Step 4: Can you update without breaking changes?
  └─ Patch version bump (1.2.3 → 1.2.4) → Update immediately.
  └─ Minor version bump (1.2.x → 1.3.0) → Test and update this sprint.
  └─ Major version bump (1.x → 2.0)     → Plan migration, assess risk of delay.

Étape 1 : Est-elle dans le CISA KEV ?
  └─ OUI → Patcher MAINTENANT. Exploitation active confirmée.
  └─ NON → Continuer à l'étape 2.

Étape 2 : Le CVSS est-il ≥ 9.0 (Critique) ?
  └─ OUI → Vérifier le score EPSS.
     └─ EPSS > 0.1  → Patcher ce sprint. Sévérité haute + exploitation réelle.
     └─ EPSS < 0.1  → Vérifier l'accessibilité (étape 3).
  └─ NON → Continuer à l'étape 3.

Étape 3 : Le code vulnérable est-il accessible ?
  └─ Le package est-il dans vos dépendances de PRODUCTION (pas devDependencies) ?
  └─ La fonction/endpoint vulnérable est-il réellement appelé dans votre code ?
  └─ Le vecteur d'attaque est-il pertinent ? (Vuln réseau dans un outil CLI = risque moindre)
     └─ OUI à tout  → Prioriser selon la sévérité CVSS.
     └─ NON à l'un → Planifier pour la prochaine fenêtre de maintenance.

Étape 4 : Pouvez-vous mettre à jour sans casser ?
  └─ Patch version (1.2.3 → 1.2.4) → Mettre à jour immédiatement.
  └─ Minor version (1.2.x → 1.3.0) → Tester et mettre à jour ce sprint.
  └─ Major version (1.x → 2.0)     → Planifier la migration, évaluer le risque du délai.

This framework captures what experienced security teams do intuitively: combine severity with exploitability and context. It's the difference between reacting to every alert and strategically managing your risk surface.

Ce framework capture ce que les équipes sécurité expérimentées font intuitivement : combiner la sévérité avec l’exploitabilité et le contexte. C’est la différence entre réagir à chaque alerte et gérer stratégiquement votre surface de risque.

Using CVSS in Your CI/CD Pipeline

Utiliser le CVSS dans Votre Pipeline CI/CD

Here's how to set up threshold-based gates that are strict enough to catch real risks without blocking every deployment:

Voici comment mettre en place des gates basées sur des seuils suffisamment stricts pour attraper les vrais risques sans bloquer chaque déploiement :

# Example: GitHub Actions vulnerability gate
- name: Check vulnerabilities
  run: |
    # Block on Critical (9.0+) in production deps
    CRITICAL=$(audit-tool --min-severity 9.0 --prod-only --format count)
    if [ "$CRITICAL" -gt 0 ]; then
      echo "❌ $CRITICAL critical vulnerabilities found"
      exit 1
    fi

    # Warn on High (7.0+) but don't block
    HIGH=$(audit-tool --min-severity 7.0 --prod-only --format count)
    if [ "$HIGH" -gt 0 ]; then
      echo "⚠️ $HIGH high vulnerabilities found — review before merge"
    fi

# Exemple : gate de vulnérabilités GitHub Actions
- name: Vérifier les vulnérabilités
  run: |
    # Bloquer sur Critical (9.0+) dans les deps de production
    CRITICAL=$(audit-tool --min-severity 9.0 --prod-only --format count)
    if [ "$CRITICAL" -gt 0 ]; then
      echo "❌ $CRITICAL vulnérabilités critiques trouvées"
      exit 1
    fi

    # Avertir sur High (7.0+) mais ne pas bloquer
    HIGH=$(audit-tool --min-severity 7.0 --prod-only --format count)
    if [ "$HIGH" -gt 0 ]; then
      echo "⚠️ $HIGH vulnérabilités hautes trouvées — revoir avant le merge"
    fi

Pro tip: Audit at the lockfile level, not just direct dependencies. Transitive dependencies account for the majority of CVEs in most projects. Tools like CVE OptiBot scan your package-lock.json, requirements.txt, or composer.lock daily and alert you when new CVEs are published — even for vulnerabilities discovered after you deployed.

Astuce pro : Auditez au niveau du lockfile, pas seulement les dépendances directes. Les dépendances transitives représentent la majorité des CVE dans la plupart des projets. Des outils comme CVE OptiBot scannent votre package-lock.json, requirements.txt, ou composer.lock quotidiennement et vous alertent quand de nouvelles CVE sont publiées — même pour les vulnérabilités découvertes après votre déploiement.

Frequently Asked Questions

Questions Fréquentes