En bref : PHP et Node.js ont chacun leur alerte : corriger l’un ne règle pas l’autre. Une version plus ancienne que la version corrigée de sa branche est exposée. Sans correctif, un site peut tomber, être contrôlé à distance ou laisser fuir ses données. Il faut d’abord connaître la version réellement utilisée, puis mettre à jour sans attendre. Après la mise à jour, on vérifie que le site répond et que ses fonctions marchent.
Sommaire
- Faille de sécurité PHP et Node.js : ce que les éditeurs annoncent
- PHP : deux vulnérabilités notées 9,2 en attente de détails officiels
- Versions PHP à surveiller : les branches 8.2 à 8.5 et leur portée réelle
- Node.js : trois lignes visées, avec une gravité maximale classée HIGH
- Risques possibles : l’exécution de code à distance rapportée, sans confirmation
- Comment mettre à jour PHP et Node.js sans attendre les détails
PHP et Node.js reçoivent chacun leur alerte de sécurité, et ces alertes sont distinctes.
Si le site tourne sur une version touchée, un inconnu peut le contrôler à distance, et il faut agir vite.
Cet article indique quelles failles touchent PHP et Node.js, quelles versions corriger et comment vérifier ensuite que le site fonctionne.
Faille de sécurité PHP et Node.js : ce que les éditeurs annoncent
PHP et Node.js reçoivent deux alertes distinctes. Pour PHP, une mise à jour de sécurité est prévue le mercredi 21 octobre à 14 h UTC (temps universel).
Elle corrige deux failles critiques, notées 9,2 sur 10 (CVSS v4.0, échelle de gravité).
Node.js reçoit des bulletins séparés, qui visent trois lignes de version avec une gravité maximale HIGH.
Les versions en fin de vie sont concernées aussi. Une mise à jour PHP ne règle pas Node.js : chaque logiciel se vérifie à part.
Le bulletin Node.js vise les lignes 26.x, 24.x et 22.x. Pour chacune, la gravité maximale annoncée est HIGH, soit un niveau élevé. Il prévoit leur mise à jour le 21 octobre 2026 ou peu après.
Le bulletin précise aussi que les versions en fin de vie sont touchées dès qu’une mise à jour de sécurité paraît. Si le site tourne sur une de ces versions, il faut la passer à une ligne encore suivie.
PHP : deux vulnérabilités notées 9,2 en attente de détails officiels
PHP reçoit deux failles critiques, notées 9,2 sur 10 selon l’échelle CVSS v4.0, qui mesure la gravité d’une faille. Elles portent les identifiants CVE-2026-109618 et CVE-2026-109619 : c’est avec ces numéros qu’on les retrouve dans les bulletins de sécurité.
Le risque rapporté est l’exécution de code à distance sans authentification : un attaquant pourrait lancer des commandes sur le serveur sans avoir de compte.
Avec un 9,2, il faut traiter ces failles comme sérieuses et mettre PHP à jour vite.
Ces deux failles pourraient toucher toutes les versions de PHP, depuis PHP 5. Le niveau de gravité est élevé, donc on les traite comme sérieuses dès maintenant.
Rien ne montre pour l’instant qu’une attaque soit en cours. Par précaution, chaque PHP installé en dessous de la version corrigée de sa branche est considéré comme exposé, et il vaut mieux le mettre à jour sans tarder.
Versions PHP à surveiller : les branches 8.2 à 8.5 et leur portée réelle
PHP 8.5.12, 8.4.27, 8.3.36 et 8.2.35 corrigent les failles
Chaque branche de PHP a sa propre version corrigée, et le tableau indique laquelle viser. Ces corrections ne sont pas encore confirmées.
| Critère | PHP 8.2 | PHP 8.3 | PHP 8.4 | PHP 8.5 |
|---|---|---|---|---|
| Version corrigée à viser | 8.2.35 | 8.3.36 | 8.4.27 | 8.5.12 |
| Statut de la correction | Non confirmé | Non confirmé | Non confirmé | Non confirmé |
| Version à considérer comme exposée | Toute version 8.2 inférieure à 8.2.35 | Toute version 8.3 inférieure à 8.3.36 | Toute version 8.4 inférieure à 8.4.27 | Toute version 8.5 inférieure à 8.5.12 |
Versions affectées : ce qui reste à confirmer
La liste officielle des versions touchées n’est pas encore publiée. L’annonce de PHP du 20 octobre 2026 renvoie ces précisions à la sortie de la mise à jour.
Le bulletin du CERT-EU cite PHP 5 et les versions suivantes comme potentiellement touchées, sans dire lesquelles le sont vraiment.
Tant que cette liste manque, une version inférieure à la version corrigée de sa branche doit être considérée comme exposée.
Par exemple, PHP 8.4.26, la dernière version finale de l’archive datée du 24 septembre 2026, reste en dessous de 8.4.27 : il faut la remplacer.
Node.js : trois lignes visées, avec une gravité maximale classée HIGH
Le bulletin d’octobre vise trois lignes de Node.js : 26.x, 24.x et 22.x. Une ligne regroupe toutes les versions d’une même famille. Pour chacune, la gravité maximale est classée HIGH, le deuxième niveau de l’échelle.
Les mises à jour sont attendues le 21 octobre 2026 ou peu après. Le bulletin ne donne pas encore les numéros des versions corrigées.
Si la version installée fait partie de l’une de ces lignes, elle est exposée jusqu’à leur publication.
La page de publication Node.js du 21 octobre présente Node.js 26.12.1 comme mise à jour de sécurité, et elle cite ces failles, toutes classées HIGH :
- CVE-2026-106069
- CVE-2026-106072
- CVE-2026-105482
- CVE-2026-105483
- CVE-2026-111497
- Pour les lignes 22.x et 24.x, le bulletin officiel ne donne pas encore le numéro de version corrigée : il reste à vérifier.
Risques possibles : l’exécution de code à distance rapportée, sans confirmation
Une exécution de code à distance sans authentification pourrait toucher un serveur PHP vulnérable. C’est une hypothèse : elle repose sur l’évaluation du risque faite avec les informations disponibles alors, et rien n’est encore confirmé.
Node.js classe ses failles d’octobre au niveau maximal, HIGH. Ce classement indique la gravité, pas les effets : il ne dit pas ce que la faille permet concrètement sur un site.
Quatre risques menacent un site touché par ces failles, le dernier dépendant de son hébergeur web gratuit :
- Exécution de code à distance : un attaquant lance ses commandes sur le serveur et modifie les pages.
- Déni de service : le serveur plante ou ralentit, et le site ne répond plus.
- Fuite de données : des fichiers sensibles, comme les mots de passe, peuvent être lus.
- Contamination : un site voisin infecté, sur le même serveur, peut atteindre les fichiers de l’autre site.
Comment mettre à jour PHP et Node.js sans attendre les détails
Côté PHP : vérifier la branche puis appliquer le correctif
Avant de toucher à quoi que ce soit, il faut savoir quelle version de PHP tourne réellement. Sur un serveur Ubuntu, la commande php -v affiche la version de PHP utilisée par le terminal.
Les deux premiers chiffres, comme 8.3, donnent la branche. C’est cette branche qu’il faut comparer à la version corrigée de la même branche.
On applique le correctif dans cet ordre :
sudo apt updateactualise la liste des paquets connus du système.sudo apt upgradeinstalle les mises à jour des paquets déjà présents, PHP compris.sudo systemctl restart php8.4-fpmredémarre PHP-FPM, en remplaçant8.4par la branche installée.sudo systemctl status php8.4-fpmconfirme que le service tourne bien.- Avec Nginx,
sudo systemctl restart nginxrelance le serveur web ; avec Apache, c’estapache2.
Côté Node.js : repérer la ligne et choisir une version à jour
Sur le serveur, node -v affiche la version de Node.js du terminal. Le premier numéro indique la ligne, celle qui décide si le bulletin la vise.
Une mise à jour de Node.js ne garantit pas que les paquets Ubuntu ont suivi. Il faut donc vérifier la version réellement utilisée par le site, et celle des paquets qui le fournissent.
Après le correctif, il faut contrôler le site avec ces trois vérifications. Les mesures provisoires, comme un pare-feu et un scanner de vulnérabilités, ne sont qu’un appoint :
- Le site répond en HTTP, page d’accueil comprise.
- Ses fonctions principales marchent, comme la connexion, un formulaire ou une commande.
- En cas d’erreur, les journaux du serveur web et de PHP-FPM donnent la cause.
Il faut retenir que PHP et Node.js se corrigent séparément, et qu’une version plus ancienne que la correction de sa branche reste exposée.
Le prochain pas consiste à lancer php -v et node -v sur le serveur, à comparer chaque numéro à la version à viser, puis à mettre à jour sans attendre.
Ensuite, on vérifie que le site répond et que la connexion ou un formulaire fonctionne.
