Sortie d'urgence de PHP : deux RCE critiques corrigés en 8.2.35 à 8.5.12
PHP a publié une mise à jour de sécurité hors calendrier qui corrige deux vulnérabilités critiques de type use-after-free dans le cœur du langage, toutes deux exploitables pour une exécution de code à distance sans authentification et toutes deux notées 9,2 sur l'échelle CVSS v4.0. Les versions corrigées sont PHP 8.5.12, 8.4.27, 8.3.36 et 8.2.35, publiées aujourd'hui et listées dans les archives de versions du projet. Des backports de source minimaux pour les branches 7.4, 8.0 et 8.1, longtemps abandonnées, existent uniquement sur GitHub - aucun binaire officiel n'est fourni pour elles.
La sortie a été précédée d'une fenêtre de divulgation chaotique. Le 20 octobre, le projet a annoncé une publication d'urgence pour aujourd'hui 14h00 UTC sans nommer les versions ni les fonctions concernées ; comme l'a documenté OX Security, des captures d'outil d'exploitation ont circulé avant même la mise en ligne des correctifs, et le projet lui-même avertissait que le code proof-of-concept circulant dans cette fenêtre est souvent du malware déguisé. Les correctifs et avis étant désormais publics, le tableau technique est plus clair que le cycle de teasers ne le laissait croire.Un chemin de manque de mémoire vers l'exécution de code
CVE-2026-109618, référencée GHSA-w8hw-w9fx-j79w, exploite la façon dont PHP gère l'épuisement mémoire. Quand une allocation échoue, le moteur déroule la requête par un longjmp() - et si cela survient alors que la mémoire de la requête n'est que partiellement initialisée, la phase de terminaison lit ou branche ensuite sur une mémoire en état invalide. L'avis décrit une famille de techniques de pression d'allocation qui rendent cela atteignable depuis une simple requête HTTP : des corps multipart sans content-length exploitable qui se faufilent au-delà de post_max_size, des parties garnies de milliers d'en-têtes dont la représentation en mémoire écrase leur taille sur le fil, et des contrôles de fichiers vides qui allouent des tableaux de métadonnées sans jamais compter contre max_file_uploads. Le SAPI mod_php d'Apache est confirmé exploitable : des chercheurs ont validé l'exécution de code à distance non authentifiée sous le compte du worker web via HTTP brut sur des configurations prefork par défaut, avec une complexité d'attaque élevée et possiblement plusieurs essais. PHP-FPM est jugé susceptible via des chemins d'allocation propres à l'application, FrankenPHP et LiteSpeed probablement aussi. Le correctif remplace le longjmp brut par un piège logiciel de manque de mémoire au prochain point sûr de la VM, plus un échec dur qui tue le worker immédiatement.Un état périmé dans les processus worker
CVE-2026-109619 (GHSA-6wmf-4rv5-p3rp) est la sœur silencieuse : les processus worker portent un état global - gestionnaires d'erreurs, données de session, comptabilité des objets et extensions - qui peut finir par pointer vers la mémoire d'une seule requête. Si une erreur fatale, un abandon faute de mémoire ou un diagnostic tardif écrit cet état et que rien ne le réinitialise avant la libération de la mémoire de la requête, les globales du worker pointent dans le vide. Ce qui les touche avant l'initialisation d'une nouvelle requête lit de la mémoire libérée. Deux chemins de production sont confirmés : les traces d'erreur fatale introduites dans PHP 8.5 sous mod_php, et le mécanisme session upload progress sous mod_php et FPM. Producteur et consommateur doivent tomber sur le même processus worker, ce qui rend les pools FPM à nombreux workers plus difficiles - mais pas impossibles - à viser.Un agencement de heap stratégiquement conçu peut produire une exécution de code à distance (RCE) complète. - Avis de sécurité PHP, GHSA-6wmf-4rv5-p3rp
Ce que les administrateurs doivent faire maintenant
Mettre à jour est la seule atténuation complète, et ce n'est pas un simple patch-and-forget : les deux avis insistent sur le redémarrage de tous les workers PHP après la mise à niveau, car un état périmé peut survivre dans des processus de longue durée. Les branches supportées disposent de binaires ; les sites figés sur des branches EOL doivent poser eux-mêmes les backports sources.- Mettre à jour vers 8.2.35, 8.3.36, 8.4.27 ou 8.5.12 (ou appliquer les backports GitHub pour 7.4/8.0/8.1), puis redémarrer tous les processus worker.
- Si la mise à jour est impossible aujourd'hui : définir session.upload_progress.enabled=0 et, sous PHP 8.5, fatal_error_backtraces=0, puis redémarrer les workers.
- Pour la faille OOM, imposer memory_limit=-1 de façon centralisée et vérifier qu'aucun override de pool ou .htaccess ne restaure une limite finie.
- Garder un post_max_size conservateur, bloquer au frontend les requêtes multipart si l'application ne les utilise pas, et borner variables d'entrée, en-têtes et téléversements.
- Préférer les limites mémoire conteneur/cgroup à RLIMIT_AS ou RLIMIT_DATA - l'avis avertit explicitement que les mécanismes RLIMIT poussent les échecs d'allocation vers le chemin vulnérable.
- En option, plafonner le recyclage des workers avec pm.max_requests pour raccourcir la fenêtre de transfert d'état.