En esta página
El 21 de octubre de 2026, el proyecto PHP publicó PHP 8.5.12, 8.4.27, 8.3.36 y 8.2.35. Estas versiones corrigen dos vulnerabilidades críticas, CVE-2026-109618 y CVE-2026-109619, el par conocido como php2shell. En las condiciones adecuadas, permiten a un atacante no autenticado ejecutar código en un servidor que ejecuta PHP. La PHP Foundation lo dice sin rodeos: si usas PHP, actualiza ahora.
Vodlix parcheó sus sistemas antes de que las fallas se hicieran públicas. Los clientes de Vodlix no tuvieron que hacer nada.
Un parche no protege a nadie hasta que está instalado en tu servidor. Para un negocio de vídeo, a eso se reduce php2shell.
¿Qué es php2shell?
php2shell es el nombre de dos fallas relacionadas de ejecución remota de código en PHP, CVE-2026-109618 y CVE-2026-109619. Ambas se encuentran en la gestión de memoria y el manejo de errores, partes de PHP por las que pasa casi cualquier petición. Los avisos del proyecto PHP las califican como críticas, y las versiones corregidas salieron el 21 de octubre de 2026.
La PHP Foundation y los avisos del proyecto PHP se refieren a las fallas por sus números CVE, así que úsalos cuando busques en los avisos de tus proveedores y hosts.
CVE-2026-109618: corrupción de memoria cuando PHP se queda sin memoria
Si una petición alcanzaba el memory_limit de PHP justo en el peor momento, PHP podía dejar datos internos parcialmente inicializados y después tratarlos como válidos. En Apache con mod_php, una petición no autenticada puede provocarlo antes de que se ejecute cualquier código de la aplicación, y la PHP Foundation afirma que se demostró la ejecución remota de código completa con la configuración por defecto. La ejecución remota de código también se confirmó en PHP-FPM a través de rutas de código de la aplicación.
CVE-2026-109619: estado obsoleto heredado de una petición anterior
Un error fatal en el momento equivocado podía dejar un estado interno apuntando a memoria que pertenecía a una petición anterior. Una petición posterior en el mismo worker podía entonces usar esa memoria liberada. Según la PHP Foundation, quien lo reportó demostró la ejecución remota de código contra una aplicación real en Apache con mod_php.
¿Qué versiones de PHP corrigen la vulnerabilidad php2shell?
Las versiones corregidas son PHP 8.5.12, 8.4.27, 8.3.36 y 8.2.35, todas publicadas el 21 de octubre de 2026. Todas las versiones anteriores de esas cuatro ramas están afectadas, según el aviso del proyecto PHP para CVE-2026-109618. Si usas PHP 8.1 o una versión anterior, no hay parche para tu rama.
Tu rama de PHP | Afectada | Actualizar a |
|---|---|---|
8.5 | Anterior a 8.5.12 | 8.5.12 |
8.4 | Anterior a 8.4.27 | 8.4.27 |
8.3 | Anterior a 8.3.36 | 8.3.36 |
8.2 | Anterior a 8.2.35 | 8.2.35 |
8.1 y anteriores | Ya sin soporte | Una rama con soporte, como 8.5.12 |
TechCrunch informa de que los agujeros han estado presentes en todas las versiones de PHP desde PHP 5, publicada en 2004, y de que PHP 8.1 y las versiones anteriores ya no tienen soporte. Los sitios que usan esas versiones tienen por delante más trabajo que una actualización menor.
¿Quién descubrió las fallas, y cuándo?
El investigador Ryan A, de la empresa de seguridad Calif, reportó a PHP la primera ejecución remota de código el 11 de agosto de 2026, durante una auditoría que había comenzado el 30 de julio de 2026. Después, Wiz y OpenAI reportaron otras vías de ataque. La causa raíz se remonta a un problema de memoria que el equipo de PHP detectó por primera vez en 2024.
El propio relato de la PHP Foundation establece el orden de los acontecimientos:
2024: durante la primera auditoría de seguridad externa de PHP en años, un desarrollador principal encontró los primeros indicios del problema de falta de memoria. Entonces no se halló ninguna vía de ataque concreta, y la corrección quedó estancada.
30 de julio de 2026: Calif comenzó una auditoría de PHP dentro del programa Patch the Planet.
11 de agosto de 2026: Ryan A, de Calif, reportó una ejecución remota de código incondicional con la misma causa raíz. OpenAI reportó de forma independiente la misma causa raíz.
24 de agosto de 2026: Wiz reportó otros vectores de ataque.
18 de septiembre de 2026: OpenAI reportó otros vectores de ataque.
21 de octubre de 2026: PHP publicó las versiones corregidas.
La Foundation es franca sobre ese lapso: califica el retraso desde 2024 como «un fallo estructural» del proceso de decisión del equipo de seguridad y de su falta de recursos, y afirma que el equipo está cambiando su forma de trabajar.
¿Qué tan grave es php2shell, y cómo ha reaccionado internet?
Es grave porque PHP está en todas partes y el peor escenario es un atacante ejecutando código en tu servidor. TechCrunch informa de que PHP impulsa aproximadamente el 70 % de los sitios web, y de que la Agencia de Seguridad Nacional de EE. UU. aconsejó desconectar un sitio si no se puede parchear de inmediato.
TechCrunch también informa de que los agujeros pueden permitir a los atacantes acceder al sistema de archivos de un servidor o a una base de datos que use la aplicación web. En el momento de su reportaje del 21 de octubre, OpenAI dijo que las fallas habían sido descubiertas por investigadores antes que por atacantes, sin informes de explotación activa. La divulgación cambia eso, porque los detalles ahora son públicos.
Los proveedores de nube reaccionaron el mismo día. AWS publicó el boletín de seguridad 2026-143-AWS el 21 de octubre de 2026, marcado como «Important (requires attention)», para los entornos de ejecución web de PHP afectados por ambas CVE.
¿Qué significa php2shell para una plataforma de streaming o un sitio de vídeo?
Significa revisar cada parte de tu negocio de vídeo que ejecute PHP, no solo el reproductor. Un sitio de streaming es una tienda, un inicio de sesión, un flujo de facturación y, a menudo, un sitio de marketing o un blog. Si cualquiera de ellos ejecuta PHP en un servidor que gestionas tú o tu host, necesita una versión corregida.
Aquí la seguridad no es solo una tarea de TI. Es una cuestión de negocio. Un sitio de vídeo que se desconecta para esperar un parche deja de vender suscripciones y alquileres durante todo el tiempo que esté caído.
WordPress es un caso habitual. TechCrunch informa de que WordPress dijo que la falla no es específica de WordPress, y de que los sitios que lo usan deben parchear sus servidores y trabajar con sus empresas de hosting.
Parchear es una capa de protección. Nuestra guía sobre los fundamentos de seguridad OTT para tu contenido y tus espectadores cubre las demás, y nuestra página sobre seguridad de inicio de sesión para plataformas de streaming cubre las cuentas de los espectadores.
¿Cómo gestionó Vodlix php2shell?
Vodlix parcheó sus sistemas contra CVE-2026-109618 y CVE-2026-109619 antes de que las fallas se hicieran públicas el 21 de octubre de 2026. En Vodlix solo el middleware usa PHP, y eso fue lo que se parcheó. Los clientes de Vodlix no tuvieron que tomar ninguna medida.
En una plataforma gestionada como Vodlix, las actualizaciones de seguridad como esta se aplican por ti. Si quieres reportar un problema de seguridad sobre Vodlix, escribe a [email protected].
¿Qué debes hacer si gestionas tus propios sitios PHP?
Actualiza cada instalación de PHP que gestiones a una versión corregida, o pide a tu host que lo haga, y lee los avisos de tus proveedores. Si no puedes actualizar de inmediato, sigue la recomendación de la NSA que recoge TechCrunch y desconecta el sitio hasta que puedas.
Haz una lista de lo que ejecuta PHP. Incluye tu sitio principal, cualquier sitio o blog de WordPress, las páginas de destino y las herramientas de administración.
Comprueba cada versión. Compárala con la tabla anterior.
Actualiza o pide a tu host que lo haga. Pasa a 8.5.12, 8.4.27, 8.3.36 u 8.2.35. En un host gestionado, pídeles que confirmen la fecha en que actualizaron.
Planifica una migración para las ramas antiguas. PHP 8.1 y las versiones anteriores ya no tienen soporte, así que no habrá parche para ellas.
Lee los avisos de tus proveedores. Empieza por tu host y tu proveedor de nube. AWS ya ha publicado uno.
Confirma que la nueva versión está en ejecución. Vuelve a comprobarlo después de la actualización, en cada servidor.
Próximos pasos
Si eres cliente de Vodlix, no necesitas hacer nada respecto a php2shell. Para cualquier duda, visita el centro de ayuda de Vodlix o contacta con el equipo de Vodlix.
Si estás valorando una plataforma gestionada para que actualizaciones como esta se hagan por ti, consulta las funciones de la plataforma Vodlix o solicita una demo de Vodlix.
Preguntas frecuentes
¿Qué es php2shell?
php2shell es el apodo de dos vulnerabilidades críticas de PHP, CVE-2026-109618 y CVE-2026-109619. Los avisos oficiales, como los de la PHP Foundation, usan los números CVE. Ambas son fallas en la gestión de memoria y el manejo de errores de PHP que, en las condiciones adecuadas, permiten a un atacante no autenticado ejecutar código en un servidor. PHP las corrigió el 21 de octubre de 2026.
¿Qué versiones de PHP corrigen CVE-2026-109618 y CVE-2026-109619?
PHP 8.5.12, 8.4.27, 8.3.36 y 8.2.35 corrigen ambas vulnerabilidades. Se publicaron el 21 de octubre de 2026. Cualquier versión anterior de las ramas 8.5, 8.4, 8.3 y 8.2 está afectada. PHP 8.1 y las versiones anteriores ya no tienen soporte, por lo que los sitios que las usan deben pasar a una rama con soporte.
¿Los clientes de Vodlix tienen que hacer algo respecto a php2shell?
No. En Vodlix solo el middleware usa PHP, y Vodlix lo parcheó antes de que las fallas se hicieran públicas el 21 de octubre de 2026. Los clientes no tuvieron que tomar ninguna medida. Si quieres reportar un problema de seguridad sobre Vodlix, puedes escribir a [email protected].
¿WordPress está afectado por la vulnerabilidad de PHP de octubre de 2026?
WordPress funciona sobre PHP, así que los sitios de WordPress están expuestos a través de la versión de PHP del servidor. TechCrunch informa de que WordPress dijo que la falla no es específica de WordPress, y de que los sitios que lo usan deben parchear sus servidores y trabajar con sus empresas de hosting. Actualizar WordPress no sustituye a actualizar PHP.
¿Se explotó php2shell antes de que saliera la corrección?
TechCrunch informó el 21 de octubre de 2026 de que, según OpenAI, las fallas fueron descubiertas por investigadores antes que por atacantes y en ese momento no había informes de explotación activa. Ahora que los detalles son públicos, los servidores sin parchear corren un riesgo mayor, y por eso la NSA aconsejó desconectar los sitios que no se puedan parchear.
¿Qué hago si no puedo actualizar PHP de inmediato?
TechCrunch informa de que la Agencia de Seguridad Nacional de EE. UU. aconsejó que, si un sitio web no se puede parchear de inmediato, se desconecte hasta que sea posible. Pregunta a tu host cuándo aplicará PHP 8.5.12, 8.4.27, 8.3.36 u 8.2.35, y lee su aviso y el de tu proveedor de nube, como el boletín 2026-143-AWS de AWS.
¿Te gustó lo que acabas de leer?
Suscríbete para obtener las últimas noticias, estrategias e insights sobre negocios de membresía entregados directamente a tu bandeja de entrada.



