L'IA a découvert des failles de mémoire dans le moteur PHP qui permettent à un attaquant de prendre le contrôle de serveurs exécutant la majeure partie du Web
L'équipe de sécurité PHP a publié le 21 octobre des correctifs d'urgence pour deux vulnérabilités critiques dans le moteur principal du langage.
Les deux ont un score CVSS v4.0 de 9,2. Une exploitation réussie donne à un attaquant distant non authentifié l'exécution de code en tant que travailleur Web sur n'importe quel serveur exécutant une version PHP vulnérable. PHP fonctionne sur environ 70 % des sites Web dont le langage côté serveur est connu, selon les mesures de W3Techs qui se situent dans cette fourchette depuis des années.
WordPress, Drupal, Joomla, Magento, Laravel et les scripts simples sont tous exposés lorsque l'interpréteur sous-jacent l'est.
Les problèmes sont suivis sous les noms CVE-2026-109618 et CVE-2026-109619. Ce ne sont pas des bugs dans le code de l’application. Ils résident dans la gestion par le moteur de la mémoire des requêtes et des erreurs fatales.Wiz Research a rapporté le premier d'entre eux en août après avoir utilisé son système Atlas avec Gemini 4 Argon et GPT-5.6 Sol.
Les modèles ont permis de localiser les conditions, d'enchaîner les effets de mémoire et d'adapter les exploits résultants entre les versions PHP, les SAPI et les dispositions de tas qu'un seul chercheur aurait autrement passé des mois à cartographier à la main.
Une preuve de concept fonctionnelle et non authentifiée par rapport aux conteneurs WordPress et Drupal actuels était prête quelques jours après la découverte initiale. La société a ensuite publié un article technique sous le nom de PHP2Shell.
Le mécanisme principal est l'utilisation par le moteur de longjmp() pour abandonner une requête en cas de manque de mémoire. PHP traite l'épuisement de la mémoire comme fatal et sort du contexte actuel plutôt que d'exécuter un nettoyage normal qui pourrait lui-même allouer.Dans plusieurs chemins — analyse de formulaire en plusieurs parties qui étend les en-têtes ou les champs imbriqués au-delà des valeurs apparentes post_max_size et memory_limit, gestion de la progression du téléchargement de session et certaines étapes de traçage des erreurs ou de persistance OPcache — les structures appartenant aux requêtes sont allouées puis laissées partiellement initialisées ou toujours référencées à partir de l'état global du processus lorsque le saut se produit.
Le tas de requêtes est ensuite libéré, mais les variables globales (BG(unserialize), EG(last_fatal_error_backtrace), identifiants de session et similaires) continuent de pointer vers la mémoire désormais invalide.
Une requête ultérieure traitée par le même travailleur peut lire ou écrire via ces pointeurs obsolètes avant que l'initialisation normale ne les remplace. Avec une disposition de tas contrôlée, le résultat est une utilisation après libération qui produit une lecture ou une écriture arbitraire et, dans les cas démontrés, une exécution complète du code.Un avis décrit le chemin OOM en détail : une requête en plusieurs parties peut forcer l'échec de l'allocation au démarrage ou lors d'une analyse précoce ; longjmp() ignore la réinitialisation correspondante ; l'arrêt ou les premiers diagnostics de la requête suivante fonctionnent alors sur l'état corrompu. L'avis complémentaire couvre le cas global obsolète plus large, dans lequel des erreurs fatales, des diagnostics non fatals pendant l'arrêt ou des opérations de session interrompues laissent la mémoire des demandes accessible à tous les travailleurs.
Il a été confirmé que les deux produisaient une exécution de code à distance non authentifiée dans les limites par défaut des configurations courantes telles qu'Apache mod_php avec prefork. La divulgation en mémoire d'autres requêtes’ données (informations d'identification, jetons, clés) est également possible.
Les failles sont présentes depuis au moins PHP 5.4 ; chaque version publiée au cours de la dernière décennie est affectée par au moins l'une d'entre elles.Des correctifs sont disponibles pour les branches prises en charge : 8.2.35, 8.3.36, 8.4.27 et 8.5.12.
Les succursales plus anciennes ne reçoivent aucune solution officielle. Les estimations du nombre d'hôtes exposés connectés à Internet qui continuent de promouvoir une version varient d'environ 1,3 million à plus, avec une fraction substantielle de versions en fin de vie qui ne peuvent pas être mises à jour sur place.
Certains hôtes ont déjà désactivé session.upload_progress comme atténuation temporaire en attendant les packages. Les premières tentatives de numérisation et d'exploitation ont été signalées le matin de la sortie.
Les propres avis de sécurité du projet PHP sur GitHub donnent les modes de défaillance précis et le remplacement du chemin OOM dur longjmp() par une défaillance logicielle retardée plus une _exit() immédiate en cas d'épuisement réel.
Le dossier de recherche est public. Le message de Wiz détaille le processus de découverte, les racines spécifiques de la sécurité de la mémoire et le calendrier de divulgation du 19 août à la publication du 21 octobre. Les deux avis de sécurité GitHub dans le référentiel php-src précisent la corruption d'OOM et l'utilisation après libération globale obsolète.
Le compte rendu du Wall Street Journal publié le même jour présente la réponse opérationnelle actuellement en cours. La limite pratique est la même que celle qui s'appliquait à tous les problèmes antérieurs du moteur PHP : l'interpréteur doit être mis à jour ou le service mis hors ligne. Les correctifs au niveau de l’application ne ferment pas ces chemins.
Ne0199
ne0199@libestria.fr
npub1csta...qa3l
No Free Internet Without Free Software !
𝓕𝓻𝓮𝓮𝓭𝓸𝓶𝓼 𝓪𝓻𝓮𝓷'𝓽 𝓰𝓲𝓿𝓮𝓷, 𝓽𝓱𝓮𝔂'𝓻𝓮 𝓽𝓪𝓴𝓮𝓷 !!
https://nostrmap.fr
🟠 Monero : 891R4MmLqApXoEY853R3JS2j3GNqWUfxEQBpXsdLxc5W6UoK1ntjQwzPKukNCsFfRs4uW5nCHyvm5Lq3ZLyLnqBcDCBTrs1
.
..:
L'IA a découvert des failles de mémoire dans le moteur PHP qui permettent à un attaquant de prendre le contrôle de serveurs exécutant la majeure partie du Web
L'équipe de sécurité PHP a publié le 21 octobre des correctifs d'urgence pour deux vulnérabilités critiques dans le moteur principal du langage.
Les deux ont un score CVSS v4.0 de 9,2. Une exploitation réussie donne à un attaquant distant non authentifié l'exécution de code en tant que travailleur Web sur n'importe quel serveur exécutant une version PHP vulnérable. PHP fonctionne sur environ 70 % des sites Web dont le langage côté serveur est connu, selon les mesures de W3Techs qui se situent dans cette fourchette depuis des années.
WordPress, Drupal, Joomla, Magento, Laravel et les scripts simples sont tous exposés lorsque l'interpréteur sous-jacent l'est.
Les problèmes sont suivis sous les noms CVE-2026-109618 et CVE-2026-109619. Ce ne sont pas des bugs dans le code de l’application. Ils résident dans la gestion par le moteur de la mémoire des requêtes et des erreurs fatales.Wiz Research a rapporté le premier d'entre eux en août après avoir utilisé son système Atlas avec Gemini 4 Argon et GPT-5.6 Sol.
Les modèles ont permis de localiser les conditions, d'enchaîner les effets de mémoire et d'adapter les exploits résultants entre les versions PHP, les SAPI et les dispositions de tas qu'un seul chercheur aurait autrement passé des mois à cartographier à la main.
Une preuve de concept fonctionnelle et non authentifiée par rapport aux conteneurs WordPress et Drupal actuels était prête quelques jours après la découverte initiale. La société a ensuite publié un article technique sous le nom de PHP2Shell.
Le mécanisme principal est l'utilisation par le moteur de longjmp() pour abandonner une requête en cas de manque de mémoire. PHP traite l'épuisement de la mémoire comme fatal et sort du contexte actuel plutôt que d'exécuter un nettoyage normal qui pourrait lui-même allouer.Dans plusieurs chemins — analyse de formulaire en plusieurs parties qui étend les en-têtes ou les champs imbriqués au-delà des valeurs apparentes post_max_size et memory_limit, gestion de la progression du téléchargement de session et certaines étapes de traçage des erreurs ou de persistance OPcache — les structures appartenant aux requêtes sont allouées puis laissées partiellement initialisées ou toujours référencées à partir de l'état global du processus lorsque le saut se produit.
Le tas de requêtes est ensuite libéré, mais les variables globales (BG(unserialize), EG(last_fatal_error_backtrace), identifiants de session et similaires) continuent de pointer vers la mémoire désormais invalide.
Une requête ultérieure traitée par le même travailleur peut lire ou écrire via ces pointeurs obsolètes avant que l'initialisation normale ne les remplace. Avec une disposition de tas contrôlée, le résultat est une utilisation après libération qui produit une lecture ou une écriture arbitraire et, dans les cas démontrés, une exécution complète du code.Un avis décrit le chemin OOM en détail : une requête en plusieurs parties peut forcer l'échec de l'allocation au démarrage ou lors d'une analyse précoce ; longjmp() ignore la réinitialisation correspondante ; l'arrêt ou les premiers diagnostics de la requête suivante fonctionnent alors sur l'état corrompu. L'avis complémentaire couvre le cas global obsolète plus large, dans lequel des erreurs fatales, des diagnostics non fatals pendant l'arrêt ou des opérations de session interrompues laissent la mémoire des demandes accessible à tous les travailleurs.
Il a été confirmé que les deux produisaient une exécution de code à distance non authentifiée dans les limites par défaut des configurations courantes telles qu'Apache mod_php avec prefork. La divulgation en mémoire d'autres requêtes’ données (informations d'identification, jetons, clés) est également possible.
Les failles sont présentes depuis au moins PHP 5.4 ; chaque version publiée au cours de la dernière décennie est affectée par au moins l'une d'entre elles.Des correctifs sont disponibles pour les branches prises en charge : 8.2.35, 8.3.36, 8.4.27 et 8.5.12.
Les succursales plus anciennes ne reçoivent aucune solution officielle. Les estimations du nombre d'hôtes exposés connectés à Internet qui continuent de promouvoir une version varient d'environ 1,3 million à plus, avec une fraction substantielle de versions en fin de vie qui ne peuvent pas être mises à jour sur place.
Certains hôtes ont déjà désactivé session.upload_progress comme atténuation temporaire en attendant les packages. Les premières tentatives de numérisation et d'exploitation ont été signalées le matin de la sortie.
Les propres avis de sécurité du projet PHP sur GitHub donnent les modes de défaillance précis et le remplacement du chemin OOM dur longjmp() par une défaillance logicielle retardée plus une _exit() immédiate en cas d'épuisement réel.
Le dossier de recherche est public. Le message de Wiz détaille le processus de découverte, les racines spécifiques de la sécurité de la mémoire et le calendrier de divulgation du 19 août à la publication du 21 octobre. Les deux avis de sécurité GitHub dans le référentiel php-src précisent la corruption d'OOM et l'utilisation après libération globale obsolète.
Le compte rendu du Wall Street Journal publié le même jour présente la réponse opérationnelle actuellement en cours. La limite pratique est la même que celle qui s'appliquait à tous les problèmes antérieurs du moteur PHP : l'interpréteur doit être mis à jour ou le service mis hors ligne. Les correctifs au niveau de l’application ne ferment pas ces chemins.

getmonero.org, The Monero Project
The Monero Project
Monero, a digital currency that is secure, private, and untraceable
monostr est un client Nostr pour Android (Kotlin, Jetpack Compose, rust-nostr) qui permet d'envoyer des pourboires en Monero sur n'importe quelle note ou profil. Il est en public beta et open source sous licence AGPL-3.0-or-later (GitHub, 
Monostr
Nostr with Monero tips
Tip any note or profile in Monero, straight from your own wallet. Free Android app, no Lightning, no custodian.
Monostr watcher
nosmero - Nostr + Monero