Según un informe del 24 de octubre de Pierluigi Paganini, publicado en Security Affairs y basado en observaciones de honeypots de investigadores de AWS, los atacantes intentaron explotar PHP2Shell cuatro días antes de la divulgación pública y de la disponibilidad de los parches. Los intentos detectados no demuestran que los servidores hayan sido comprometidos con éxito.
Los dos avisos oficiales de PHP, publicados el 21 de octubre de 2026, describen vulnerabilidades críticas en la gestión de memoria que pueden permitir la ejecución remota de código. Ambos indican las correcciones en PHP 8.2.35, 8.3.36, 8.4.27 y 8.5.12, y las versiones anteriores de cada rama afectada. Las condiciones precisas de explotación varían según la vulnerabilidad, la interfaz del servidor, la aplicación y la configuración.
Una explotación exitosa podría permitir a un atacante ejecutar comandos con los permisos de la cuenta del proceso web. Paganini describió posibles consecuencias, entre ellas el robo de datos, la instalación de malware, cambios en los sitios web y interrupciones del servicio. Se trata de impactos potenciales, no de resultados confirmados de los intentos registrados.
El agotamiento de memoria puede dejar expuesto un estado de solicitud no válido
La primera vulnerabilidad, CVE-2026-109618, afecta al uso que hace PHP de longjmp() para abandonar el procesamiento de una solicitud tras un error de falta de memoria. Si esa salida se produce mientras la memoria de la solicitud está solo parcialmente inicializada, el procesamiento de cierre puede encontrar un estado no válido y llevar a la ejecución remota de código.
El aviso describe varias formas en que las solicitudes multiparte pueden agotar la memoria pese a los límites de entrada aparentes. Entre ellas figuran solicitudes sin una longitud de contenido declarada utilizable, cabeceras sin restricciones dentro de cada parte y controles de archivo vacíos que generan metadatos sin contar para max_file_uploads. El procesamiento específico de cada aplicación sobre entradas controladas por el atacante también puede agotar la memoria.
El aviso de PHP indica que se validó la ejecución remota de código sin autenticación por HTTP contra Apache mod_php, con los límites predeterminados de entrada y memoria de PHP y configuraciones prefork normales con varios procesos worker. El análisis automático del cuerpo de la solicitud puede activar el problema antes de que se ejecute el código de la aplicación. Los workers adicionales y el tráfico no relacionado pueden aumentar el número de intentos necesarios, mientras que la fiabilidad depende de la compilación de PHP, las extensiones, el comportamiento del frontend y la disposición del asignador de memoria.
La evidencia difiere en otros tipos de despliegue. FPM termina un proceso hijo cuando falla el inicio de la solicitud, lo que impide que esa ruta de inicio consuma estado no válido. No obstante, el análisis del código fuente indica susceptibilidad tras el inicio normal, aunque no se ha demostrado ningún exploit completo para FPM. El aviso considera probable que FrankenPHP sea vulnerable a ataques independientes de la aplicación, mientras que la explotación específica de cada aplicación a través de LSAPI se considera probable, pero sigue sin validarse.
El estado obsoleto puede cruzar los límites de las solicitudes
La segunda vulnerabilidad, CVE-2026-109619, afecta a un estado a nivel de worker que conserva referencias a memoria perteneciente a una solicitud ya completada.
La explotación requiere una operación que deje accesible el estado propio de la solicitud después de liberar esa memoria, seguida de otra operación que use el estado obsoleto antes de que la inicialización normal lo borre. En el caso demostrado, ambas operaciones se producen en solicitudes HTTP distintas gestionadas por el mismo worker.
Los errores fatales, incluido el agotamiento de memoria, pueden interrumpir la limpieza. Los diagnósticos no fatales también pueden volver a llenar el estado de error después de haberse borrado. Un montículo (heap) dispuesto con cuidado puede convertir el use-after-free resultante en ejecución remota de código. La accesibilidad depende del estado concreto, la aplicación, las extensiones y la configuración.
Las actualizaciones ofrecen la solución completa
Ambos avisos remiten a los administradores a las versiones corregidas de sus respectivas ramas de PHP:
- PHP 8.2: 8.2.35
- PHP 8.3: 8.3.36
- PHP 8.4: 8.4.27
- PHP 8.5: 8.5.12
El emisor afirma que actualizar es la única mitigación completa para el fallo de agotamiento de memoria y la única mitigación fiable para el fallo de estado obsoleto.
En las instalaciones que no pueden actualizarse, forzar administrativamente memory_limit=-1 elimina el límite predecible por solicitud que usa el exploit confirmado de agotamiento de memoria. Hay que reiniciar todos los workers de PHP, y los administradores deben asegurarse de que la configuración del pool, del directorio o de la aplicación no restablezca un límite finito. Sigue siendo una protección incompleta: los fallos subyacentes de asignación pueden activar igualmente la ruta vulnerable.
PHP advierte expresamente contra el uso de RLIMIT_AS o RLIMIT_DATA, porque pueden provocar fallos de mmap() que activen esa ruta. Los límites de memoria de contenedores o cgroups también constituyen una mitigación incompleta y pueden terminar varios workers o el proceso maestro.
En PHP 8.5, establecer administrativamente fatal_error_backtraces=0 y reiniciar todos los workers elimina el generador usado en el caso confirmado de RCE por estado obsoleto. No cubre otro estado global o de extensiones; el aviso indica que ningún cambio genérico de configuración ofrece protección completa.
El emisor recomienda también valores conservadores de post_max_size, límites de tamaño de solicitud decodificada aplicados de forma independiente en el frontend, y límites al anidamiento de entradas, variables, partes multiparte, cabeceras por parte y cargas de archivos. Las aplicaciones que no usan datos de formularios multiparte pueden bloquearlos en el frontend. Estos controles reducen el riesgo, pero no sustituyen a las actualizaciones.
En su informe del 24 de octubre, Paganini instó a los administradores a revisar la actividad sospechosa desde el 17 de octubre. También habló de cómo la IA podría acelerar el desarrollo de exploits, aunque advirtió de que no debe asumirse automáticamente que los ataques estén impulsados por IA.
