PHP corrige ses failles critiques : comment mettre à jour pour protéger vos sites

Les deux failles critiques de PHP dont je vous ai parlé ce matin ont leurs correctifs : PHP 8.5.12, 8.4.27, 8.3.36 et 8.2.35 sont sortis cet après-midi un peu avant 16h.

Ces vulnérabilités peuvent permettre d'exécuter du code à distance, sans authentification, sur toute installation PHP qui sert des requêtes web, dont PHP-FPM, Apache avec mod_php, php-cgi, FrankenPHP et LiteSpeed.

Pour installer ces correctifs, la marche à suivre dépend de l'endroit où tourne votre site.

Deux trous de mémoire

La première faille (CVE-2026-109618) se déclenche quand PHP manque de mémoire : il peut alors s'interrompre en laissant les données internes de la requête à moitié initialisées, puis les traiter comme valides au moment du nettoyage.

La seconde (CVE-2026-109619) tient au recyclage des workers, ces processus qui enchaînent les requêtes de visiteurs au lieu de relancer PHP à chaque visite.

Entre deux requêtes, un worker est censé faire table rase. Or un état interne propre à une requête peut survivre à la libération de la mémoire qui le porte : le worker garde des restes de la requête précédente.

L'attaque se joue donc en deux temps. Une première requête piégée laisse ces restes derrière elle, puis une seconde les exploite si elle tombe sur le même worker, jusqu'à exécuter du code malveillant.

L'équipe de PHP juge le risque le plus élevé avec mod_php, le module qui fait tourner PHP dans Apache : un exploit y a été démontré, où une requête non authentifiée peut déclencher l'attaque avant même que le code de l'application ne s'exécute.

Autrement dit, avoir un WordPress ou un Laravel à jour ne vous protège pas : c'est bien PHP lui-même qu'il faut mettre à jour.

Selon le NCSC, l'agence de cybersécurité néerlandaise, une preuve de concept a été publiée, c'est-à-dire un code qui démontre que l'attaque fonctionne. Cloudflare dit aussi voir passer les premières tentatives d'exploitation.

Depuis, la société de sécurité watchTowr dit aussi observer des tentatives d'exploitation sur ses pièges à attaquants (honeypots). Aucun piratage réel n'a en revanche été confirmé par les autorités, ni par le NCSC ni par le BSI allemand.

En mutualisé, l'hébergeur a la main

Sur un hébergement mutualisé, PHP appartient à l'hébergeur : impossible donc de le mettre à jour vous-même.

Vérifiez la version réellement servie (dans le panneau de l'hébergeur ou avec un phpinfo() temporaire, à retirer ensuite), puis consultez sa page de statut ou son support pour savoir s'il a déployé le correctif.

Inutile de bricoler les parades détaillées plus bas : celle contre la faille des workers recyclés doit passer par le php.ini, un pool FPM ou la configuration du serveur (des réglages que l'hébergeur garde en général pour lui), et non par .user.ini ou ini_set(), prévient l'avis de PHP.

Si votre site est sensible et que le correctif n'est pas encore déployé, la mise en maintenance reste la solution de repli : le CERT-EU conseille d'envisager d'isoler les applications exposées tant qu'un correctif ne peut pas être appliqué.

Encore faut-il une vraie maintenance : le mode maintenance de WordPress ou d'une extension ne protège de rien, puisque PHP traite la requête avant que l'application ne vérifie quoi que ce soit. Il vous faut donc servir une page statique, sans passer par PHP.

Sur un VPS, php -v ne dit pas tout

Si PHP vient de votre distribution, tout passe par le gestionnaire de paquets :

sudo apt update && sudo apt upgrade   # Debian, Ubuntu
sudo dnf upgrade 'php*'               # Fedora, RHEL et dérivées

Redémarrez ensuite PHP-FPM ou Apache, sans quoi les workers déjà lancés gardent l'ancien code en mémoire :

sudo systemctl restart php8.3-fpm   # nom du service à adapter à votre version et à votre distribution
sudo systemctl restart apache2      # Debian, Ubuntu
sudo systemctl restart httpd        # Fedora, RHEL

Ne vous fiez pas au numéro de version pour vérifier : les distributions rétroportent le correctif, c'est-à-dire qu'elles l'appliquent à leur version de PHP sans changer son numéro.

Sur Ubuntu 24.04 LTS, le correctif arrive avec le paquet php8.3 en version 8.3.6-0ubuntu0.24.04.13, et php -v affiche toujours 8.3.6 (non, la mise à jour n'a pas échoué).

Ubuntu a aussi corrigé php8.1 sur la 22.04 LTS et php8.5 sur la 26.04 LTS. Le bon repère, c'est la version du paquet installé, à rapprocher de celle qu'indique l'avis de sécurité de votre distribution (pour Debian, son suivi de sécurité).

Autre piège : php -v interroge le PHP du terminal, alors que plusieurs versions peuvent cohabiter sur un serveur et que le site peut très bien passer par une autre.

Un phpinfo() temporaire vous dit quelle version répond vraiment aux visiteurs, et c'est le paquet correspondant qu'il faut vérifier (php8.3-fpm ou libapache2-mod-php8.3 sur Debian et Ubuntu, par exemple).

Remi sans mise à jour

Sur les distributions de la famille Red Hat (RHEL, AlmaLinux, Rocky Linux), beaucoup de serveurs installent PHP depuis le dépôt de Remi (rpms.remirepo.net). Ce dépôt tiers, tenu par des bénévoles, propose des versions plus récentes que celles de la distribution.

Il n'aura pas de mise à jour aujourd'hui, prévient l'avis de PHP : chez ceux qui l'utilisent, un dnf upgrade ne corrigera donc rien.

L'équipe de PHP invite ceux qui en dépendent à passer aux paquets de leur distribution ou à compiler PHP depuis les sources (de quoi bien occuper sa soirée).

Sous Docker, pas de correctif sans nouvelle image

Le dépôt de l'image officielle php a intégré les quatre versions corrigées, et les tags correspondants (8.5.12, 8.4.27, 8.3.36 et 8.2.35) sont publiés sur Docker Hub depuis 17h42.

Reconstruisez alors vos images avec docker build --pull, qui force la récupération de la nouvelle image de base, ou lancez docker compose pull puis docker compose up -d si vous utilisez l'image telle quelle.

Dans le conteneur, php -v doit ensuite afficher la version corrigée. Les images dérivées comme wordpress ne seront corrigées qu'une fois reconstruites sur la nouvelle image php, et une image figée sur un tag précis (php:8.3.35-fpm) ne bougera jamais toute seule.

PHP 8.1 et plus ancien : c'est le système D

PHP 7.4, 8.0 et 8.1 n'auront pas de nouvelle version officielle.

Vous avez donc trois options :

• le correctif rétroporté de votre distribution ou d'un fournisseur de support étendu (LTS), s'il existe

• les correctifs source minimaux publiés par l'équipe sécurité de PHP pour 7.4, 8.0 et 8.1, à compiler vous-même (bon chance)

• la migration vers une version maintenue, la seule solution durable

Pour ces versions, le CERT-FR recommande d'isoler les équipements concernés, puis de migrer.

Le projet PHP ne prévoit rien pour PHP 5, alors que le CERT-FR estime les failles présentes au moins depuis cette version.

Les réglages en attendant la mise à jour

Si vous ne pouvez pas mettre à jour tout de suite, le bulletin de sécurité de PHP liste des réglages qui réduisent l'exposition sur certains chemins d'attaque, sans rendre une installation sûre pour autant : seule la mise à jour corrige.

Contre la faille mémoire, il recommande memory_limit=-1, de préférence via php_admin_value dans le pool FPM ou la configuration d'Apache pour que l'application ne puisse pas le modifier, ainsi qu'un post_max_size bas (8M sans upload, 32M avec).

Attention, memory_limit=-1 retire le garde-fou mémoire de PHP : c'est un pansement à enlever une fois la mise à jour faite !

Contre la faille des workers recyclés, désactivez session.upload_progress.enabled dans le php.ini, la configuration du serveur ou le pool FPM (pour le pool FPM, le CERT-FR propose php_admin_flag[session.upload_progress.enabled] = off), puis redémarrez chaque worker. Sur PHP 8.5, faites de même avec fatal_error_backtraces.

Le CERT-FR précise que ce réglage ne réduit la surface d'attaque que pour l'une des deux failles. Il conseille aussi de bloquer, ou à défaut de surveiller, les requêtes au Content-Type multipart (celui des formulaires d'envoi de fichiers), par exemple sur un pare-feu applicatif.

Les uploads, c'est ciao, le temps du blocage.

Cloudflare a déployé des règles provisoires sur son pare-feu applicatif, y compris pour son offre gratuite : une solution d'attente, de l'aveu même de son directeur technique.

Elles ne protègent que si votre serveur refuse le trafic qui ne passe pas par Cloudflare. Sinon, un attaquant n'a qu'à viser directement son adresse IP.

Mieux vaut débrancher que guérir

Plusieurs organisations ont préféré couper en attendant le correctif, comme le suggérait dès ce matin une développeuse du cœur de PHP pour ceux qui pouvaient se le permettre. Aucune n'a annoncé de piratage.

Aux Pays-Bas, le NCSC avait mis son propre site hors ligne par précaution, et renvoyait vers sa page LinkedIn.

La Tweede Kamer, la chambre basse du Parlement néerlandais, a suivi, tout comme MijnOverheid, le portail où les Néerlandais reçoivent leur courrier administratif, et DigiD, leur équivalent de FranceConnect.

En Finlande, le prestataire informatique de l'État est allé plus loin en bloquant dès la mi-journée tout le trafic entrant des services Internet publics de l'administration. La coupure n'est due ni à une exploitation ni à une intrusion, a-t-il précisé.

En France, le ministère de l'Intérieur a mis en maintenance préventive tous ses sites exposés aux failles, dont ceux des préfectures, à la demande de l'ANSSI. Les préfectures communiquent en attendant sur les réseaux sociaux et par voie d'affichage (à l'ancienne, donc).

La préfecture des Ardennes, elle, annonce sur X une maintenance planifiée visant à améliorer ses services en ligne (moui, planifiée depuis ce matin peut-être).

Le site de la CNIL affiche lui aussi une page de maintenance depuis le début de l'après-midi, et c'était toujours le cas à 18h.

Contrairement au ministère, la CNIL n'a pas officiellement lié cette coupure aux failles de PHP. MAIS BON. 👀

Pour appliquer dès maintenant les correctifs sur vos sites concernés :

• Ubuntu : paquets corrigés

• Debian : php8.4 corrigé sur Debian 13, php8.2 sur Debian 12

• Docker : image officielle php

• Télécharger PHP (sources)

• Télécharger PHP pour Windows

UPDATE 21/10/2026 18:18 : premières tentatives d'exploitation observées par watchTowr. Correctifs désormais disponibles pour Debian 12 et Docker.