Failles PHP CVE-2026-109618 et CVE-2026-109619 : que faire maintenant pour votre site

Le 21 octobre 2026 à 16 h, heure suisse, le projet PHP a publié les versions 8.5.12, 8.4.27, 8.3.36 et 8.2.35. Elles corrigent deux failles critiques, CVE-2026-109618 et CVE-2026-109619, qui, dans certaines conditions, permettent à un attaquant d'exécuter du code sur un serveur web sans authentification et sans aucune interaction de l'utilisateur. Le même jour, l'Office fédéral de la cybersécurité (OFCS) a recommandé d'installer les mises à jour sans attendre.

PHP est le langage sur lequel reposent WordPress, Joomla, Drupal, Magento, les applications Laravel et Symfony ainsi qu'un très grand nombre de boutiques en ligne et de logiciels de gestion. Si votre site utilise l'un de ces systèmes, vous êtes concerné. Voici les faits vérifiés, les versions à installer et une checklist pratique.

Ce qui s'est passé

Selon l'avis de sécurité de php.net, les deux failles se trouvent dans le cœur de PHP, dans la gestion de la mémoire et des erreurs, c'est-à-dire dans des parties que presque chaque requête traverse :

• CVE-2026-109618 : lorsqu'une requête épuise la mémoire au mauvais moment, PHP peut laisser des données internes partiellement initialisées, puis les traiter comme valides, ce qui corrompt la mémoire.
• CVE-2026-109619 : un état interne lié à une requête peut subsister après la libération de la mémoire correspondante ; une requête suivante traitée par le même processus peut le réutiliser.

Les deux failles ont un score CVSS 4.0 de 9,2 sur 10, niveau critique. La note de 10.0 qui a circulé sur les réseaux sociaux avant la publication était erronée, comme le précise la PHP Foundation. Dans les médias, elles sont aussi appelées « PHP2Shell », par analogie avec Log4Shell en 2021.

Les failles ont été signalées par les sociétés de sécurité Calif et Wiz ainsi que par OpenAI. La publication était prévue pour le 22 octobre, mais le 20 octobre les identifiants CVE ont commencé à circuler en ligne et le projet PHP a avancé la sortie d'un jour.

Qui est concerné

Selon php.net, toute installation PHP qui répond à des requêtes web est à risque : PHP-FPM, Apache avec mod_php, php-cgi, FrankenPHP et LiteSpeed. Le risque le plus élevé concerne Apache avec mod_php, où une attaque a été démontrée : une requête non authentifiée déclenche la faille avant même l'exécution du code de l'application. Les versions vulnérables vont de la 5.4 à la 8.5.11 ; le BSI allemand évoque toutes les versions depuis au moins PHP 5.

L'OFCS rappelle que la vérification ne doit pas se limiter aux sites publics : PHP peut aussi se trouver dans des interfaces d'administration, des applications internes, des plateformes d'hébergement, des conteneurs et des appareils, parfois à l'insu de leurs exploitants.

L'état de la menace

Au moment de la publication, aucune exploitation confirmée n'était connue. Le BSI faisait toutefois état d'informations non confirmées sur des exploits existants, et le Centre canadien pour la cybersécurité indique qu'une preuve de concept est disponible. Selon la BBC, le directeur technique de Cloudflare a déclaré observer les premières tentatives d'attaque.

Plusieurs autorités ont mis temporairement leurs sites hors ligne par précaution jusqu'à l'installation du correctif : en Allemagne, par exemple, le gouvernement du Bade-Wurtemberg et plusieurs universités (tagesschau) ; selon la BBC, également les services web publics du gouvernement finlandais. Il ne s'agissait pas d'attaques réussies, mais de mesures de prudence.

Les versions à installer

• PHP 8.5 : version 8.5.12
• PHP 8.4 : version 8.4.27
• PHP 8.3 : version 8.3.36
• PHP 8.2 : version 8.2.35 (fin du support le 31 décembre 2026)

PHP 8.1, 8.0, 7.x et antérieures ne reçoivent plus de mises à jour officielles. L'équipe de sécurité de PHP a publié des correctifs minimaux dans le code source pour 7.4, 8.0 et 8.1, et certaines distributions Linux proposent des paquets corrigés, mais la solution recommandée est de passer à une version supportée.

Attention au numéro de version sur les serveurs Linux : les distributions appliquent souvent le correctif à leur propre version du paquet. Sur Ubuntu 24.04, par exemple, le paquet corrigé est 8.3.6-0ubuntu0.24.04.13 (USN-8948-1) ; sur Debian 13, 8.4.27-1~deb13u1 (DSA-6574-1). Ce qui compte, c'est la version exacte du paquet indiquée par le fournisseur, pas seulement le numéro affiché par PHP.

Que faire maintenant

Avec un hébergement géré

Si votre site est sur un hébergement mutualisé ou géré, la mise à jour de PHP incombe au fournisseur. Demandez-lui une confirmation écrite que le correctif est installé, comme le suggère aussi l'OFCS. Dans le panneau de contrôle, vérifiez quelle version de PHP utilise votre site : si c'est la 8.1 ou une version antérieure, planifiez dès maintenant le passage à la 8.3 ou à la 8.4, en le testant d'abord sur une copie du site.

Avec un VPS ou un serveur propre

1. Faites une sauvegarde ou un snapshot du serveur, bases de données et fichiers téléversés compris.
2. Mettez à jour les paquets PHP avec le gestionnaire de la distribution (sur Debian et Ubuntu : apt update puis mise à jour des paquets PHP).
3. Redémarrez PHP-FPM et le serveur web : sans redémarrage, les processus en cours continuent d'utiliser l'ancien code.
4. Vérifiez la version réellement utilisée avec php -v et la version du paquet, y compris pour le processus qui sert le site.
5. Reconstruisez et redéployez les images Docker qui contiennent PHP.
6. Contrôlez les journaux à la recherche de requêtes inhabituelles, de plantages, de fichiers modifiés et de processus inattendus : une mise à jour ne répare pas une compromission déjà survenue.

Une bonne pratique de plus : définir expose_php = Off, pour que le serveur n'annonce pas sa version de PHP dans les en-têtes HTTP. Cela ne protège pas contre la faille, mais réduit les informations utiles à qui recherche des serveurs non corrigés.

Si vous ne pouvez pas mettre à jour tout de suite

php.net indique quelques mesures temporaires, par exemple session.upload_progress.enabled=0 et une valeur basse pour post_max_size. Elles ne réduisent que certaines voies d'attaque et ne rendent pas l'installation sûre. Selon l'OFCS, un pare-feu applicatif web seul ne suffit pas non plus. Pour les applications critiques, il faut envisager une déconnexion temporaire d'Internet.

Checklist en bref

1. Dressez la liste des sites, boutiques en ligne, logiciels de gestion et panneaux qui utilisent PHP.
2. Pour chacun, notez qui le gère et quelle version de PHP il utilise.
3. Demandez à votre hébergeur de confirmer que le correctif est installé.
4. Sur vos propres serveurs : sauvegarde, mise à jour, redémarrage des services, vérification de la version.
5. Planifiez le passage de PHP 8.1 ou antérieur à une version supportée.
6. Mettez aussi à jour le CMS, les thèmes et les extensions, qui sont un sujet distinct.
7. Surveillez les journaux et les fichiers du site dans les prochains jours.

Questions fréquentes

Mon site WordPress est-il à risque ?

WordPress fonctionne avec PHP, donc oui, si le serveur utilise une version de PHP non corrigée. Le problème n'est pas dans WordPress mais dans le langage sous-jacent : mettre à jour WordPress et ses extensions est utile, mais ne remplace pas la mise à jour de PHP.

Comment savoir quelle version de PHP utilise mon site ?

Dans le panneau de votre hébergement, en général dans la rubrique PHP ou dans les réglages du site. Dans WordPress : Outils, Santé du site, Infos, Serveur. Sur votre propre serveur : avec la commande php -v et la version du paquet installé.

Mon site utilise encore PHP 7.4 : que faire ?

PHP 7.4 ne reçoit plus de mises à jour officielles. Les correctifs minimaux publiés pour la 7.4 sont destinés à ceux qui compilent PHP eux-mêmes ou n'ont pas de fournisseur avec support étendu. Pour un site d'entreprise, la bonne voie est la migration vers PHP 8.3 ou 8.4, testée d'abord sur une copie du site.

Un pare-feu ou un service comme Cloudflare suffit-il ?

Non. Ils peuvent filtrer certaines attaques connues, mais l'OFCS précise qu'un pare-feu applicatif web seul ne suffit pas. La seule solution complète est la mise à jour.

La mise à jour peut-elle casser mon site ?

Une mise à jour au sein de la même branche, par exemple de 8.3.35 à 8.3.36, est une version de sécurité et ne change normalement pas le fonctionnement. Le passage à une nouvelle branche, par exemple de 7.4 à 8.3, doit en revanche être testé d'abord sur une copie, car d'anciens thèmes, extensions ou code peuvent ne pas être compatibles.

J'ai mis à jour : dois-je faire autre chose ?

Redémarrez les services PHP, vérifiez la version utilisée et contrôlez les journaux. Si vous constatez des fichiers modifiés, des administrateurs inconnus ou des processus étranges, considérez le serveur comme compromis.

Notre approche

ElaraTeq Sagl gère des sites et des applications pour des PME et des collectivités au Tessin avec un hébergement en Suisse. Nous pouvons vérifier quelle version de PHP utilise votre site, installer le correctif ou planifier la migration depuis une version qui n'est plus supportée. Pour la maintenance continue, il y a le service décrit dans Orbit ; pour une vérification, écrivez-nous.

Sources

• PHP, « Security advisory: Critical remote code execution vulnerabilities, update now », 21 octobre 2026 : php.net
• PHP, avis GitHub GHSA-w8hw-w9fx-j79w (CVE-2026-109618) et GHSA-6wmf-4rv5-p3rp (CVE-2026-109619)
• The PHP Foundation, « Today's PHP Security Release », 21 octobre 2026 : thephp.foundation
• OFCS, avertissement sur les failles critiques de PHP, 21 octobre 2026 : bacs.admin.ch
• BSI, « PHP – Kritische Schwachstellen bedrohen Webanwendungen weltweit », 21 octobre 2026 : bsi.bund.de
• Ubuntu, USN-8948-1 ; Debian, DSA-6574-1
• Centre canadien pour la cybersécurité, AL26-026
• tagesschau/SWR, 21 octobre 2026 : sites du Bade-Wurtemberg mis hors ligne par précaution ; BBC, 21 octobre 2026 : Websites taken down worldwide