✨︎ Resumen (TL;DR):
- Ondřej Surý convirtió las correcciones de dos fallos críticos de PHP en paquetes instalables para Debian y Ubuntu.
- PHP publicó las correcciones el 21 de octubre de 2026, un día antes de lo previsto, para las vulnerabilidades CVE-2026-109618 y CVE-2026-109619.
- DDEV documentó paquetes corregidos para PHP 5.6 a 8.5 en equipos Intel y AMD; el NCSC británico pidió priorizar los sistemas expuestos a internet.
Ondřej Surý ayudó a convertir en paquetes instalables las correcciones de dos vulnerabilidades críticas de PHP para administradores de Debian y Ubuntu. PHP publicó los parches el 21 de octubre de 2026, un día antes de lo previsto, después de que se divulgaran antes de tiempo los identificadores CVE-2026-109618 y CVE-2026-109619. Bajo ciertas condiciones, ambos fallos permiten ejecutar código en un servidor sin iniciar sesión.
Del código corregido a una actualización instalable
Surý mantiene paquetes de PHP para Debian y Ubuntu. En su sitio de distribución señala que hace ese trabajo desde PHP 5 y que los paquetes oficiales de ambas distribuciones son suyos o se basan en su trabajo.
El proyecto PHP publica el código fuente corregido. Surý lo prepara en paquetes que los administradores pueden instalar y usar para automatizar el despliegue en muchos servidores, sin compilar el lenguaje en cada equipo.
En una entrevista publicada por The Atlantic el 22 de octubre de 2026, Surý explicó esa función y agradeció al proyecto PHP haberle dado acceso anticipado a las correcciones.
DDEV obtiene PHP del repositorio de Surý. En un aviso del 21 de octubre, la herramienta documentó que ya había paquetes corregidos para versiones de PHP 5.6 a 8.5 en equipos con procesadores Intel y AMD. Ese canal también llevó la corrección a ramas antiguas, donde los mantenedores adaptan los arreglos a versiones anteriores.
El proyecto PHP publicó cuatro versiones corregidas:
- PHP 8.5.12
- PHP 8.4.27
- PHP 8.3.36
- PHP 8.2.35
La lista de versiones del proyecto puede coexistir con los paquetes de DDEV para PHP 5.6 a 8.5. El proyecto publica las ramas que mantiene directamente, mientras otros mantenedores adaptan las correcciones a versiones anteriores.
La demora empezó antes del lanzamiento
La Fundación PHP reconoció que los primeros indicios de uno de los problemas aparecieron en 2024. La solución debía ser compatible con el software existente, no había una vía de ataque demostrada y faltaban desarrolladores especializados. La organización calificó el retraso como un fallo estructural.
Los informes recibidos en agosto de 2026 aclararon el alcance del problema y convirtieron la 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 a esa tarea.
La organización también señaló que las herramientas de IA aumentan la detección de errores, pero que la elección y la revisión de las soluciones todavía requieren ingenieros experimentados.
La alerta también llegó a los administradores
El trabajo continúa en cada instalación. El NCSC británico pidió identificar los sistemas que utilizan PHP, priorizar los que están expuestos a internet y aplicar las actualizaciones. La solicitud incluye los productos que incorporan el lenguaje.
La recomendación amplía el alcance del parche más allá de los servidores donde alguien instaló PHP de forma directa. También contempla software que integra el lenguaje como parte de su funcionamiento.
Un mantenimiento voluntario con plan de continuidad
Surý combina el mantenimiento de PHP con su empleo como director de ingeniería de DNS en Internet Systems Consortium, organización 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. Surý también pidió que las empresas que más se benefician del código abierto remuneren a quienes lo mantienen.
Además, 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.
La alerta mostró que publicar una corrección es solo una parte del proceso. La actualización también debe convertirse en paquetes, llegar a ramas antiguas y mantenerse cuando la distribución depende del trabajo de pocos desarrolladores. En este caso, Surý y Hertzog ya analizan cómo conservar esa cadena si el mantenedor no puede continuar.
