21 octobre 2026 | PHP | Sécurité informatique
Le 21 octobre 2026, l'équipe de sécurité de PHP a publié des mises à jour pour toutes les versions de PHP encore prises en charge. Elles corrigent deux failles critiques connues sous le nom de PHP2Shell. Le BSI a émis une alerte à ce sujet et exige de corriger sans délai les systèmes concernés. Quiconque exploite un serveur web avec PHP devrait agir dès aujourd'hui. Cela vaut aussi pour tous ceux qui exploitent « seulement » un WordPress, un Nextcloud ou un Joomla, car ces applications tournent sur PHP.
Cet article résume ce qui s'est passé, quelles versions de PHP sont concernées, de quelle version vous avez besoin maintenant et comment vérifier en quelques minutes si votre serveur est protégé.
Contenu de cet article
- Que s'est-il passé ? Le déroulement chronologique
- Les deux failles PHP en un coup d'œil
- Qui est concerné ?
- Ces versions de PHP sont sûres
- Comment vérifier et mettre à jour votre serveur
- PHP 8.1 et antérieur : aucune mise à jour officielle
- Mesures transitoires et la question « Mettre le serveur hors ligne ? »
- Questions fréquentes
- Assistance de Biricon IT Services
Que s'est-il passé ? Le déroulement chronologique
L'équipe de sécurité de PHP avait annoncé à l'avance la publication des correctifs afin que les hébergeurs et les administrateurs aient le temps de se préparer. La publication elle-même a eu lieu le 21 octobre 2026. Le BSI a émis son alerte (version 1.1) le jour même.
- 20 octobre 2026 : préavis de l'équipe de sécurité de PHP annonçant que des mises à jour de sécurité paraîtront le lendemain.
- 21 octobre 2026, 14:00 UTC (16:00 CEST) : les correctifs pour PHP 8.5, 8.4, 8.3 et 8.2 sont publiés.
- 21 octobre 2026 : le BSI met en garde contre les « failles critiques qui menacent les applications web dans le monde entier » et recommande de corriger sans délai. Selon le BSI, de grands hébergeurs ont en partie mis des serveurs hors ligne par précaution.
Les deux failles PHP en un coup d'œil
Il s'agit de deux erreurs distinctes dans le noyau de PHP : CVE-2026-109618 et CVE-2026-109619. Selon l'équipe de sécurité de PHP, toutes deux peuvent permettre à un attaquant d'exécuter du code sur le serveur sans s'authentifier (unauthenticated Remote Code Execution). Les failles sont notées CVSS v4.0 : 9,2 (critique).
| Caractéristique | Signification |
|---|---|
| Identifiants | CVE-2026-109618 et CVE-2026-109619 |
| Note | CVSS v4.0 : 9,2 — critique |
| Conséquence | Exécution de code sur le serveur (Remote Code Execution), sans authentification |
| Cause 1 | Mémoire corrompue lorsque PHP ne dispose plus de mémoire vive pendant le traitement (Out-of-Memory) |
| Cause 2 | État global périmé qui reste en mémoire entre les requêtes |
| Particulièrement exposé | Apache avec mod_php |
Selon l'évaluation du BSI, il n'y avait, au moment de la publication, aucune attaque confirmée, mais il existait des indices non confirmés de tentatives d'exploitation. Pour des failles critiques dans un logiciel aussi répandu, il faut, d'expérience, s'attendre à ce que des attaquants analysent les correctifs et préparent des attaques automatisées. La fenêtre pour corriger est donc courte.
Qui est concerné ?
Est concerné en principe tout serveur sur lequel tourne PHP, quelle que soit la manière dont PHP est intégré : PHP-FPM, mod_php dans Apache, php-cgi, FrankenPHP ou LiteSpeed. Selon l'équipe de sécurité de PHP, le risque est le plus élevé avec Apache et mod_php.
Le BSI cite expressément des applications reposant sur PHP et qui peuvent donc être concernées elles aussi :
- Systèmes de gestion de contenu : WordPress, Drupal, TYPO3, Joomla
- Systèmes de boutique : Magento
- Cloud et stockage de fichiers : Nextcloud
- Interfaces de pare-feu : pfSense, OPNsense
L'application elle-même n'a pas besoin d'être défectueuse pour cela. La faille se trouve dans PHP, c'est pourquoi une mise à jour de WordPress, Nextcloud & Cie ne suffit pas à elle seule. Il faut mettre à jour la version de PHP sur le serveur. Pour les pare-feu comme pfSense et OPNsense, la version corrigée de PHP arrive via la mise à jour du micrologiciel du fabricant respectif.
Ces versions de PHP sont sûres
Les failles sont corrigées dans les versions suivantes. Tout ce qui est inférieur est considéré comme vulnérable.
| Branche PHP | Minimum requis | Remarque |
|---|---|---|
| PHP 8.5 | 8.5.12 | branche actuelle |
| PHP 8.4 | 8.4.27 | |
| PHP 8.3 | 8.3.36 | |
| PHP 8.2 | 8.2.35 | Le support prend fin le 31 décembre 2026 |
| PHP 8.1 et antérieur | aucune mise à jour officielle, voir en bas | |
Comment vérifier et mettre à jour votre serveur
1. Déterminer la version de PHP installée
En ligne de commande sur le serveur, php -v affiche la version de PHP en ligne de commande. Le serveur web peut utiliser une autre version de PHP. Vérifiez donc aussi la version de PHP-FPM ou du module Apache, par exemple avec php-fpm8.3 -v ou via une page qui affiche phpinfo() (à supprimer ensuite immédiatement).
2. Installer la mise à jour via le gestionnaire de paquets
Sous Debian, Ubuntu, RHEL et dérivés, la version corrigée arrive via le gestionnaire de paquets habituel, par exemple apt update && apt upgrade ou dnf upgrade. Pour les sources tierces comme le PPA de Sury ou le dépôt Remi, les nouveaux paquets apparaissent généralement rapidement.
apt changelog php8.3-fpm ou rpm -q --changelog php | grep CVE-2026-1096).
3. Redémarrer le service PHP
Une mise à jour de paquet seule ne suffit pas : les processus PHP en cours conservent l'ancien code en mémoire. Redémarrez PHP-FPM (systemctl restart php8.3-fpm) ou Apache (systemctl restart apache2), puis vérifiez ensuite que les processus ont bien été démarrés après la mise à jour.
4. Sites web hébergés
Avec un hébergement mutualisé, c'est en général le fournisseur qui effectue la mise à jour. Dans le menu client, on peut le plus souvent régler la version de PHP pour chaque site web. Choisissez-y l'une des versions sûres mentionnées ci-dessus, ou demandez au fournisseur où en sont les correctifs. Selon le BSI, certains fournisseurs ont déconnecté des serveurs du réseau par précaution. Si votre site est brièvement inaccessible, cela peut en être la cause.
PHP 8.1 et antérieur : aucune mise à jour officielle
Pour PHP 8.1 et antérieur, il n'existe plus de mises à jour de sécurité officielles. Les exploitants de tels systèmes ont deux possibilités :
- Passer à une version prise en charge (recommandé). Plus la version est ancienne, plus l'effort d'adaptation de l'application et des extensions est important ; un changement devrait donc être testé au préalable.
- Rétroporter les correctifs. L'équipe de sécurité de PHP a mis les correctifs à disposition dans des branches de développement sur GitHub. Celui qui compile PHP lui-même peut reprendre ces modifications dans des versions plus anciennes. C'est une solution transitoire et elle exige des connaissances spécialisées.
PHP 8.2 n'est lui aussi pris en charge que jusqu'au 31 décembre 2026. Prévoyez donc dès maintenant le passage à PHP 8.4 ou 8.5, et ne le repoussez pas au changement d'année.
Mesures transitoires et la question « Mettre le serveur hors ligne ? »
Avec son annonce, l'équipe de sécurité de PHP a aussi décrit des mesures de protection provisoires. Elles réduisent le risque, mais ne comblent pas entièrement les failles. Elles ne remplacent pas la mise à jour et ne sont destinées qu'à combler le temps jusqu'à celle-ci.
La question de savoir s'il faut déconnecter du réseau un serveur jusqu'à la mise à jour dépend de son importance et de son accessibilité. Le BSI indique que de grands fournisseurs ont franchi ce pas. Règle empirique :
- Serveur accessible publiquement, mise à jour possible maintenant : corriger immédiatement, pas besoin d'arrêter.
- Serveur accessible publiquement, mise à jour impossible à court terme : restreindre l'accès (par exemple par pare-feu, uniquement pour des adresses connues) ou arrêter temporairement le service, en particulier avec
mod_php. - Serveur accessible uniquement en interne : corriger rapidement, l'urgence est moindre.
Questions fréquentes
Dois-je mettre à jour WordPress, Joomla ou Nextcloud ?
Pas à cause de cette faille. Elle se situe dans PHP, pas dans l'application. Mettez à jour la version de PHP sur le serveur. Une mise à jour de l'application reste néanmoins judicieuse, indépendamment de cela.
Comment savoir si quelqu'un a déjà exploité la faille ?
Il est difficile de donner une réponse certaine. Sont suspects : des fichiers PHP inconnus dans le répertoire web, des processus inhabituels sous l'utilisateur du serveur web, de nouveaux comptes utilisateurs ou tâches cron, ainsi qu'un trafic sortant inhabituel. En cas de soupçon concret, le système devrait faire l'objet d'une analyse forensique et, en cas de doute, être réinstallé.
Un pare-feu applicatif web (WAF) suffit-il ?
Un pare-feu peut bloquer des schémas d'attaque connus, mais il ne remplace pas la mise à jour. Pour en savoir plus sur l'articulation de plusieurs couches de protection, lisez notre article Sécuriser Odoo 19 : pare-feu, 2FA & Web RBL. Les principes s'appliquent à toute application web.
Odoo est-il concerné ?
Non. Odoo est écrit en Python et ne fonctionne pas sur PHP. Seules les applications PHP exécutées sur le même serveur seraient concernées.
Où trouver les informations officielles ?
L'annonce de l'équipe de sécurité de PHP se trouve dans les archives des actualités sur php.net (entrée du 20 octobre 2026), les versions sous php.net/downloads. L'alerte du BSI porte le numéro 2026-297981-1032 et est publiée sur bsi.bund.de .
Assistance de Biricon IT Services
Si vous ne savez pas avec certitude quelle version de PHP s'exécute sur votre serveur, ou si vous avez besoin d'aide pour appliquer les correctifs, nous sommes à votre disposition : pour l'inventaire de tous les systèmes PHP, pour l'installation des mises à jour, pour le passage à une version de PHP prise en charge et pour la recherche d'une éventuelle compromission. En tant que prestataire informatique, nous gérons les serveurs, pare-feu et applications web des petites et moyennes entreprises.
Situation au 21 octobre 2026. La situation peut évoluer rapidement ; font foi les publications de l'équipe de sécurité de PHP et du BSI.