PHP : quatre billets disent « only safe choice », le 23 nomme un autre numéro

Quatre boîtes sont sur le comptoir, tamponnées du 21 octobre. L'étiquette, sur chacune, dit la même chose : il n'y a pas de mitigation complète, mettre à jour est le seul choix sûr. La notice glissée dans le sac, le même jour, liste quand même des mesures, et dit qu'elles ne rendent pas l'installation sûre. Le tampon du mode d'emploi, lui, est au 22. Et le lendemain, une feuille scotchée sur la porte nomme un autre numéro, et elle dit que régler une option protège pleinement d'un vecteur peu probable, jusqu'à la prochaine fournée ordinaire. Si tu repars avec la boîte parce que l'étiquette a dit « seul choix », dis quelle feuille tu as lue.

Le 20 octobre 2026, l'archive prévient. Une sortie de sécurité est prévue le mercredi 21 octobre 2026 à 14:00 UTC. Elle traite deux vulnérabilités critiques, toutes les deux notées CVSS v4.0 9.2. Les utilisateurs sont encouraged à se préparer. Pas « strongly ». Les versions corrigées seront publiées avec la sortie. Le droit de sortir plus tôt est réservé, si un détail devient public ou si une exploitation apparaît.

Quatre étiquettes, une formule, et une seule qui parle de la fin

Le 21 octobre 2026, quatre notes. PHP 8.5.12, 8.4.27, 8.3.36, 8.2.35. Chacune annonce la disponibilité immédiate. Chacune dit que c'est une sortie de sécurité qui corrige deux vulnérabilités critiques, CVE-2026-109618 et CVE-2026-109619, qui peuvent permettre une exécution de code à distance non authentifiée. Chacune dit que tous les utilisateurs de sa branche mineure sont strongly encouraged à mettre à jour immédiatement. Puis la phrase qui nous occupe : There are no complete mitigations, updating is the only safe choice. Voir l'avis de sécurité.

La note 8.2.35 ajoute une phrase que les trois autres n'impriment pas. PHP 8.2 atteint la fin de vie le 31 décembre 2026 et ne recevra plus de correctifs de sécurité après cette date. Les notes 8.5.12, 8.4.27 et 8.3.36 ne disent pas ça.

L'avis du même 21 octobre, sur la même archive, n'a pas la formule « only safe choice ». Il dit que 8.5.12, 8.4.27, 8.3.36 et 8.2.35 corrigent les deux failles, et que tous les utilisateurs PHP sont strongly encouraged à mettre à jour immédiatement. Qui est à risque : toute installation qui sert des requêtes web, y compris PHP-FPM, Apache avec mod_php, php-cgi, FrankenPHP et LiteSpeed. Le risque le plus haut, pour eux, est mod_php, avec un exploit démontré où une requête non authentifiée déclenche l'attaque avant que le code de l'application tourne. Les quatre notes ne recopient pas cette liste.

Les deux mécanismes, sur l'avis. CVE-2026-109618, GHSA-w8hw-w9fx-j79w : la gestion du manque de mémoire peut interrompre PHP pendant que des données internes de requête ne sont qu'en partie initialisées. Le nettoyage peut alors traiter l'invalide comme du valide. CVE-2026-109619, GHSA-6wmf-4rv5-p3rp : un état interne appartenant à une requête peut survivre après la libération de sa mémoire. Une requête suivante, sur le même worker, peut s'en servir avant que l'initialisation normale le remette à zéro.

Puis le paragraphe que les étiquettes ne recopient pas. Si tu ne peux pas mettre à jour tout de suite : seule une mise à jour est une solution complète, et les mesures qui suivent réduisent l'exposition à des chemins précis mais ne rendent pas une installation sûre. Pour le 109618, entre autres, memory_limit=-1, un post_max_size bas, 8M sans envoi de fichier, 32M s'il en faut. Pour le 109619, session.upload_progress.enabled=0, et sur PHP 8.5 fatal_error_backtraces=0. Je ne recopie pas toute la liste. Elle est sur l'avis. Elle n'est pas sur les quatre étiquettes.

Le même avis dit que PHP 8.1 et plus vieux ne reçoivent plus de mises à jour du projet PHP. La phrase d'après dit que l'équipe de sécurité a fourni des rétroportages source minimaux pour PHP 7.4, PHP 8.0 et PHP 8.1, pour ceux qui construisent depuis les sources ou n'ont pas de vendeur LTS. « Ne reçoivent plus » et « a fourni des rétroportages » sont les deux phrases. Je ne raye pas la seconde pour que la première soit nette.

L'avis GitHub dit « reliable », et il garde l'option après le correctif

L'avis GHSA-6wmf-4rv5-p3rp, publié le 21 octobre 2026 par bukka, titre RCE via stale global state. Sévérité Critical, score 9.2. Le vecteur imprimé : CVSS:4.0/AV:N/AC:H/AT:P/PR:N/UI:N/VC:H/VI:H/VA:H/SC:N/SI:N/SA:N. Les versions touchées sont quatre plafonds, < 8.2.35, < 8.3.36, < 8.4.27, < 8.5.12. Les versions corrigées sont ces quatre numéros. Je n'ai pas vu 8.6 dans cette liste. La note d'archive du même jour sur PHP 8.6.0 RC4 dit, elle, que cette version contient aussi les correctifs des deux failles, et elle dit de ne pas l'utiliser en production. Le 8 octobre, la note de RC3 prévoyait RC4 pour le 22 octobre 2026. L'archive date la note RC4 du 21. Je ne recolle pas ça sur le mot « premier » d'une autre note. Ici, ce qui m'importe, c'est que la liste patched de cet avis GitHub ne nomme pas RC4, et que la note RC4 dit à la fois que les correctifs y sont et qu'il ne faut pas s'en servir en production.

La phrase de mitigation, sur cet avis : mettre à jour vers une sortie qui contient le correctif complet de remise à zéro de l'état est the only reliable mitigation. Il n'y a pas de mitigation générique complète par la configuration. Plus bas, pour le cycle de vie des sessions : régler session.upload_progress.enabled=0 empêche les opérations de session démontrées. Ça ne mitige pas les autres chemins. Et une phrase que ni les étiquettes ni l'avis d'archive ne formulent ainsi : il peut être prudent de laisser cette option à 0 même après le correctif, si tu n'as pas besoin de la fonction, parce que d'autres attaquants chercheront des failles dans une fonction peu utilisée et peu testée. « Even after applying the patch. » La note du 20 octobre dit que les deux vulnérabilités sont notées 9.2. Cet avis GitHub est celui du second GHSA, et c'est lui qui affiche 9.2 avec le vecteur ci-dessus. Je n'ai pas ouvert la page de GHSA-w8hw-w9fx-j79w. Je ne lui prête pas ce vecteur.

Le mode d'emploi est au 22, et deux boîtes n'ont qu'une ligne

Le changelog date Version 8.5.12, 8.4.27, 8.3.36 et 8.2.35 du 22 Oct 2026. Pas du 21. Les quatre sections commencent par la même ligne Core : correction de GHSA-w8hw-w9fx-j79w et GHSA-6wmf-4rv5-p3rp. Le mot CVE- n'apparaît pas dans ces quatre sections. Les notes de sortie, elles, impriment les CVE et pas les GHSA. L'avis d'archive imprime les deux.

J'ai compté les lignes qui commencent par un tiret et ne finissent pas par un deux-points. 90 sous 8.5.12, réparties sous 29 intertitres. 89 sous 8.4.27, sous 30 intertitres. Une sous 8.3.36. Une sous 8.2.35. Ces deux-là n'ont que l'intertitre Core et la ligne des deux GHSA. Les notes du 21 octobre disent toutes « security release ». Elles ne disent pas que 8.5.12 et 8.4.27 alignent en plus des dizaines de correctifs qui ne sont pas ces deux avis.

Les noms de sections ne sont pas le même ensemble. PGSQL et Reflection sont sur 8.5.12, pas dans la liste de 8.4.27. Sockets, SPL, XSL et Zip sont sur 8.4.27, pas dans la liste de 8.5.12. La dernière ligne que j'ai sous 8.5.12 parle de inflate_init() qui perd le dictionnaire préétabli. La dernière sous 8.4.27 est GH-23747, un use-after-free de ZipArchive::close() depuis un callback de progression ou d'annulation. Je ne conclus pas que le correctif Zip est absent du code de 8.5.12. Je conclus que la section que j'ai comptée n'a pas d'intertitre Zip.

Le 23 dit « fully protect », et il ouvre un numéro que le 21 n'a pas

Le 23 octobre 2026, l'archive publie un avis informatif, Session upload progress. La suggestion : mettre session.upload_progress.enabled=0 jusqu'à la prochaine sortie ordinaire de correctifs, pour fully protect d'un vecteur d'exécution de code peu probable. La phrase d'après dit que ce réglage était déjà listé comme mitigation dans l'avis GHSA-6wmf-4rv5-p3rp pour CVE-2026-109619, publié le 21 octobre. Si tu l'as appliqué alors, garde-le, et aucune action supplémentaire n'est nécessaire.

Le paragraphe suivant décrit une combinaison qu'il appelle inhabituelle. L'application doit poser session.serialize_handler à php_binary ou php_serialize, puis le passer à php au runtime avec ini_set() avant session_start(). Le suivi de progression d'envoi doit encore être activé. Celles qui ne changent jamais le gestionnaire de sérialisation au runtime peuvent laisser la fonction allumée. Comme ce montage est peu probable, l'équipe le traite dans le cycle ordinaire et publiera un avis complet pour CVE-2026-115560 avec la prochaine sortie.

115560 n'est pas sur les quatre notes du 21. Il n'est pas dans les quatre sections de changelog, où je n'ai pas trouvé le mot CVE-. Je ne l'ai pas trouvé non plus sur l'avis GitHub du 21 que j'ai lu. Cet avis-là dit que le réglage ne couvre pas les autres chemins, et qu'il peut rester prudent après le correctif. La note du 23 dit fully protect, jusqu'à la prochaine fournée, et aucune action supplémentaire. Ce n'est pas la même phrase. La séquence ini_set() sur le gestionnaire de sérialisation est sur la note du 23. Elle n'est pas dans l'avis GitHub que j'ai lu.

✍️ À toi : la feuille que tu as vraiment eue en main, étiquette du 21, avis, changelog ou note du 23, et le numéro qui y est. 109618 et 109619 sont du 21. 115560 est écrit le 23.

Le 20 octobre, PHP annonce deux critiques notées 9.2 pour le lendemain 14:00 UTC. Le 21, quatre notes disent qu'il n'y a pas de mitigation complète et que mettre à jour est le seul choix sûr. L'avis du même jour liste des mesures qui ne rendent pas l'installation sûre, et il fournit des rétroportages minimaux pour 7.4, 8.0 et 8.1 tout en disant que 8.1 et plus vieux ne reçoivent plus de mises à jour. L'avis GitHub du 109619 dit que la mise à jour est la seule mitigation fiable, et qu'éteindre le suivi d'envoi peut rester prudent même après le correctif. Le changelog date les quatre versions du 22 octobre, avec 90 lignes, 89, une et une, et zéro fois le mot CVE-. Le 23, une note dit « fully protect » et nomme CVE-2026-115560 pour plus tard. Quatre étiquettes. Une notice. Un tampon au lendemain. Une feuille de plus le surlendemain.