PHP programme un correctif d'urgence pour deux failles critiques notées 9.2

L'équipe de sécurité de PHP publiera une version de sécurité hors cycle le 21 octobre 2026 à 14:00 UTC, pour deux failles qu'elle juge critiques. Selon des chercheurs, ces bugs permettent l'exécution de code à distance, et des détails ont fuité un jour plus tôt. Toute personne qui utilise PHP doit être prête à appliquer le correctif dès la parution de la version.

PHP est le langage qui fait tourner WordPress, Drupal et une grande partie du code serveur du web. Une version hors cycle est publiée en dehors du calendrier de sortie normal du projet. PHP réserve ce type de version aux correctifs urgents.

Ce que l'équipe de sécurité de PHP a annoncé

L'avis de PHP.net, publié le 20 octobre, en dit peu, et c'est voulu. Il cite deux vulnérabilités et note chacune 9.2 sur CVSS v4.0, l'échelle de gravité standard de 0 à 10. Il ne donne ni numéro CVE, ni description, ni numéro de version. Les versions touchées et corrigées « seront publiées avec la mise à jour », indique l'avis.

L'équipe s'est aussi laissé la possibilité d'aller plus vite. Elle indique qu'elle pourra publier plus tôt si les détails deviennent publics ou si des attaques commencent. « Tous les utilisateurs de PHP sont invités à se préparer dès maintenant afin de pouvoir mettre à jour dès que la version sera disponible », indique l'avis.

LWN, un site d'actualité Linux et open source de longue date, a relayé l'avertissement le même jour. Il a demandé à toute personne qui fait tourner un site PHP de se préparer à la mise à jour.

Ce qui a fuité, et ce qui reste non confirmé

The Hacker News rapporte que des chercheurs appellent ces deux failles « php2shell », un nom que PHP n'a pas utilisé. La société de sécurité watchTowr indique que les failles permettent l'exécution de code à distance, ce qui signifie qu'un attaquant pourrait exécuter des commandes sur le serveur. Le 20 octobre, watchTowr a déclaré sur X qu'une fuite à leur sujet était authentique. Elle a ajouté que les failles étaient sous embargo, une période pendant laquelle les détails restent privés jusqu'à la parution d'un correctif.

Cette fuite était un message publié sur Hacker News, le forum technologique. Il indiquait qu'une divulgation était prévue le jeudi 22 octobre, et affirmait que toutes les versions depuis PHP 5 sont touchées. Cette portée n'est pas confirmée. Pour reprendre la FAQ de watchTowr, elle « n'a pas été confirmée par un avis officiel de l'éditeur ».

Les chercheurs associent deux identifiants à ces failles : CVE-2026-109618 et CVE-2026-109619. L'avis de PHP ne cite ni l'un ni l'autre.

Un article autopublié sur jackalsyn.com, signé par un chercheur qui se fait appeler J4ck3LSyN, relie ces identifiants à un bug de type use-after-free dans session.upload_progress. Un use-after-free se produit quand un programme continue d'utiliser une mémoire qu'il a déjà libérée. La fonctionnalité elle-même suit la progression des envois de fichiers dans la session d'un utilisateur.

Cet article note ses propres découvertes bien plus bas que PHP : 5.3, soit Medium, pour un chemin et 0.0 pour un autre. Il n'a reproduit le bug que sur Apache avec mod_php en mode prefork, et il n'a montré aucune exécution de code. Rien ne confirme qu'il décrit les mêmes bugs que ceux que PHP a notés 9.2.

Quelles versions de PHP recevront des correctifs

The Hacker News indique que seules les branches prises en charge, de 8.2 à 8.5, recevront des correctifs. Alpine Linux et le chercheur en sécurité Kevin Beaumont suivent les numéros de version attendus, que PHP n'a pas confirmés.

Branche	Version actuelle	Statut du support	Correctif attendu (non confirmé)
PHP 8.5	8.5.11	Support actif jusqu'au 31 décembre 2027	8.5.12
PHP 8.4	8.4.26	Support actif jusqu'au 31 décembre 2026	8.4.27
PHP 8.3	8.3.35	Correctifs de sécurité uniquement jusqu'au 31 décembre 2027	8.3.36
PHP 8.2	8.2.34	Correctifs de sécurité uniquement jusqu'au 31 décembre 2026	8.2.35
PHP 8.1 et antérieures	Sans objet	Fin de vie	Aucun correctif de PHP

Les anciennes branches représentent une grande part du web. Un comptage Shodan réalisé par Mallory le 20 octobre, cité par The Hacker News, a recensé environ 884 000 hôtes exposés sur Internet qui annoncent PHP 8.1 ou une version antérieure. Cela représente 59 % des quelque 1,5 million d'hôtes qui annoncent une version, quelle qu'elle soit. Environ 740 000 autres annoncent PHP sans version. Il s'agit de comptages de bannières, pas de systèmes dont la vulnérabilité est confirmée.

Aucune attaque n'a été signalée jusqu'ici. Huntress, une société de sécurité, n'avait observé aucune exploitation au 20 octobre et n'avait connaissance d'aucun code d'exploitation public. Les failles ne figurent pas sur la liste des vulnérabilités exploitées connues de la CISA. Ce répit pourrait être court : Akamai a observé des tentatives d'attaque dans les 24 heures qui ont suivi la publication de CVE-2024-4577, une faille PHP antérieure, en juin 2024.

Ce que cela signifie pour les développeurs

Commencez par trouver chaque copie de PHP. Huntress et CERT-EU conseillent tous deux un inventaire qui inclut les copies embarquées, comme PHP dans des images de conteneur, des appliances et des panneaux d'hébergement. Le serveur que vous avez oublié est celui qui se fait attaquer.

Corrigez d'abord les systèmes exposés sur Internet, dès que la version paraît à 14:00 UTC. Elle est depuis sortie sous les numéros PHP 8.5.12, 8.4.27, 8.3.36 et 8.2.35. Si vous installez PHP depuis une distribution Linux ou une image de base de conteneur, vérifiez quand cette source publie son paquet recompilé. Elle peut être en retard sur php.net.

Préparez dès maintenant le cas des branches en fin de vie. PHP 8.1 et les versions antérieures ne recevront aucun correctif du projet. CERT-EU recommande d'« envisager d'isoler des réseaux publics les applications exposées sur Internet jusqu'à ce qu'un correctif soit disponible ». Les autres options sont une mise à niveau, un VPN ou un pare-feu applicatif web placé devant le site.

Traitez la solution de contournement non officielle avec prudence. L'article de jackalsyn.com suggère de définir session.upload_progress.enabled = Off. PHP n'a publié aucune solution de contournement, et cet article ne décrit peut-être pas les bugs que PHP corrige. La plupart des applications n'ont pas besoin de ce réglage, sauf si elles affichent des barres de progression d'envoi, donc le désactiver est une solution d'attente peu coûteuse, pas un correctif.

Guettez les signes de compromission cette semaine. The Hacker News relaie le conseil de déclencher une alerte quand un processus PHP lance un shell ou un outil de téléchargement. Les applications PHP ont connu un mois chargé : Drupal a publié le 14 octobre un correctif pour une faille critique dans Field UI.