Un fallo crítico en una librería que WordPress ni siquiera incluye puede tumbar webs WordPress desde fuera y sin iniciar sesión. La empresa de seguridad Patchstack alertó el 30 de octubre de que la vulnerabilidad CVE-2026-111497, bautizada como Broccoli2Shell, en el descompresor Brotli de Google, alcanza a las instalaciones de WordPress a través de sus peticiones salientes. Con una sola petición se puede bloquear un proceso de PHP, y con muchas, mantener la web caída. La solución no está en el panel de WordPress, sino en el servidor.
Un fallo crítico que ya se está explotando
Brotli es un formato de compresión muy usado en la web. Según Patchstack, el fallo es una escritura fuera de límites en su decodificador que afecta a las versiones 1.0.3 a 1.2.0. Google, que asignó el CVE, le da una puntuación de 9,2, y las versiones corregidas, 1.0.10, 1.1.1 y 1.2.1, se publicaron el 21 de octubre.
La agencia de ciberseguridad de Estados Unidos, CISA, la añadió el 27 de octubre a su catálogo de vulnerabilidades explotadas activamente y ha fijado el 10 de noviembre como plazo para que las agencias federales la corrijan. El Centro Canadiense de Ciberseguridad emitió una alerta el 28 de octubre en la que avisa de que el fallo también afecta a tecnologías como Node.js, .NET, PowerShell o los paquetes de Brotli para Python.
Cómo llega el ataque a WordPress
WordPress no incluye Brotli, pero usa la librería libcurl del sistema operativo para sus conexiones salientes y le pide que descomprima automáticamente las respuestas, también las comprimidas con Brotli. Si un atacante consigue que la web se conecte a un servidor suyo, puede enviarle una respuesta manipulada que llega al decodificador vulnerable antes de que PHP vea ningún dato.
La vía más peligrosa es el pingback de XML-RPC. Según Patchstack, no requiere autenticación y basta con que haya una entrada publicada que acepte pingbacks, algo que ocurre en una instalación por defecto. Hay otras vías: plugins y temas que descargan URLs indicadas por el usuario, el descubrimiento de oEmbed, que exige al menos una cuenta de colaborador, y la lectura de feeds configurados por el administrador.
Patchstack advierte de una trampa habitual: el filtro xmlrpc_enabled no bloquea el pingback, porque este no necesita iniciar sesión. Y un cortafuegos de aplicaciones tampoco ayuda mucho, ya que la carga maliciosa no viaja en la petición que recibe la web, sino en la respuesta del servidor del atacante.
Qué puede pasar: caídas confirmadas, ejecución de código sin probar
El impacto confirmado en WordPress es la denegación de servicio. Una sola petición puede tumbar un proceso de PHP, y en el laboratorio una carga de menos de 100 bytes dejó un proceso al 100 % de CPU. La fuga de memoria y la ejecución remota de código no están demostradas en PHP: según Patchstack, existen cadenas de ataque públicas contra Node.js y Bun, pero ninguna contra PHP con Apache o PHP-FPM por ahora.
Hay un detalle que complica la revisión. Debian y Ubuntu corrigen el fallo sin cambiar el número de versión, así que una librería que dice ser la 1.1.0 puede estar parcheada o no. Patchstack recuerda además que la imagen oficial de Docker wordpress:latest todavía incluía, cuando publicó su análisis, un paquete libbrotli1 vulnerable.
Qué deberían hacer ya los responsables de webs WordPress
La prioridad es actualizar Brotli en el servidor: instalar la actualización de seguridad de libbrotli1 de la distribución o pasar a una versión corregida, comprobando la revisión del paquete y no solo el número de versión. En hosting compartido o gestionado, toca preguntar al proveedor si ya lo ha aplicado. Quien use Docker debe actualizar el paquete en su propia imagen hasta que se reconstruya la oficial.
Mientras tanto, Patchstack propone medidas temporales que no arreglan el fallo pero cierran puertas: eliminar el método pingback.ping de XML-RPC o bloquear xmlrpc.php en el servidor, desactivar la descompresión automática de libcurl con el hook http_api_curl o enviar las conexiones salientes a través de un proxy con lista blanca.
Para detectar intentos, conviene vigilar respuestas salientes con Content-Encoding: br, errores de segmentación en Apache o PHP-FPM, procesos bloqueados y peticiones POST a xmlrpc.php con pingbacks de orígenes desconocidos. Llega justo después del parche 7.1.4 y confirma que la seguridad de WordPress depende cada vez más de toda la pila del servidor.