PHP corrige PHP2Shell, dos fallos RCE críticos, con ataques en marcha

Actualización (24 de octubre de 2026, 13:26 UTC): PHP publicó el 23 de octubre un aviso informativo sobre un tercer vector de RCE, CVE-2026-115560, sin parche de emergencia, y Sophos, Hunt.io y SOCRadar documentan intentos de usar PHP2Shell para repartir la variante de Mirai Potassium sin compromisos confirmados. Lee la noticia de seguimiento.

Actualización (21 de octubre de 2026, 18:00 UTC): esta noticia se ha ampliado con los descubridores de los fallos (Wiz Research, Calif y OpenAI), la cobertura publicada por los fabricantes de WAF, IPS y EDR (Cloudflare, Akamai, Imperva, Palo Alto Networks, Cisco Talos, CrowdStrike y Corelight), la alerta de CISA, los intentos de explotación que watchTowr dice observar en sus honeypots y las cifras de exposición de Palo Alto Networks, Cisco y VirusTotal.

PHP ha publicado el 21 de octubre de 2026, a las 13:35 UTC y antes de la hora que había anunciado, las versiones 8.5.12, 8.4.27, 8.3.36 y 8.2.35 que corrigen CVE-2026-109618 y CVE-2026-109619, dos fallos críticos de ejecución remota de código sin autenticación con CVSS v4.0 9,2 que la comunidad llama PHP2Shell. La filtración de los detalles antes de tiempo, los primeros intentos de ataque que Cloudflare y Patchstack dicen observar y la desconexión preventiva de webs públicas en Países Bajos convierten la actualización en una tarea que no admite espera en ningún servidor web con PHP.

Qué ha pasado

El 20 de octubre a las 15:20 UTC apareció en Hacker News un mensaje que anunciaba dos fallos de ejecución remota de código en PHP, con CVSS 10,0, presentes desde PHP 5 y con divulgación prevista para el jueves 22 de octubre. El autor reconocía no tener pruebas y el mensaje fue retirado, pero las capturas ya circulaban. Poco después el investigador Florian Roth publicó en X que existía una vulnerabilidad de RCE en el núcleo de PHP, con CVSS 10,0, y que solo PHP 8 recibiría parches.

watchTowr confirmó esa misma tarde que la información filtrada era real y que ambos fallos estaban bajo embargo hasta el jueves. Su CEO, Benjamin Harris, declaró a SecurityWeek que «we can confirm that these vulnerabilities are indeed real» (podemos confirmar que estas vulnerabilidades son reales) y que su equipo había reproducido CVE-2026-109618, aunque no publicaría detalles hasta que hubiera parche.

A las 19:33 UTC el equipo de seguridad de PHP publicó un aviso previo en php.net con la fecha de la actualización, adelantada al miércoles 21 de octubre a las 14:00 UTC (16:00 en la España peninsular). El aviso hablaba de dos vulnerabilidades críticas con CVSS v4.0 9,2, pedía a los usuarios que se preparasen para actualizar en cuanto saliera y añadía: «We reserve the right to release earlier should details of either vulnerability become public» (nos reservamos el derecho a publicar antes si los detalles de cualquiera de las vulnerabilidades se hacen públicos). Eso es lo que ha ocurrido. Según la API de versiones de php.net, que este medio consultó cada minuto, las cuatro versiones corregidas aparecieron a las 13:35 UTC, veinticinco minutos antes de lo previsto.

Durante la noche el cuadro pasó de un aviso de embargo a una carrera contra reloj. GMO Flatt Security publicó un análisis preliminar, un desarrollador del núcleo de PHP afirmó que la única mitigación es parchear, Cloudflare dijo ver los primeros ataques y varios organismos holandeses apagaron sus webs. Todo ello en menos de doce horas y antes de que existiera una versión corregida. El propio aviso de PHP reconoce que las distribuciones de Linux y los proveedores de soporte extendido recibieron los parches por adelantado.

El aviso de seguridad definitivo confirma la puntuación de 9,2 para ambos fallos, los identificadores CVE y que la ejecución remota de código no requiere autenticación. No adopta el nombre PHP2Shell, que viene de la filtración, y resume la situación en una frase: «There are no complete mitigations, updating is the only safe choice» (no hay mitigaciones completas, actualizar es la única opción segura).

Con el parche llegó también la autoría. Wiz Research (Sagi Tzadik, Shir Tamari, Nir Ohfeld y Tomer Schwartz) cuenta que encontró el primer fallo el 19 de agosto de 2026 con ayuda de herramientas de IA, que confirmó ejecución remota contra Drupal el 20 y contra WordPress el 21, que lo comunicó al equipo de seguridad de PHP el 24 de agosto y que PHP acusó recibo el 21 de septiembre. Wiz atribuye a los modelos Gemini 4 Argon y GPT-5.6 Sol una parte sustancial del hallazgo y de la validación del parche. El sitio de divulgación php2shell.com, que mantiene Wiz, acredita además a Amy Burnett (OpenAI Codex Security) y a Ryan Austin (Calif), y OpenAI publicó en X que sus modelos ayudaron a los investigadores «operating as part of our Patch the Planet initiative» (que operaban dentro de su iniciativa Patch the Planet) y que durante dos meses coordinó a mantenedores, investigadores y proveedores de seguridad para preparar correcciones y protecciones antes de la divulgación. Los alias de los avisos GHSA (sagitzadik-wiz, amyb-oai, lcfr-hax) encajan con esos nombres. Cybersecurity Dive añade que la Casa Blanca supo de los fallos el 16 de octubre.

En X la noticia ha corrido con la misma velocidad. Wiz la presentó como «a decade-old PHP Core vulnerability reaching CVSS 9.2 severity impacting 70% of the Internet» (una vulnerabilidad del núcleo de PHP con una década de antigüedad, CVSS 9,2, que afecta al 70 % de Internet) y Sagi Tzadik abrió el hilo técnico con las demostraciones sobre WordPress, Drupal y Joomla. El CTO de Cloudflare, Dane Knecht, avisó a las 07:43 UTC de que «We are seeing early attacks emerging» (estamos viendo aparecer los primeros ataques) y a las 13:40 remató con «PHP changes are live. Start patching.» (los cambios de PHP están publicados, empezad a parchear). La División Cibernética del FBI publicó su propio aviso, en el que dice que los fallos «could allow malicious cyber actors to remotely execute code in PHP core» (podrían permitir a actores maliciosos ejecutar código de forma remota en el núcleo de PHP). El medio polaco Niebezpiecznik difundió el vídeo del exploit contra WordPress, phpBB y Drupal, y GMO Flatt Security usó la red para corregir su propia recomendación sobre session.upload_progress.

Detalles técnicos

Los dos avisos de PHP en GitHub, publicados el 21 de octubre junto con las versiones corregidas, ponen nombre a los fallos. GHSA-w8hw-w9fx-j79w (CVE-2026-109618) describe una corrupción de la memoria de la petición cuando el intérprete se queda sin memoria antes de terminar de inicializarla, de modo que la limpieza posterior trabaja con datos inválidos. GHSA-6wmf-4rv5-p3rp (CVE-2026-109619) describe un estado interno del worker que sobrevive a la petición que lo creó y que una petición posterior, atendida por el mismo worker, puede usar antes de que la inicialización normal lo reinicie. En ambos casos el resultado es ejecución de código con los privilegios del usuario del servidor web, y PHP considera que el riesgo es mayor en Apache con mod_php, donde ha validado un exploit que actúa antes de que se ejecute el código de la aplicación. En PHP-FPM el aviso habla de susceptibilidad por análisis del código, sin un exploit completo demostrado. Los avisos acreditan a cuatro investigadores por sus alias de GitHub (lcfr-hax, sagitzadik-wiz, tomash-areion y amyb-oai) y a arnaud-lb, iluuu1994, bukka y ndossche como autores de la corrección.

El aviso de INCIBE-CERT, publicado el 21 de octubre con importancia 5 (crítica), describe CVE-2026-109618 como una ejecución remota de código relacionada con el agotamiento de memoria al analizar entradas conforme a la RFC 1867, que es el estándar de subida de ficheros por formulario, y CVE-2026-109619 como una ejecución remota de código relacionada con la corrupción del estado global tras un error fatal. El mismo aviso recoge que, según el equipo de PHP, todas las versiones podrían estar afectadas y las pruebas se han realizado en las ramas 5 a 8, y adelantaba los retroportes para 7.4, 8.0 y 8.1 que PHP ha confirmado después. CERT-EU, en su aviso 2026-018, deduce de la puntuación que la explotación no requiere autenticación.

El análisis preliminar de GMO Flatt Security, publicado el 21 de octubre a las 11:12 (hora de Japón), apunta a la función Session Upload Progress de la extensión de sesiones, activada por defecto en cualquier instalación. La firma japonesa se basa en el vídeo de una demostración que circula desde el día 20, en el que el objetivo es un Ubuntu 26.04 con PHP 8.5.4 bajo Apache en modo prefork con mod_php y la ejecución termina con los privilegios del usuario del servidor web (www-data). Flatt hablaba de un fallo de corrupción de memoria y advertía de que su análisis era una inferencia. El aviso definitivo le da la razón a medias: PHP confirma que el progreso de subida de sesiones es una de las vías demostradas de CVE-2026-109619, pero no la única. Sansec añade que una herramienta llamada PHP2Shell, atribuida a Calif.IO, se ha filtrado y que su texto de presentación afirma funcionar contra toda versión de PHP desde la 5.4.0, un dato que tampoco está confirmado.

El punto en el que coinciden Sansec y Patchstack es el que importa para defenderse. PHP analiza el cuerpo de una petición multipart/form-data antes de que se ejecute una sola línea de la aplicación. Por eso el modo de mantenimiento de Magento o de WordPress no protege, y por eso las únicas barreras posibles antes del parche están delante del intérprete, en el servidor web o en un WAF. El diagrama siguiente resume dónde actúa cada medida provisional según esas fuentes y el propio aviso de PHP.

Sansec propone bloquear temporalmente cualquier petición multipart en el servidor web mientras no se pueda actualizar, con esta regla para nginx dentro de cada bloque server que pase peticiones a PHP, y su equivalente en Apache con RewriteCond sobre la cabecera Content-Type.

# Bloqueo temporal de subidas multipart (romperá la subida de ficheros)
if ($http_content_type ~* "multipart/form-data") {
    return 403;
}

La regla corta de raíz la subida de ficheros, incluidas las imágenes de producto en Magento y la biblioteca de medios de WordPress, y algunas tiendas envían el carrito o el pago como multipart, así que conviene probar un pedido completo después de aplicarla y retirarla en cuanto el intérprete esté actualizado.

La otra medida que circuló durante la mañana fue desactivar la función de progreso de subida en php.ini. Flatt la propuso a primera hora y a las 14:00 (hora de Japón) matizó que solo ofrece una mitigación parcial. The Hacker News recoge la posición de Gina Peter Banyard, del equipo de desarrollo del núcleo de PHP, para quien la única mitigación es parchear o actualizar PHP, y la de Joe Ferguson, release manager de PHP 8.6: «ini settings won't save you» (los ajustes del ini no os van a salvar). El aviso definitivo de PHP zanja la discusión con una lista de medidas que reducen la exposición a vías concretas sin hacer segura la instalación: para CVE-2026-109618, quitar el límite de memoria de PHP con memory_limit=-1 fijado donde la aplicación no pueda cambiarlo, bajar post_max_size a 8M si la aplicación no sube ficheros o a 32M si los necesita, mantener upload_max_filesize por debajo y poner los límites de tamaño, número de campos y partes multipart en el servidor web o el proxy, usando un límite de contenedor o cgroup como tope de disponibilidad y nunca RLIMIT_AS ni RLIMIT_DATA. Para CVE-2026-109619, desactivar session.upload_progress.enabled desde php.ini o el pool de FPM (no con ini_set ni con .user.ini) y, en PHP 8.5, poner fatal_error_backtraces=0, reiniciando todos los workers en ambos casos. PHP describe así las directivas que recomienda para una instalación que no pueda actualizar de inmediato.

; Medidas parciales de PHP para quien no pueda actualizar hoy, no sustituyen al parche
memory_limit = -1
post_max_size = 8M
upload_max_filesize = 4M
session.upload_progress.enabled = 0
; Solo en PHP 8.5
fatal_error_backtraces = 0

En PHP-FPM esos valores se fijan por pool con php_admin_value y php_admin_flag y se reinician los workers, y hay que comprobarlos con una petición servida por FPM o por mod_php, porque la salida de php -i en la consola describe otra configuración distinta. Sansec y Patchstack añaden session.use_strict_mode=1 como capa adicional y recuerdan que las barras de progreso nativas no las usan ni Magento, ni Shopware ni WooCommerce.

En cuanto a la detección, Huntress no había visto explotación en los entornos de sus clientes a 20 de octubre y, a falta de IoC, recomienda vigilar lo que delata cualquier RCE en un servidor web: procesos php-fpm, php-cgi, httpd o apache2 que lanzan shells, intérpretes como python o perl o herramientas de descarga, patrones de shell inversa en la línea de órdenes (/dev/tcp/, fsockopen, mkfifo) y órdenes de reconocimiento como whoami, id o uname -a ejecutadas desde el servidor web. Esta comprobación rápida lista los procesos del usuario del servidor web que no son el propio servidor ni PHP y sirve para una primera revisión manual.

# Procesos del usuario del servidor web que no son nginx, Apache ni PHP
ps -eo pid,ppid,user,comm,args --no-headers \
  | awk '$3=="www-data" || $3=="apache" || $3=="nginx"' \
  | grep -Ev 'php-fpm|php-cgi|apache2|httpd|nginx'

Huntress ha capturado una línea base del comportamiento normal de PHP en los endpoints de sus clientes para compararla tras el parche y promete publicar IoC y reglas Sigma y YARA en cuanto haya detalles técnicos. Para quien quiera montar su propia vigilancia de red, nuestras reglas de Snort para detectar intrusiones siguen siendo un buen punto de partida.

Qué cobertura han publicado los fabricantes de WAF, IPS y EDR

A lo largo del 21 de octubre los grandes proveedores de WAF, IPS y EDR han ido publicando su cobertura. La tabla recoge lo que cada uno había hecho público a las 17:40 UTC, con el identificador de regla o firma cuando lo hay, y los párrafos siguientes dan el detalle y los matices de cada uno.

Cloudflare cuenta que empezó a construir las protecciones a principios de octubre y que las activó por defecto a las 03:02 UTC del 21 de octubre, unas nueve horas antes de la divulgación, para todos sus clientes de WAF, incluidos los del plan gratuito. Son siete reglas Anomalous Execution (familia Generic Rules) en cada uno de los dos conjuntos gestionados (el Free, con identificador 77454fe2d30c4220b5701f6fdfb893ba, y el de pago, efb7b8c949ac4650a09736fc376e9aee), más una regla de respuesta, Default block for High confidence Signatures, que es la primera detección gestionada de Cloudflare capaz de bloquear la respuesta del origen antes de que llegue al atacante. Cloudflare dice haber visto tráfico de ataque y a los atacantes mutando sus payloads para esquivar las reglas, sin dar cifras, y pide a los clientes de pago que comprueben que el Managed Ruleset está desplegado en modo block y que revisen los eventos bloqueados filtrando por esos identificadores.

Akamai ha publicado la regla 3000991 v1 de su Adaptive Security Engine, PHP Remote Code Execution Attack Detected, para App & API Protector, y añade que sus reglas de inyección de comandos ya mitigaban los payloads armados. Imperva protege Cloud WAF de serie, pide actualizar Elastic WAF a la 2.2.1 y WAF Gateway a las ramas 14.7 LTS o 15.5 LTS con la actualización de contenido ADC, y ofrece un comprobador en php2shell.sh que da una evaluación preliminar de una URL. Imperva señala que durante la monitorización previa a la divulgación no observó tráfico que coincidiera con los patrones del exploit.

Unit 42 explica que los clientes de Advanced Threat Prevention Plus con Frontier Virtual Patching en PAN-OS 12.2.4 recibieron cobertura adelantada con el Threat ID 543004 a las 22:21 (hora del Pacífico) del 20 de octubre, es decir, a las 05:21 UTC del 21, y que el IPS estándar la recibió tras la publicación del parche con las firmas 543004 y 97622 a 97625. Palo Alto Networks dice haber visto pruebas de concepto, no explotación, y su Cortex Xpanse cuenta más de 22,6 millones de instancias expuestas potencialmente vulnerables. El dato incómodo está en su propio aviso de producto: PAN-OS y Panorama figuran como afectados en todas sus versiones, con fecha de corrección por determinar, y la mitigación es la de siempre, restringir la interfaz de administración a direcciones internas de confianza. Prisma Access, Cloud NGFW, Cortex XDR, XSOAR y Xpanse no están afectados.

Cisco Talos ha publicado las firmas Snort 67359 y 67360, disponibles también en el Community Ruleset gratuito, y a las 14:00 UTC afirmaba que «has not seen them being exploited in the wild yet» (todavía no las ha visto explotadas en la red). Su estimación inicial es que alrededor del 50 % de los sistemas PHP no recibirán parche. CrowdStrike se centra en la post-explotación: sus indicadores de ataque detectan el despliegue de webshells y los procesos hijos sospechosos de PHP o del servidor web, y ha añadido a Falcon Next-Gen SIEM una plantilla de correlación que busca errores de agotamiento de memoria en la fase de arranque de la petición. Su análisis aporta el detalle forense más útil del día: la explotación es silenciosa, el worker no se cae, el servidor devuelve un 200 y el único rastro en el servidor es un error fatal de límite de memoria en el log del servidor web que termina en «in Unknown on line 0», señal de que ningún script PHP estaba en ejecución cuando ocurrió.

La captura de Falcon que publica CrowdStrike muestra ese árbol de procesos: apache2 lanza una shell dash que acaba leyendo el fichero de contraseñas del sistema. Es lo que debería disparar cualquier EDR, y es también el motivo por el que CrowdStrike recomienda vigilar el endpoint cuando la telemetría HTTP no enseña nada. Corelight ha liberado en GitHub un paquete para Zeek 7.0 y reglas para Suricata basados en el comportamiento de las peticiones (longitud de los nombres de campo, estructuras serializadas y cabeceras MIME repetidas), con la limitación de que el tráfico cifrado hay que descifrarlo antes.

Al otro lado están los silencios. Fortinet respondió en su foro de soporte que no tiene aviso y que ha empezado a seguir el caso, y en el momento de esta actualización no había firma IPS ni de FortiWeb anunciada. De F5, AWS, Fastly y Google Cloud no hemos localizado reglas públicas con identificador, aunque Wiz cita a AWS, Fastly, Google Cloud, Microsoft, Automattic y Vercel entre quienes prepararon mitigaciones para sus clientes antes de la divulgación. Para OWASP CRS no hay regla oficial con número, y la comunidad del proyecto informa de que los intentos conocidos los bloquean varias reglas en el nivel de paranoia 1 siempre que el WAF inspeccione el cuerpo de la petición. Y en el ecosistema WordPress, Patchstack recuerda que ningún plugin puede parchear virtualmente un fallo del intérprete, lo que deja fuera de juego a los firewalls de aplicación que viven dentro de WordPress.

A quién afecta

A cualquier servidor web que ejecute PHP, con independencia de la aplicación que corra encima. Tenable recuerda que, según W3Techs, PHP está detrás del 69,3 % de los sitios web con lenguaje de servidor conocido, y recoge dos recuentos de exposición: Silas Cutler estima más de 1,3 millones de hosts expuestos potencialmente vulnerables y una búsqueda en Shodan de Henk Poley cuenta más de 1,9 millones de hosts que anuncian PHP. The Hacker News cita el recuento de Mallory del 20 de octubre, que es el que recoge el gráfico siguiente: unos 884.000 hosts expuestos anuncian PHP 8.1 o anterior, un 59 % del millón y medio que declara versión, y otros 740.000 anuncian PHP sin versión.

Las cifras del 21 de octubre por la tarde son mayores. Cortex Xpanse, de Palo Alto Networks, habla de más de 22,6 millones de instancias expuestas potencialmente vulnerables, VirusTotal estima más de 5,1 millones de hosts PHP visibles en Internet, 3,8 millones de ellos con al menos un puerto abierto según BleepingComputer, y Cisco calcula que cerca de la mitad de las instancias expuestas son demasiado antiguas para recibir el parche. Son cabeceras HTTP, no sistemas vulnerables confirmados, pero el reparto importa porque PHP solo mantiene las ramas 8.2 a 8.5, y la 8.2 deja de recibir correcciones el 31 de diciembre de 2026. Todo lo que esté en 8.1, 8.0, 7.x o 5.x ha llegado al final de su vida y depende de que la distribución o el proveedor de hosting retroporten la corrección. PHP ha dado un paso poco habitual. Por la dimensión del caso, su equipo de seguridad ha publicado en GitHub ramas con retroportes mínimos en código fuente para 7.4, 8.0 y 8.1, pensados para quien compila PHP o no tiene acceso a un proveedor de soporte extendido. No son paquetes, hay que compilarlos, y PHP no se compromete a mantenerlos.

El impacto visible llegó primero a Países Bajos. Según NL Times, el 21 de octubre la web de la Tweede Kamer (la cámara baja del Parlamento), la del propio NCSC holandés, Tweakers, Security.NL, el club de fútbol Fortuna Sittard, el sindicato policial ACP, la asociación de farmacéuticos KNMP, la operadora de transporte EBS y parte de la red informática compartida de universidades y hospitales universitarios se desconectaron por precaución. Un portavoz de la Tweede Kamer explicó que estas vulnerabilidades «make it possible to remotely control a server» (permiten controlar un servidor de forma remota). El NCSC holandés, que no había detectado explotación activa, pidió a las organizaciones: «Apply these updates immediately as soon as they become available» (apliquen estas actualizaciones de inmediato en cuanto estén disponibles). Patchstack añade a la lista DigiD y MijnOverheid, los portales de identidad y trámites del Gobierno holandés, y varios servicios japoneses. Por la tarde el fenómeno se extendió. El NCSC británico pidió actualizar de inmediato o retirar de Internet los sistemas PHP expuestos cuando la corrección no sea viable, y según Insurance Business los ayuntamientos de Edimburgo y Oxford y la Policía Metropolitana de Londres apagaron sus webs. Cybersecurity Dive suma al Gobierno de Finlandia y recoge que CISA, Reino Unido, Canadá, Australia y la Unión Europea han pedido lo mismo. CISA publicó su alerta el 21 de octubre con una frase que conviene leer entera: «has not observed exploitation of these vulnerabilities as of the time of publication» (no ha observado explotación de estas vulnerabilidades en el momento de la publicación), y aun así recomienda sacar de línea los sistemas en PHP 8.1 o anterior que no puedan actualizarse.

En España no constaba ninguna desconexión preventiva ni aviso del CCN-CERT en el momento de escribir esta noticia. Sí está el aviso de INCIBE-CERT del 21 de octubre, con la máxima importancia de su escala, y la realidad de que WordPress, PrestaShop, Drupal, Joomla y Moodle, todos escritos en PHP, sostienen buena parte de las webs de pymes, ayuntamientos y comercios electrónicos del país, casi siempre en hosting compartido o gestionado donde el intérprete lo actualiza el proveedor.

Qué hacer

1. Actualiza a PHP 8.5.12, 8.4.27, 8.3.36 u 8.2.35 desde php.net o desde los paquetes de tu distribución, que según PHP recibió los parches por adelantado, empezando por los servidores expuestos a Internet y reiniciando todos los workers de PHP-FPM o Apache. Si usas el repositorio de Remi en RHEL, Fedora o derivados, ten en cuenta que la PHP Foundation avisó el 21 de octubre de que ese repositorio voluntario no tendría paquetes el mismo día, así que valora los paquetes de la distribución o compilar desde las fuentes.
2. Inventaría cada instalación de PHP antes de parchear: servidores web, contenedores, entornos de pruebas, paneles de control, appliances y software de terceros que lo empaquetan. Tenable ofrece para ello los plugins 48243 (detección de versión), 58987 (versión sin soporte), 200476 (Windows) y 216936 (Unix). En cada equipo, confirma la versión y el SAPI que sirve tráfico real, y no únicamente la CLI.
3. Si tienes PHP 8.1 o anterior, decide hoy: actualiza a una rama soportada, pregunta a tu distribución o proveedor si retroportará la corrección, compila desde las ramas de retroporte de PHP para 7.4, 8.0 y 8.1 si gestionas tu propia compilación, o saca el servicio de Internet y déjalo detrás de VPN o de una lista de IP autorizadas.
4. Mientras no puedas parchear, pon el servicio detrás de un WAF o CDN con las reglas de emergencia activas (Cloudflare las ha desplegado para todos sus planes, incluido el gratuito, Akamai tiene la regla 3000991 y Imperva protege Cloud WAF de serie) y asegúrate de que el origen solo acepta tráfico desde la CDN, porque una petición directa a la IP del servidor se salta las reglas. Si la aplicación lo tolera, bloquea multipart/form-data en nginx o Apache con la regla de Sansec, o pasa la web a modo de solo lectura devolviendo 503 a todo lo que no sea GET ni HEAD.
5. Si no puedes actualizar hoy, aplica las directivas del apartado anterior (memory_limit, post_max_size, session.upload_progress.enabled y, en 8.5, fatal_error_backtraces) donde la aplicación no pueda cambiarlas, reinicia los workers y trátalas como capa adicional, nunca como solución. No instales plugins ni fragmentos de código que prometan corregir el fallo desde la aplicación: no es posible, el fallo está debajo.
6. Si tienes firewall de Palo Alto Networks, confirma que Advanced Threat Prevention tiene activas las firmas 543004 y 97622 a 97625, y si usas Snort o Suricata, carga las SID 67359 y 67360 de Talos o el paquete de Corelight. Si eres cliente de Fortinet, F5, AWS, Fastly o Google Cloud, pide a tu proveedor la referencia de su cobertura, porque a la hora de esta actualización no había identificador público.
7. Revisa los logs del servidor web del 20 y el 21 de octubre en busca de peticiones POST multipart a rutas que no aceptan subidas, errores fatales de PHP repetidos desde una misma IP y respuestas 500 anómalas, y aplica la comprobación de procesos del apartado anterior. Si encuentras indicios, aísla el servidor sin apagarlo, preserva los logs y busca webshells, ficheros nuevos en el directorio web, tareas cron y cuentas recién creadas. Busca en concreto errores fatales de límite de memoria que terminen en «in Unknown on line 0», el rastro que describe CrowdStrike, y confía más en el EDR que en los logs HTTP, porque la explotación devuelve un 200.
8. Si gestionas una empresa, notifica cualquier compromiso a INCIBE-CERT a través del 017 o del correo incidencias@incibe-cert.es, y si eres organismo público, al CCN-CERT. Si el servidor trataba datos personales, recuerda el plazo de 72 horas del RGPD ante la AEPD.

Análisis

Lo que distingue a PHP2Shell de un aviso crítico más no es la puntuación, es el orden en que han llegado las cosas. En el caso de Drupal de esta misma semana el parche llegó con el aviso y la comunidad tuvo horas para aplicarlo antes de que nadie supiera dónde mirar. Aquí la filtración rompió el embargo con dos días de antelación, una herramienta con nombre propio circulaba antes del parche y Sansec calculaba que la explotación a gran escala empezaría en los quince minutos siguientes a la publicación de la corrección, que ya está en la calle, porque la diferencia entre la versión antigua y la nueva señala el fallo a cualquiera que sepa leer un commit. En la práctica, quien no actualice esta tarde queda expuesto con la misma certeza que quien no parcheó el fallo CVSS 10 de GitLab la semana pasada, con la diferencia de que el número de objetivos se mide en millones.

El aviso oficial despacha las ramas sin soporte en dos líneas, y ahí está el problema de fondo. Más de la mitad de los hosts que declaran versión en Shodan están en 8.1 o anterior, y en España ese porcentaje es creíble en el hosting compartido, donde conviven aplicaciones antiguas que nadie se atreve a tocar. Para esos servidores no hay paquete oficial de PHP, y la decisión real de hoy es si la distribución retroporta la corrección, si el proveedor migra la cuenta a 8.2 o superior o si la web se queda fuera de línea. Los retroportes en código fuente para 7.4, 8.0 y 8.1 que PHP ha publicado son una ayuda real para quien compila su propio intérprete, y una señal de que el proyecto sabe que la mitad del parque no puede saltar de rama en una tarde. Para el hosting compartido no cambian nada: ahí la pieza la mueve el proveedor, y la pregunta que toca hacerle hoy es cuándo aplica el parche y a qué rama migra las cuentas que siguen en 7.4 u 8.1.

También conviene leer con cuidado las afirmaciones sobre explotación, que han cambiado a lo largo del día. Por la mañana Cloudflare y Patchstack hablaban de intentos observados sin publicar indicadores, y watchTowr, Huntress y el NCSC holandés no habían visto ataques. A las 14:19 UTC watchTowr pasó a decir que observa intentos de explotación de ambos CVE en su red de honeypots Attacker Eye, y su responsable de inteligencia de amenazas, Jake Knott, matizó a Cybersecurity Dive que «Whilst nobody has been successful to date» (aunque nadie lo ha conseguido hasta la fecha) no espera que eso dure. Talos a las 14:00 UTC y CISA en su alerta seguían sin ver explotación, y a las 17:40 UTC ninguno de los dos CVE estaba en el catálogo KEV. Con una herramienta filtrada en circulación y, según Tenable, código público que afirma explotar los fallos y que nadie ha verificado, es razonable actuar como si la explotación fuera inminente, pero no conviene confundir las reglas de un WAF con una corrección: Cloudflare las califica de parche provisional, solo cubren el tráfico que pasa por su red y una variante nueva del exploit las deja atrás, como ya ocurrió con el zero-day de BeyondTrust que se explotó durante semanas detrás de defensas perimetrales. Si gestionas una web en WordPress, PrestaShop o Magento, la lección de las últimas semanas, desde el backdoor servido por Rank Math PRO hasta este fallo del propio intérprete, es la misma: actualizar la aplicación no actualiza lo que hay debajo, y lo que hay debajo es lo que hoy está en juego.

Cronología

Las horas son UTC. La del parche es la de aparición de las versiones en la API de php.net.

El 20 de octubre a las 15:20 aparece el mensaje de Hacker News y a las 19:33 PHP publica su aviso previo. A las 02:13 del día 21 Gina Peter Banyard, del núcleo de PHP, afirma que la única mitigación es parchear. A las 07:34 Patchstack recibe los primeros informes de explotación de sus socios de hosting y a las 07:43 el CTO de Cloudflare, Dane Knecht, anuncia que su empresa ve los primeros ataques y despliega reglas de WAF. A las 08:48 la PHP Foundation avisa de que el repositorio de Remi no tendrá paquetes ese día. A las 10:35 Tweakers, la Tweede Kamer, el NCSC y Security.NL se desconectan. A las 13:35 php.net publica las cuatro versiones corregidas, veinticinco minutos antes de la hora anunciada, junto con el aviso de seguridad y los dos avisos GHSA en GitHub. Entre las 13:50 y las 14:20 se publican en cadena el informe de Wiz, los avisos de Cloudflare (13:56), Akamai, Imperva, Unit 42, Talos y CrowdStrike, la alerta de CISA y, a las 14:19, el aviso de watchTowr sobre intentos de explotación en sus honeypots. A las 16:30 Unit 42 actualiza su informe con el aviso de producto de Palo Alto Networks. La cronología se cerró a las 17:40 UTC.

PHP ya aparece tres veces en el catálogo KEV de CISA: CVE-2012-1823 y CVE-2019-11043, ambas añadidas el 25 de marzo de 2022, y CVE-2024-4577, el fallo de PHP-CGI en Windows añadido el 12 de junio de 2024 y usado en campañas de ransomware. Cuando ese último se hizo público, Akamai registró intentos de explotación en las primeras 24 horas, según recuerda The Hacker News, y aquel fallo requería una configuración concreta. Este no parece requerir ninguna, y la experiencia del sector con Log4Shell y la detección de aplicaciones vulnerables enseña que el inventario, y no el parche, es lo que marca la diferencia en las primeras 48 horas.

Preguntas frecuentes

¿Mi web en WordPress está afectada aunque tenga todo actualizado?

Sí, si el servidor ejecuta una versión vulnerable de PHP. El fallo está en el intérprete, no en WordPress ni en sus plugins, así que actualizar el CMS, el tema o los plugins no cambia nada. En hosting compartido o gestionado el responsable de actualizar PHP es el proveedor: pregúntale cuándo aplicará la versión corregida y, si tu cuenta sigue en PHP 7.4 u 8.1, pide el cambio a una rama soportada.

¿Basta con poner la web detrás de Cloudflare o de otro WAF?

Reduce el riesgo, pero no lo elimina. Las reglas que Cloudflare, Akamai, Imperva o Palo Alto Networks publicaron el 21 de octubre cubren los vectores conocidos, y Cloudflare ya ha visto a los atacantes mutar los payloads para esquivarlas. Un WAF en la nube solo actúa sobre el tráfico que pasa por su red. Si el servidor de origen acepta conexiones directas desde cualquier IP, un atacante que conozca esa dirección se salta la protección. El propio CTO de Cloudflare la describe como una medida provisional hasta aplicar el parche.

¿Qué hago si mi servidor usa PHP 7.4 u 8.1 y no puedo migrar hoy?

Comprueba primero si tu distribución (Debian, Ubuntu, RHEL) o tu proveedor publican una corrección retroportada, y si compilas PHP, usa las ramas de retroporte que PHP ha publicado en GitHub para 7.4, 8.0 y 8.1. Si no hay nada de eso, saca el servicio de Internet o limítalo a una VPN o a IP autorizadas, bloquea las peticiones multipart en el servidor web si la aplicación lo permite y planifica la migración a 8.2 o superior como tarea de esta semana, no de este trimestre.

¿Cómo sé si ya me han atacado?

Busca en los logs del servidor web peticiones POST con Content-Type multipart/form-data a rutas que no aceptan subidas, sobre todo desde el 20 de octubre, y en los logs de PHP errores fatales repetidos desde una misma IP. En el sistema, revisa si procesos de PHP o del servidor web han lanzado shells o herramientas de descarga, y busca ficheros PHP recién creados en el directorio web. Ante cualquier indicio, aísla la máquina sin apagarla y conserva los registros, a ser posible centralizados en alguna de las soluciones open source de gestión de logs que ya hemos analizado.