PHP2Shell a explosé : CVSS 9.2, la veille de l'ouverture, et les deux trous étaient en code pendant 10 ans.

Premièrement, la conclusion est la suivante :PHP a produit un code à distance non autorisé pour CVSS 9.2, numéros CVE-2026-109618 et CVE-2026-109619, avec un surnom PHP2Shell. Le 20 octobre, il a été rendu public et le 21 octobre, à 14h00 UTC, des patchs ont été libérés, tandis que les boîtes de miel d'Amazon ont été enregistrées le 17 octobre — quatre jours avant l'ouverture.

Ce qui est pire, c'est l'autre chose : ces deux trous sont les premiers à atteindre PHP 5.4, ce qui signifie...Ils sont en code depuis plus d'une décennie.Je ne sais pas. Et en 2024, quand l'audit du développeur PHP a découvert le chemin d'OOM, l'équipe s'est réunie pour discuter de la façon de le corriger.On n'était pas d'accord et on ne l'a pas réparé.Je ne sais pas. La raison en est que personne ne pensait qu'il pourrait vraiment être utilisé.

Cette phrase semble maintenant particulièrement ironique. La raison pour ne pas pouvoir le faire n'est pas que le trou est insignifiant, mais que la chaîne est trop complexe pour aller au-delà de la capacité physique des chercheurs humains. Puis AI est venu et l'a écrit.

D'abord, éloignez le mot « intervention d'urgence multinationale ». Regarde.

Le mot préféré du parti est "alarme mondiale". Ce n'est pas une exagération cette fois, mais c'est un score clair.

• Fonctionnaire PHP: Un préavis a été émis le 20 octobre, indiquant que le 21 octobre à 14h00 UTC serait publié dans une version sécurisée si les détails étaient divulgués ou affichés. En conséquence, le numéro CVE a été poignardé à Hacker News le même jour, et la sortie prévue pour octobre 22 a été forcée à un jour plus tôt.
• CERT-UE: avis de sortie 2026-018 et inclure les deux CVE.
• NuageflareLe 21 octobre, la CTO Dane Knecht a déclaré directement « l'attaque précoce a été vue pour émerger », et les règles de la WAF ont été publiées dans leur intégralité, y compris les utilisateurs libres. Mais il s'est dit que c'était juste un stopgap, et la vraie solution était de s'arranger.
• Information sur la menace d'Amazon: Des boîtes de miel MadPot ont été capturées le 17 octobre et un autre lot a été capturé le 21 octobre et la charge utile et l'infrastructure ont indiqué un certain nombre d'attaquants différents. php2shell "est déjà largement utilisé".
• Regarder Towr: Les deux trous sont réémergés, tandis que des tentatives d'exploitation des deux sont observées.

Donc "l'attaque a été trouvée" n'est pas un rendu, mais un fait. Et l'intervention d'urgence multinationale n'est pas un coup -- c'est juste que les principaux sujets de l'intervention sont les fabricants, les CDN et les organisations d'urgence, pas aucun gouvernement dans le pays.

Deux, deux trous, deux façons complètement différentes de mourir.

Beaucoup de gens pensent que c'est un trou avec deux chiffres, non. Il s'agit de deux voies d'attaque distinctes, chacune CVSS 9.2.

CVE-2026-109618: Bombe lorsque la mémoire est épuisée

Le traitement d'une requête est interrompu lorsque la distribution de mémoire PHP échoue. Le problème est :À ce stade, les données de la requête interne n'ont peut-être été que demi-initialisées, et la logique de nettoyage subséquente aurait utilisé cette partie non incorporée de mauvaises données comme données valides.

La méthode de déclenchement est simple : construire une requête en plusieurs parties pour imploser la mémoire. Le truc bizarre, c'est,La taille de la demande semble correspondre à votre plafond.Ce n'est pas la taille maximale que vous avez configurée, c'est le décodeur et la consommation de traitement interne.

Le pire est mod php. Mod php pour Apache lorsque la demande de démarrage a échouéÇa va encore nettoyer., de sorte que cette chaîne peut être achevée avant tout fonctionnement de code applicable. Votre code PHP est si propre, il n'y a pas d'échappatoire, il n'y a pas d'arrêt.

PHP-FPM tuera le travailleur quand il ne démarre pas, juste pour couper la chaîne, donc officiellement, mod php est le plus grand risque. Mais attention -- cela ne signifie pas que le FPM est sûr.Après un démarrage réussiIl y a encore une possibilité d'exploitation.

CVE-2026-109619: État sale entre les demandes

Celui-ci est pire. PHP réutilisera le processus worker pour traiter plusieurs requêtes. La dernière demande de libération de la mémoire, le pointeur reste dans l'état interne; la prochaine demande entre en jeu,Lire l'adresse vide avant l'initialisation normale.Je ne sais pas.

Erreurs fatales (épuisement de la mémoire, délai d'exécution) interrompre le nettoyage de l'état. Pire encore, un diagnostic non létal pendant l'arrêt aurait remplacé le mauvais état.Refaire.Je ne sais pas.

Les voies officiellement confirmées incluent : les RCE avec erreur fatale lorsque PHP 8.5 a activé les backtraces d'erreur fatale (ouverture par défaut), et les RCE du cycle de vie de session sur motor php et FPM.session.upload_progress Par défaut, vous pouvez agir comme un consommateur précoce dans un état de saleté.Et il n'y a pas besoin d'appliquer les appelsJe ne sais pas.

Ce trou est toujours attaché.Fuite de mémoireJe ne sais pas. Qu'est-ce qui fuit ? est le mot de passe, jeton, clé API, certificat pour d'autres requêtes dans la mémoire du processus. Wiz directement comparé à Heartbled, ce qui n'est pas trop.

Chronologie, plus que le titre Regardez.

Heure	Que s'est-il passé ?
Année 2024	L'audit du développeur PHP a trouvé OOM, ce bug, l'équipe n'avait pas de consensus sur la loi, la mettre en attente.
2026-08	Ryan Austin de Calif identifie des failles avec OpenAI GPT-5.6 Sol; Wiz Independent Discovery
2026-10-17	Amazon MadPot, le miel peut enregistrer une tentative, quatre jours avant l'ouverture.
2026-10-20	Numéro CVE divulgué dans Hacker News et les médias sociaux, PHP
2026-10-21	14:00 UTC Publication 8.5.12 / 8.4.27 / 8.3.36 / 8.2.35

Le 17 octobre doit être distingué.Le jour public était le 20, mais l'attaque a eu lieu le 17.La proposition Amazon est simple: le point de départ ne devrait pas être la date de publication, mais au moins le 17 octobre.

Quant à la façon dont les attaquants ont obtenu l'information à l'avance, l'Amazon a dit "pas clair." Je ne peux pas y aller, mais tu dois accepter une réalité.Le jour de la divulgation n'a jamais été le jour de l'attaque, mais le jour où vous avez enfin su.

Quatre, cette fois c'est vraiment de l'IA.

Le blog de Wiz.com contient une phrase que j'ai lu à deux reprises : Ces défauts sous-jacents existent depuis des décennies, mais pour prouver qu'ils peuvent être utilisés, ils ont besoin d'une chaîne d'étapes exceptionnellement complexe, en marge des capacités réelles des chercheurs humains.Le modèle IA de première ligne réduit considérablement ce seuil.Je ne sais pas.

Spécifique : Ryan Austin, chercheur à Calif, a été trouvé dans le projet OpenAI "Patch the Planet" avec GPT-5.6 Sol. Wiz a trouvé le même problème indépendamment. Pour en faire usage, nous avons besoin d'une chaîne de défauts et de cibler chaque cible.Mise en page de la mémoire étalonnée à plusieurs reprisesWiz dit que le modèle de première ligne leur permet de développer des applications utilisables pour différentes applications en quelques heures.

Ça ne veut pas dire "AI a encore gagné".Le fait est que les douves de "complexe" échouent.

Beaucoup de vieilles lacunes n'ont pas été éliminées au cours des deux dernières décennies, non pas parce qu'elles ne sont pas graves, mais parce que le seuil d'utilisation est trop élevé — quelques semaines d'investissement de la part de chercheurs de haut niveau et un peu de chance. Donc vous les mettez dans la colonne "théoriquement risqué". Cette clôture a disparu.

Ces trous de dix ans qui se trouvent dans votre système et sont évalués comme "difficiles et non traités" doivent être réévalués.

Cinq, lequel devriez-vous aller ?

Branche	Version affectée	Élimination
PHP 8.5	< 8.5.12	Porter à 8.5.12.
PHP 8.4	< 8.4.27	Porter à 8.4.27.
PHP 8.3	< 8.3.36	Élever à 8.3.36.
PHP 8.2	< 8.2.35	Élevez à 8.2.35.
PHP 7.4 / 8.0 / 8.1	Tous	Officiellement non publié, niveau source seulement
PHP 5.4 – 7.3	Tous	EOL, le gouvernement ne le répare pas. Entreprises

Plusieurs rappels réels :

• Linux Release et LTS VendorJ'ai un patch à l'avance.Consultez l'avis de votre fabricant avec un paquet de distribution. Ne pressez pas le code source.
• Utilisation rpms.remirepo.net Note : PHP a officiellement déclaré la source le 21 octobre.Aucune mise à jourAinsi, vous pouvez passer à un paquet de distribution ou le faire à partir du code source.
• Le binaire Windows de PHP 8.5 est également sur la page de téléchargement officielle.
• Ne pensez pas que c'est bon d'exécuter dans le conteneur -- la version PHP du miroir conteneur doit être vérifiée.

Six, si vous n'avez pas de patch, faites d'abord ces quatre-là.

Premier état :Aucun de ceux ci-dessous ne vous rendra en sécurité.La phrase officielle PHP est "réduire l'exposition à des chemins d'attaque spécifiques, mais ne pas rendre les installations plus sûres". Leur valeur est de vous donner du temps pour obtenir des patchs.

Définir la limite de mémoire à -1

Objectif: Pour supprimer le plafond de mémoire PHP prévisible a échoué, c'est-à-dire que CVE-2026-109618 a confirmé la condition de déclenchement dont elle dépend.

Le fait est,Comment ça ?: à définir dans les endroits où l'application n'est pas modifiée, comme le Pool FPM php_admin_value ou configuration Apache. Vous devez vérifier qu'il n'y a pas de pops, de répertoires, de paramètres d'application pour ajouter la limite.Puis redémarrez chaque travailleur.

Le prix est clair : vous êtes hors de la clôture de mémoire de PHP, et l'échec de distribution en bas peut encore être sur ce chemin dangereux. Donc, il doit être un conteneur ou un cgroup pour limiter la couverture -- mais ce n'est qu'une stratégie pour « tuer les personnes touchées ».N'utilisez jamais RLIMIT AS ou RLIMIT DATACes deux sont précisément le genre d'échecs de distribution qui créent les failles.

Réduire la taille du post max

Sites sans fichier 8M au fichier 32M et garantis upload_max_filesize Moins que ça. En même temps, des limites sont ajoutées au serveur web ou à la couche proxy - le volume des requêtes décodées, le nombre de champs, le nombre de parties multiples, le nombre de têtes, la profondeur des nids.Ces restrictions doivent couvrir les demandes qui ne sont pas valides.Ou on fera le tour.

3. Débrancher le processus session.upload

session.upload_progress.enabled = 0

Il est écrit en php.ini, outil FPM ou configuration du serveur.Elle doit être effective avant la demande.Je ne sais pas. Utilisation ini_set() Ou FPM. .user.ini C'était trop tard, c'était sale. Le changement est également de redémarrer tout workker.

PHP 8.5 Un seul de plus

fatal_error_backtraces = 0

Ce bloc n'a confirmé que des erreurs mortelles en arrière, sans autres variantes. Exigez également les paramètres de niveau administrateur + redémarrer workker.

En outre, l'officiel mentionne que beaucoup vont ignorer:Correction des erreurs fatales que les attaquants peuvent déclencher et exécuter le temps écoulé., y compris sauvegarde, téléchargement, traitement d'importation, pannes de nettoyage. Et...Supprimer les configurations obsolètes ou illégales imposées sur demande- Ils crachent les informations diagnostiques avant qu'elles soient initialisées et alimentent la fuite.

Cette dernière phrase est très facilement mal comprise:Il ne fonctionne pas pour cacher le diagnostic avec des rapports d'erreurs, afficher des erreurs ou @.Ça n'arrivera pas.

VII. De vraies leçons

Je ne veux pas finir en écrivant "Fermer le patch". Bien sûr que c'est un patch. On est aujourd'hui. Mais certains jugements doivent changer.

1. Le terme « difficile à utiliser » n'est plus le même que « prescrit ».PHP la chaîne d'accès de ce trou est assez compliquée pour avoir besoin de l'aide de l'IA, qui a déjà aidé. Les anciens trous de votre liste d'actifs qui marquent le « risque théorique » devraient être réévalués.
2. La langue court à un seul moment.WordPress, Drupal, Joomla, Magento, MediaWiki fonctionnent tous sur PHP, votre audit de code d'application est propre, et le noyau PHP est en difficulté. Rythme compensatoire des couches d'infrastructure, avec des couches d'application séparées.
3. "Le code d'application est cassé sans fonctionner." WAF ne peut que retarder.Cloudflare lui-même a dit que c'était stopgap. Mettre WAF en solution équivaut à donner vie à la couverture des règles.
4. Il y a beaucoup d'anciens sites dans le pays en utilisant PHP.Les stations qui fonctionnent sur PHP 5.6/7.0, qui étaient il y a longtemps non entretenues et suspendues sur un ordinateur central cloud, sont dans cette exposition de 1,3 à 1,9 million. Ils ne recevront aucun avis.

Les calibrations de données sont enregistrées : selon W3Techs, les PHP représentent 69,3 % des langues connues du service, et 70 % de Wiz; les hôtes d ' exposition, le chercheur en sécurité Silas Cutler estime à plus de 1,3 million et la recherche de Shodan de Henk Poley dépasse 1,9 million. Ces nombres sont de calibres différents et ne les utilisent pas comme valeurs précises, mais l'échelle est la même -Des millions dans le monde.

Un détail supplémentaire mérite d'être rappelé : quand le numéro CVE a été divulgué, les points CVSS qui sont sortis étaient 10.0, PHP a été officiellement confirmé.Ce score était faux.En fait, il est 9.2. Personne ne saurait rien de ce détail, mais il sera toujours en circulation. En voyant 10,0, vous savez ce que c'est.

Un trou de 10 ans, deux mois de recherche assistée par l'IA, quatre jours d'utilisation précoce, une fenêtre de patch d'une journée. Ce calendrier est la normale de tous les logiciels de base qui suivent.

Vérifiez la version maintenant.php -vOu regardez vos miroirs de conteneur sur l'étiquette. N'attendez pas demain.