PHP 8.5.11, 8.4.26, 8.3.35, 8.2.34 : ce que ce correctif touche chez vous

Le 24 septembre, l’équipe PHP a publié en même temps les versions 8.5.11, 8.4.26, 8.3.35 et 8.2.34, toutes classées correctifs de sécurité. Le titre le plus visible est un déni de service dans l’extension SOAP, noté « élevé » par l’avis. Mais je pense que le plus utile pour un projet ancien est ailleurs : dans deux défauts plus discrets, sur les redirections HTTP et la vérification TLS, qui touchent du code que personne ne relit depuis des années. Voici comment trier ça en une heure, sans lire les changelogs en entier.

Ce que contient la livraison

Le changelog de la 8.5.11 et de la 8.4.26 sur php.net liste plusieurs dizaines de corrections, dont onze portent un identifiant CVE. J’ai lu en entier ces deux entrées ; je n’ai pas pu ouvrir celles de la 8.3.35 et de la 8.2.34, mais les avis listent bien ces deux versions comme corrigées. Voici ce qui compte pour un legacy web :

Les avis que j’ai ouverts indiquent tous la même plage : toute version antérieure à 8.2.34, 8.3.35, 8.4.26 ou 8.5.11. Les branches déjà hors support ne sont pas évaluées, et le projet ne publiera rien pour elles.

Le SOAP : le défaut le plus grave, sur l’extension la plus oubliée

Selon l’avis, un attaquant non authentifié peut envoyer à n’importe quel endpoint SoapServer une requête avec des dizaines de milliers d’éléments imbriqués, ce qui épuise la pile et fait tomber le processus. La charge utile reste petite parce que les balises répétées se compressent. Sous PHP-FPM, des envois répétés épuisent le pool de workers et l’endpoint devient indisponible. Aucun contournement n’est documenté ; le correctif introduit une profondeur maximale de 2048 (SOAP_MAX_XML_DEPTH) et transforme les fonctions récursives en parcours itératifs.

La question utile n’est donc pas « utilisons-nous SOAP ? » mais « exposons-nous un serveur SOAP ? ». Un client SOAP qui appelle un partenaire n’est pas dans le cas décrit par l’avis. Un SoapServer derrière un vieil endpoint /ws/ oublié, pour un ERP ou un partenaire qui n’a jamais migré, l’est. Sur les migrations que j’ai menées, ces endpoints sont souvent les derniers à être documentés, et personne n’ose les couper.

Les deux défauts discrets : redirections HTTP et TLS

Le premier concerne le wrapper HTTP de PHP, celui qui se cache derrière file_get_contents('https://…'). D’après l’avis, il transmettait les en-têtes Authorization, Cookie et Proxy-Authorization tels quels lors d’une redirection, même vers un autre hôte, un autre port, ou un passage de HTTPS à HTTP. Conditions : des identifiants fournis via stream_context_create() et follow_location actif, ce qui est le réglage par défaut. Le risque réel est qu’un service tiers que vous appelez vous redirige vers un domaine qu’il ne contrôle plus, ou qu’un attaquant contrôle la destination.

Le contournement documenté tient en une ligne, et il vaut la peine de le connaître même après mise à jour :

$context = stream_context_create([
    'http' => [
        'header' => 'Authorization: Bearer ' . $token,
        'follow_location' => 0, // on gère la redirection soi-même
    ],
]);

$body = file_get_contents($url, false, $context);

Si la réponse est une redirection, vous décidez alors, en vérifiant que l’hôte de destination est bien celui que vous attendez, de la suivre ou non, sans y renvoyer le jeton.

Le second défaut est plus subtil. Quand un certificat présente un SAN qui ne correspond pas au nom d’hôte demandé, PHP retombait sur le champ Common Name, ce que la RFC 6125 interdit. L’avis précise que l’exploitation suppose un attaquant capable d’obtenir un certificat avec un CN précis et un SAN différent, typiquement dans une PKI privée ou une autorité interne mal contrôlée. Note modérée, donc, mais cela concerne file_get_contents, fopen et stream_socket_client en TLS, c’est-à-dire tous les appels sortants qu’on n’a jamais passés en Guzzle ou en client Symfony HttpClient.

Savoir en une heure si vous êtes concerné

Trois recherches suffisent à faire un premier tri. Lancez-les à la racine du code, vendor/ compris, car les dépendances anciennes comptent autant que votre code :

# 1. Serveurs SOAP exposés
grep -rn "new SoapServer\|SoapServer(" --include=*.php . | head

# 2. Appels sortants par les wrappers de flux
grep -rnE "stream_context_create|file_get_contents\(|fopen\(" --include=*.php src lib app 2>/dev/null

# 3. Version réellement en production, pas celle du composer.json
php -v && php -r 'echo PHP_VERSION, PHP_EOL;'

Le troisième point paraît naïf, mais c’est celui qui surprend : sur des images Docker anciennes, la version de production peut être en retard de plusieurs correctifs sur celle de la préproduction. Comparez le numéro, pas la branche. Pour PHP-FPM, vérifiez aussi si listen.allowed_clients est utilisé avec des adresses IPv6 ; si vous n’utilisez qu’un socket Unix, l’avis sur l’ACL ne vous concerne pas.

Le cas de la 8.2

Au passage, la 8.2 mérite une attention particulière. D’après php.net, la 8.2 est en support de sécurité jusqu’au 31 décembre 2026, la 8.3 jusqu’au 31 décembre 2027, la 8.4 jusqu’au 31 décembre 2028 et la 8.5 jusqu’au 31 décembre 2029. Si votre production est encore en 8.2, vous avez environ trois mois avant que ce type d’avis cesse de vous être destiné. Je ne dis pas qu’un correctif de sécurité suffit à justifier une migration précipitée : je dis que le calendrier de la migration est maintenant fixé par un tiers, et qu’il vaut mieux le choisir que le subir.

Les limites

Cet article ne remplace pas la lecture des avis complets, et je n’ai pas reproduit ces failles : je m’appuie sur les textes de php.net et de php-src. Les notes de gravité viennent des avis eux-mêmes ; elles ne tiennent pas compte de votre contexte, et un défaut noté « modéré » peut être critique chez vous si le jeton qui fuit ouvre votre API de paiement.

Par ailleurs, monter d’un correctif de la même branche est en général peu risqueux, mais pas nul. Cette livraison corrige aussi des comportements des générateurs (yield from imbriqué), de array_keys() et de plusieurs extensions. Si votre code contourne un de ces bogues sans le savoir, un test de non-régression sur vos parcours critiques reste nécessaire. Enfin, mes trois grep détectent les usages directs, pas les bibliothèques qui utilisent ces wrappers pour vous : lisez le résultat comme un plancher, pas comme une preuve d’absence.

Concrètement, par où commencer

1. Relevez la version exacte de PHP sur chaque environnement de production, y compris les conteneurs et les serveurs que personne n’a redéployés récemment.
2. Cherchez les SoapServer exposés. Si un endpoint est inutile, coupez-le ; sinon, mettez-le à jour en priorité et limitez son accès par IP ou par authentification au niveau du reverse proxy.
3. Repérez les appels sortants qui portent un jeton via stream_context_create(), et passez follow_location à 0 tant que la mise à jour n’est pas faite.
4. Planifiez la mise à jour de correctif dans la branche actuelle, avec vos tests de parcours critiques, plutôt qu’en attendant la prochaine migration majeure.
5. Si vous êtes en 8.2, inscrivez la date du 31 décembre 2026 dans votre feuille de route dès aujourd’hui.

Une montée de correctif se prépare comme une petite migration : un inventaire, un test, un déploiement progressif. Le vrai gain de l’exercice est l’inventaire : on découvre à cette occasion ce qui tourne encore en production, et que personne ne savait plus exposé.

Sources

• PHP: ChangeLog-8, php.net, entrées 8.5.11 et 8.4.26 du 24 septembre 2026
• PHP: News Archive 2026, php.net, consulté le 30 septembre 2026
• GHSA-rgrp-mwpx-f6rm : récursion non bornée dans le SOAP, php-src, septembre 2026
• GHSA-fpwc-w8rq-cr92 : fuite d’identifiants par redirection du wrapper HTTP, php-src, septembre 2026
• GHSA-vvx9-73fr-5jjx : vérification du nom d’hôte TLS, php-src, septembre 2026
• PHP: Supported Versions, php.net, consulté le 30 septembre 2026