Des failles PHP trouvées avec l’IA imposent une réponse bien humaine
Deux failles critiques de PHP ont été corrigées le 21 octobre. L’IA a contribué à leur découverte, mais la protection dépend du déploiement des mises à jour.
Les modèles d’IA peuvent aider à trouver une faille très ancienne. Ils ne mettent pas automatiquement à jour les serveurs qui l’utilisent. La publication de deux correctifs critiques pour PHP le 21 octobre 2026 illustre cet écart. Les mainteneurs du langage et les autorités européennes demandent aux organisations concernées d’agir rapidement.
Le rôle de l’IA donne à cet épisode une portée particulière. OpenAI explique que Calif a identifié une faille avec GPT-5.6 Sol dans son initiative Patch the Planet. L’entreprise indique aussi que Wiz a découvert et signalé indépendamment les deux vulnérabilités. Les mainteneurs de PHP ont conduit les corrections et leur diffusion.
La découverte doit devenir une protection
Dans son récit de la coordination, OpenAI décrit un travail avec les chercheurs et les fournisseurs de sécurité. L’enjeu consistait à préparer les correctifs et les protections avant la divulgation. L’éditeur propose un cadre pour rendre cette coopération reproductible.
Cette proposition ne constitue pas une règle internationale adoptée. Elle ne donne pas non plus une autorisation générale de modifier des systèmes tiers. Le fait établi ici reste une publication de correctifs par PHP. La disponibilité d’un correctif et son installation effective sont deux étapes différentes.
Deux vulnérabilités critiques dans PHP
L’avis de sécurité de PHP identifie CVE-2026-109618 et CVE-2026-109619. Les problèmes touchent la gestion interne de la mémoire et de l’état des requêtes. Ils peuvent permettre une exécution de code à distance sans authentification sur des installations vulnérables.
PHP cite plusieurs modes de fonctionnement des applications Web. L’équipe considère le risque particulièrement élevé pour Apache avec mod_php. Elle indique qu’une requête non authentifiée peut déclencher le problème avant l’exécution du code de l’application dans un scénario démontré. Ce constat ne signifie pas que chaque site a déjà été compromis.
La première vulnérabilité concerne le traitement d’un manque de mémoire pendant une initialisation incomplète. La seconde concerne un état interne conservé après la libération de la mémoire correspondante. Ces descriptions servent à comprendre la nature des corrections. Elles ne remplacent pas l’avis technique de la version utilisée.
Des versions corrigées réellement publiées
Les versions annoncées comme corrigées sont PHP 8.5.12, PHP 8.4.27, PHP 8.3.36 et PHP 8.2.35. L’alerte commune publiée par l’ENISA précise que les mises à jour sont sorties le 21 octobre à 13 h 40 UTC. Il ne s’agit donc plus seulement d’une annonce de correctifs à venir.
Les distributions Linux et les fournisseurs de maintenance peuvent livrer leurs propres paquets corrigés. Un numéro de version apparent ne raconte pas toujours toute l’histoire lorsqu’un fournisseur applique des correctifs à une ancienne branche. Il faut vérifier son avis plutôt que supposer qu’un téléchargement du code source suffit à protéger le service exploité.
PHP indique que ses branches 8.1 et antérieures ne reçoivent plus les mises à jour ordinaires du projet. Des rétroportages minimaux sont proposés pour certaines anciennes branches face à la gravité de ces failles. Ça ne rétablit pas un cycle général de maintenance pour ces versions.
L’exposition compte autant que l’inventaire
L’ENISA recommande d’identifier les applications concernées et de coordonner les mises à jour avec les hébergeurs. Les systèmes exposés à Internet doivent être prioritaires. Lorsque la correction immédiate n’est pas possible, les autorités invitent à envisager l’isolement des applications exposées.
Des produits peuvent utiliser PHP sans que leurs utilisateurs le sachent. L’inventaire doit donc tenir compte des composants intégrés. L’équipe PHP souligne par ailleurs que les mesures temporaires ne couvrent pas tous les chemins d’attaque. Seule la mise à jour apporte la solution complète indiquée par les mainteneurs.
Mon article sur la protection des accès aux modèles d’IA traite un autre maillon de cette sécurité.
Je retiens surtout la chaîne complète. Trouver un problème avec l’IA est utile. Faire parvenir une correction fiable jusqu’aux services réellement en fonctionnement reste le travail décisif.