Next AI v2 IA générative

PHP : deux failles à 9,2, des sites se coupent du web

Le projet PHP a publié le 21 octobre 2026 des correctifs pour deux failles permettant l'exécution de code à distance sans authentification. Des agences recommandent de couper les systèmes non corrigés, et plusieurs sites se sont déconnectés.

· 782 mots · Rédigé par une IA

Le projet PHP a publié le 21 octobre 2026, à 13 h 30 UTC selon CERT-EU, les versions 8.5.12, 8.4.27, 8.3.36 et 8.2.35. Elles corrigent deux vulnérabilités critiques, CVE-2026-109618 et CVE-2026-109619, qui peuvent permettre une exécution de code à distance sans authentification. Les deux sont notées 9,2 sur l'échelle CVSS. Les autorités, dont la CISA américaine, demandent un correctif immédiat. Plusieurs sites ont préféré se couper du web en attendant.

Deux failles, un même risque

Selon l'annonce du projet PHP, toute installation qui sert des requêtes web est concernée : PHP-FPM, Apache avec mod_php, php-cgi, FrankenPHP et LiteSpeed. Le risque est jugé maximal pour mod_php. Un exploit démontré y permet à une requête non authentifiée de déclencher l'attaque avant l'exécution du moindre code applicatif.

La première faille (CVE-2026-109618) tient à la gestion des dépassements de mémoire. PHP interrompt une requête qui dépasse son memory_limit au moyen de longjmp(). Cela peut survenir alors que des données internes sont à moitié initialisées, par exemple pendant l'analyse d'un envoi de fichier par formulaire. Le nettoyage tente alors de libérer de la mémoire jamais initialisée, qui peut contenir des données issues d'allocations précédentes contrôlées par l'attaquant, détaille CERT-EU.

La seconde (CVE-2026-109619) concerne un état global périmé. Des données propres à une requête survivent à la libération de la mémoire qui les contenait, après une erreur fatale par exemple. La requête suivante traitée par le même processus peut s'en servir avant la réinitialisation normale.

Qui doit mettre à jour, et comment

Les branches 8.2 à 8.5 antérieures aux versions corrigées sont touchées, ainsi que les branches en fin de vie (8.1 et antérieures), qui ne reçoivent plus de mises à jour du projet. Certaines distributions et fournisseurs LTS proposent des correctifs rétroportés. Vu la gravité, l'équipe sécurité de PHP a aussi publié des rétroportages minimaux du code source pour PHP 7.4, 8.0 et 8.1.

Le dépôt bénévole rpms.remirepo.net n'aura pas de mise à jour le jour de la publication. Le projet PHP conseille de passer aux paquets de la distribution ou de compiler depuis les sources.

Pour ceux qui ne peuvent pas mettre à jour tout de suite, le projet liste des mesures partielles, qui ne rendent pas une installation sûre. Pour la première faille : memory_limit=-1 de façon non modifiable par les applications, une valeur basse de post_max_size (8 Mo, ou 32 Mo si des envois de fichiers sont nécessaires), des limites au niveau du serveur ou du proxy, et une limite de conteneur ou de cgroup. RLIMIT_AS et RLIMIT_DATA sont à proscrire, car ils peuvent provoquer l'échec d'allocation visé. Pour la seconde : session.upload_progress.enabled=0, et sur PHP 8.5 fatal_error_backtraces=0, avec redémarrage des processus. Ces réglages ne bloquent que les chemins confirmés.

CERT-EU rappelle que de nombreux produits embarquent PHP sans l'exposer directement. Il renvoie au dépôt GitHub du NCSC-NL pour repérer les logiciels tiers concernés. La CISA, qui désigne les failles sous le nom « php2shell », demande d'inventorier les systèmes et de corriger en priorité ceux exposés à Internet. Elle recommande de mettre hors ligne ceux qui ne peuvent être mis à jour ou qui tournent sous PHP 8.1 ou antérieur, et de surveiller les processus PHP qui lanceraient des shells ou téléchargeraient des outils.

Des sites hors ligne, une exploitation incertaine

Selon NBC News, PHP est utilisé par 69 % des sites d'après W3Techs, et près de 55 millions de propriétés web en faisaient tourner mercredi, d'après Censys. Pinboard, certaines parties de Wikipédia, 4Chan et Something Awful étaient indisponibles. Des sites japonais l'étaient aussi, selon ITmedia.

Le niveau d'exploitation reste flou. La CISA indique ne pas avoir « observé d'exploitation » au moment de sa publication. Patchstack dit avoir reçu des « signalements d'exploitation active », et le directeur technique de Cloudflare écrit voir émerger des attaques précoces. CERT-EU relève que des preuves de concept commencent à circuler, ce qui rend l'exploitation déjà plausible. « Aujourd'hui, les gens essaient de passer de "tout PHP est vulnérable" à une vision précise », explique Silas Cutler, chercheur principal en sécurité chez Censys, qui prévoit une meilleure évaluation « dans quelques jours » (traduction) (NBC News).

OpenAI affirme avoir contribué à la découverte, via son programme d'accès à des modèles pour les sociétés de cybersécurité. L'entreprise juge ces failles parmi « les problèmes de sécurité les plus lourds de conséquences de mémoire récente » (traduction) (NBC News).

La publication a aussi été compliquée par une rupture d'embargo. D'après la PHP Foundation, Chainguard a diffusé les détails du correctif six heures avant sa sortie, ce qui facilitait sa rétro-ingénierie. Chainguard n'avait pas répondu à NBC News au moment de la publication.

Le projet Node.js a de son côté annoncé le même jour des correctifs de sécurité, dont un pour une écriture hors limites dans son décodeur Brotli, mais cela concerne un autre produit.

Sources

PHP faille critique RCE cybersécurité CISA