PHP : corriger CVE-2026-91767 et CVE-2026-91769 (OpenSSL)

Ce que corrigent ces deux avis

L'essentiel en sept points

• CVE-2026-91769 — sévérité modérée, CVSS 3.1 de 4.3. La vérification du nom de pair consulte d'abord les subjectAltName, puis retombe sur le Common Name même lorsque le certificat présente un SAN DNS qui ne correspond pas.
• CVE-2026-91767 — sévérité modérée, CVSS 3.1 de 6.5 (CWE-122). Dans php_openssl_matches_wildcard_name(), un sous-dépassement de longueur passé à memchr() provoque une lecture hors tampon quand le nom à joker du certificat a plus de caractères littéraux que l'hôte vérifié.
• Versions corrigées — PHP 8.2.34, 8.3.35, 8.4.26 et 8.5.11, pour les deux failles. Les versions 8.4.26 et 8.5.11 figurent au changelog de PHP à la date du 24 septembre 2026.
• Qui est concerné — les clients qui s'appuient sur la valeur par défaut de verify_peer_name, via file_get_contents(), fopen() et stream_socket_client() sur https:// et tls://.
• Contournement — l'avis n'en indique aucun. Désactiver la vérification n'en est pas un, c'est une faille de plus.
• Branches 8.1 et antérieures — en fin de vie, sans correctif amont. Des correctifs de distribution ou des backports tiers existent peut-être : à vérifier paquet par paquet.
• Exploitation — nous n'avons trouvé, dans les sources consultées, aucune exploitation constatée de ces deux failles.

Ce que ces failles permettent, et ce qu'elles ne permettent pas

Notées modérées : est-ce urgent ?

Mesurer votre exposition en quatre étapes

1. 01

   Relevez la version de PHP réellement servie

   Sur le serveur, lancez php -r 'echo PHP_VERSION, PHP_EOL;'. Ne vous fiez pas à OPENSSL_VERSION_TEXT : ce n'est pas la bibliothèque OpenSSL du système qui est corrigée, c'est le code de l'extension, donc la version de PHP. Attention, le CLI peut différer de ce que servent vos sites : sur un serveur qui héberge plusieurs branches, relevez aussi la version de chaque pool PHP-FPM (étape de vérification plus bas). Sur cPanel, la version se lit par domaine, voir notre guide du sélecteur PHP.

2. 02

   Cherchez les appels qui passent par les flux PHP

   Listez les appels sortants avec une URL en clair dans le code : grep -rnE "(file_get_contents|fopen)\(\s*['\"]https?://|stream_socket_client\(\s*['\"]tls://" /var/www --include='*.php'. Sur un hébergement cPanel, remplacez /var/www par /home. Complétez avec les appels dont l'URL vient d'une variable : grep -rnE "(file_get_contents|fopen|stream_socket_client)\(\s*\$" /var/www --include='*.php'. Pensez aux plugins WordPress et au dossier vendor : c'est souvent là que se cachent les appels sortants.

3. 03

   Repérez les vérifications déjà désactivées

   Lancez grep -rn "verify_peer_name" /var/www --include='*.php'. Une valeur à false signifie qu'aucun nom d'hôte n'est vérifié du tout : ce code est exposé à bien plus que ces deux avis, quelle que soit la version de PHP. Corrigez-le avant tout le reste.

4. 04

   Classez vos sites

   Un site est prioritaire s'il cumule une branche en dessous du plancher du tableau suivant et des appels sortants par les flux. Les appels passés par l'extension cURL ne sont pas cités par l'avis, qui liste les flux PHP. WordPress et la plupart des bibliothèques HTTP utilisent en général cURL quand il est disponible, mais retombent sur les flux sinon : ne les excluez pas sans vérifier.

Quelle version installer selon votre branche

Faites défiler le tableau

Appliquer le correctif selon votre environnement

1. 05

   Debian et Ubuntu

   Mettez l'index à jour avec sudo apt update, puis les paquets de votre branche avec sudo apt install --only-upgrade 'php8.3*' (remplacez 8.3 par votre branche). Pour voir ce qui est en attente : apt list --upgradable 2>/dev/null | grep -i php. Les distributions corrigent souvent par backport sans changer le numéro amont : lisez le journal du paquet avec apt changelog php8.3-cli | grep -i CVE-2026-91769. Avec un dépôt tiers de type Sury, les mêmes commandes s'appliquent.

2. 06

   RHEL, AlmaLinux et Rocky Linux

   Lancez sudo dnf update 'php*'. Si vous utilisez un flux de modules, la branche suit le module activé : dnf module list --enabled php la donne. Contrôlez ensuite le journal avec rpm -q --changelog php-cli | grep -i CVE-2026-91769. Avec un dépôt tiers, les noms de paquets changent : adaptez le motif à ce que renvoie rpm -qa 'php*'.

3. 07

   cPanel : EasyApache 4 et sélecteur PHP

   Les branches d'EasyApache 4 sont des paquets ea-php83, ea-php84, etc. Si vous avez le root, listez-les avec rpm -qa 'ea-php*' | sort puis mettez-les à jour avec sudo dnf update 'ea-php*'. Lisez le journal avec rpm -qa --changelog 'ea-php83*' | grep -i CVE-2026-91769 et la version réelle avec /opt/cpanel/ea-php83/root/usr/bin/php -v. Sur un hébergement mutualisé, c'est l'hébergeur qui met à jour : votre part consiste à vérifier, dans le sélecteur PHP de cPanel (MultiPHP Manager, ou Select PHP Version sous CloudLinux), que chaque domaine tourne sur une branche corrigée.

4. 08

   Docker

   Une image ne se corrige pas en place : reconstruisez-la en tirant la base à jour avec docker build --pull --no-cache -t votre-image ., ou docker compose build --pull --no-cache avec Compose, puis relancez avec docker compose up -d. Vérifiez le résultat dans le conteneur avec docker run --rm votre-image php -v. Une étiquette flottante comme php:8.4-fpm n'avance que si l'image amont a été reconstruite : le numéro affiché fait foi, pas le nom de l'étiquette.

5. 09

   Redémarrez les services PHP

   PHP-FPM et Apache gardent l'ancien code en mémoire tant qu'on ne les recharge pas. Sur Debian ou Ubuntu : sudo systemctl restart php8.3-fpm (adaptez la branche), et sudo systemctl restart apache2 si vous utilisez mod_php. Sur RHEL ou AlmaLinux : sudo systemctl restart httpd. Sur cPanel avec PHP-FPM, systemctl list-units 'ea-php*' donne le nom exact du service à redémarrer.

6. 10

   Vérifiez la version réellement servie

   Le CLI n'est pas le service web. Interrogez le binaire FPM : php-fpm8.3 -v sur Debian et Ubuntu, php-fpm -v sur RHEL et dérivés, ou la version du domaine dans cPanel. Le numéro doit atteindre le plancher de votre branche, ou son journal doit citer CVE-2026-91769. Terminez par un appel sortant de test : php -r 'echo strlen(file_get_contents("https://votre-domaine.com/")), PHP_EOL;'.

Si votre branche est en fin de vie (8.1 et avant)

Un troisième correctif OpenSSL du même trimestre

Dépannage après la mise à jour

Les erreurs rencontrées et leurs remèdes

• SSL operation failed with code 1 puis certificate verify failed — message complet typique : stream_socket_client(): SSL operation failed with code 1. OpenSSL Error messages: error:0A000086:SSL routines::certificate verify failed. Cause probable : le certificat présente un SAN DNS qui ne contient pas l'hôte appelé, mais son CN le contient. L'ancienne vérification l'acceptait par repli sur le CN, la nouvelle le refuse. Lisez le certificat avec openssl s_client -connect interne.votre-domaine.com:443 -servername interne.votre-domaine.com </dev/null 2>/dev/null | openssl x509 -noout -subject -ext subjectAltName. Remède : réémettre le certificat avec un SAN DNS correct pour chaque nom utilisé, jamais désactiver la vérification.
• file_get_contents(): Failed to enable crypto — avertissement qui accompagne le précédent. Lisez le message complet qui suit : selon la version, vous pouvez aussi trouver Peer certificate CN=… did not match expected CN=…. Même cause, même remède.
• Un certificat sans aucun SAN, avec un CN seul, échoue quand même — le correctif conserve le repli sur le CN pour les certificats sans identifiant de service. La cause est donc ailleurs : autorité non approuvée par le client, hôte appelé par un alias ou une adresse IP absents du certificat, certificat expiré. Remède : ajouter l'autorité interne à cafile dans le contexte du flux, et réémettre le certificat avec un SAN.
• child exited on signal 11 (SIGSEGV) dans le journal de PHP-FPM — un worker qui plante au moment d'un appel sortant TLS est compatible avec CVE-2026-91767. Ne concluez pas sur ce seul indice : vérifiez la version, mettez à jour et regardez si le motif disparaît.
• php -v affiche encore l'ancienne version — service non redémarré, CLI et FPM de branches différentes, image Docker reconstruite sans --pull, ou version du domaine inchangée dans cPanel. Reprenez l'étape de vérification.
• Le journal de la distribution ne cite pas la CVE — son absence ne prouve ni que le correctif est là, ni qu'il manque. Consultez le suivi de sécurité de la distribution, et à défaut comparez le numéro amont au plancher du tableau.

Fixer la mise à jour dans votre routine

1. 11

   Reportez le plancher dans votre inventaire

   Ajoutez à votre inventaire de parc une colonne « version minimale » par branche, avec les valeurs du tableau. Une version sous le plancher devient visible sans recherche.

2. 12

   Planifiez les mises à jour de PHP

   Un correctif de sécurité de PHP est une mise à jour mineure de la même branche : prévoyez un créneau régulier plutôt qu'un chantier à chaque avis, avec redémarrage des services et vérification de la version servie.

3. 13

   Testez un appel sortant après chaque mise à jour

   Rejouez php -r 'echo strlen(file_get_contents("https://votre-domaine.com/")), PHP_EOL;' depuis chaque serveur, et un appel vers vos services internes. Une erreur de certificat apparaît alors tout de suite, pas chez un client.

4. 14

   Reliez ce correctif au reste de votre veille

   Pour la méthode de relevé sur un parc, lisez l'inventaire des versions PHP d'un parc clients. Pour la faille la plus critique du moment, voir PHP2Shell. Pour changer la version d'un site, suivez le guide du sélecteur PHP de cPanel. Pour une branche qui s'éteint, reprenez la checklist de migration de PHP 8.2.