--- title: 'PHP2Shell: RCE crítico en todo PHP | DevSense' description: 'Análisis de PHP2Shell — CVE-2026-109618 y CVE-2026-109619, un RCE no autenticado en el núcleo de PHP: cómo funcionan las vulnerabilidades, por qué son tan peligrosas, quién se lanzó a repararlas y cómo proteger su servidor. Sin exploit funcional, con fines educativos.' faq: - { question: '¿Qué es PHP2Shell y qué versiones de PHP están afectadas?', answer: 'PHP2Shell es el nombre común de dos vulnerabilidades del núcleo de PHP, CVE-2026-109618 y CVE-2026-109619, divulgadas el 21 de octubre de 2026. Juntas permiten la ejecución remota de código no autenticada a través del análisis ordinario de una petición HTTP. Están afectadas prácticamente todas las ramas de la última década; las correcciones salieron en PHP 8.5.12, 8.4.27, 8.3.36 y 8.2.35, y para 8.1/8.0/7.4 PHP publicó backports mínimos.' } - { question: '¿El atacante necesita autenticación o un plugin vulnerable?', answer: 'No. Ahí está lo esencial: el agujero está en el propio núcleo de PHP, en la ruta de análisis de la petición entrante, que se ejecuta antes incluso del código de la aplicación. No hace falta ni un inicio de sesión, ni un CMS concreto, ni un plugin vulnerable: basta con que el servidor acepte peticiones HTTP y ejecute PHP. Por eso los investigadores hablan del «70% de la web»: es la proporción de sitios que corren sobre PHP, no el número de servidores realmente comprometidos.' } - { question: '¿Se está explotando la vulnerabilidad en ataques reales?', answer: 'En el momento de escribir esto (al tercer día de la divulgación) no hay brechas confirmadas públicamente precisamente a través de PHP2Shell, pero Cloudflare y otros ya observan escaneos e intentos de explotación, además con mutación del payload para evadir los filtros. Con un RCE no autenticado de hasta CVSS 9.2, la ventana entre «nadie alcanzó a actualizar» y «aparecieron ataques masivos» se mide en días.' } - { question: '¿Qué hacer ahora mismo si no es posible actualizar de inmediato?', answer: 'Actualizar PHP es la única solución completa. Mientras no esté desplegada: active un WAF (Cloudflare, Fastly, Akamai, Imperva y los proveedores de nube ya lanzaron protección por defecto), limite el tamaño del cuerpo de la petición en el proxy inverso, desactive session.upload_progress.enabled y, en PHP 8.5, fatal_error_backtraces, y vigile en los logs los errores de falta de memoria con «Unknown on line 0» y las caídas de los workers. Esto reduce el riesgo, pero no cierra el agujero.' } published: '2026-10-23' --- # PHP2Shell: RCE crítico en todo PHP — qué pasó y cómo protegerse Hay un tipo especial de vulnerabilidad: las que no viven en el plugin de nadie ni en la línea torcida de una aplicación concreta, sino en el cimiento mismo sobre el que descansa todo lo demás. PHP2Shell es exactamente eso. No es un agujero en WordPress, ni el desliz de un programador, ni un `eval()` olvidado. Es una grieta en el muro de carga: en ese mismísimo código del núcleo de PHP que analiza la petición entrante antes de que se ejecute la primera línea de su aplicación. El 21 de octubre de 2026, PHP publicó versiones de emergencia y divulgó dos vulnerabilidades — **CVE-2026-109618** y **CVE-2026-109619** — que juntas dan aquello más temible que casi cualquier cosa en la web: la **ejecución remota de código no autenticada**. Sin inicio de sesión. Sin plugin vulnerable. Sin un solo clic de la víctima. Este artículo está escrito al tercer día de la divulgación, cuando el parche ya existe pero media internet todavía no ha actualizado, y por eso está escrito sin una sola línea de exploit funcional. Analizaremos qué se rompió y por qué es tan peligroso, pero no pondremos un arma en las manos de nadie. El objetivo es que usted entienda al enemigo y cierre la puerta, no que alguien monte un ataque a partir de nuestro texto. **Guías relacionadas:** [Ataques web y cómo prevenirlos](web-attacks-and-prevention) · [Integraciones tolerantes a fallos](resilient-external-integrations) · [Observabilidad y monitoreo](observability-monitoring-laravel) · [Zero-downtime deployment](zero-downtime-deployment-laravel) ## Contenido * [En breve: lo que hay que saber en treinta segundos](#tldr) * [Por qué una vulnerabilidad en el núcleo es otra escala](#why-core) * [Cronología: cómo una IA encontró el agujero en todo PHP](#timeline) * [Dos puertas: qué se esconde tras los dos CVE](#two-doors) * [Qué tan grave es el daño](#impact) * [La mirada del atacante: modelo de amenazas sin instrucciones](#attacker) * [Quién ya se lanzó a reparar](#responders) * [¿Hay ya víctimas?](#victims) * [Cómo protegerse: paso a paso](#defense) * [Cómo ver el ataque en sus propios logs](#detection) * [PHP está vivo — y esta es la prueba](#php-alive) * [Checklist](#checklist) * [Cuestionario de autoevaluación](#self-test-quiz) --- ## En breve: lo que hay que saber en treinta segundos * **Qué:** dos vulnerabilidades del núcleo de PHP bajo el nombre común PHP2Shell — CVE-2026-109618 y CVE-2026-109619. * **Qué amenaza:** ejecución remota de código no autenticada (RCE), con gravedad de hasta **CVSS 9.2**. * **A quién afecta:** prácticamente todas las ramas de PHP de la última década, con independencia del CMS y del framework. * **Dónde está corregido:** PHP **8.5.12, 8.4.27, 8.3.36, 8.2.35**; para 8.1/8.0/7.4, backports mínimos del equipo de PHP. * **Qué hacer:** actualizar PHP y reiniciar PHP-FPM y los workers de colas. De inmediato. Lo demás son solo apuntalamientos temporales. Si está leyendo esto desde una producción con una versión sin parchear, cierre el artículo, actualice y vuelva. En serio. --- ## Por qué una vulnerabilidad en el núcleo es otra escala La mayoría de las vulnerabilidades web se parecen a una ventana sin cerrar de un apartamento concreto: un bug en un plugin, una inyección SQL en un controlador casero, una comprobación de permisos olvidada. Arregle el apartamento y la ventana queda cerrada. PHP2Shell es un defecto de fábrica en la cerradura que está montada en una de cada dos puertas del planeta. PHP procesa la petición entrante por capas. Primero, el núcleo: lee las cabeceras, analiza el cuerpo de la petición, llena los arrays superglobales `$_POST`, `$_FILES`, `$_COOKIE`. Y solo después el control llega a su código: al router de Laravel, al núcleo de WordPress, a la primera línea que escribió usted. PHP2Shell vive **en la primera capa**. La ruta vulnerable se ejecuta para todos y siempre, por el simple hecho de que el servidor aceptó una petición. De ahí la célebre formulación de los investigadores sobre el «70% de internet». Es importante entender qué significa: PHP atiende alrededor del 70% de todos los sitios del mundo, y la superficie de ataque teórica son todos ellos. Esto **no** significa que el 70% de los sitios ya estén comprometidos ni que cada uno de ellos vaya a caer garantizado en una sola petición. Significa que el techo de esta vulnerabilidad es del tamaño de la web. --- ## Cronología: cómo una IA encontró el agujero en todo PHP Esta historia tiene un detalle por el que entrará en los libros de texto, y no es la vulnerabilidad en sí. La encontraron no con una auditoría manual clásica, sino con un tándem de humano e IA. Los investigadores de Wiz llevaron la búsqueda con ayuda de modelos modernos y, según sus propias palabras, el modelo hizo una «contribución inestimable» no solo en el descubrimiento, sino también en convertir los hallazgos en exploits funcionales contra varios objetivos, «en cuestión de horas». Vivimos en un mundo donde el fuzzing del núcleo de PHP no lo lleva solo un humano con un depurador, sino también una IA, y ambos lados de la barricada ya lo han entendido. Cronología de 2026 (según datos de Wiz): | Fecha | Evento | |------|---------| | 19 de agosto | Se encuentra la primera de las vulnerabilidades | | 20 de agosto | Se confirma el RCE no autenticado contra Drupal | | 21 de agosto | Se confirma el RCE no autenticado contra WordPress | | 24 de agosto | Se reporta al equipo de seguridad de PHP | | 21 de septiembre | PHP confirma el problema e inicia una corrección coordinada | | 21 de octubre | Se publican los parches y se produce la divulgación pública | Casi dos meses entre el reporte silencioso al equipo de PHP y la divulgación pública. Este es el proceso correcto, «adulto»: primero se repara, luego se cuenta. El artículo que está leyendo apareció dos días después de la última línea de esta tabla. --- ## Dos puertas: qué se esconde tras los dos CVE Bajo el nombre de PHP2Shell se esconden dos defectos distintos: dos puertas a una misma habitación. Distintos investigadores y proveedores describen los bugs subyacentes con pequeñas discrepancias en los detalles, y bajo cada CVE se esconde más bien una clase de problemas que una sola línea. Nos mantenemos a propósito en el nivel de la mecánica — «qué se rompió exactamente» — sin descender hasta la receta de cómo llegar hasta la shell. ### CVE-2026-109618 — procesamiento de los datos entrantes de la petición La primera puerta se abre en la etapa en que PHP analiza el cuerpo de una petición POST y procesa las subidas. El problema está en el manejo de la memoria en esa ruta: ante cierta forma de los datos de entrada, el núcleo accede a memoria que ya liberó o lleva mal la contabilidad al asignarla. Donde debería haber un pulcro «asigno, uso, libero», aparece una ventana en la que el estado de la memoria deja de corresponderse con lo que el código espera. Y un manejo de memoria corrupto en código nativo es un trampolín clásico: de ahí salen tanto la fuga de fragmentos de memoria del proceso (y con ello la evasión de protecciones como ASLR) como el control sobre la ejecución. Un detalle clave: esta ruta no requiere ni autenticación ni una configuración especial de la aplicación. Basta con que PHP analice automáticamente el cuerpo de la petición, y eso lo hace siempre. ### CVE-2026-109619 — estado residual entre peticiones La segunda puerta es más sutil y, en cierto sentido, más elegante. PHP-FPM es un proceso de larga vida: un mismo worker atiende petición tras petición sin recargar el framework (por qué eso es a la vez rápido y peligroso lo analizamos en el artículo sobre [colas en producción](laravel-queues-production#memory)). Si, tras procesar una petición, en el worker queda un estado «basura» — por ejemplo, del mecanismo de seguimiento del progreso de subida de archivos (`session.upload_progress`) o de la generación de trazas de errores fatales —, entonces la siguiente petición puede tropezarse con esos datos rancios. Una petición prepara la trampa; la segunda cae en ella. Lo pérfido es que parte de estos mecanismos funciona aunque la aplicación nunca los haya invocado explícitamente. `session.upload_progress` está activado por defecto y se dispara sin un solo `session_start()` en su código. > [!NOTE] > Recuerde dos ajustes de la segunda puerta — `session.upload_progress.enabled` y (en PHP 8.5) `fatal_error_backtraces`. Más abajo, en el apartado sobre defensa, son precisamente los que taparemos si actualizar ahora mismo no es posible. --- ## Qué tan grave es el daño El RCE es la cúspide de la cadena alimentaria de las vulnerabilidades. No es «se filtraron datos» ni «se alteró una página», sino que **código ajeno se ejecuta en su servidor con los privilegios de su proceso web**. Qué significa esto en la práctica: * **Control total de la aplicación.** El atacante lee y modifica cualquier cosa del código y de los archivos accesibles para `www-data`. * **Acceso a los secretos.** El `.env` con la contraseña de la base de datos, las claves de los sistemas de pago, los tokens de API, la `APP_KEY`: todo lo que el proceso pueda leer, lo lee también el atacante. * **La base de datos entera.** No a través de una inyección retorcida, sino directamente, con las mismas credenciales que la aplicación. * **Movimiento lateral.** El servidor se convierte en un punto de apoyo: desde ahí se escanea la red interna, se atacan los servicios vecinos y se afianzan mediante una web shell. * **Silencio.** Una explotación exitosa puede devolver un HTTP 200 normal y no tumbar el worker. Por fuera, nada; por dentro, el intruso ya está en casa. Para un sitio como DevSense, donde no hay pagos ni datos personales de los usuarios más allá del mínimo, el daño directo es menor que para una tienda en línea o un banco. Pero «menor» no significa «ninguno»: incluso nuestro servidor es acceso a la base de datos, a las claves de correo, a la infraestructura de despliegue y un excelente punto de apoyo para atacar a otros. Por eso [actualizamos PHP](../tools/dockerfile-php-best-practices) ese mismo día. --- ## La mirada del atacante: modelo de amenazas sin instrucciones Mirar la vulnerabilidad con los ojos del atacante es útil: así se entiende mejor dónde poner la defensa. Pero «la mirada del atacante» aquí significa el **modelo de amenazas y la economía del ataque**, no una receta paso a paso. La receta no la daremos por principio: tiene dos días, golpea un RCE no autenticado y la mitad de los servidores todavía no está cerrada. Qué mueve al atacante en una situación así: * **La masividad importa más que la precisión.** Cuando «toda la web» es vulnerable, nadie elige a la víctima con puntería. Se lanza un escaneo amplio: probamos con todos por igual y nos afianzamos en quienes dio resultado. Su sitio cae bajo el ataque no porque usted sea interesante, sino porque existe y responde a las peticiones. * **Carrera contra el parche.** El valor del exploit es máximo en los primeros días, mientras la masa no ha actualizado. De ahí el repunte de actividad justo después de la divulgación, que ya se observa. * **Evasión de filtros.** En cuanto los proveedores de WAF sacaron sus reglas, los atacantes empezaron a mutar el payload para no caer bajo ellas. Cloudflare ya lo ha registrado. La conclusión para usted: el WAF es tiempo ganado, no una victoria. Solo gana el parche. * **La automatización también está de su lado.** Si la IA ayudó a encontrar y explotar la vulnerabilidad en horas del lado de los investigadores, entonces también del lado de los atacantes el ciclo «del CVE al escáner masivo» se ha vuelto más corto que nunca. El sentido práctico de esta óptica es uno solo: no cuente con que «mi sitio pequeño no le interesa a nadie». En un mundo de ataques de difusión amplia, no existen los sitios que no interesen. --- ## Quién ya se lanzó a reparar La buena noticia: la industria reaccionó ante PHP2Shell como un organismo bien coordinado y, quizá, esta es la mejor ilustración de que el ecosistema de PHP está vivo y sano. La divulgación fue coordinada: a la hora X, la protección ya estaba en pie. * **Cloudflare** sacó reglas de WAF **unas 9 horas antes de la divulgación pública** y activó la protección por defecto el 21 de octubre a las 3:02 UTC, en todos los planes, incluido el gratuito, sin que el cliente tuviera que hacer nada. Según sus datos, ya ven tráfico de ataque y sus mutaciones. * **Fastly, Akamai, Imperva** sacaron sus propias reglas de protección para los clientes que no pueden actualizar al instante. * **AWS, Google Cloud, Microsoft, Vercel** publicaron guías de respuesta y protección a nivel de sus plataformas. * **Automattic** (la empresa detrás de WordPress.com) y otros participantes del ecosistema figuran entre quienes ayudaron con la respuesta coordinada. Merece una mención aparte el propio equipo de seguridad de PHP: dos meses de trabajo silencioso, la publicación sincronizada de parches en todas las ramas soportadas e incluso backports para ramas cuyo soporte oficial ya había terminado (7.4, 8.0, 8.1). Para un proyecto al que entierran en los comentarios desde hace años, es una reacción ejemplar. --- ## ¿Hay ya víctimas? Aquí conviene ser honestos y no multiplicar el pánico. **Al tercer día de la divulgación no hay brechas confirmadas públicamente precisamente a través de PHP2Shell.** Ninguna organización grande ha sido nombrada todavía como víctima. Pero varias cosas se saben con certeza: * Existen exploits funcionales: están demostrados por los investigadores contra imágenes recientes de WordPress, Drupal y Joomla. Es una demostración de la superficie, no la raíz del problema: no se trata de esos CMS, sino del PHP que corre debajo. * El escaneo y los intentos de explotación ya están en marcha: lo dicen tanto Cloudflare, que observa tráfico de ataque, como los boletines del sector, que registran «la aparición de intentos de explotación». * La ausencia de víctimas públicas al tercer día no es un «nos salvamos», sino un «todavía es pronto». Entre el escaneo masivo y los primeros informes públicos de brechas suelen pasar semanas. La ventana para alcanzar a actualizar está abierta ahora mismo. Dicho de otro modo: el silencio en el marcador no es el cese de la alarma, sino una ventaja de salida. Aprovéchela. --- ## Cómo protegerse: paso a paso ### 1. Actualice PHP — es la única solución de verdad Todo lo demás que sigue son apuntalamientos que compran tiempo. El agujero solo lo cierra el parche. ```bash # Debian/Ubuntu, repositorio de Ondřej Surý (como el nuestro) sudo apt-get update sudo apt-get install --only-upgrade -y \ $(dpkg-query -W -f='${db:Status-Abbrev} ${Package}\n' 'php8.5*' | awk '$1 == "ii" {print $2}') # Reiniciar todo lo que mantenga el binario antiguo en memoria sudo systemctl restart php8.5-fpm sudo supervisorctl restart all # los workers de colas también son PHP ``` Versiones objetivo: **8.5.12 / 8.4.27 / 8.3.36 / 8.2.35** o más recientes. Compruebe tanto la CLI como FPM: ```bash php -v | head -1 /usr/sbin/php-fpm8.5 -v | head -1 ``` > [!WARNING] > Reiniciar PHP-FPM es obligatorio. El proceso de larga vida mantiene en memoria el binario antiguo y vulnerable incluso después de un `apt upgrade`, hasta que se lo reinicia. Lo mismo vale para los workers de colas bajo Supervisor u Horizon: no ven el PHP nuevo hasta que se los reinicia. En detalle, sobre la actualización y la reconstrucción de imágenes, en nuestro análisis de [la imagen de producción para PHP](../tools/dockerfile-php-best-practices). ### 2. Levante un WAF Si está detrás de Cloudflare, la protección ya está activada por defecto; solo compruebe que las reglas estén en modo de bloqueo. Fastly, Akamai, Imperva y los proveedores de nube sacaron algo análogo. Recuerde la mutación del payload: el WAF es una medida temporal. ### 3. Limite el cuerpo de la petición en el borde En el proxy inverso (nginx, balanceador) corte los cuerpos de petición anormalmente grandes antes de que lleguen a PHP. Esto no cura, pero frena una parte considerable de los intentos automatizados. ### 4. Tape la segunda puerta con ajustes Si el parche todavía no está desplegado, desactive los mecanismos a través de los que funciona CVE-2026-109619. DevSense no los usa, y esto no afecta al funcionamiento del sitio: ```ini ; /etc/php/8.5/fpm/conf.d/99-hardening.ini session.upload_progress.enabled = 0 fatal_error_backtraces = 0 ; solo PHP 8.5 expose_php = Off ``` ```bash sudo systemctl restart php8.5-fpm ``` Esto reduce la exposición, pero **no reemplaza la actualización**. --- ## Cómo ver el ataque en sus propios logs La defensa sin observabilidad es ciega. Estos son los indicadores honestos en los que conviene fijarse (ninguno de ellos por sí solo demuestra una brecha: lo importante es la correlación): * **En los logs de PHP-FPM:** `Allowed memory size ... exhausted` junto con `Unknown on line 0`. La línea `on line 0` significa que la caída ocurrió en la etapa de inicialización de la petición, antes incluso del código de la aplicación, que es justo donde vive la primera puerta. * **Caídas de workers:** segfaults (`SIGSEGV`, `exited on signal 11`) en los logs de PHP-FPM o Apache, sobre todo en series. * **Peticiones anómalas:** POST con nombres de campo inusualmente largos (del orden de megabytes), datos binarios y bytes nulos en los valores de los campos. * **Cookies `PHPSESSID` inusualmente grandes**, uno de los indicios que señalan los propios investigadores. * **Procesos huérfanos del usuario web:** una shell lanzada por `www-data` ya no es un indicio, sino casi una sentencia: ```bash ps -eo user,pid,ppid,cmd | awk '$1=="www-data"' | grep -vE "php-fpm|nginx" sudo grep -h "Unknown on line 0" /var/log/php8.5-fpm.log* 2>/dev/null | tail ``` Cómo integrar estas señales en un monitoreo y unas alertas permanentes, en el artículo sobre [observabilidad](observability-monitoring-laravel). --- ## PHP está vivo — y esta es la prueba A PHP lo entierran con envidiable regularidad. «Lenguaje muerto», «legacy», «todos se fueron a Node y Go»: este obituario se escribe cada año. PHP2Shell, por paradójico que parezca, es un argumento justo en sentido contrario. Primero, una vulnerabilidad de semejante escala solo es posible en una tecnología sobre la que realmente descansa una parte enorme de la web. Los lenguajes muertos no llegan a los titulares de CISA ni obligan a Cloudflare a sacar protección nueve horas antes de la divulgación. En un agujero del tamaño del 70% de internet solo se cae lo que sostiene a esa internet. Segundo —y esto es lo principal—, fíjese en la reacción. El equipo de seguridad de PHP llevó a cabo una corrección coordinada ejemplar, publicó los parches en todas las ramas de forma sincronizada e incluso backporteó los fixes a ramas sin soporte oficial. Toda la industria —de Automattic a AWS— trabajó como un solo organismo. Así no se comporta un proyecto agonizante, sino un ecosistema maduro y vivo, con procesos adultos. PHP 8.5, con property hooks, visibilidad asimétrica, propiedades tipadas y el operador pipe, es un lenguaje moderno, no una pieza de museo. Lo vivo tiene sistema inmunitario, y en octubre de 2026 el suyo actuó rápido y coordinado. Más vivo que nunca, entre otras cosas porque sabe cicatrizar deprisa heridas como esta. --- ## Checklist 1. PHP actualizado a 8.5.12 / 8.4.27 / 8.3.36 / 8.2.35 o superior, tanto la CLI como PHP-FPM. 2. PHP-FPM reiniciado; workers de colas (Supervisor/Horizon) reiniciados. 3. Comprobado que el proceso de FPM no mantiene el binario antiguo (`/proc//exe` sin la marca `(deleted)`). 4. WAF activado y en modo de bloqueo; recuerde que esta medida es temporal. 5. Limitado el tamaño del cuerpo de la petición en el borde. 6. Si el parche no está desplegado, desactivados `session.upload_progress.enabled` y `fatal_error_backtraces`. 7. Logs revisados en busca de `Unknown on line 0`, segfaults y shells de `www-data`. 8. Imágenes de contenedor reconstruidas y redesplegadas, si PHP se instala desde la imagen. --- ## Resumen PHP2Shell es un caso raro en el que una vulnerabilidad resulta interesante no solo por lo que rompe, sino también por lo que muestra. Rompe el cimiento: un RCE no autenticado en el núcleo sobre el que descansa gran parte de la web. Y muestra que el ecosistema en torno a ese núcleo está vivo, es rápido y está bien coordinado. El parche salió, los grandes actores cubrieron a quienes no alcanzaron a reaccionar, y de usted se requiere una sola acción, sencilla: actualizar y reiniciar. Hágalo antes de que se agote la ventaja de salida. --- ## Cuestionario de autoevaluación ### Pregunta 1: ¿Por qué PHP2Shell es más peligrosa que una vulnerabilidad típica en un plugin de CMS? - A) Porque es más difícil de detectar con escáneres. - B) Porque está en el núcleo de PHP, en la ruta de análisis de la petición, y se dispara antes del código de la aplicación, sin autenticación y con independencia del CMS o del framework. - C) Porque solo afecta a versiones obsoletas de PHP.
Mostrar respuesta **Respuesta: B** El defecto vive en la primera capa de procesamiento de la petición, común a todas las aplicaciones PHP. No hace falta ni un inicio de sesión, ni un CMS concreto, ni un plugin vulnerable: basta con que el servidor acepte peticiones y ejecute PHP.
### Pregunta 2: ¿Por qué, tras un `apt upgrade`, es obligatorio reiniciar PHP-FPM y los workers de colas? - A) De lo contrario no se actualizan los archivos de configuración. - B) Porque los procesos de larga vida mantienen en memoria el binario antiguo y vulnerable de PHP hasta que se los reinicia. - C) Para purgar el OPcache de las páginas estáticas.
Mostrar respuesta **Respuesta: B** PHP-FPM y los workers de colas son procesos de larga vida. Siguen ejecutando el binario antiguo cargado en memoria incluso después de actualizar el paquete, hasta que se los reinicia. Se puede comprobar por el enlace simbólico `/proc//exe`.
### Pregunta 3: ¿Por qué el WAF es tiempo ganado y no una solución completa? - A) El WAF ralentiza el sitio y hay que desactivarlo. - B) Porque los atacantes mutan el payload para evadir las reglas; el agujero solo lo cierra la actualización de PHP. - C) Porque el WAF protege únicamente de los ataques autenticados.
Mostrar respuesta **Respuesta: B** Las reglas del WAF filtran las formas conocidas del ataque, pero los atacantes ya mutan el payload para no caer bajo ellas (lo registró Cloudflare). El WAF reduce el riesgo y compra tiempo para actualizar, pero la única solución completa es el parche.