En un texto publicado el 14 de octubre de 2026, Alexandre Daubois describe el trabajo tras los avisos de seguridad del núcleo de PHP. El equipo reúne a miembros de la comunidad y desarrolladores financiados por The PHP Foundation. Funciona de forma independiente de la Foundation. Su Ecosystem Security Team colabora desde otra estructura. Un miembro lee cada informe, intenta reproducirlo y lo contrasta con la política de clasificación antes de tomar una decisión.

Desde el 1 de julio, el equipo ha publicado 15 CVE y ha cerrado 106 informes. Los cierres correspondieron a casos que no eran vulnerabilidades, duplicados o problemas que no pudieron reproducirse. Algunos procedían de fuzzers ejecutados en condiciones poco habituales en producción. Todos fueron revisados. Un caso que no sea una vulnerabilidad pero revele un fallo puede convertirse en trabajo de endurecimiento. Daniel Scherzer se incorporó recientemente al Ecosystem Security Team para ocuparse de esa tarea.

PHP Group es una CVE Numbering Authority para php-src y asigna sus propios identificadores CVE desde 2019. El equipo controla así el calendario de sus avisos. Durante 2026, la cola de advisories de GitHub tarda semanas en revisar parte de los informes. PHP puede publicar su aviso y su CVE cuando el arreglo está listo, sin depender de esa cola.

Todavía existe una acumulación de informes de seguridad. El equipo pide que no se utilicen issues públicas, pull requests ni publicaciones en redes sociales para presionarlo. Eso podría revelar un fallo antes de que exista un arreglo. El trabajo lo realizan voluntarios y desarrolladores financiados por la PHP Foundation. El patrocinio aporta recursos para mantener esta labor.

Las herramientas de IA han aumentado el número de informes que recibe php-src y han abaratado su redacción. El equipo ha respondido con más automatización. Las reproducciones cubren Linux y macOS. También se realizan en Windows y en cualquier otra plataforma que requiera el caso. Las compilaciones usan AddressSanitizer y UndefinedBehaviorSanitizer y siguen la configuración de CI del proyecto.

El equipo utiliza Daybreak Red, el nivel más alto del programa Daybreak de OpenAI. El acceso está limitado a defensores aprobados y está diseñado para investigar vulnerabilidades y validar exploits. OpenAI lo puso a disposición del proyecto como parte de su apoyo a los mantenedores de código abierto. Sirve para seguir un proof of concept dentro del motor, comprobar el impacto declarado y detectar informes que proceden de una misma causa. A comienzos de 2026, el equipo también tuvo acceso a Claude Mythos, un modelo de Anthropic que entonces destacaba en tareas de seguridad. Ese acceso llegó principalmente a través de contactos con Alpha-Omega.

Los modelos no toman las decisiones finales. Una persona establece la gravedad y redacta o revisa cada parche. El equipo no comunica un análisis hasta que alguien ha intentado reproducir el problema.

Los informes deben enviarse mediante el formulario de avisos de seguridad de GitHub, en github.com/php/php-src/security/advisories/new. Las issues públicas sirven para los casos que quedan fuera del proceso de seguridad. Un informe eficaz empieza con el script PHP más pequeño que active el problema. Debe incluir la versión de PHP o el commit. También necesita el sistema operativo y las opciones de configuración. La salida completa de los sanitizers resulta útil cuando está disponible.

El autor debe explicar qué entrada controla el atacante, en qué tipo de aplicación ocurre y qué resultado obtiene. El impacto suele ser la parte menos desarrollada, aunque determina la gravedad. Los informes excesivamente largos o dramáticos ralentizan las investigaciones sencillas. La política de clasificación está disponible en github.com/php/policies/blob/main/security-classification.rst.

La política no considera vulnerabilidad el uso malicioso de código PHP válido. También deja fuera las entradas sin sanear pasadas a funciones como mysqli_query(), los problemas de FFI, los bypass de open_basedir, las compilaciones no estándar y los fallos limitados al servidor web integrado. Estos casos todavía pueden ser bugs y tienen cabida en el rastreador público.

Los informes escritos con ayuda de IA son bienvenidos cuando el autor reproduce el problema en una compilación de PHP, consulta la política y entiende lo que está enviando. Un crash generado por un modelo que no pueda reproducirse exige tiempo para descartarlo y será cerrado.