Respuesta rápida: php2shell, vulnerabilidades críticas filtradas de PHP (CVE-2026-109618 y CVE-2026-109619)

Puntos clave

El 20 de octubre, los detalles de dos vulnerabilidades críticas de ejecución remota de código (RCE) en PHP, CVE-2026-109618 y CVE-2026-109619, se filtraron en línea antes de su divulgación coordinada y antes de que se lanzaran los parches.
Poco después de la filtración, PHP publicó un aviso indicando que se programaría un próximo lanzamiento de seguridad para corregir las dos vulnerabilidades. El equipo de seguridad de PHP clasifica ambas fallas como de severidad crítica (con una calificación CVSS v4.0 de 9,2). PHP indicó que sus actualizaciones de emergencia ocurrirían el miércoles 21 de octubre (y que podrían lanzarse incluso antes si se hacen públicos los detalles técnicos o comienza la explotación).

El 21 de octubre, alrededor de las 9:30 a. m. hora del Este, el equipo de PHP lanzó PHP 8.5.12, 8.4.27, 8.3.36 y 8.2.35 para corregir las dos vulnerabilidades.
Huntress aún no ha observado explotación activa de estas vulnerabilidades entre nuestra base de socios al 21 de octubre a las 10:00 a. m. hora del Este; sin embargo, otros están reportando que están viendo surgir ataques. Por lo tanto, actualizar de inmediato a PHP 8.5.12, 8.4.27, 8.3.36 u 8.2.35 es fundamental.
Qué debes hacer ahora mismo: inventaría cada instalación de PHP que tengas (incluidas las que se esconden dentro de software de proveedores) y aísla de internet cualquier instalación de PHP fuera de soporte. Las organizaciones deben actualizar a PHP 8.5.12, 8.4.27, 8.3.36 u 8.2.35 lo antes posible.

Agradecimientos: Gracias especiales a Lindsey Welch y Ben Nahorney por sus contribuciones a esta investigación y redacción.

Actualización 21/10/26 @ 4:40 p. m. hora del Este

Desde que PHP publicó su aviso de seguridad esta mañana para abordar las dos vulnerabilidades críticas, varios investigadores han dado a conocer los detalles técnicos de las vulnerabilidades:

El análisis de Calif ofrece un historial detallado de las vulnerabilidades de límite de memoria de PHP, y luego explica cómo Calif revisó esos hallazgos anteriores a través de la iniciativa Patch the Planet de OpenAI, descubriendo múltiples puntos de interrupción y rutas de RCE confiables.
Wiz demostró cómo funciona la RCE no autenticada contra WordPress, Drupal y Joomla, y mostró que una ruta de divulgación de memoria independiente podría exponer contraseñas, tokens, claves de API y certificados.

Hasta el 21 de octubre a las 4:30 p. m. hora del Este, Huntress no ha observado explotación activa en los sistemas de los socios. Seguimos monitoreando los desarrollos relevantes relacionados con estas vulnerabilidades.

Actualización: 21/10/26 @ 10 a. m. hora del Este

El 21 de octubre, alrededor de las 9:30 a. m. hora del Este, el equipo de PHP lanzó PHP 8.5.12, 8.4.27, 8.3.36 y 8.2.35 para abordar las dos vulnerabilidades.

Según PHP, todas las instalaciones de PHP que atienden solicitudes web están en riesgo (incluyendo PHP-FPM, Apache con mod_php, php-cgi, FrankenPHP y LiteSpeed). Existe un exploit para mod_php en el que una solicitud no autenticada puede desencadenar un ataque antes de que se ejecute cualquier código de la aplicación.

Qué hacer:

Las descargas de código fuente están en el sitio de descargas de PHP; las organizaciones deben actualizar a PHP 8.5.12, 8.4.27, 8.3.36 u 8.2.35 lo antes posible. Para las organizaciones que no pueden actualizar de inmediato, PHP también ha detallado medidas para reducir la exposición a rutas de ataque específicas en su aviso.

Otras indicaciones de actualización de PHP:

Las distribuciones de Linux y los proveedores de LTS recibieron los parches antes de su publicación. Consulta con tu proveedor sobre paquetes de PHP actualizados.
PHP 8.1 y versiones anteriores ya no cuentan con soporte del proyecto PHP y no recibirán actualizaciones oficiales. Algunas distribuciones y proveedores de LTS podrían retroportar correcciones para estas versiones, así que asegúrate de contactar a tu proveedor para más información o actualizar a una versión compatible.
Las organizaciones que usan el repositorio mantenido por voluntarios rpms.remirepo.net deben pasar a paquetes proporcionados por la distribución o compilar PHP desde el código fuente para aplicar las actualizaciones de inmediato. Los paquetes actualizados de ese repositorio no estarán disponibles hoy.
El equipo de seguridad de PHP también ha proporcionado retroportes mínimos de código fuente para PHP 7.4, PHP 8.0 y PHP 8.1. Estas ramas están destinadas a organizaciones que compilan PHP desde el código fuente o no tienen acceso a un proveedor de LTS.

Para quienes usan versiones más antiguas y obsoletas de PHP (anteriores a los números de versión 8.2.x), es probable que no haya un parche oficial para resolver las vulnerabilidades. Para entornos que ejecutan versiones obsoletas y fuera de soporte de PHP, los administradores deben agregar de inmediato la línea session.upload_progress.enabled = Off a la configuración de php.ini en su servidor. Esto puede requerir reiniciar los servicios web o el servidor en sí para que surta efecto, pero mitigará los casos de abuso conocidos.

Si bien el software en estas versiones obsoletas no recibirá un parche oficial de los mantenedores de PHP, investigadores de seguridad han producido sus propios parches que permitirán a los administradores recompilar los módulos de PHP desde el código fuente. Huntress no puede evaluar si estos parches son efectivos, y recomienda que, siempre que sea posible (y con pruebas adecuadas para garantizar que la actualización no afecte la funcionalidad del sitio web), los administradores actualicen su versión de PHP en los servidores que mantienen a la versión 8.5.x más reciente.

Las vulnerabilidades:

PHP publicó más información sobre las dos vulnerabilidades.

CVE-2026-109618 es una falla de ejecución remota de código en el manejo de errores de memoria agotada de PHP. Si PHP se queda sin memoria mientras configura los datos de la solicitud, se interrumpe y esos datos quedan solo parcialmente inicializados. Durante la limpieza de la solicitud, esos datos parcialmente inicializados se tratan como válidos, creando una ruta hacia la ejecución de código.

El impacto aquí es ejecución remota de código (RCE) no autenticada bajo la cuenta del trabajador web: según PHP, se validó una RCE completa a través de HTTP contra mod_php con los límites predeterminados de entrada y memoria de PHP, y configuraciones prefork normales con múltiples trabajadores.

CVE-2026-109619 es una falla de ejecución remota de código causada porque PHP retiene el estado específico de la solicitud después de que su memoria de respaldo ha sido liberada. Si el mismo trabajador procesa una solicitud posterior, PHP puede acceder a ese estado obsoleto antes de que la inicialización normal lo restablezca. Esta vulnerabilidad puede provocar uso de memoria liberada (heap use-after-free) no autenticado, divulgación de memoria y ejecución remota de código con los privilegios del trabajador web.

Huntress aún no ha observado explotación activa de estas vulnerabilidades en nuestra base de socios hasta el 21 de octubre a las 10 a. m. hora del Este; sin embargo, otros están reportando que están viendo ataques emergentes. Por lo tanto, actualizar de inmediato a PHP 8.5.12, 8.4.27, 8.3.36 u 8.2.35 y seguir las indicaciones anteriores es fundamental.

Huntress sigue monitoreando los avances relacionados con CVE-2026-109618 y CVE-2026-109619. Actualizaremos este blog según surja nueva información.

Antecedentes

En la mañana del 20 de octubre, una publicación en Hacker News afirmó que dos vulnerabilidades críticas de PHP estaban por hacerse públicas. La publicación se eliminó, pero no antes de que las capturas de pantalla circularan por las redes sociales. En pocas horas, nuestros buenos amigos de watchTowr confirmaron la filtración, escribiendo que las vulnerabilidades eran reales y que "se suponía que todos debíamos esperar hasta el jueves a las 11 a. m. hora del Este."

Poco después, el equipo de seguridad de PHP publicó un aviso anticipado de un próximo lanzamiento de seguridad que abordaría dos vulnerabilidades críticas, ambas con una calificación CVSS v4.0 de 9,2. El equipo programó ese lanzamiento para el miércoles 21 de octubre a las 14:00 UTC, un día antes del embargo original, y señaló que se reserva el derecho de publicarlo incluso antes "si los detalles de cualquiera de las vulnerabilidades se hacen públicos, o si aparece evidencia de explotación activa en el entorno real."

PHP está en todas partes. Impulsa silenciosamente sitios de WordPress, Drupal, Joomla y Magento, plataformas de alojamiento compartido, paneles de control, y una gran cantidad de software que ni siquiera anuncia que usa PHP por debajo. Cuando una falla crítica aparece en PHP mismo, en lugar de en una aplicación construida sobre él, la cantidad de lugares donde hay que buscar para identificar versiones vulnerables de PHP crece muy rápido.

Huntress está monitoreando los avances relacionados con estas vulnerabilidades y actualizará este blog a medida que haya nueva información disponible.

¿Qué son CVE-2026-109618 y CVE-2026-109619?

Las fallas existen en PHP, el popular lenguaje de programación detrás de una enorme cantidad de sitios web. PHP está diseñado principalmente para el desarrollo web y cuenta con amplio soporte por parte de los proveedores de hosting.

Esto es lo que sabemos hasta ahora sobre las vulnerabilidades de PHP (y lo que no sabemos):

Lo que sabemos: ambas vulnerabilidades fueron calificadas como críticas por el equipo de seguridad de PHP. Los reportes públicos las describen como ejecución remota de código en el núcleo de PHP, lo que significaría que un atacante podría hacer que el servidor ejecute comandos de su elección.
Qué afecta: PHP aún no ha publicado las versiones afectadas. Algunos reportes han señalado que las versiones 5, 6, 7 y 8 se verían afectadas, y algunos investigadores han dicho que esperan que las correcciones solo se apliquen a las ramas de PHP 8 actualmente compatibles. Sin embargo, en su comunicado oficial, PHP dijo que las versiones afectadas y corregidas (junto con los detalles completos de las fallas) se publicarán con el lanzamiento de seguridad del 21 de octubre.
Cómo funciona: aún no se ha publicado ninguna causa técnica raíz. Por ahora no sabemos qué parte de PHP está involucrada, si es accesible mediante una solicitud web común, o si depende de una configuración particular. Actualizaremos esta publicación cuando el aviso y los análisis de los investigadores sean públicos.

¿Por qué "php2shell"? Ese es el nombre que circula entre los investigadores. Si has seguido este tema por algún tiempo, sabes que un nombre así suele significar una cosa: alguien envía una solicitud a tu sitio web y obtiene una shell en tu servidor vulnerable.

Detalles técnicos

Sin detalles técnicos públicos todavía, no podemos mostrarte el exploit. Lo que sí podemos hacer es contarte qué estamos buscando y qué dice nuestra propia telemetría sobre dónde se concentra el riesgo.

Cómo probablemente se verá la explotación

Florian Roth, quien publicó una herramienta gratuita llamada process-watcher (una herramienta de monitoreo de procesos basada en Linux diseñada para detectar explotación), lo explicó bien: la explotación de estas fallas probablemente se manifestará como procesos secundarios sospechosos generados por PHP. En Huntress, eso coincide con lo que vemos en casi todas las intrusiones de PHP que analizamos.

En la práctica, eso significa que un proceso worker de PHP como php-fpm, php-cgi, php-cgi.exe, httpd, o apache2 lanzaría algo anormal:

Shells como sh, bash, cmd.exe, o powershell.exe
Intérpretes como python o perl
Herramientas de descarga o redes como curl, wget, nc, o certutil.exe

Vale la pena examinar más de cerca las líneas de comando que incluyen patrones de shell inversa:

/dev/tcp/
fsockopen
mkfifo

También vale la pena observar comandos de reconocimiento rápido como whoami, id, uname -a, o ipconfig ejecutados directamente desde el servidor web.

Abuso de PHP por parte de atacantes: lo que hemos visto recientemente

Incluso antes de esta filtración, Huntress detecta regularmente a atacantes que abusan de aplicaciones PHP.

Un patrón de un incidente reciente de Huntress ocurrido la semana pasada es un buen adelanto de cómo podría verse la explotación de php2shell. En este incidente, un proceso PHP FastCGI ejecutó repetidamente un comando de una línea que escribía un pequeño archivo PHP con cadenas marcadoras aleatorias en el primer directorio temporal con permisos de escritura que encontraba, antes de ejecutarlo y luego eliminarlo. Si ningún directorio tenía permisos de escritura, imprimía !notwrtbl! para señalarlo.

Aunque este patrón no está relacionado con php2shell, es un buen ejemplo de PHP generando procesos que no debería.

En el lado de Linux, la mayoría del PHP expuesto a internet reside en servidores web y hosting compartido, que no se monitorean de cerca. Un servidor web Linux expuesto sin detección de endpoints es el tipo de sistema donde las fallas de PHP pueden explotarse silenciosamente y pasar desapercibidas.

Prueba de concepto

No hemos creado ni reproducido una prueba de concepto para estas vulnerabilidades, y no tenemos conocimiento de código de exploit público al momento de escribir esto. Un breve video de explotación se publicó en línea por poco tiempo y luego se eliminó. Una vez que se publiquen las correcciones, esperamos que los detalles técnicos y el código de prueba de concepto aparezcan rápidamente, y actualizaremos esta publicación.

¿Qué deben hacer las organizaciones afectadas?

Las correcciones aún no están disponibles, así que el objetivo ahora es estar listos para aplicar el parche en el momento en que salga. Mientras tanto, hay varias cosas que puedes hacer para reducir tu exposición.

Haz un inventario de cada instalación de PHP. Empieza con tus servidores web y luego busca las ubicaciones menos obvias: dispositivos de proveedores y software de Windows que incluyen php.exe o php-cgi.exe, paneles de control como cPanel y Plesk, y todo lo que ejecute WordPress, Drupal, Joomla o Magento.
Planifica tu ventana de parcheo para el miércoles 21 de octubre a las 10:00 a. m. hora del Este. Parchea primero los sistemas expuestos a internet. Consulta el anuncio oficial de PHP para conocer los números de versión corregidos, y revisa tu distribución de Linux y tu proveedor de hosting por si ofrecen paquetes con la corrección aplicada.
Identifica cualquier entorno de PHP que haya llegado al final de su vida útil. Si usas PHP 5, 7 u 8.0/8.1, es posible que no recibas ninguna corrección. Actualiza, sácalo de internet o ponlo detrás de una VPN o un firewall de aplicaciones web (WAF) mientras tanto.
Vigila qué procesos genera PHP. Activa alertas cuando los procesos worker de PHP lancen shells, intérpretes o herramientas de descarga. En servidores Linux sin detección de endpoints, "process-watcher" de Florian Roth, disponible aquí, es una forma rápida y gratuita de obtener esta visibilidad hoy mismo. Inícialo en modo de observación.
Si encuentras algo, aísla el servidor y conserva los registros del servidor web y de PHP. Busca webshells y archivos nuevos en tu directorio raíz web, además de nuevas tareas cron, tareas programadas y cuentas.

¿Qué está haciendo Huntress?

Buscando amenazas en toda nuestra flota. Capturamos una referencia del comportamiento normal de PHP en los endpoints de nuestros socios antes del lanzamiento. En cuanto se publiquen las correcciones y los detalles técnicos, compararemos contra esa referencia para detectar actividad nueva rápidamente.
Ya monitoreamos actividad maliciosa en servidores. Huntress ya detecta procesos de servidores web que generan shells y actividad común de webshells en Windows y Linux. Nuestro SOC está alerta ante cualquier actividad relacionada con PHP.
Siguiendo de cerca el lanzamiento del parche. Nuestro equipo de Adversary Tactics está monitoreando el lanzamiento y los análisis de los investigadores en tiempo real, y actualizaremos esta publicación con indicadores y guías de detección a medida que estén disponibles.
Auditando nuestro uso interno de PHP. Huntress ha revisado los sistemas internos relevantes y ha tomado las medidas adecuadas para mitigar la posible exposición a estas vulnerabilidades.

Reglas Sigma / YARA

Publicaremos reglas de detección en huntresslabs/threat-intel en cuanto haya detalles técnicos disponibles. Las reglas YARA se incluirán en esa publicación.