Failles PHP critiques CVE-2026 : patchez maintenant

Temps de lecture : 7 min

Deux failles qui touchent l’ensemble de l’écosystème PHP

Le 21 octobre 2026, deux vulnérabilités critiques de type exécution de code à distance (RCE) ont été rendues publiques dans PHP : CVE-2026-109618 et CVE-2026-109619. Concrètement, n’importe quel serveur faisant tourner PHP depuis la version 5 est potentiellement concerné. Un attaquant peut y exécuter du code arbitraire et compromettre entièrement la machine.

Le point qui change tout : un code d’exploitation (proof-of-concept) est déjà public. Pas de fenêtre de confort, pas de « on verra plus tard ». La seule vraie protection, c’est le patch. Toutes les mitigations intermédiaires réduisent la surface d’attaque, mais ne rendent pas l’installation sûre.

Pourquoi je prends ça très au sérieux

PHP, c’est une bonne partie du web. WordPress, Drupal, Laravel, des CMS oubliés dans un coin, des panneaux d’admin comme phpMyAdmin… et tout ce que vous avez déployé en mode « je teste vite fait » il y a trois ans. J’ai moi-même encore des vieux projets en PHP qui tournent quelque part, et c’est exactement le genre de faille qui vous rappelle qu’un inventaire à jour de son parc n’est pas un luxe.

Plus précisément : si vous hébergez sur DigitalOcean (Droplets, DOKS, App Platform, images Marketplace), vous êtes dans le périmètre jusqu’à preuve du contraire. Cloudways, l’offre managée, applique les correctifs WordPress automatiquement pour vous. Pour le reste, c’est à vous de jouer.

Les versions patchées (et les oubliées)

Le projet PHP a publié les correctifs suivants :

• PHP 8.5.12
• PHP 8.4.27
• PHP 8.3.36
• PHP 8.2.35

Si vous êtes sur PHP 8.1 ou antérieur, mauvaise nouvelle : ces branches sont en fin de vie et ne recevront aucun patch officiel. La seule issue est la migration vers PHP 8.2 minimum. Et vu le contexte, autant viser directement 8.3 ou 8.4 quand c’est possible.

Le plan d’action, étape par étape

1. Recenser tous les systèmes qui font tourner PHP

Pas seulement les serveurs étiquetés « PHP ». Pensez aussi aux CMS, aux panneaux d’administration, aux vieilles apps internes, aux conteneurs Docker, aux images Marketplace déployées en un clic (WordPress, LAMP, LEMP, Laravel…). Concrètement, tant que vous n’avez pas vérifié, considérez que vous êtes exposé.

2. Patcher immédiatement

Sur Debian/Ubuntu, un classique :

sudo apt update && sudo apt upgrade

Sur RHEL/CentOS/Rocky/Alma, la famille était encore en train de finaliser les paquets à la publication. Vérifiez l’avis de sécurité de votre distribution avant de forcer la mise à jour.

Étape trop souvent oubliée : redémarrer PHP-FPM ou le serveur web. Sans ce redémarrage, les processus vulnérables continuent de tourner en mémoire.

3. Upgrader si vous êtes sur une version morte

PHP 8.1 et antérieurs : migration obligatoire vers 8.2+. C’est le moment de passer à une stack moderne, d’autant que côté écosystème, Next.js et React Native ont largement pris le relais sur beaucoup de nouveaux projets. Mais pour l’existant, il faut migrer proprement.

4. Réduire la surface d’attaque dans l’intervalle

Si vous ne pouvez pas patcher tout de suite :

• Restreindre l’accès public aux applications PHP qui n’ont pas besoin d’être exposées sur Internet
• Activer les règles de pare-feu et de WAF. Si vous êtes derrière Cloudflare, des règles d’urgence ont été déployées
• Surveiller les logs d’accès et les comportements anormaux

Attention : ces mesures ne rendent pas votre installation sûre. Ce sont des pansements, pas des guérisons.

5. Cas particuliers : conteneurs et PaaS

Sur DOKS ou App Platform en conteneur custom : mettez à jour la version de PHP dans votre image de base ou votre Dockerfile, rebuild, redéployez. Simple sur le papier, mais souvent oublié dans les pipelines CI/CD. C’est exactement le genre de tâche que j’automatise avec n8n dans mes workflows d’ops : détection de version d’image, alerte, et déclenchement du rebuild.

Après le patch : vérifier si vous avez déjà été compromis

Patcher ferme la porte. Ça n’efface pas ce qui est déjà entré. Un serveur compromis sert souvent au minage de cryptomonnaies, à l’hébergement de spam ou de phishing, à des attaques DDoS, ou de point d’entrée pour un rançongiciel.

Quelques signes à surveiller :

• Processus inconnus consommant du CPU
• Fichiers modifiés récemment dans des dossiers inattendus
• Connexions sortantes vers des IP inconnues
• Comptes ou clés d’API créés sans votre intervention

Un point important : une tentative d’exploitation n’est pas une compromission. Beaucoup d’attaques échouent, surtout sur des serveurs patchés. Mais sans vérification, vous ne saurez jamais.

Ce que fait DigitalOcean (et ce qu’il ne fera pas)

Dans son modèle de responsabilité partagée, l’hébergeur patche les runtimes de ses services managés (App Platform, Cloudways, Functions), suspend les images Marketplace affectées jusqu’à correction, et peut restreindre temporairement le trafic des ressources montrant des signes de compromission.

Mais sur vos Droplets, c’est vous qui gérez le système et PHP. Personne ne patchera à votre place. C’est la contrepartie de la liberté d’une VM.

Le réflexe à garder

Cette alerte est l’occasion de mettre en place un vrai processus : inventaire automatisé des versions PHP, alertes sur les versions en fin de vie, et patch régulier. Concrètement, un cron qui remonte les versions et un petit workflow n8n qui vous notifie sur Slack quand une version sort du support, ça se monte en une après-midi et ça évite de revivre ce genre de stress.

Patcher maintenant, c’est le seul chemin sûr. Le reste, c’est de la gestion de risque.