Faille PHP critique : pourquoi les sites Drupal 7 sont les plus exposés

Le 21 octobre 2026, l’équipe de sécurité de PHP a publié deux vulnérabilités critiques, référencées CVE-2026-109618 et CVE-2026-109619, avec un score CVSS de 9,2 sur 10. Elles permettent une exécution de code à distance sans authentification. Le CERT-FR a émis une alerte le jour même. La CISA a recommandé de mettre hors ligne les systèmes qui ne peuvent pas être corrigés.

Si votre site tourne sous Drupal 7, votre situation n’est pas la même que celle des autres. Pas parce que Drupal 7 serait particulièrement vulnérable à cette faille précise, mais parce que les sites restés en Drupal 7 cumulent presque toujours une version de PHP ancienne et une absence de correctifs côté Drupal. Et cette seconde moitié du problème, qui est la plus grave, passe souvent complètement inaperçue.

Ce qui s’est passé le 21 octobre

Les deux vulnérabilités visent le traitement interne des requêtes par PHP. Le vecteur confirmé passe par session.upload_progress, une fonctionnalité activée par défaut depuis PHP 5.4 et qui reste atteignable même si votre application n’appelle jamais session_start(). Autrement dit, aucune configuration applicative particulière n’est nécessaire pour être exposé. Un site Drupal standard l’est par défaut.

Les versions corrigées sont PHP 8.5.12, 8.4.27, 8.3.36 et 8.2.35. Ce sont les seules branches encore officiellement maintenues par le projet PHP.

Sur l’exploitation réelle, les sources divergent et il faut rester précis. Le CERT-FR indique avoir connaissance de preuves de concept publiques. La CISA précisait, au moment de sa publication, ne pas avoir observé d’exploitation. Certains éditeurs de sécurité annoncent des tentatives constatées. La lecture raisonnable est celle d’une fenêtre qui se referme vite, pas d’une attaque généralisée déjà en cours. Cela ne change rien à l’urgence de corriger.

Le cas particulier de PHP 7.4

PHP 7.4 est en fin de vie depuis le 28 novembre 2022. Sa dernière version officielle est la 7.4.33 et il n’y aura jamais de 7.4.34. Pourtant, le CERT-FR liste explicitement les branches 5.x et 7.x parmi les versions affectées.

L’équipe de sécurité de PHP a publié des branches de code source contenant un correctif minimal pour 7.4, 8.0 et 8.1. Il faut comprendre ce que cela signifie exactement : ce ne sont pas des versions, il n’y a pas d’archive officielle à télécharger et le correctif se contente de désactiver purement et simplement session.upload_progress, là où les branches maintenues reçoivent une correction complète. Un binaire compilé depuis ces branches se déclare d’ailleurs en version de développement.

En pratique, la plupart des sites ne compilent pas PHP eux-mêmes. La correction arrive par trois canaux :

Les paquets des distributions. Les dépôts d’Ondřej Surý, largement utilisés sur Debian et Ubuntu, ont publié un paquet php7.4-fpm corrigé dès le 21 octobre. Ubuntu Pro a diffusé un correctif équivalent pour 20.04 LTS, via un abonnement payant.

Les hébergeurs mutualisés. Beaucoup ont appliqué les correctifs automatiquement sur toutes les versions qu’ils proposent, souvent en quelques heures et basculé session.upload_progress à Off par défaut. Si vous êtes chez un hébergeur de ce type, il y a de bonnes chances que le travail soit déjà fait sans que personne ne vous ait prévenu.

Les offres de support étendu de PHP, proposées par plusieurs éditeurs commerciaux pour les branches hors support.

Un piège à connaître : chez plusieurs hébergeurs, le numéro de version affiché ne change pas après l’application du correctif. Un php -v ou une page phpinfo() continuera d’indiquer la même version. Vous ne pouvez donc pas conclure par vous-même que vous n’êtes pas corrigé. Posez la question à votre hébergeur, c’est la seule réponse fiable.

Le vrai problème se trouve du côté de Drupal

Pendant que l’attention se porte sur PHP, un avis autrement plus direct est passé sous les radars.

Le 14 octobre 2026, soit une semaine avant la faille PHP, le projet Drupal a publié l’avis SA-CORE-2026-014, référencé CVE-2026-108097. Il s’agit d’une exécution de code à distance, classée critique avec un score de 19 sur 25, ne nécessitant aucune authentification. Les versions corrigées sont Drupal 10.6.19, 11.3.19 et 11.4.10.

Pour Drupal 7, l’avis indique qu’aucun correctif n’est disponible. C’est la conséquence mécanique de la fin de vie, prononcée le 5 janvier 2025.

La dernière version communautaire de Drupal 7 est la 7.103, publiée le 4 décembre 2024. Si votre site en est resté là, il lui manque aujourd’hui quatre versions de sécurité, toutes publiées après la fin de vie par le programme de support étendu commercial : la 7.104, qui corrige une vulnérabilité dans une bibliothèque JavaScript utilisée notamment par Views, la 7.105, la 7.106 qui reprend un avis d’août 2026 et la 7.107 qui corrige précisément la faille critique du 14 octobre.

Un site Drupal 7 dont PHP a été corrigé par son hébergeur reste donc exposé à une exécution de code à distance critique, côté applicatif, sans correctif gratuit disponible.

Ce que vous pouvez vérifier dès aujourd’hui

Quatre vérifications, dans l’ordre. Aucune ne demande de compétence particulière.

Votre version de Drupal. Dans l’administration, la page des rapports d’état l’affiche. Si vous lisez 7.103 ou une version inférieure, vous êtes concerné par ce qui précède.

Votre version de PHP. Même page. Et si elle est inférieure à 8.0, gardez à l’esprit que le numéro affiché ne dit rien de l’application du correctif.

L’état de votre hébergement. Écrivez à votre hébergeur et posez une question simple : les correctifs du 21 octobre ont-ils été appliqués à la version de PHP que sert mon site et session.upload_progress est-il désactivé ? Conservez la réponse par écrit.

L’exposition de vos fichiers de version. Beaucoup de sites Drupal 7 servent encore publiquement leur fichier CHANGELOG.txt, qui annonce la version exacte à qui la demande. Ce n’est pas une vulnérabilité en soi, mais cela transforme une recherche automatisée en liste de cibles. Bloquer ce fichier prend deux minutes.

Les trois voies possibles, sans détour

Une fois le constat posé, il n’existe que trois réponses honnêtes.

Souscrire au support étendu de Drupal 7. Deux fournisseurs seulement sont certifiés dans le programme officiel, HeroDevs et Tag1 Consulting. Ils livrent les versions 7.104 à 7.107 et les suivantes, pour le cœur de Drupal, les modules contribués et les thèmes. Le code spécifique à votre site n’est jamais couvert. C’est la seule façon d’obtenir aujourd’hui le correctif de la faille du 14 octobre sans migrer. C’est une dépense récurrente qui n’achète que du temps.

Remonter la version de PHP. C’est souvent plus simple qu’on ne le croit et c’est le point que la plupart des équipes ignorent : Drupal 7.103 passe officiellement ses tests sous PHP 8.3. La compatibilité PHP 8.1 est arrivée avec la 7.92, la 8.2 avec la 7.94 et la 8.3 avec la 7.103. Si votre site est bloqué en 7.4, le blocage ne vient donc pas du cœur de Drupal, mais de vos modules contribués, de votre thème ou de votre code spécifique. C’est un diagnostic borné, pas une fatalité. Nous détaillons les versions compatibles dans notre article sur PHP et Drupal.

Viser PHP 8.3 a un intérêt pratique : cette branche reçoit des correctifs de sécurité jusqu’au 31 décembre 2027. PHP 8.2 sort du support dès le 31 décembre 2026, ce qui en fait une cible insuffisante.

Migrer. C’est la seule voie qui supprime le problème au lieu de le reporter. Le passage de Drupal 7 vers Drupal 11 n’est pas une mise à jour, c’est une migration de données, avec des outils dédiés intégrés au cœur de Drupal. Nous avons décrit la démarche complète dans notre guide de migration de Drupal 7 vers Drupal 11, ainsi que les risques réels de l’immobilisme dans Rester sur Drupal 7.

Ce qu’il faut retenir

La faille PHP du 21 octobre est sérieuse, mais pour beaucoup de sites elle est déjà corrigée par l’hébergeur, sans action de leur part. Elle sert surtout de révélateur.

Ce qu’elle révèle, c’est qu’un site resté en Drupal 7 accumule deux dettes au lieu d’une. La première, celle de PHP, se règle par un appel à l’hébergeur ou un changement de version. La seconde, celle de Drupal, ne se règle plus gratuitement. Une vulnérabilité critique sans correctif y est désormais la situation normale plutôt que l’exception.

La bonne question n’est donc pas de savoir si vous êtes à jour aujourd’hui. C’est de savoir combien de fois vous accepterez de vous reposer la question et à quel prix, avant de faire le pas qui y met fin.

Votre site tourne encore sous Drupal 7 et vous voulez savoir précisément ce qui vous bloque et ce que coûterait d’en sortir ? Parlons de votre projet. Si la situation est urgente, nous proposons aussi une intervention de support.