Mientras gobiernos, hospitales, universidades y empresas de todo el mundo desconectaban servicios por precaución, un ingeniero checo trabajaba en segundo plano para convertir un parche de seguridad en algo que miles de administradores pudieran instalar rápidamente. Se llama Ondřej Surý y, aunque no es una celebridad tecnológica, su labor voluntaria fue decisiva para contener una de las alertas más graves recientes en la web.
Un fallo que puso en jaque a la web
La crisis comenzó con la divulgación de dos vulnerabilidades críticas en PHP, el lenguaje de programación del lado del servidor que, según The Atlantic, se utiliza en cerca del 70% de los sitios web. Los fallos —identificados como CVE-2026-109618 y CVE-2026-109619— podían permitir a un atacante ejecutar código de forma remota sin autenticarse en servidores afectados.
En la práctica, eso significaba un riesgo real de robo de datos, caída de sitios, alteración de contenidos o uso de servidores comprometidos para actividades delictivas. La gravedad llevó a que organismos públicos y entidades de salud en Europa tomaran medidas preventivas, incluida la desconexión temporal de algunos servicios digitales.
La PHP Foundation y el proyecto PHP aceleraron la publicación de las correcciones después de que información sobre las vulnerabilidades se filtrara antes de lo previsto. Pero había un problema adicional: tener el código no bastaba. Los administradores necesitaban paquetes listos para instalar en servidores, especialmente en sistemas basados en Debian y Ubuntu.
Quién es Ondřej Surý
Ondřej Surý es un ingeniero de software checo que vive en Chequia y trabaja como director de ingeniería de DNS en Internet Systems Consortium (ISC), la organización sin fines de lucro que participa en el mantenimiento de infraestructura esencial de internet. Su especialidad incluye DNS, DNSSEC, enrutamiento y alojamiento web, según su ficha oficial en Debian.
Pero su relevancia en esta emergencia no proviene de su empleo principal. Desde hace más de 20 años, Surý mantiene de manera voluntaria paquetes de PHP para Debian y Ubuntu, la base técnica que permite instalar y actualizar el lenguaje en millones de servidores. En una entrevista con The Atlantic, explicó que gran parte de ese proceso está automatizado.
No trabaja para la PHP Foundation ni recibe un salario por esa tarea de mantenimiento. Su labor se sostiene, en parte, con donaciones modestas, pese a que sus paquetes son utilizados de forma masiva por administradores de sistemas, empresas, universidades y proyectos de software libre.
Por qué fue clave para resolver el problema
La PHP Foundation aportó el código fuente de la corrección, pero Surý hizo algo igual de importante: lo transformó en paquetes instalables. Ese paso evitó que cada administrador tuviera que compilar PHP manualmente o improvisar una solución durante una emergencia de seguridad.
Su aporte no se limitó a las versiones modernas. Surý también preparó correcciones retroactivas para versiones antiguas de PHP, algunas con cerca de una década de antigüedad, que seguían siendo utilizadas por pequeñas empresas, escuelas y organizaciones con presupuestos limitados.
Eso fue determinante porque muchas organizaciones no pueden actualizar de inmediato a la última versión de PHP por compatibilidad con aplicaciones heredadas, plugins, sistemas internos o proveedores externos. Al ofrecer parches para versiones anteriores, Surý amplió la cobertura de la respuesta de seguridad y redujo el riesgo para sistemas que, de otro modo, habrían quedado más expuestos.
El “héroe silencioso” de internet
La reacción pública fue rápida. En foros y redes sociales, usuarios de PHP lo describieron como la persona que estaba evitando un desastre global, al punto de que la cobertura de The Atlantic lo presentó como una figura central de la llamada “PHPocalypse”.
Sin embargo, Surý no encaja en el perfil del genio solitario que aparece de la nada. Es, más bien, el ejemplo de un mantenimiento de infraestructura open source que suele ser invisible hasta que falla. Su trabajo demuestra que la seguridad de internet no depende solo de grandes empresas o fundaciones, sino también de personas que mantienen paquetes, automatizan actualizaciones y sostienen sistemas durante años sin protagonismo.
Llevo mucho tiempo haciendo esto, más de 20 años. Muchas de las cosas que hago son automatizadas. Pero la razón por la que no me pareció una locura es que en realidad no tengo ningún sistema que funcione con PHP. Así que para mí fue como, sí, siento una responsabilidad hacia los usuarios de internet. Sería un día loco para mí si estuviera en un barco en medio del mar Adriático. Eso podría pasar. Pero tuve tiempo de preparar los paquetes.
La lección es incómoda: buena parte de la web depende de un puñado de mantenedores voluntarios. Si Surý no hubiera tenido preparados los procesos, la distribución del parche habría sido más lenta y la ventana de exposición para miles de servidores habría sido mayor.
Qué debe hacerse ahora
La alerta no terminó con la publicación de los parches. Los especialistas y el propio Surý advierten que el riesgo persiste mientras haya sitios que no actualicen PHP o no apliquen las correcciones disponibles.
Para administradores y responsables técnicos, las acciones prioritarias son claras:
- Actualizar PHP a las versiones corregidas: 8.2.35, 8.3.36, 8.4.27 o 8.5.12, según la rama utilizada.
- Verificar si el proveedor de hosting ya aplicó el parche.
- Revisar sistemas con versiones antiguas y aplicar los backports disponibles cuando la actualización completa no sea posible.
- Auditar registros, accesos y configuraciones de servidores que pudieron quedar expuestos antes del parche.
Ondřej Surý no “inventó” la solución por sí solo: el código de corrección provino del proyecto PHP y de la PHP Foundation. Pero su trabajo fue el puente entre una vulnerabilidad potencialmente catastrófica y una respuesta práctica a escala global. En una internet construida sobre software abierto, ese puente puede ser la diferencia entre una alerta técnica y una crisis mundial.
