Mise à jour de sécurité PHP : corriger, puis revoir les secrets et les accès

Le 21 octobre 2026, PHP a publié 8.5.12, 8.4.27, 8.3.36 et 8.2.35 pour corriger CVE-2026-109618 et CVE-2026-109619, des vulnérabilités critiques pouvant permettre une exécution de code à distance sans authentification. L’annonce officielle vise les installations traitant des requêtes web, dont PHP-FPM et Apache mod_php. Seule la mise à jour constitue une correction complète ; les atténuations temporaires ne sont pas équivalentes.

Une installation vulnérable ne prouve pas une compromission. Reliez correction, investigation et récupération des identifiants, en décidant selon votre environnement et les éléments disponibles.

Vérifier ce qui traite réellement les requêtes

Inventoriez sites publics, services internes, conteneurs et comptes d’hébergement exécutant PHP. Confirmez la version et les correctifs du moteur traitant les requêtes web : la version en ligne de commande peut correspondre à une autre installation.

En hébergement administré, demandez confirmation du paquet appliqué, du service concerné et du redémarrage ou déploiement. Les distributions peuvent rétroporter des correctifs ; obtenez leur confirmation plutôt que de vous fier au seul numéro de version amont. Vérifiez le périmètre avec l’opérateur à partir des avis de l’équipe PHP. Ne publiez pas une page de diagnostic révélant la configuration du serveur.

Contenir l’exposition et rétablir la confiance

Coordonnez rapidement la mise à jour avec l’hébergeur ou l’équipe d’exploitation. Limitez l’exposition ou isolez les systèmes si l’évaluation l’exige, en préservant les preuves utiles. Ne retardez pas un confinement urgent pour finir de collecter des journaux.

Examinez la période d’exposition, les journaux web et système, les fichiers ou processus inattendus et les événements d’audit des fournisseurs concernés. L’absence d’alerte ou des journaux apparemment normaux ne prouvent pas que l’hôte est intact.

Si une compromission est établie ou raisonnablement soupçonnée, suivez votre procédure pour reconstruire ou restaurer depuis une source fiable. Le correctif ne supprime pas la persistance d’un attaquant. N’utilisez pas un hôte ou appareil douteux pour générer, recevoir ou installer les nouveaux secrets.

Évaluer les identifiants avant leur rotation

Listez ceux auxquels le processus affecté pouvait accéder : configuration applicative, variables d’environnement, jetons de déploiement, accès aux bases et clés API. Déterminez leurs permissions, leur portée et l’exposition possible. L’annonce ne démontre pas que tous les identifiants de l’organisation ont fui.

Pour ceux potentiellement exposés, coordonnez remplacement et révocation auprès du fournisseur émetteur depuis un poste d’administration fiable. Installez les nouvelles valeurs dans l’environnement reconstruit et vérifiez les intégrations légitimes. Choisissez l’ordre selon les abus en cours, les capacités du fournisseur et les dépendances. Ne promettez pas une continuité sans interruption et ne laissez pas une clé exposée active indéfiniment par commodité.

Revoyez les sessions et accès de récupération selon les besoins, et notez le responsable de chaque changement. Ne placez jamais les secrets bruts dans le ticket ou les journaux de l’incident. OWASP

Fermer les accès d’urgence après l’intervention

Donnez aux intervenants des comptes individuels, des droits minimaux et une heure de fin convenue. Après récupération, examinez rôles temporaires, sessions, accès de déploiement et liens de transmission. Retirez les droits devenus inutiles et confirmez les résultats dans les services concernés, sans vous fier uniquement au calendrier.

Distinguer trois contrôles différents

Transmettre temporairement après rétablissement de la confiance

Si votre procédure l’autorise, créez une note protégée par mot de passe depuis un système fiable, avec le strict nécessaire pour un destinataire vérifié. Transmettez le mot de passe séparément et utilisez expiration ou limites d’accès si votre offre les prévoit. N’y placez ni phrase de récupération de portefeuille ni clé privée.

LOCK.PUB est un outil de transmission limité : il ne corrige pas PHP, ne répare pas les appareils infectés, ne révoque pas les clés des fournisseurs et ne rappelle pas les copies. Il ne remplace ni gestionnaire de secrets, ni contrôles d’identité, ni réponse à incident.

Questions fréquentes

Installer la mise à jour PHP termine-t-il l’investigation ?

Non. Elle corrige la vulnérabilité ; preuves et exposition déterminent les investigations, la récupération et les actions sur les identifiants encore nécessaires.

L’expiration d’une note désactive-t-elle sa clé API ?

Non. Révoquez ou remplacez cette clé chez son fournisseur. Un identifiant copié reste distinct du lien qui l’a transmis.

À lire : partager des clés API avec des limites claires.