PHP parchea dos fallos críticos y refuerza su equipo de seguridad

Si tu infraestructura ejecuta PHP, hoy toca actualizar. Las nuevas versiones 8.5.12, 8.4.27, 8.3.36 y 8.2.35 corrigen dos vulnerabilidades críticas que, en determinadas configuraciones, permiten a un atacante no autenticado ejecutar código en el servidor.

Se trata de CVE-2026-109618 y CVE-2026-109619. Su puntuación real es 9,2, no el 10,0 que circuló en algunos mensajes durante la jornada. Los detalles técnicos y las instrucciones oficiales de actualización están publicados en el anuncio de php.net.

Qué hace cada fallo

Los dos viven en las zonas del motor que atraviesa casi cualquier petición: la gestión de memoria y el tratamiento de errores. Eso es lo que los hace serios y, a la vez, difíciles de corregir sin romper compatibilidad o rendimiento.

• CVE-2026-109618 — corrupción al agotar la memoria. Si una petición llegaba al límite de memoria en el instante preciso, PHP podía dejar datos internos a medio inicializar y tratarlos después como válidos, corrompiendo la memoria. En Apache con mod_php, una petición anónima podía dispararlo antes de ejecutar una sola línea de la aplicación. También se confirmó ejecución remota sobre PHP-FPM a través de rutas de código de la propia aplicación.
• CVE-2026-109619 — estado obsoleto entre peticiones. Un error fatal en el punto equivocado podía dejar el estado interno apuntando a memoria de una petición anterior. La siguiente petición atendida por el mismo worker utilizaba esa memoria ya liberada. Se confirmó un use-after-free, un bloqueo del worker y ejecución remota contra una aplicación real.

Qué versiones instalar

Comprueba la versión en cada entorno con php -v, actualiza los paquetes, reinicia PHP-FPM y Apache, y repite la operación en las imágenes de Docker y en el pipeline de integración continua. Si algún proyecto fija la versión de PHP en su configuración, ese es el primer sitio donde hay que mirar.

Por qué la solución tardó casi dos años

El primer indicio apareció en 2024, durante la primera auditoría externa de seguridad del núcleo de PHP en años. Mientras se corregía otro de los hallazgos, un desarrollador del equipo encontró señales de lo que después sería CVE-2026-109618. En aquel momento se teorizó un posible exploit, pero no se encontró un vector concreto y hubo problemas más evidentes que acapararon la atención.

La corrección se atascó por una razón que conviene contar sin adornos: no había una solución limpia. Cada alternativa rompía compatibilidad, abría una nueva vía de denegación de servicio o exigía cambios coordinados en miles de extensiones de terceros. El equipo de seguridad, que decidía por consenso, no lograba elegir, y el grupo de personas con conocimiento profundo del motor era muy pequeño y estaba ocupado en otras tareas. Los intentos se reiniciaron varias veces durante meses.

En agosto de 2026 se entendió el alcance real: una auditoría encontró ejecución remota de código incondicional con la misma causa raíz, y otros equipos de investigación llegaron al mismo punto de forma independiente. Desde ese día, corregirlo pasó a ser la prioridad absoluta.

Cómo se ha reorganizado la seguridad de PHP

En los últimos meses cambió bastante la forma de trabajar. Se creó un equipo de seguridad del ecosistema que colabora con el equipo del núcleo en triaje, coordinación y endurecimiento; se incorporaron dos personas dedicadas en julio y septiembre; y se sumaron herramientas de validación, compilaciones con sanitizadores y entornos de reproducción que replican la integración continua en cada plataforma soportada.

El programa de auditorías también creció: un fondo público financió la auditoría de 2024, varias empresas de seguridad han revisado el código en 2026 y el número de informes recibidos se ha multiplicado. La inteligencia artificial ayuda a agrupar reportes y descartar duplicados, pero cada decisión y cada parche siguen pasando por manos humanas.

La filtración que adelantó el lanzamiento

La coordinación funcionó hasta dos días antes de la fecha prevista. El 20 de octubre empezaron a circular los identificadores de los CVE en foros y redes, con una hora de publicación equivocada y una puntuación de 10,0 que no era real. No se filtraron detalles técnicos, pero el proyecto adelantó el aviso y movió la publicación un día antes para que los distribuidores llegaran a tiempo.

Después llegó un error de una de las empresas de seguridad, que publicó por equivocación un vídeo con una prueba de concepto, y más tarde un distribuidor rompió el embargo publicando imágenes ya parcheadas más de seis horas antes del anuncio. Nada de eso cambia la recomendación: quien tenga PHP expuesto debe actualizar cuanto antes.

Lo que revela el episodio

PHP sostiene una parte enorme de la web, incluidos servicios públicos, tiendas y banca. Sin embargo, su seguridad depende de un grupo reducido de personas financiadas por la fundación y de algo de trabajo voluntario. Las herramientas encuentran fallos cada vez más rápido, para defensores y atacantes, pero no deciden cómo resolver un problema de diseño con compromisos delicados: eso requiere ingenieros que conozcan todo el código.

La lección práctica para quien mantiene sistemas es doble. La primera, mantener un inventario real de qué versión de PHP corre en cada servicio, porque el parche de hoy solo sirve si se aplica. La segunda, entender que la seguridad del lenguaje que usamos también se financia: quien construye sobre PHP tiene interés directo en que ese equipo crezca.

Lista rápida para tu equipo

• Comprobar php -v en producción, staging y local.
• Actualizar a la versión corregida de tu rama y reiniciar FPM/Apache.
• Actualizar imágenes de contenedor y pipelines, no solo los servidores.
• Revisar logs en busca de bloqueos o errores raros de workers.
• Si no puedes actualizar de inmediato, aplica el parche del proveedor y una regla temporal en el WAF mientras preparas la actualización.
• Seguir los avisos oficiales de php.net para no depender de rumores en redes.