PHP2Shell : que faire après une faille de sécurité

Le 21 octobre 2026, le projet PHP a corrigé deux failles critiques de son moteur, surnommées PHP2Shell. La même semaine, OpenJDK a publié son avis de sécurité trimestriel puis un avis critique. Aucune technologie n'est à l'abri des failles. Voici où elles se trouvent et les six étapes à suivre après leur annonce, quel que soit votre runtime.

PHP2Shell : ce qui s'est passé

Le 21 octobre 2026, le projet PHP a publié les correctifs de deux vulnérabilités du moteur PHP : CVE-2026-109618 et CVE-2026-109619. Une CVE est l'identifiant public d'une faille. Leur note de gravité CVSS v4.0 est de 9,2 sur 10.

Ce sont deux failles de mémoire. Dans la première, un manque de mémoire laisse les données d'une requête à moitié préparées. Dans la seconde, une partie d'une requête survit à la mémoire qui la contenait (avis GHSA). L'avis concerne toutes les installations PHP qui traitent des requêtes web. Le risque le plus élevé concerne Apache avec mod_php. Les versions corrigées sont PHP 8.5.12, 8.4.27, 8.3.36 et 8.2.35.

Côté Java, OpenJDK a publié son avis trimestriel le 20 octobre. Il liste 47 CVE et la plus élevée est notée 7,0. Le 21 octobre, OpenJDK a publié un avis supplémentaire pour CVE-2026-91403, notée 9,1. Cette faille concerne huit certificats d'autorité intermédiaires compromis dans la bibliothèque TLS.

Si vous exploitez PHP, suivez l'avis officiel et l'alerte de votre agence nationale : le CERT-FR en France et la CISA aux États-Unis.

Pourquoi aucune plateforme n'est à l'abri

Un CMS est fait de plusieurs couches de logiciels. Une faille peut toucher chacune d'elles et chaque couche se corrige à sa façon.

• Le moteur ou runtime. Ce logiciel exécute le code du CMS. Il s'agit de PHP ou de la machine virtuelle Java (JVM). PHP2Shell et CVE-2026-91403 touchent cette couche. On corrige ce type de faille en mettant à jour le moteur, quelle que soit la version du CMS.
• Les bibliothèques et les frameworks. Le CMS réutilise ces composants. En décembre 2021, Log4Shell touchait la bibliothèque Java Log4j. En mars 2022, CVE-2022-22965 permettait d'exécuter du code à distance dans le framework Spring. On corrige ce type de faille en mettant à jour la dépendance.
• L'application. Il s'agit du code du CMS et de ses extensions. Leur éditeur publie le correctif.

L'intelligence artificielle accélère la découverte des failles. Wiz Research rapporte qu'un seul chercheur a fait en une semaine le travail de plusieurs mois d'une équipe de haut niveau. La PHP Foundation fait le même constat. Son équipe de sécurité a publié 15 CVE depuis le 1er juillet et traité plus de 100 signalements invalides, en doublon ou non reproductibles.

Que faire après une faille : six étapes

Ces six étapes s'appliquent à PHP2Shell et aux prochaines failles, quel que soit le runtime.

1. Lire les sources officielles. L'avis du projet ou de l'éditeur et l'alerte de votre agence nationale sont la référence. Ils indiquent les versions touchées, les versions corrigées et les configurations les plus exposées.
2. Inventorier ce que vous exploitez. Dans son alerte, la CISA demande de recenser chaque instance PHP, y compris celles intégrées à d'autres logiciels. Faites de même pour une JVM livrée avec un produit.
3. Appliquez un correctif au calque dans lequel la vulnérabilité est présente : le moteur, une bibliothèque ou l’application. Une application à jour sur un moteur vulnérable est toujours exposée, et un moteur corrigé ne peut pas protéger une application vulnérable.
4. Corriger d'abord les systèmes critiques. Appliquez les versions corrigées indiquées dans l'avis en commençant par les systèmes accessibles depuis Internet. Si vous ne pouvez pas corriger tout de suite, suivez les consignes de votre agence nationale.
5. Savoir qui corrige et dans quel délai. L'éditeur, l'hébergeur et votre équipe ont chacun un rôle. Écrivez ce partage avant la prochaine faille avec un délai cible entre l'annonce et le correctif.
6. Préparer la prochaine faille. Suivez le calendrier de support de vos versions. Une branche en fin de vie ne reçoit plus de correctifs. Chaque branche PHP reçoit deux ans de support actif puis deux ans de correctifs de sécurité. PHP 8.2 ne recevra plus de correctifs après le 31 décembre 2026. OpenJDK publie ses correctifs en janvier, avril, juillet et octobre. Après la crise, notez ce qui a ralenti la correction.

Les questions à poser à votre éditeur et à votre hébergeur

Posez ces questions avant la prochaine faille. Posez-les à chaque éditeur pour comparer les réponses.

• Quelles versions du runtime et du CMS prenez-vous en charge, et jusqu'à quand ?
• Qui applique les correctifs, et dans quel délai après l'annonce d'une faille ?
• Où publiez-vous vos avis de sécurité ?
• Comment vous signaler une vulnérabilité ?
• En combien de temps pouvez-vous dire si une nouvelle faille nous concerne ?

Notre article sur la sécurité logicielle d'un CMS détaille les bonnes pratiques.

La réaction de la PHP Foundation

Le 21 octobre, la PHP Foundation a publié un billet sur l'origine du retard. Un audit de sécurité externe a relevé les premiers signes du problème en 2024. Aucun vecteur d'attaque concret n'était connu à l'époque. Plusieurs correctifs ont été développés et le travail s'est arrêté puis a repris pendant des mois.

La Foundation qualifie ce retard d'"échec structurel". Elle l'attribue au processus de décision de son équipe de sécurité et à son manque de moyens. Cette équipe compte "un petit groupe de développeurs financés par la fondation et un peu d'aide bénévole". La Foundation a commencé à changer ses processus.

Et chez nous ?

Jahia est un CMS Java. Il s'exécute sur la JVM dans un conteneur de servlets, Apache Tomcat par défaut (Jahia Academy). Nous éditons un CMS Java et nous publions, nous aussi, des correctifs. Notre Trust Center indique que Jahia analyse son code en continu et publie régulièrement des correctifs. Vous pouvez nous signaler une vulnérabilité à security@jahia.com.

Un mot pour les équipes qui corrigent

Corriger une faille critique en pleine semaine est un travail exigeant, et on le voit rarement. Les équipes qui le font, quel que soit leur runtime, ont tout notre soutien.

FAQ