Ondřej Surý ayudó a convertir las correcciones de dos fallos críticos del lenguaje de programación PHP en paquetes que los administradores podían instalar en sus servidores. En una entrevista publicada por The Atlantic el 22 de octubre de 2026, el mantenedor explicó cómo su trabajo voluntario facilitó la distribución después de que el proyecto adelantara un día la salida de los parches.
PHP publicó las correcciones el 21 de octubre para las vulnerabilidades CVE-2026-109618 y CVE-2026-109619. Bajo determinadas condiciones, permiten ejecutar código en un servidor sin iniciar sesión. La Fundación PHP confirmó que la divulgación anticipada de sus identificadores obligó a mover el lanzamiento, previsto para el día 22.
Del código corregido a una actualización instalable
Surý mantiene paquetes de PHP para Debian y Ubuntu. En su sitio de distribución explica que realiza ese trabajo desde PHP 5 y que los paquetes oficiales de esas distribuciones son suyos o se basan en su trabajo.
El proyecto PHP publica el código fuente corregido. Surý lo prepara en paquetes que permiten instalarlo y automatizar su despliegue en muchos servidores sin que cada administrador tenga que compilarlo. Así describió su función a The Atlantic y agradeció al proyecto haberle dado acceso anticipado a las correcciones.
La herramienta de desarrollo DDEV obtiene PHP del repositorio de Surý. En su aviso del 21 de octubre documentó que ya había paquetes corregidos para versiones de PHP 5.6 a 8.5 en equipos con procesadores Intel y AMD. La corrección, por tanto, también estaba llegando a versiones antiguas a través de ese canal.
Las cuatro versiones publicadas por el proyecto PHP fueron 8.5.12, 8.4.27, 8.3.36 y 8.2.35. El caso de DDEV ayuda a entender por qué esa lista y la disponibilidad de paquetes para versiones anteriores pueden coexistir: los mantenedores también adaptan correcciones a ramas antiguas.
Surý combina esta actividad con su empleo como director de ingeniería de DNS en Internet Systems Consortium, que lo presenta en un perfil institucional. A The Atlantic le contó que lleva más de 20 años haciendo este trabajo y que buena parte está automatizada. Su mantenimiento voluntario de PHP recibe donaciones.
Encontrar el fallo fue solo una parte del trabajo
La Fundación PHP reconoció que los primeros indicios de uno de los problemas aparecieron en 2024. La dificultad para elegir una solución compatible con el software existente, la falta de una vía de ataque demostrada y la escasez de desarrolladores especializados retrasaron el arreglo. La organización calificó la demora como un fallo estructural.
Los informes recibidos en agosto de 2026 aclararon el alcance del problema y convirtieron su corrección en la prioridad del equipo de seguridad. Según la Fundación, su financiación permitió dedicar a varias personas a tiempo completo. También señaló que las herramientas de IA aumentan la detección de errores, mientras la elección y revisión de las soluciones siguen necesitando ingenieros experimentados.
El trabajo continúa en cada instalación. El NCSC británico pidió identificar los sistemas que utilizan PHP, priorizar los expuestos a internet y aplicar las actualizaciones, incluidas las de productos que incorporan el lenguaje.
Surý pidió que las empresas que más se benefician del código abierto remuneren a quienes lo mantienen. También contó que conversa con Raphaël Hertzog, de Freexian, sobre un plan de continuidad para que la empresa pueda hacerse cargo de su trabajo si él deja de estar disponible.

