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 ejecución remota de código sin necesidad de autenticación y fueron calificadas con 9.2 de severidad bajo el estándar CVSS v4.0 por los equipos nacionales de respuesta a incidentes (CERT) que difundieron el aviso. La noticia es relevante para México y América Latina porque PHP es uno de los lenguajes más usados en la infraestructura web de la región, desde sitios de gobierno hasta plataformas de comercio electrónico y sistemas escolares.
¿Qué es CVE-2026-109618 y por qué es tan grave?
El fallo principal, CVE-2026-109618, afecta el mecanismo que PHP utiliza para limitar el consumo de memoria por solicitud. Cuando un script intenta usar más memoria de la permitida, el motor aborta la ejecución mediante una función llamada longjmp() en lugar de devolver un error controlado. Si esa interrupción ocurre mientras el motor aún está construyendo las estructuras internas de la solicitud —por ejemplo, al procesar la carga de un archivo—, la fase de limpieza posterior puede encontrar campos no inicializados y tratar datos inválidos como válidos. Esto abre la puerta a corrupción de memoria que, en manos de un atacante, puede derivar en ejecución de código arbitrario.
El aviso del CSIRT de Chipre describe con detalle técnico este camino defectuoso, aunque aclara que no se conoce un exploit público hasta el momento. La calificación refleja el potencial de la clase de defecto, no un ataque confirmado en curso.
Segunda vulnerabilidad: CVE-2026-109619
El mismo comunicado cierra CVE-2026-109619, un defecto separado en el manejo del estado de las solicitudes, con la misma calificación de severidad. Ambas fallas fueron corregidas en las versiones PHP 8.5.12, 8.4.27, 8.3.36 y 8.2.35, publicadas el 21 de octubre tras un preanuncio el día anterior.
¿Quiénes están en riesgo?
Todas las versiones de PHP 8.5 anteriores a 8.5.12, 8.4 anteriores a 8.4.27, 8.3 anteriores a 8.3.36 y 8.2 anteriores a 8.2.35 contienen el defecto. Las ramas 8.1 y anteriores están al final de su vida útil y no reciben actualizaciones ordinarias del proyecto, por lo que permanecen afectadas indefinidamente a menos que un proveedor externo mantenga parches retroactivos.
El arreglo se encuentra en el motor central, de modo que todo entorno de ejecución construido a partir de un árbol de código afectado hereda la vulnerabilidad: paquetes de distribuciones, imágenes base de contenedores, intérpretes embebidos y tiempos de ejecución incluidos en electrodomésticos o dispositivos. Las aplicaciones no necesitan un parche propio, pero sí requieren que el intérprete subyacente sea reconstruido.
Una búsqueda en el motor de escaneo ZoomEye con la consulta app="PHP" devolvía 94,382,282 activos con huella de PHP en el momento de redactar esta nota. Esa cifra no indica el nivel de parcheo, sino el inventario de sistemas donde la actualización es relevante. Muchos de esos sistemas operan detrás de plataformas de gestión de contenidos que reportan su propia versión, no la del intérprete.
¿Cómo protegerse?
La recomendación principal es 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 por el canal habitual suele ser la vía más rápida en Linux. Tras la actualización, verifica la versión del intérprete con php -v y confirma que el servicio en ejecución haya tomado el nuevo binario, ya que algunas configuraciones de despliegue conservan una versión anterior 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 extendido. Otras deberían planear la migración a una rama soportada.
Si la actualización debe esperar, los avisos recomiendan aislar las aplicaciones PHP expuestas a internet de las redes públicas hasta que el parche esté instalado y verificado, y revisar si el software de terceros incorpora su propia copia de PHP. El repositorio de NCSC-NL se señala como el lugar para consultar los productos afectados.
Contexto: la memoria como vector de ataque
El límite de memoria de PHP está diseñado para proteger al servidor de scripts descontrolados. Esta vulnerabilidad convierte ese mecanismo de seguridad en una primitiva de ataque. La condición para explotarla no es la autenticación, sino la alcanzabilidad: una solicitud debe llegar a un código PHP que asigne suficiente memoria para alcanzar el límite configurado mientras la solicitud aún está a medio construir. Manejadores de carga de archivos de larga duración, procesamiento de imágenes y analizadores de XML o JSON grandes son los candidatos naturales. Los valores bajos de memory_limit hacen más fácil cruzar el umbral, por lo que configuraciones endurecidas pueden estar más expuestas a esta ruta de aborto que configuraciones generosas.
Una explotación exitosa otorga ejecución de código en el contexto del usuario del servidor web, el mismo privilegio que PHP ya posee. En entornos de alojamiento compartido y multinquilino, eso basta para leer datos de otros clientes, 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 falla la ejecución de código, un aborto dentro del análisis de la solicitud puede dejar al trabajador en un estado indefinido.
Recomendaciones finales para equipos de TI en Latinoamérica
- Identifica todos los servidores y contenedores que ejecuten PHP y verifica su versión actual.
- Actualiza a las versiones parcheadas lo antes posible, priorizando aquellos expuestos a internet.
- Revisa si tu plataforma de gestión de contenidos o aplicaciones de terceros incluyen su propio intérprete PHP.
- Si no puedes actualizar de inmediato, aísla las aplicaciones PHP de redes públicas y monitorea intentos de solicitudes anómalas.
- Considera migrar de ramas obsoletas (8.1 o anteriores) a versiones con soporte activo.
La industria de la ciberseguridad en la región debe estar atenta: aunque no se ha detectado explotación activa, la gravedad de la falla y la amplia base instalada de PHP exigen acción inmediata. La actualización no es solo una buena práctica, sino una medida urgente para proteger datos y servicios.