Saltar al contenido
← Blog
Blog · Seguridad WordPress

Hummingbird: RCE sin autenticación — actualizá a 3.21.2

WordPressPluginsSeguridad

Hummingbird Performance, el plugin de caché y optimización de WPMU DEV usado en más de 70.000 sitios, tiene una vulnerabilidad de ejecución remota de código (RCE) sin autenticación: CVE-2026-83627, con CVSS 9.8 (Critical). Reportada por el investigador Kuba vía el programa de bug bounty de Wordfence y divulgada el 4 de septiembre de 2026, permite a cualquier visitante anónimo inyectar y ejecutar PHP arbitrario en el servidor con un solo request.

Están afectadas todas las versiones hasta la 3.21.0 inclusive. El parche oficial es la 3.21.1 (liberada el 1 de septiembre de 2026) y la versión actual recomendada es la 3.21.2, que incluye hardening adicional para esta familia de problemas. Si usás Hummingbird, actualizá hoy.

Qué pasó

Wordfence divulgó el 4 de septiembre un hallazgo crítico en core/modules/class-page-cache.php del plugin. El problema es una cadena de dos errores que se combinan para terminar en RCE total. El vendor ya había liberado los parches el 1 de septiembre (3.21.1 y 3.21.2), por lo que la divulgación no dejó ninguna ventana sin fix disponible:

  1. El log de debug del page cache se escribe en un archivo PHP accesible por web: wp-content/wphb-logs/page-caching-log.php. El archivo debería estar neutralizado por una cabecera <?php inicial que impide ejecutar contenido como código.
  2. Esa protección nunca se aplica: el header está condicionado a class_exists('Filesystem'), que siempre devuelve false porque class_exists() resuelve nombres en el namespace global mientras que la clase real es Hummingbird\Core\Filesystem. Cuando el log se genera durante un request de front-end, queda escrito sin la cabecera protectora.
  3. El archivo vulnerable a inyección: get_cookies() escribe el nombre crudo de cualquier cookie con prefijo wphb_cache_ en ese archivo, sin sanitización. Un atacante manda una cookie con nombre wphb_cache_...=<?php ...código... ?> y el PHP termina dentro del archivo.
  4. Resultado: con un único request anónimo el atacante escribe PHP arbitrario y, pidiendo el archivo directamente por HTTP, lo ejecuta con todos los permisos del sitio — robo de credenciales, inyección de backdoors, desvío de pasarelas de pago o destrucción de la base de datos.

La condición previa es que el admin tenga habilitado Page Caching con la opción Debug Log (no es el default), pero ojo: el propio plugin puede llegar a ese estado solo, porque su cron diario de rotación de logs es capaz de quitar la cabecera protectora de un archivo ya existente.

Detalle técnico

CampoDato
CVECVE-2026-83627
Severidad / CVSSCrítica — 9.8 (AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H)
TipoCode Injection (CWE-94) → RCE
PluginHummingbird Performance – Cache & Page Speed Optimization
Versiones afectadas<= 3.21.0 (incluye 3.21.0)
Versión corregida3.21.1 (01-sep-2026); actual recomendada: 3.21.2
Requiere autenticaciónNo (unauthenticated)
Condición previaPage Caching + Debug Log habilitado (o alcanzable vía cron de rotación de logs)
Explotación activaNo confirmada al momento de publicación
Reportado porKuba (vía Wordfence Bug Bounty)

¿Te afecta?

El plugin tiene 70.000+ instalaciones activas y se usa mucho como alternativa gratuita de caché/preload. Te afecta si:

  • Tenés Hummingbird Performance 3.21.0 o anterior instalado (revisá Plugins → Plugins instalados en el admin de WordPress), o
  • Tenés una versión anterior y no sabés si el Debug Log del caché de páginas estuvo activo alguna vez — el estado vulnerable puede haberse alcanzado de forma no intencional tras un “Clear logs”, un flush de caché o rotación automática de logs.

Qué hacer ahora

  1. Actualizá YA: Plugins → Añadir plugins → Actualizaciones → actualizá Hummingbird a 3.21.2 (o instalalo manualmente desde wordpress.org). El parche está disponible desde el 1 de septiembre.
  2. Si ya estás en 3.21.1: subí igual a 3.21.2 — la 3.21.2 trae “Security hardening” adicional para esta familia de problemas.
  3. Verificá el archivo sospechoso: si existía antes de actualizar, revisá wp-content/wphb-logs/page-caching-log.php en busca de código PHP inyectado (contenidos tipo <?php eval(, base64_decode( o funciones letales). Si encontrás algo, asumí compromiso total del sitio: cambió administradores, claves de la base de datos y revisá los logs de acceso.
  4. Como defensa en profundidad: bloqueá el acceso web directo a wp-content/wphb-logs/ desde tu WAF o un bloqueo por .htaccess/regla de servidor. Es un directorio que ningún visitante necesita ver.
  5. Si no estás seguro de haber estado expuesto, escaneá el sitio con un plugin de seguridad (Wordfence o similar) y revisá los archivos modificados en los últimos 30 días.

TL;DR: RCE sin login en Hummingbird ≤ 3.21.0. El exploit es trivial (una cookie + un request) y el archivo vulnerable queda accesible por HTTP. Actualizá a 3.21.2 hoy y revisá si el log de debug existía antes.

Fuentes

¿Tu WordPress está caído, hackeado o querés protegerlo antes de que pase? Te ayudo a recuperarlo y blindarlo.

Solicitar diagnóstico