El proyecto PHP publicó el 21 de octubre de 2026 actualizaciones de seguridad que corrigen dos vulnerabilidades críticas en el núcleo del lenguaje, identificadas como CVE-2026-109618 y CVE-2026-109619. Ambas permiten la ejecución remota de código sin necesidad de autenticación previa y fueron calificadas con 9.2 de severidad bajo CVSS v4.0 por los CERT nacionales que retransmitieron el aviso. La falla afecta a todas las versiones de las ramas 8.5, 8.4, 8.3 y 8.2 anteriores a las versiones parcheadas, y su explotación podría comprometer servidores web en todo el mundo, incluidos los de México y América Latina, donde PHP es ampliamente utilizado en infraestructuras de hosting compartido y plataformas de gestión de contenidos.
El mecanismo de seguridad que se convirtió en un arma
El límite de memoria (memory_limit) de PHP está diseñado para proteger al servidor de scripts que consumen recursos desmedidos. Sin embargo, el fallo CVE-2026-109618 transforma ese mecanismo de seguridad en una primitiva de ataque. Cuando un script solicita más memoria de la permitida, el motor de PHP aborta la petición actual mediante una llamada longjmp(), que salta a un estado conocido en lugar de devolver un error por la vía normal. Ese aborto puede ocurrir mientras el motor aún está preparando las estructuras internas de la petición, como en el caso del análisis de formularios con carga de archivos. En ese momento, el cuerpo de la petición y sus metadatos se están poblando y el límite de memoria se dispara.
Debido a que el aborto no es un desenrollado ordenado, la fase de limpieza posterior puede encontrarse con campos que nunca fueron inicializados. El código de limpieza trata esos datos inválidos como válidos e intenta liberar memoria que nunca fue asignada en esa petición. El asignador de memoria puede devolver un bloque que aún contiene datos de una asignación anterior, y esos contenidos pueden ser influenciados por el atacante. El control del contenido de memoria liberada es una ruta estándar desde la corrupción de memoria hasta la ejecución de código, aunque depende del comportamiento del asignador y de cómo la aplicación use la memoria.
Reachability: el verdadero obstáculo para los atacantes
Los avisos no afirman que exista un exploit público, ni nombran aplicaciones específicas vulnerables. La calificación refleja el potencial de la clase de defecto, no una campaña confirmada. El reto para un atacante no es la autenticación, sino la alcanzabilidad. Una petición debe llegar a un punto del código PHP que asigne suficiente memoria para alcanzar el límite configurado mientras aún se está construyendo parcialmente la petición. Los manejadores de carga de archivos de larga duración, el procesamiento de imágenes y los analizadores de XML o JSON de gran tamaño son candidatos naturales. Cualquiera de ellos que sea accesible por HTTP amplía la exposición. Un atacante no necesita credenciales, pero sí un objetivo que acepte cuerpos de petición lo suficientemente grandes como para agotar el límite. Curiosamente, los valores bajos de memory_limit hacen que el umbral sea más fácil de cruzar, por lo que las configuraciones endurecidas pueden estar más expuestas a esta ruta de aborto que las generosas.
Impacto en entornos de hosting compartido y multinquilino
La explotación exitosa conduce a la ejecución de código en el contexto del usuario del servidor web. Ese es el mismo privilegio que PHP ya posee, por lo que el efecto inmediato no es necesariamente root. Sin embargo, en despliegues de hosting compartido y multinquilino, es suficiente para leer datos de otros inquilinos, alcanzar servicios internos desde una posición de red confiable o persistir mediante un archivo que la aplicación pueda escribir. La denegación de servicio es el límite inferior: incluso si la ejecución de código falla, un aborto dentro del análisis de la petición puede dejar al trabajador en un estado indefinido.
Versiones afectadas y cómo protegerse
Todas las versiones de PHP 8.5 anteriores a 8.5.12, las 8.4 anteriores a 8.4.27, las 8.3 anteriores a 8.3.36 y las 8.2 anteriores a 8.2.35 contienen el defecto. Las ramas PHP 8.1 y anteriores están al final de su vida útil y no reciben actualizaciones ordinarias del proyecto, por lo que quedan afectadas indefinidamente a menos que un proveedor externo mantenga parches retroactivos. La corrección está en el motor central, por lo que cada tiempo de ejecución construido a partir de un árbol de fuentes afectado hereda la vulnerabilidad: paquetes de distribución, imágenes base de contenedores, intérpretes embebidos y tiempos de ejecución de lenguajes incluidos en dispositivos.
Las aplicaciones no necesitan su propio parche, pero sí necesitan que el intérprete subyacente sea reconstruido. Una búsqueda en ZoomEye con app="PHP" devolvió 94,382,282 activos coincidentes en el momento de la redacción. Esa cifra cuenta sistemas con huella PHP y no dice nada sobre su nivel de parcheo, por lo que debe leerse como un inventario de dónde importa la actualización, no como un recuento de hosts explotables. PHP es infraestructura, y una gran parte de esos sistemas están detrás de plataformas de gestión de contenidos que informan sus propias versiones en lugar de la compilación del intérprete.
Para mitigar el riesgo, se recomienda actualizar a PHP 8.5.12, 8.4.27, 8.3.36 o 8.2.35. Los mantenedores de distribuciones y proveedores de soporte a largo plazo recibieron los parches antes de su publicación, por lo que refrescar los paquetes a través del canal normal suele ser la ruta más rápida en Linux. Después de la actualización, verifique la versión del intérprete con php -v y confirme que el servicio en ejecución adoptó el nuevo binario, ya que algunas configuraciones de despliegue mantienen una compilación antigua en disco. Para las ramas al final de su vida útil, el equipo de seguridad de PHP publicó correcciones retrospectivas mínimas para 7.4, 8.0 y 8.1 dirigidas a organizaciones que compilan desde el código fuente o carecen de un proveedor de soporte a largo plazo. Otros deberían planificar el paso a una rama soportada.
Cuando la aplicación de parches deba esperar, los avisos recomiendan aislar las aplicaciones PHP expuestas a internet de las redes públicas hasta que la corrección esté instalada y verificada, y comprobar si el software de terceros incluye su propia copia de PHP. El repositorio NCSC-NL se señala como el lugar para buscar productos afectados.
Contexto para América Latina
En México y la región, una gran cantidad de sitios web y aplicaciones empresariales se ejecutan sobre PHP, a menudo en entornos de hosting compartido donde las actualizaciones dependen del proveedor de servicios. La vulnerabilidad subraya la importancia de mantener actualizados los intérpretes y de verificar que los proveedores de hosting apliquen las actualizaciones de seguridad de manera oportuna. Las organizaciones deben revisar sus versiones de PHP y asegurarse de que los paneles de control y las plataformas de gestión de contenidos estén utilizando las versiones parcheadas.