Refuerzo de Monitoreo y Configuración por Incidencias de Parches Post-Actualización de PHP2Shell

Descripción

El proyecto PHP liberó correcciones para dos fallas críticas (CVSS 9.2) que permiten la ejecución remota de código (RCE) sin autenticación:

• CVE-2026-109618 (GHSA-w8hw-w9fx-j79w): Corrupción de memoria por agotamiento de recursos (OOM). PHP fuerza el aborto de peticiones al superar el memory_limit dejando estructuras parcialmente inicializadas, provocando accesos a memoria no inicializada durante la limpieza.
• CVE-2026-109619 (GHSA-6wmf-4rv5-p3rp): Persistencia de estado global obsoleto tras un error fatal, reutilizando direcciones de memoria liberadas en solicitudes posteriores dentro del mismo worker.

Investigaciones publicadas por Datadog Security Labs y monitoreos de tráfico confirman que la autenticación de la aplicación no protege frente a estos ataques, dado que las solicitudes maliciosas son procesadas por PHP antes de ejecutar el código del backend. Adicionalmente, se han detectado cadenas de explotación activas en php:8.4.26-apache y vectores de bypass que continúan funcionando incluso sobre versiones corregidas como PHP 8.5.12, permitiendo evadir protecciones como ASLR mediante solicitudes preparatorias de disposición de memoria.

Derivado de incidencias con los parches recientes, se han identificado patrones críticos en los registros de errores (error.log) y de accesos (access.log). Los análisis deben realizarse ejecutando las siguientes búsquedas mediante la herramienta zgrep:

zgrep -HnEi 'Allowed memory size.*exhausted|Unknown on line 0|SIGSEGV|Segmentation fault|zend_mm_heap corrupted|exited on signal 11' error.log*
zgrep -HnEi 'POST /(wp-admin/admin-ajax\.php|wp-cron\.php|xmlrpc\.php|/api/|/upload|/import|/media)' access.log* | grep -E ' (5[0-9]{2}) | [0-9]{6,}'

Estos comandos permiten identificar anomalías clave, tales como errores en la gestión de memoria del motor PHP (Zend Memory Manager o ZMM), caídas de procesos worker de PHP FastCGI Process Manager (PHP-FPM) y solicitudes HTTP POST masivas orientadas a saturar los recursos del servidor.

Recursos afectados

El impacto afecta directamente a servidores web que alojan aplicaciones PHP y manejan peticiones POST. Los efectos operativos incluyen la caída de procesos worker, agotamiento de memoria (OOM, por sus siglas en inglés) e interrupciones del servicio web por fallos de segmentación.

Solución/Mitigación

Aplicar las correcciones de configuración y los parches de estabilidad recomendados por los proveedores para solventar las deficiencias de la actualización de PHP2Shell y estabilizar la gestión de memoria en los servicios web.

Mitigaciones temporales en PHP si no afecta a la lógica de funcionamiento de sus sistemas:

• Establecer session.upload_progress.enabled=0 y, en PHP 8.5, configurar fatal_error_backtraces=0. Reiniciar todos los workers y procesos PHP afectados para que las opciones tengan efecto. Estas medidas reducen vectores conocidos pero no sustituyen el parche oficial.

Al confirmarse que los parches pueden ser evadidos en ciertos contextos, se deben imponer restricciones a nivel de servidor web y proxy para reducir la superficie de ataque:

• Para CVE-2026-109618: Forzar memory_limit=-1 en configuraciones administrativas no modificables por la aplicación (php_admin_value) para evitar los abortos controlados. Reducir post_max_size (8M o 32M) y bloquear peticiones multipart directamente en el proxy o WAF si la aplicación no requiere subida de archivos. Utilizar límites en cgroups o contenedores para reiniciar workers afectados.
• Para CVE-2026-109619: Deshabilitar de forma obligatoria session.upload_progress.enabled=0 en php.ini o la piscina FPM. En PHP 8.5, establecer fatal_error_backtraces=0. En entornos PHP-FPM, se recomienda configurar pm.max_requests=1 para forzar la destrucción del worker tras cada petición y prevenir el reuso de estado global.

Desplegar las versiones oficiales corregidas: PHP 8.5.12, 8.4.27, 8.3.36 y 8.2.35.

• Para ramas discontinuadas (PHP 8.1 o inferior), aplicar parches mínimos publicados por el equipo de PHP o consultar con proveedores LTS.
• Reconstruir e inspeccionar imágenes de contenedores desde cero, verificando el digest de imagen y confirmando que el motor en ejecución (Apache/PHP-FPM) corresponda a la versión parcheada.

Indicadores de compromiso

• Presencia en los registros de errores (error.log) de cadenas como Allowed memory size.*exhausted, Unknown on line 0, SIGSEGV, Segmentation fault, zend_mm_heap corrupted o exited on signal 11.
• Peticiones HTTP POST con códigos de estado HTTP 500, 502 o 503 dirigidas a rutas que no aceptan subidas de archivos, acompañadas de un volumen de datos transferido elevado (varios millones de bytes) y solicitudes repetidas desde una misma dirección IP en un lapso breve.

Recomendaciones

• Se recomienda que, en caso de disponer de firmware privado, este sea actualizado para aceptar las nuevas reglas, si fuera necesario, y que dichas reglas se incluyan en los dispositivos perimetrales (FW, WAF, etc.).
• Ejecutar de inmediato las rutinas de inspección de registros especificadas para detectar errores tempranos de memoria y accesos anómalos.
• Revisar los límites de asignación de memoria (memory_limit) configurados en los entornos de ejecución afectados.
• En caso de no poder contener un ataque dirigido en servidores propios, la medida extrema de mitigación es el aislamiento inmediato de la red (desconexión física o bloqueo de upstream) para frenar el movimiento lateral y la exfiltración de datos. Antes de cualquier apagado, se debe realizar un volcado forense de la RAM y almacenamiento, revocar credenciales y tokens masivamente, y reconstruir los sistemas afectados desde respaldos limpios.
• Monitorear de forma continua los registros del servidor web, proxy, PHP y contenedores en busca de ejecuciones de comandos no autorizadas o comportamientos anómalos previos a la inicialización del framework web.