Dans un texte publié le 14 octobre 2026, Alexandre Daubois décrit le traitement des signalements visant le cœur de PHP. L’équipe réunit des membres de la communauté et des développeurs financés par The PHP Foundation. Elle fonctionne indépendamment de la Foundation. L’Ecosystem Security Team de la Foundation travaille en parallèle. Chaque signalement est lu par un membre de l’équipe, puis sa reproduction et sa conformité avec la politique de classification sont vérifiées avant toute décision.

Depuis le 1er juillet, l’équipe a publié 15 CVE et clôturé 106 signalements. Ces clôtures concernaient des cas qui n’étaient pas des vulnérabilités, des doublons ou des problèmes impossibles à reproduire. Certains venaient de fuzzers configurés dans des conditions éloignées de la production. Tous ont été examinés. Un cas qui n’est pas une vulnérabilité mais révèle un bug peut devenir un travail de renforcement. Daniel Scherzer a récemment rejoint l’Ecosystem Security Team pour cette activité.

Le PHP Group est une CVE Numbering Authority pour php-src et attribue ses propres identifiants CVE depuis 2019. L’équipe maîtrise donc le calendrier de ses advisories. En 2026, la file d’attente des advisories de GitHub nécessite parfois plusieurs semaines de revue. PHP n’a pas à attendre cette file lorsqu’un correctif est prêt.

Un stock de signalements reste à traiter. L’équipe demande aux chercheurs de ne pas utiliser les issues publiques, les pull requests ou les réseaux sociaux pour la relancer. Une telle démarche pourrait exposer le problème avant la disponibilité d’un correctif. Des bénévoles et des développeurs financés par la PHP Foundation assurent ce travail. Les parrainages apportent les ressources nécessaires à la sécurité du projet.

Les outils d’IA ont fait progresser le nombre de signalements reçus par php-src et ont réduit le coût de leur rédaction. L’équipe automatise donc davantage son traitement. Les reproductions couvrent Linux et macOS. Windows et toute autre plateforme nécessaire sont également utilisés. Les compilations activent AddressSanitizer et UndefinedBehaviorSanitizer et reprennent la configuration de la CI du projet.

L’équipe dispose de Daybreak Red, le niveau le plus élevé du programme Daybreak d’OpenAI. Cet accès est réservé aux défenseurs approuvés et vise la recherche de vulnérabilités ainsi que la validation d’exploits. OpenAI l’a accordé dans le cadre de son soutien aux mainteneurs open source. L’outil sert à suivre un proof of concept dans le moteur, à vérifier l’impact annoncé et à repérer les signalements qui partagent une même cause. Plus tôt en 2026, l’équipe a aussi utilisé Claude Mythos, un modèle d’Anthropic alors en pointe pour les travaux de sécurité. Cet accès provenait surtout de contacts noués avec Alpha-Omega.

Les modèles ne prennent pas les décisions finales. Une personne fixe la gravité et écrit ou relit chaque correctif. Aucun retour d’analyse n’est envoyé avant qu’un membre de l’équipe ait tenté la reproduction.

Les signalements doivent passer par le formulaire d’avis de sécurité GitHub, à l’adresse github.com/php/php-src/security/advisories/new. Les issues publiques servent aux cas qui ne relèvent pas du processus de sécurité. Un bon dossier commence par le plus petit script PHP capable de déclencher le problème. Il indique la version de PHP ou le commit concerné. Le système d’exploitation et les options de configuration sont également nécessaires. La sortie complète des sanitizers est utile lorsqu’elle existe.

Le signalement doit préciser quelle entrée l’attaquant contrôle, dans quel type d’application et quel résultat il peut obtenir. L’impact est souvent la partie la moins documentée, alors qu’il détermine la gravité. Les textes très longs ou alarmistes ralentissent les vérifications simples. La politique de classification est publiée à l’adresse github.com/php/policies/blob/main/security-classification.rst.

Du code PHP valide utilisé de manière malveillante n’est pas classé comme vulnérabilité. La politique exclut aussi les entrées non assainies transmises à des fonctions comme mysqli_query(), les problèmes liés à FFI, les contournements de open_basedir, les compilations non standard et les défauts limités au serveur web intégré. Ces cas peuvent rester des bugs et doivent être signalés dans le suivi public.

Les signalements rédigés avec l’aide d’une IA sont acceptés si leur auteur reproduit le problème sur une compilation PHP, vérifie la politique et comprend ce qu’il soumet. Un crash produit par un modèle mais impossible à reproduire demande autant de travail pour être écarté et sera fermé.