Failles critiques PHP : ce qu’il faut savoir et comment nous avons protégé nos clients

Publié le 22 octobre 2026 · Par Olivier Guimard · Lecture : 6 min

Le 21 octobre 2026, l’équipe de développement de PHP a publié les correctifs de deux failles PHP critiques (CVE-2026-109618 et CVE-2026-109619), notées 9,2 sur 10 et capables de permettre l’exécution de code à distance. Chez L’Agence Webmarketing, nous avions prévenu nos clients en amont : leurs sites ont été mis à jour dès la publication du correctif, sans attaque ni défaut de service constaté. Voici ce qu’il faut comprendre de ces failles et la façon dont nous traitons ce type d’alerte.

Que s’est-il passé ?

PHP fait tourner une très grande partie du web : WordPress, Drupal, Joomla, Laravel, Symfony et de nombreux sites sur mesure s’appuient sur lui. Quand une faille touche PHP lui-même, tous les sites qui l’utilisent sont concernés, quel que soit le CMS.

• 20 octobre 2026 : les deux identifiants CVE ont fuité sur des forums et des réseaux sociaux avant la date prévue. L’équipe PHP a avancé sa pré-annonce, et la sortie des correctifs est passée du 22 au 21 octobre.
• 21 octobre 2026, 16 h (heure de Paris) : publication des correctifs, accompagnée d’alertes des autorités de cybersécurité, dont le CERT-FR.

Au moment de la divulgation publique, l’équipe sécurité de PHP indiquait n’avoir identifié aucun exploit fonctionnel en circulation. Plusieurs chercheurs s’attendent toutefois à des tentatives d’exploitation automatisées après la publication, ce qui rend la mise à jour urgente. La presse généraliste s’en est aussi fait l’écho, notamment la RTS.

Les deux failles PHP expliquées simplement

Les deux vulnérabilités sont de type « exécution de code à distance » (RCE) : un attaquant pourrait faire exécuter ses propres instructions par le serveur. Elles ont la même gravité, 9,2 sur 10 selon l’échelle CVSS v4.0, et partagent une origine commune : la gestion de la mémoire quand PHP interrompt brutalement le traitement d’une requête.

• CVE-2026-109618 — mémoire insuffisanteSi une requête atteint la limite de mémoire (memory_limit) au mauvais moment, PHP peut réutiliser des données internes partiellement initialisées. La mémoire est alors corrompue, ce qui peut conduire à l’exécution de code.
• CVE-2026-109619 — état global obsolèteAprès une erreur fatale mal placée, un pointeur peut survivre à la libération de la mémoire d’une requête. La requête suivante, traitée par le même processus, peut alors l’utiliser à tort.

Pourquoi c’est sérieux. Selon l’annonce de PHP, une exécution de code a été démontrée sur Apache avec mod_php, avec les réglages par défaut, par une requête non authentifiée et avant même l’exécution du code de votre application. Autrement dit, un site bien développé et à jour côté CMS reste exposé si l’interpréteur PHP du serveur est vulnérable. C’est pourquoi la mise à jour de PHP est la seule solution complète. Toutes les installations qui servent des requêtes web sont concernées : PHP-FPM, mod_php, php-cgi, FrankenPHP ou LiteSpeed.

Qui est concerné, et quelles versions corriger ?

Selon le CERT-FR, sont vulnérables toutes les versions de PHP 5.x, 6.x, 7.x, 8.0.x et 8.1.x, ainsi que les versions 8.2 à 8.5 antérieures aux correctifs ci-dessous.

Si votre site tourne sur une version non supportée, la mise à jour de PHP devient un chantier de migration. C’est le même enjeu que celui que nous décrivions pour la fin de vie de Drupal 7 et pour la migration de Drupal 10 vers Drupal 11 : mieux vaut l’anticiper que la subir en urgence.

Comment l’Agence Webmarketing traite ce type de sujet

Une alerte de sécurité de cette ampleur ne se gère pas dans l’improvisation. Voici, concrètement, comment nos développeurs ont traité cet événement :

1. Veille permanenteNous suivons en continu les alertes de sécurité qui touchent les technologies de nos clients. Cette veille nous a permis de réagir dès l’annonce de l’échéance de publication des correctifs.
2. Information anticipée des clientsNos développeurs ont averti nos clients en avance, en attendant la publication du correctif prévue le 21 octobre à 16 h, afin qu’ils sachent ce qui allait se passer et quand.
3. Mise à jour de l’ensemble des sitesDès la publication du correctif, nous avons mis à jour l’ensemble des sites de nos clients.
4. Surveillance et disponibilitéAucune attaque ni défaut de service n’a été constaté. Nous restons en veille : tout est mis en œuvre pour que les services digitaux de nos clients restent opérationnels.

Cette approche prolonge ce que nous défendons depuis toujours : l’importance des mises à jour de sécurité, la transparence envers nos clients et une maintenance suivie de leurs sites. Elle compte aussi dans le choix d’un prestataire, en particulier dans les secteurs réglementés : c’est l’un des critères à examiner pour choisir son prestataire digital en mutuelle santé. Pour découvrir l’équipe, rendez-vous sur la page Qui sommes-nous.

Que faire de votre côté ?

Si vous gérez vous-même un serveur ou un site PHP, voici les étapes recommandées par l’équipe PHP et par le CERT-FR :

1. Identifier votre version de PHPVérifiez la version réellement utilisée par le site web, qui peut différer de celle de la ligne de commande. Inventoriez aussi les anciens serveurs, conteneurs et outils internes.
2. Mettre à jour PHPPassez à 8.5.12, 8.4.27, 8.3.36 ou 8.2.35 selon votre branche, puis redémarrez PHP-FPM ou Apache. Avec Docker, reconstruisez les images. Les processus déjà lancés gardent l’ancienne version en mémoire.
3. Sinon, appliquer les mesures provisoiresElles réduisent l’exposition mais ne rendent pas l’installation sûre. À poser dans le php.ini ou la configuration du pool, jamais avec ini_set() ni .user.ini, puis redémarrer tous les processus.
4. Planifier la migration des versions anciennesPour PHP 8.1 et antérieures, limitez l’accès au site (pare-feu, liste d’adresses) en attendant de migrer vers une branche supportée.

; Mesures provisoires recommandées par l'équipe PHP (ne remplacent pas la mise à jour)
memory_limit = -1
post_max_size = 8M          ; 32M si les envois de fichiers sont nécessaires
upload_max_filesize = 6M    ; doit rester inférieur à post_max_size
session.upload_progress.enabled = 0
; PHP 8.5 uniquement :
fatal_error_backtraces = 0

Sur un hébergement mutualisé, c’est à votre hébergeur de mettre à jour PHP : demandez-lui explicitement la version installée et la date de déploiement du correctif.

Questions fréquentes sur les failles PHP

Sources

• php.net — annonce de sécurité du 21 octobre 2026
• Avis de sécurité GHSA-w8hw-w9fx-j79w (CVE-2026-109618)
• Avis de sécurité GHSA-6wmf-4rv5-p3rp (CVE-2026-109619)
• CERT-FR — alerte CERTFR-2026-ALE-014
• PHP Foundation — billet du 21 octobre 2026
• RTS — Cybersécurité : deux failles majeures découvertes dans PHP