Failles critiques PHP : les 5 vérifications pour votre site WordPress ou votre boutique
CVE-2026-109618 et CVE-2026-109619 : versions corrigées, sites exposés et mesures d'attente
Image générée par IA (art. 50 AI Act)
Analyse 2LKATIME
Le 21 octobre 2026, 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 d'exécution de code à distance. Nos auditeurs résument ce que disent les avis officiels, qui est exposé et ce qu'une PME doit vérifier dès aujourd'hui.
Un site WordPress ou une boutique en ligne ? Cet article vous concerne
PHP fait tourner WordPress, WooCommerce, PrestaShop, Magento et Drupal. Si un hébergeur ou un prestataire gère votre serveur, posez-lui la question aujourd'hui : quelle version de PHP, et quand le correctif sera-t-il appliqué ?
Le projet PHP avait annoncé le 20 octobre une release de sécurité pour le lendemain, sans aucun détail. Elle est sortie le 21 octobre à 14 h UTC, soit 16 h à Paris. Elle corrige CVE-2026-109618 et CVE-2026-109619, deux failles notées 9,2 sur l'échelle CVSS v4.0, qui permettent selon l'équipe PHP une exécution de code à distance sans authentification.
Le projet insiste sur un point : seule la mise à jour règle le problème, et aucune configuration ne protège complètement. Cela change l'organisation. On ne cherche pas un contournement astucieux, on planifie un correctif, avec une sauvegarde avant et un redémarrage après.
1. Ce qui est publié
2
Failles critiques corrigées
9,2
Score CVSS v4.0 de chacune
4
Branches corrigées : 8.2, 8.3, 8.4, 8.5
31 déc. 2026
Fin de vie de PHP 8.2
Toute version antérieure aux suivantes est concernée :
| Branche PHP | Première version corrigée |
|---|---|
| 8.5 | 8.5.12 |
| 8.4 | 8.4.27 |
| 8.3 | 8.3.36 |
| 8.2 | 8.2.35 |
PHP 8.1 et les versions plus anciennes ne reçoivent plus de mises à jour du projet. Il a pourtant fourni des correctifs minimaux pour les sources de 7.4, 8.0 et 8.1, ce qui laisse penser que ces branches sont touchées aussi. Certaines distributions et éditeurs LTS rétroportent le correctif : demandez-leur. Autrement, il faut migrer vers une branche supportée.
Deux précisions pratiques. Le projet déconseille de compter sur le dépôt communautaire Remi, qui ne publiera pas de mise à jour aujourd'hui. Et PHP 8.2 atteint sa fin de vie le 31 décembre 2026 . Si vous êtes sur cette branche, prévoyez dès maintenant la migration vers la 8.4 ou la 8.5.
L'annonce du projet ne mentionne aucune exploitation active. Les détails techniques sont publics depuis aujourd'hui et un exploit complet a été démontré sur mod_php : il est raisonnable de s'attendre à des tentatives d'attaque dans les jours qui viennent.
2. Les deux failles en clair
Les deux défauts touchent la gestion de la mémoire de PHP, et non un plugin ou un thème. Elles se combinent aussi : les avis se renvoient l'un à l'autre et demandent d'appliquer les deux séries de mesures.
CVE-2026-109618 : le manque de mémoire
Quand PHP n'a plus de mémoire, il abandonne la requête d'un coup. Dans certains cas, des données internes sont alors à moitié initialisées, et le nettoyage de fin de requête les lit comme si elles étaient valides. Une requête d'envoi de fichiers (multipart) bâtie pour gonfler la mémoire suffit à provoquer ce cas, par exemple avec un nombre excessif d'en-têtes dans une même partie.
CVE-2026-109619 : l'état résiduel
Un worker PHP garde de l'état d'une requête à l'autre. Si une requête s'achève sur une erreur fatale, une partie de cet état pointe vers de la mémoire déjà libérée. La requête suivante, traitée par le même worker, peut s'en servir avant que PHP ne la remette à zéro. L'attaque se joue donc en deux temps, avec deux requêtes sur le même worker.
Les deux avis évaluent l'attaque de la même façon : réseau, aucun privilège, aucune interaction d'utilisateur, avec une complexité élevée. Cette complexité tient à la disposition de la mémoire du serveur, qui varie selon la version, les extensions et la charge. Elle ralentit un attaquant et ne l'arrête pas.
3. Qui est exposé
Le niveau de risque dépend de la façon dont PHP est branché au serveur web. Le projet distingue plusieurs cas :
| Mode d'exécution | Exposition selon le projet PHP |
|---|---|
| Apache mod_php | Risque le plus élevé. Un exploit complet a été démontré sans authentification, avant l'exécution du moindre code de l'application. |
| PHP-FPM (nginx, Apache) | Vulnérable d'après l'analyse du code. Pour la seconde faille, un chemin complet a été validé via le suivi de progression d'envoi de session, à condition qu'une opération de l'application s'y prête. Pas d'exploit complet démontré pour la première. |
| FrankenPHP | Probablement exposé à la première faille, comme mod_php, car il appelle lui aussi le nettoyage de fin de requête dans tous les cas. |
| LSAPI (LiteSpeed) | Exploits dépendant de l'application jugés probables, mais non validés. |
| php-cgi | Cité par le projet PHP parmi les installations à risque, sans détail supplémentaire. |
La combinaison la plus répandue pour WordPress est nginx avec PHP-FPM. Le scénario y est moins direct qu'avec mod_php, puisque FPM supprime le worker en cas d'échec au démarrage d'une requête. Moins direct ne veut pas dire sûr : un chemin validé existe pour la seconde faille, et le projet recommande la mise à jour à tous les utilisateurs, sans distinction de mode.
4. Cinq vérifications aujourd'hui
Aucune ne demande d'être expert. La plus utile est la deuxième : savoir précisément qui doit agir.
1. Relever la version de PHP
Santé du site dans WordPress, panneau de l'hébergeur ou commande php -v. Comparez avec 8.2.35, 8.3.36, 8.4.27 ou 8.5.12. Une version plus basse dans la même branche est vulnérable.
2. Savoir qui applique le correctif
Hébergement mutualisé : l'hébergeur. Serveur dédié ou VPS : vous, ou votre infogérant. Demandez une date par écrit. Sur Debian ou Ubuntu, lancez apt update puis apt list --upgradable et cherchez les paquets php. Les distributions ont reçu les correctifs en avance, mais leurs paquets peuvent arriver après la version amont.
3. Sauvegarder avant de mettre à jour
Copiez les fichiers et la base, et gardez la copie hors du serveur. Passer de 8.2.34 à 8.2.35 reste une mise à jour mineure, au risque faible. Redémarrez ensuite le service PHP, sinon les anciens workers continuent de tourner avec le code vulnérable.
4. Réduire l'exposition en attendant
Si le correctif tarde, posez les mesures d'attente décrites plus bas. Elles réduisent certains chemins d'attaque et ne rendent pas le site sûr.
5. Surveiller les journaux
Cherchez dans les journaux PHP et nginx les erreurs fatales répétées, les messages « Maximum execution time exceeded », les redémarrages de workers et les requêtes d'envoi de fichiers inhabituelles. Surveillez aussi les nouveaux fichiers PHP dans wp-content/uploads et les comptes administrateurs inconnus. Des journaux calmes ne prouvent rien : le projet PHP le dit lui-même.
5. Si vous ne pouvez pas mettre à jour tout de suite
Le projet PHP publie une liste de mesures d'attente. Il précise qu'elles réduisent l'exposition à certains chemins d'attaque et ne rendent pas l'installation sûre. Après chaque changement, redémarrez tous les workers et vérifiez qu'aucun réglage de pool, de dossier ou d'application ne rétablit l'ancienne valeur.
Contre la première faille
Fixez memory_limit à -1 dans la configuration du pool FPM avec php_admin_value, pour qu'aucune application ne la rétablisse. Posez un post_max_size bas : 8M sans envoi de fichiers, 32M avec. Bloquez les requêtes multipart en amont si le site n'en a pas l'usage. Attention : sans limite côté PHP, un script gourmand peut saturer le serveur, donc bornez la mémoire au niveau du conteneur ou du système.
Contre la seconde faille
Désactivez session.upload_progress.enabled dans php.ini ou dans le pool FPM, puis redémarrez tous les workers. N'utilisez ni ini_set() ni .user.ini, qui s'appliquent trop tard. Sous PHP 8.5, ajoutez fatal_error_backtraces=0. Retirez aussi les directives PHP obsolètes qui produisent des avertissements au démarrage de chaque requête.
Option radicale
Le projet PHP cite pm.max_requests=1, qui recycle chaque worker après une requête et coupe le lien entre deux requêtes. Le coût en performances est élevé, donc réservez-le à un site peu chargé en attendant le correctif.
Sur un hébergement mutualisé, vous n'avez pas la main sur ces réglages. Le seul levier est de demander à l'hébergeur son calendrier et de choisir la version corrigée dès qu'elle apparaît dans le sélecteur.
6. Conformité : ce que ça change pour vous
Une boutique compromise expose des données de clients : noms, adresses, historique de commandes. L'article 32 du RGPD impose des mesures de sécurité adaptées au risque, et laisser une faille critique publique ouverte pendant des semaines devient difficile à défendre. En cas de fuite de données personnelles, la notification à la CNIL doit intervenir sous 72 heures.
Pour les entités soumises à NIS2, la gestion des vulnérabilités et des correctifs fait partie des mesures attendues, y compris chez vos prestataires d'hébergement. Notez dans votre registre la date de publication du correctif, la date d'application et la personne qui l'a faite : en cas de contrôle ou de sinistre, cette trace compte.
7. Ce que 2LKATIME recommande
Mettez à jour PHP aujourd'hui si vous gérez votre serveur, ou obtenez une date écrite de votre hébergeur. Ensuite, regardez ce que la faille aurait pu atteindre chez vous : comptes inutiles, fichiers téléversés exécutables, sauvegardes stockées sur le même serveur. Nos audits cybersécurité commencent par cet inventaire.
Les structures de Paris, de Lyon ou de Bordeaux trouveront les formules sur nos pages tarifs. Le diagnostic d'un site WordPress ou d'une boutique se fait aussi à distance, partout en France.
FAQ - Failles critiques PHP
Mon site WordPress est-il vulnérable ?
Si votre version de PHP est antérieure à 8.2.35, 8.3.36, 8.4.27 ou 8.5.12, elle contient les deux failles. L'exploitation dépend du mode d'exécution et de la configuration, mais le projet PHP demande la mise à jour immédiate dans tous les cas. WordPress n'est pas en cause : le défaut se trouve dans le moteur PHP, donc aussi sous WooCommerce, PrestaShop ou Magento.
Comment connaître ma version de PHP ?
Dans WordPress, ouvrez Outils puis Santé du site, onglet Info, section Serveur. Sur un serveur que vous gérez, la commande php -v donne la version de la ligne de commande, et php-fpm -v celle du service web. Sur un hébergement mutualisé, le panneau de l'hébergeur indique la version active pour chaque site.
Mon hébergeur mutualisé s'en occupe-t-il ?
En principe oui, puisqu'il gère le serveur. Demandez-lui une confirmation écrite avec une date, car certains hébergeurs laissent le choix de la version PHP dans le panneau de contrôle. Si un sélecteur de version existe, passez sur la dernière version disponible dès qu'elle contient le correctif.
Un pare-feu applicatif (WAF) suffit-il à se protéger ?
Non. Le projet PHP écrit que seule la mise à jour règle complètement le problème. Un WAF ou une règle nginx peut bloquer les requêtes multipart anormales, ce qui réduit l'exposition à la première faille, mais il ne couvre pas tous les chemins de la seconde. Gardez-le comme protection d'appoint pendant la mise à jour.
Que faire si je soupçonne une compromission ?
Isolez le site, conservez les journaux, puis cherchez les fichiers PHP récents dans les dossiers d'envoi, les comptes administrateurs inconnus et les tâches planifiées suspectes. Restaurez une sauvegarde saine sur un PHP corrigé et changez tous les secrets : mots de passe, clés de wp-config.php, accès à la base et clés d'API. Si des données personnelles sont touchées, la notification à la CNIL se fait sous 72 heures.
Sources
Votre site tourne-t-il sur une version de PHP vulnérable ?
2LKATIME contrôle votre version de PHP, la configuration de votre serveur et l'exposition de votre site, puis vous remet un plan d'action priorisé.