PHP2Shell: cómo Myrmex ayuda a investigar, corregir y demostrar la respuesta

Después de descubrir los hosts afectados por PHP2Shell, viene la parte más compleja de la respuesta: investigar cada servidor, identificar cuáles son críticos y necesitan corregirse en horarios específicos, preparar esos cambios, ejecutarlos en la ventana, reunir la evidencia y escribir el informe.

Myrmex ayuda a sus clientes en la investigación, la planificación, la acción y las evidencias, con aprobación humana en cada etapa. Este artículo resume lo que se sabe sobre PHP2Shell y muestra cómo conducir la respuesta, del inventario al informe.

El 21 de octubre de 2026, el proyecto PHP publicó correcciones de emergencia para CVE-2026-109618 y CVE-2026-109619, conocidas como PHP2Shell. Son dos fallas críticas en el núcleo de PHP, ambas con CVSS 9.2, que permiten a un atacante remoto ejecutar comandos en el servidor web. Como la explotación ocurre antes de que se ejecute cualquier código de la aplicación, deja poco o ningún rastro en los registros de la aplicación.

Qué es PHP2Shell

Las dos fallas comparten la misma causa raíz. Cuando PHP encuentra una condición fatal en medio de una solicitud, como agotar el memory_limit, alcanzar el tiempo máximo de ejecución o perder la conexión del cliente, aborta la solicitud sin deshacer las estructuras que estaba armando. Después, la rutina de cierre trata esos datos a medio construir como si fueran válidos.

• CVE-2026-109618 (falta de memoria, en la misma solicitud). Un cuerpo POST preparado agota la memoria mientras PHP lee las variables de la solicitud y deja una estructura parcialmente inicializada que el propio cierre de la solicitud usa. Basta una solicitud.
• CVE-2026-109619 (estado global inválido, entre solicitudes). Un error fatal deja punteros globales apuntando a memoria ya liberada, y la siguiente solicitud atendida por el mismo proceso los usa. Son dos etapas: envenenar y disparar. Los procesos persistentes, como Apache con mod_php, amplifican el problema.

Los investigadores también demostraron la lectura de memoria de los procesos PHP, lo que puede exponer contraseñas, tokens y claves de API.

Las fallas se encontraron con ayuda de inteligencia artificial, de forma independiente, por las empresas de seguridad Calif, en un programa conducido con OpenAI, y Wiz. Señales del mismo problema de memoria ya habían aparecido en una auditoría de Quarkslab en 2024. PHP es el lenguaje detrás de cerca del 70% de los sitios web, y una gran parte de ellos corre versiones antiguas, ya sin corrección oficial.

Una corrección anticipada y una carrera contra el reloj

La divulgación estaba pensada para después de la corrección, pero los detalles se filtraron antes:

• 17/oct: los servidores señuelo de Amazon registraron un intento de explotación, cuatro días antes de la divulgación pública.
• 20/oct: los identificadores de las fallas empezaron a circular en foros, y PHP adelantó la publicación de la corrección. Ese mismo día se filtró un video con la explotación funcionando, que se difundió en las redes sociales.
• 21/oct, madrugada: Cloudflare activó reglas de protección para todos sus clientes.
• 21/oct, 11:35 UTC: Hadrian registró explotación a escala, horas antes de que la corrección oficial estuviera disponible.
• 21/oct: PHP publicó las versiones corregidas.

El impacto en Brasil

En Brasil, la respuesta llegó el mismo día. El 21 de octubre, el centro de ciberseguridad del gobierno digital (CISC gov.br) emitió una alerta, que el CTIR Gov reenvió a los equipos de tecnología del gobierno federal, y el GSI orientó a los gestores a actualizar los sistemas de inmediato. Las recomendaciones siguen el mismo camino de este artículo: actualizar PHP, mapear los servidores que lo usan, priorizar los expuestos a internet y aislar temporalmente lo que no pueda actualizarse.

El SEI, el sistema electrónico de expedientes usado en todo el gobierno federal y en estados y municipios, corre en PHP. Por precaución, Anatel suspendió el acceso externo al SEI, y los Tribunales Regionales Federales de las regiones 1, 4 y 6 adoptaron medidas similares.

Quién está afectado

• Versiones: todo PHP desde 5.4 hasta 8.5.11.
• Versiones corregidas: 8.5.12, 8.4.27, 8.3.36 y 8.2.35. PHP 8.1 y anteriores están fuera de soporte; hay parches mínimos en código fuente para 7.4, 8.0 y 8.1, y las distribuciones Linux publican sus propios paquetes, que pueden mantener el número de versión anterior.
• Formas de ejecución: PHP-FPM, Apache con mod_php, php-cgi, FrankenPHP y LiteSpeed, es decir, cualquier PHP que atienda solicitudes web. mod_php es el escenario más riesgoso.
• No depende de la aplicación: la falla está en el procesamiento de la solicitud por el propio PHP, así que no depende del framework ni del CMS.
• La configuración importa: el camino de falta de memoria es alcanzable cuando el cuerpo de la solicitud puede crecer lo suficiente para agotar el memory_limit antes de que corra el script, lo que ocurre cuando el memory_limit es menor que unas 4 veces el post_max_size. Los valores por defecto de PHP no cumplen esa condición, pero los servidores ajustados para cargas grandes sí, y el post_max_size puede cambiarse por directorio o por sitio.

Con explotación ya registrada, trátalo como urgente.

¿Estoy afectado? Qué revisar

1. Inventario. Lista todos los servidores con PHP, incluidas las instalaciones fuera del gestor de paquetes. El php -v de la línea de comandos puede reportar una instalación distinta de la que atiende el sitio.
2. Versión y paquete. Compara la versión (o el paquete de la distribución) con las versiones corregidas.
3. Forma de ejecución. Identifica si es mod_php, PHP-FPM, php-cgi, FrankenPHP o LiteSpeed.
4. Configuración. Revisa memory_limit, post_max_size y upload_max_filesize, incluidas las sobrescrituras por directorio (.htaccess, .user.ini, virtual hosts).
5. Exposición. Empieza por lo que es accesible desde internet.
6. Señales de explotación. Busca en el registro de errores del servidor web la combinación "Allowed memory size of N bytes exhausted" con "in Unknown on line 0", que indica una falla antes de que se ejecutara cualquier archivo PHP. Y busca procesos del servidor web o de PHP abriendo shells u otros procesos inesperados.

Cómo ayuda Myrmex a responder

Todo empieza con un pedido en lenguaje natural, como "Encuentra todos los hosts afectados por PHP2Shell, corrige PHP y dame la evidencia para el informe." A partir de ahí, Myrmex conduce las cuatro etapas que más tiempo consumen al equipo:

• Investigar. Perseus usa el agente Myrmex instalado en los servidores para relevar, de cada host, la versión de PHP, el paquete, la forma de ejecución y los valores de memory_limit y post_max_size, incluidas las sobrescrituras por sitio. También busca en el registro de errores del servidor web el patrón "in Unknown on line 0" y lo cruza con las alertas de tu EDR o SIEM, buscando procesos del servidor web que abren shells.
• Planificar. Con la topología y el inventario, Myrmex separa lo que es crítico, expuesto a internet o de producción, de lo que puede seguir un cambio estándar. Para los críticos, arma las solicitudes de cambio ya completas: hosts afectados, impacto, ventana, plan de implementación y rollback.
• Actuar. Cada solicitud de cambio sigue las reglas de aprobación de tu equipo y solo se ejecuta después de aprobada, en la ventana definida. Si la corrección tiene que esperar, las mitigaciones de configuración también pasan por aprobación, con el aviso de que no cubren todos los caminos de ataque.
• Demostrar. Antes y después de cada actualización, Myrmex registra la versión y el paquete y vuelve a verificar. Scribe arma el informe del incidente: hosts encontrados, qué se corrigió, cuándo, quién lo aprobó y qué sigue pendiente, listo para la auditoría, el comité o el cliente. Para seguir la flota, la verificación puede convertirse en un runbook programado en Books.

Cada paso queda en la lista de pasos de la conversación y en los registros de auditoría, y nada cambia en producción sin tu aprobación. (Por qué importa: Aprobación humana que no es teatro.)

La IA está de los dos lados

PHP2Shell muestra los dos lados de la IA en seguridad. Ayudó a encontrar una falla que llevaba años escondida en el núcleo de PHP, y la filtración mostró cómo una explotación funcional se difunde antes de la corrección. La respuesta necesita la misma velocidad. Para eso existe Myrmex: agentes de IA que investigan, planifican, ejecutan y documentan la corrección con tu equipo al mando.

Recomendaciones

• Actualiza PHP. Es la única corrección completa. Usa 8.5.12, 8.4.27, 8.3.36 u 8.2.35, o el paquete corregido de tu distribución.
• No confíes solo en mitigaciones. Desactivar session.upload_progress solo cubre los caminos de sesión de una de las fallas. Los límites de memoria por cgroup, reducir post_max_size y upload_max_filesize y, en PHP 8.5, fatal_error_backtraces=0 ayudan mientras llega la corrección, pero no reemplazan la actualización.
• Reinicia los procesos. Después de actualizar o cambiar la configuración, reinicia todos los procesos de PHP y del servidor web.
• Aísla lo que no puedas corregir ahora. Restringe el acceso público o saca el servicio de línea hasta actualizarlo.
• Busca señales de explotación en los servidores que quedaron expuestos antes de la corrección.

Habla con nuestro equipo para revisar la exposición de tu entorno a PHP2Shell.