Deux vulnérabilités critiques de PHP ont déclenché une alerte appelant à appliquer d'urgence les correctifs, alors que des chercheurs en sécurité signalent les premières activités malveillantes. Les administrateurs doivent identifier les systèmes exposés avant la publication des correctifs prévus.
L'équipe de sécurité de PHP a programmé la publication des correctifs pour le 21 octobre 2026 à 14 h 00 UTC (10 h, heure de l'Est). Les deux failles obtiennent un score de 9,2 selon la version 4.0 du Common Vulnerability Scoring System (CVSS). Les chercheurs alertent sur un risque potentiel d'exécution de code à distance (RCE), bien que PHP n'ait pas confirmé le mode opératoire des attaques ni les versions concernées.
Les organisations qui exploitent des sites web, des plateformes de commerce électronique et des applications personnalisées reposant sur PHP doivent identifier les environnements d'exécution potentiellement vulnérables et coordonner l'application des correctifs. Les installations qui ne sont plus prises en charge posent des difficultés supplémentaires, car elles ne recevront pas les mises à jour de sécurité habituelles en amont.
Deux failles critiques de PHP et des attaques émergentes
Dans son annonce de sécurité du 20 octobre, PHP a exhorté les administrateurs à se préparer à effectuer immédiatement les mises à niveau. L'équipe a également indiqué que les correctifs pourraient être publiés plus tôt si des détails techniques venaient à être rendus publics ou si des indices d'exploitation active apparaissaient.
CERT-EU a identifié les vulnérabilités CVE-2026-109618 et CVE-2026-109619. Les chercheurs estiment que des versions de PHP remontant à PHP 5 pourraient être concernées, mais le périmètre officiel reste à confirmer. Une exploitation réussie pourrait permettre à des attaquants non authentifiés d'exécuter du code sur des serveurs vulnérables.
La société de sécurité watchTowr a déclaré à BleepingComputer qu'elle pensait avoir reproduit la CVE-2026-109618. Tenable a ensuite signalé que Cloudflare observait les premières attaques, bien que l'ampleur des compromissions réussies reste inconnue.
Les vulnérabilités signalées concernent PHP lui-même, et non l'extension d'une application tierce. Une récente vulnérabilité de Bricksforge pour WordPress a également exposé des sites web reposant sur PHP à des risques d'exécution de code, mais la seule mise à jour des composants de l'application ne suffirait pas nécessairement à corriger une installation PHP concernée.
Préparer les systèmes PHP aux correctifs d'urgence
Les administrateurs doivent se préparer à installer les correctifs de sécurité PHP vérifiés dès leur disponibilité. La politique de prise en charge des versions de PHP couvre les branches 8.2 à 8.5. Les versions plus anciennes ne bénéficient plus du support en amont, même si certains fournisseurs peuvent proposer des correctifs rétroportés.
Les équipes de sécurité doivent donner la priorité à six mesures :
- Identifier les systèmes PHP exposés. Répertorier les applications, serveurs, conteneurs et environnements d'hébergement accessibles depuis Internet. Vérifier les environnements d'exécution de production plutôt que de se fier uniquement aux contrôles de version en ligne de commande.
- Préparer et vérifier les mises à jour. Coordonner l'application des correctifs, vérifier les sauvegardes, tester la compatibilité et reconstruire les conteneurs concernés. Les récents correctifs de sécurité de NGINX renforcent la nécessité de vérifier les versions et les configurations installées.
- Restreindre les accès et les privilèges. Isoler les charges de travail vulnérables, appliquer le principe du moindre privilège et limiter les connexions externes superflues.
- Renforcer les défenses temporaires. Examiner les protections des WAF et des fournisseurs d'hébergement. La mise à jour d'urgence du WAF de Cloudflare du 21 octobre a ajouté quatre règles gérées pour les requêtes anormales : deux règles de blocage et deux règles de journalisation. Cloudflare n'a pas identifié les CVE de PHP dans cette annonce, et ces contrôles ne peuvent pas remplacer l'application des correctifs. La récente vulnérabilité du WAF SiteGuard souligne également la nécessité de maintenir une infrastructure de défense à jour.
- Surveiller les signes d'une compromission. Enquêter sur les requêtes HTTP suspectes, les processus inattendus sur les serveurs et les modifications de fichiers non autorisées. Préserver les éléments de preuve et évaluer les identifiants potentiellement exposés.
- Tester les plans de réponse aux incidents. Vérifier les procédures de confinement, les contacts d'escalade et la restauration des sauvegardes. Organiser des exercices couvrant l'isolement et la récupération des serveurs.
Les clients d'hébergement administré doivent confirmer le calendrier des correctifs auprès de leurs fournisseurs. L'avis sur les paquets de CloudLinux indique que les paquets d'hébergement mis à jour dépendent des correctifs PHP fournis en amont.
Les installations PHP non prises en charge nécessitent des correctifs rétroportés par le fournisseur, une migration ou le maintien de restrictions d'exposition. Les mises à jour vérifiées de l'environnement d'exécution restent la principale mesure corrective.
En savoir plus : les récentes attaques zero-day contre le VPN Ivanti montrent pourquoi l'application des correctifs doit s'accompagner d'enquêtes sur un éventuel vol d'identifiants et des accès non autorisés.