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.

¿Tenés Hummingbird instalado?

La pregunta ya no es si sos vulnerable, sino si todavía no te comprometieron. Una auditoría revisa tu instalación real: qué versión corrés, si hay archivos modificados, usuarios admin que no creaste y qué queda abierto después de actualizar.

USD 150 · informe con plan de acción priorizado · pedí tu auditoría →

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