PHP publicó el 21 de octubre de 2026 correcciones de emergencia para CVE-2026-109618 y CVE-2026-109619. Las dos vulnerabilidades críticas afectan a la memoria y tienen una puntuación CVSS v4.0 de 9.2. Permiten ejecutar código de forma remota y sin autenticación en instalaciones PHP que procesan solicitudes web. Esto incluye PHP-FPM, Apache con mod_php, php-cgi, FrankenPHP y LiteSpeed. El riesgo es mayor con mod_php, porque la explotación ocurre antes de que se ejecute el código de la aplicación.

<agent_config>
  <localfile>
    <log_format>full_command</log_format>
    <command>ps -u www-data -o comm=,args= 2>/dev/null | grep -Ev '^(php-fpm|php-fpm[0-9.]+|apache2|htcacheclean|nginx) ' | grep -Ev 'front/cron\.php' || true</command>
    <alias>web-children</alias>
    <frequency>60</frequency>
  </localfile>
  <syscheck>
    <directories realtime="yes" check_all="yes" restrict=".php$|.php5$|.php7$|.phtml$|.phar$|.inc$">/var/www</directories>
    <ignore type="sregex">/cache/|/_cache/|/sessions/|/_sessions/|/_tmp/|/_log/|/wp-content/upgrade/</ignore>
  </syscheck>
</agent_config>

Las versiones corregidas son 8.5.12, 8.4.27, 8.3.36 y 8.2.35. Las distribuciones Linux publicaron sus propios paquetes ese mismo día. PHP 8.1 y las versiones anteriores no tienen una corrección oficial. Los workers que ya estaban activos deben reiniciarse después del parche, incluidos php-fpm y el servidor web.

La contribución independiente de la comunidad presenta tres reglas locales de Wazuh y un grupo de agentes para cubrir el intervalo entre el anuncio y el despliegue completo de los parches. La configuración se probó en producción. No detecta de forma fiable la explotación inicial porque ambas vulnerabilidades actúan antes de la aplicación y no dejan una huella segura en los registros de la aplicación. En su lugar, busca procesos iniciados por el usuario del servidor web y archivos PHP creados o modificados después. El método sirve para cualquier incidente de ejecución remota de código en un servidor web PHP, no solo para estos dos CVE.

El 21 de octubre, Wazuh CTI todavía no incluía ninguno de los dos CVE. Por tanto, Vulnerability Detection no habría marcado a los agentes afectados. NVD publicó ambas entradas ese día. Ubuntu registró USN-8948 para php8.3 versión 8.3.6-0ubuntu0.24.04.13 en Ubuntu 24.04. Debian registró DSA-6574-1 y DLA-4848-1 para trixie y bookworm. Bullseye, que utiliza PHP 7.4, se quedó sin corrección. Ninguno de los dos CVE aparecía en CISA KEV. No había indicadores de compromiso confirmados, aunque circulaba una prueba de concepto no verificada que podía contener malware.

La configuración propuesta coloca únicamente los servidores que sirven PHP en un grupo de agentes como web_php. La ejecución de comandos centralizados debe habilitarse con logcollector.remote_commands=1 y después hay que reiniciar el agente. La configuración del grupo consulta cada 60 segundos los procesos pertenecientes a www-data. Excluye los procesos normales de php-fpm, Apache, htcacheclean y nginx, además del trabajo de ejemplo front/cron.php. La supervisión de integridad de archivos controla en tiempo real /var/www para las extensiones .php, .php5, .php7, .phtml, .phar y .inc. Se excluyen los directorios de caché, sesiones, temporales y registros, junto con el directorio de actualización de WordPress.

Los nombres de usuario y las rutas deben adaptarse al entorno. Debian y Ubuntu suelen utilizar www-data, mientras que las distribuciones derivadas de RHEL pueden usar apache o nginx. Hay que excluir los trabajos legítimos que se ejecuten con la cuenta web. Algunas aplicaciones sirven PHP fuera de /var/www, como el frontend de Zabbix en /usr/share/zabbix. Wazuh no sigue enlaces simbólicos en esta supervisión, así que el directorio de destino debe añadirse directamente.

Las reglas locales utilizan los identificadores 100972, 100973 y 100976, que corresponden al despliegue descrito. Los nuevos identificadores deben elegirse dentro del rango local libre 100000 a 120000. La regla 100972, con nivel 12, busca en la salida web-children shells, herramientas de descarga, utilidades de red, intérpretes de scripts y comandos similares. Relaciona la actividad con las técnicas MITRE ATT&CK T1190, T1059.004 y T1505.003. La regla 100973, también con nivel 12, informa de un archivo nuevo de la familia PHP bajo /var/www y utiliza T1505.003. La regla 100976, con nivel 8, informa de un archivo modificado de esos tipos y pide comprobar si la causa fue una actualización.

Antes de reiniciar hay que validar la configuración con GET /cluster/configuration/validation o wazuh-analysisd -t. Las rutas de las reglas deben coincidir con las de agent.conf. La contribución destaca cinco detalles operativos. El atributo restrict y el patrón de exclusión sregex no son expresiones PCRE. Los patrones con grupos pueden fallar sin mostrar errores, por lo que las alternativas deben separarse con |. $(agent.name) no se sustituye dentro de la descripción de una regla. El primer análisis crea la línea base, así que los archivos creados antes de iniciar la supervisión en tiempo real no generan alertas. Sin los comandos remotos habilitados, el agente ignora el comando del grupo. En contenedores LXC sin privilegios, el FIM en tiempo real basado en inotify funciona, pero auditd no. La auditoría de execve debe hacerse en el host con el UID asignado, por ejemplo 100033 en vez de 33.

Las alertas 100972 y 100973 deben tratarse como incidentes probables hasta que exista una explicación. Hay que revisar full_log para conocer el proceso y sus argumentos, incluidos patrones como curl canalizado a bash, /dev/tcp, nc -e y mkfifo. Un proceso desconocido requiere aislar el sitio mediante el WAF o el firewall. Antes de reiniciar, conviene conservar los registros del servidor web y de PHP, ps -ef, ss -tnp y una instantánea de la máquina virtual o del contenedor. La búsqueda de persistencia debe cubrir archivos PHP nuevos, el crontab del usuario web, cuentas nuevas y claves SSH. Una intrusión confirmada debe notificarse a la autoridad nacional de ciberseguridad correspondiente.

Ante un archivo PHP nuevo, el responsable de la aplicación debe confirmar si lo creó una actualización. Si no fue así, hay que buscar eval, base64_decode, system, shell_exec y ejecuciones alimentadas por $_POST, sin abrir el archivo desde un navegador. Entre los falsos positivos previstos están los trabajos cron de la aplicación ejecutados con la cuenta web, PHP mail(), que invoca sh -c sendmail, y las actualizaciones de CMS o plugins, que pueden generar muchas alertas 100976.

La validación exige que group_config_status = synced confirme la sincronización del grupo. ossec.log debe mostrar además la supervisión en tiempo real del directorio elegido. En logtest, un evento con log_format = full_command y location = web-children debe coincidir con 100972 cuando contenga un shell. Una lista de procesos vacía debe permanecer en nivel 0. Para una prueba de extremo a extremo, se puede ejecutar un proceso inocuo como el usuario web durante más tiempo que el intervalo de 60 segundos y crear un archivo .php vacío en la raíz web. Después hay que comprobar la llegada de las alertas al panel, al correo o al sistema SOAR y registrar la hora de la prueba.

La comprobación de procesos solo se realiza una vez por minuto. Un comando que termine en pocos segundos puede quedar fuera de la muestra. Para una cobertura completa hace falta auditd en el host. En IIS, la señal equivalente es que w3wp.exe o php-cgi.exe inicie cmd.exe o powershell.exe. Esta detección requiere Sysmon o el evento 4688 de Windows con registro de la línea de comandos.

Parchear y reiniciar siguen siendo las medidas principales. Instalar un paquete nuevo no corrige los workers que ya están ejecutándose. En PHP 7.4 a 8.1, donde no existe un parche oficial, los servicios afectados deberían retirarse de Internet. Como mitigaciones parciales, la contribución menciona session.upload_progress.enabled=0 y memory_limit=-1 mediante ajustes php_admin_*. También recomienda revisar el enrutamiento del WAF y los filtros SNI. Una solicitud con el SNI de un sitio público y el encabezado Host de un sitio interno puede llegar al sitio interno. El WAF debería bloquear desde redes externas las solicitudes dirigidas a nombres que no sean públicos.

Entre las referencias figuran PHP News Archive 2026, el aviso de GitHub GHSA-w8hw-w9fx-j79w para CVE-2026-109618, la página de Ubuntu sobre CVE-2026-109618, el rastreador de seguridad de Debian y los análisis de Huntress y Tenable. Las reglas son una contribución independiente de la comunidad. Wazuh Inc. no las ha revisado, validado ni respaldado. No forman parte del conjunto oficial de reglas de Wazuh y deben probarse en cada entorno antes de usarse en producción.