CVE-2026-7635: vulnerabilidad crítica en coreActivity

CVE-2026-7635 es una vulnerabilidad de inyección de objetos PHP descubierta en el plugin coreActivity: Activity Logging for WordPress, que afecta todas las versiones hasta la 3.0 inclusive. Un atacante sin autenticación puede inyectar un payload PHP serializado vía el header User-Agent, bloqueando de forma persistente el acceso al panel de logs para cualquier administrador del sitio.

Wordfence es un plugin de seguridad para WordPress que proporciona protección contra malware, ataques de fuerza bruta y vulnerabilidades mediante firewall, escaneo de código y monitoreo continuo. Desarrollado por Wordfence Inc.

Qué es CVE-2026-7635: vulnerabilidad crítica en coreActivity

CVE-2026-7635 es el identificador oficial asignado a una vulnerabilidad de deserialización de datos no confiables en el plugin coreActivity: Activity Logging for WordPress. Fue publicada el 13 de mayo de 2026 y recibió una puntuación CVSS v3.1 de 8.1 (Alto), con vector completo CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:H, según el registro de INCIBE-CERT.

Lo que la hace especialmente preocupante: no requiere credenciales. Cualquier visitante, bot o escáner que haga una solicitud al sitio puede activar el ataque.

El plugin coreActivity y por qué su falla duele

coreActivity es un plugin de auditoría y logging para WordPress. Registra eventos del sitio: intentos de login fallidos, cambios de configuración, actualizaciones de plugins, accesos de usuarios. Es, básicamente, la caja negra del sitio. Cuando algo sale mal, el administrador va ahí a ver qué pasó.

Eso crea un problema interesante con esta vulnerabilidad. El vector de ataque compromete precisamente la herramienta que usarías para detectar y analizar el ataque. Si alguien explota CVE-2026-7635 con éxito, vos intentás abrir el panel de logs para investigar y… no podés. El panel está roto. (Sí, en serio.)

El plugin está disponible en el repositorio oficial en GitHub y tiene presencia activa en el ecosistema de sitios WordPress que necesitan auditoría de eventos.

Cómo funciona el ataque: la cadena de explotación

Acá viene la parte técnica. La cadena de explotación tiene varios eslabones, y cada uno depende del anterior.

Todo arranca con el header HTTP User-Agent. Cuando alguien accede a tu WordPress, el plugin coreActivity registra el evento (por ejemplo, un intento de login fallido) junto con el User-Agent del visitante. El problema es que el plugin no valida ni sanitiza ese header antes de almacenarlo. Peor: lo guarda en la tabla logmeta sin ningún filtro sobre el contenido. Sobre eso hablamos en plugins que detectan esta vulnerabilidad.

Un atacante construye un payload PHP serializado, lo mete en el User-Agent y hace cualquier solicitud que dispare un evento loggeable. El payload queda guardado en la base de datos.

Después viene la segunda parte. Cuando un administrador abre la página de Logs, el plugin recupera los registros de la tabla logmeta y llama a maybe_unserialize() sobre cada valor de meta_value, sin verificar si el dato fue serializado por la propia aplicación o por un atacante externo. Esto ejecuta el payload.

En este caso específico, la deserialización pasa el valor a DeviceDetector::setUserAgent(), que espera una cadena de texto limpia. Al recibir un objeto PHP manipulado, dispara un Fatal TypeError. Ese error no es transitorio: se repite cada vez que el admin intenta cargar la página, creando una condición de Denegación de Servicio persistente. El panel de logs queda inutilizable.

¿Y qué pasó cuando intentaron acceder a los logs para diagnosticar el problema? Exacto, volvió a romperse.

Impacto real: bloqueo persistente del panel de administración

El impacto declarado es un DoS selectivo: afecta a los administradores que intentan acceder a la página de Logs, no al sitio en general. Los visitantes del front-end no notan nada. Otros usuarios del backend tampoco, siempre que no toquen los logs.

El CVSS refleja impacto alto en confidencialidad, integridad y disponibilidad. Eso puede parecer exagerado para un «simple» bloqueo de logs, pero tiene sentido: con los logs inutilizables, el administrador pierde visibilidad total sobre lo que pasa en el sitio. Si hay una intrusión en curso, no podés verla. Si alguien está probando credenciales por fuerza bruta, tampoco. La pérdida de disponibilidad del panel de monitoreo tiene consecuencias indirectas sobre todo lo demás. En herramientas especializadas en detección profundizamos sobre esto.

Además, la complejidad de acceso (AC:H) refleja que el atacante necesita que un administrador visite la página de logs para que el payload se ejecute, lo que añade una condición. Pero en sitios activos con administración regular, esa condición se cumple sola en horas o días.

Tabla: perfil de riesgo de CVE-2026-7635

Cómo verificar si tu WordPress está en riesgo

Primero lo primero: verificar la versión instalada.

• Entrá a tu panel de WordPress: Plugins → Plugins instalados.
• Buscá «coreActivity» en la lista.
• Fijate el número de versión que aparece debajo del nombre.
• Si ves 3.0 o cualquier número menor, estás en el rango vulnerable.
• Si ves «3.1» o superior, estás cubierto.

Si tenés acceso SSH al servidor o a la base de datos, podés revisar la tabla logmeta para detectar entradas con contenido serializado sospechoso en el campo meta_value. Un valor legítimo de User-Agent tiene texto plano. Si ves algo que arranca con O: o a: seguido de números y llaves, eso es serialización PHP y merece atención.

También podés revisar los logs del servidor web (Apache/Nginx) buscando solicitudes con User-Agent inusuales que contengan caracteres como {, O:, o serialize. No garantiza encontrar el payload, pero da una idea si hay actividad de escaneo reciente.

Actualizar coreActivity a versión segura: paso a paso

Si tu versión es vulnerable, el camino más directo es actualizar. Antes de hacer cualquier cosa, hacé un backup del sitio. WPVivid, UpdraftPlus, o un snapshot del servidor vía tu proveedor de hosting (si usás donweb.com u otro proveedor con snapshots) alcanza para tener un punto de restauración.

• Andá a Plugins → Plugins instalados.
• Buscá coreActivity y hacé clic en «Actualizar ahora» si aparece la notificación, o entrá a Escritorio → Actualizaciones para verlas todas juntas.
• Confirmá que después de la actualización la versión es 3.1 o superior.
• Accedé a la página de Logs del plugin para verificar que carga sin errores.

La versión 3.1 incluye validación adecuada del header User-Agent antes de almacenarlo, y verifica el origen del dato antes de llamar a maybe_unserialize(). El mecanismo de explotación queda bloqueado desde la raíz.

Si el panel de logs ya está bloqueado: opciones de recuperación

Ponele que llegaste tarde. El administrador ya visitó los logs, el Fatal TypeError se disparó, y ahora la página no carga. ¿Qué hacés?

Opción 1, la más limpia: desactivar el plugin directamente desde la base de datos o vía SSH/SFTP, sin pasar por el panel. Relacionado: el reporte de vulnerabilidades recientes.

• Vía SSH: navegá a wp-content/plugins/ y renombrá la carpeta coreactivity a coreactivity_disabled. WordPress lo desactiva automáticamente.
• Vía base de datos: en la tabla wp_options, encontrá la opción active_plugins y editá el valor para quitar la referencia a coreActivity.

Una vez desactivado, podés acceder al panel de WordPress normalmente. Limpiá los registros sospechosos en la tabla logmeta (borrá entradas con meta_value que contenga serialización PHP), actualizá el plugin a 3.1 y reactivalo.

Opción 2: restaurar desde backup. Si tenés un backup previo a la fecha en que llegó el primer payload (revisá la fecha de la entrada sospechosa en logmeta), restaurar es la opción más segura. Eliminás el problema de raíz, aunque perdés los logs del período.

Buenas prácticas para evitar vulnerabilidades de inyección de objetos PHP

CVE-2026-7635 es un caso de manual sobre qué no hacer con datos no confiables. Algunos puntos para tener en cuenta en tu stack WordPress:

• Nunca deserializés datos de origen externo sin validación previa. Los headers HTTP, parámetros GET/POST, y cookies son vectores de ataque. Si el dato no fue serializado por tu propia aplicación, no lo des por bueno.
• Usá JSON en lugar de serialización PHP para almacenar datos estructurados. json_encode() / json_decode() no ejecuta código arbitrario. unserialize() sí puede hacerlo.
• Sanitizá headers antes de loggearlos. Un User-Agent que va a guardarse en base de datos debe pasar por sanitización explícita: strip de caracteres no imprimibles, validación de longitud, exclusión de patrones de serialización.
• Revisá plugins de auditoría con regularidad. Paradoja molesta: los plugins de seguridad y logging son objetivos atractivos porque tienen acceso amplio al sistema y los administradores los consultan seguido.
• Mantené un programa de actualizaciones activo. La brecha entre publicación del CVE y explotación masiva se redujo en 2026. Ponele que tenés 24-48 horas antes de que los scanners automatizados encuentren tu instalación vulnerable.

Errores comunes al manejar esta vulnerabilidad

Error 1: Asumir que solo afecta sitios con mucho tráfico. El payload se inyecta en cualquier solicitud que dispare un evento loggeable, incluyendo un solo intento de login fallido. Un bot de escaneo que pasa una vez alcanza.

Error 2: Intentar acceder al panel de logs para «ver si ya pasó algo» antes de actualizar. Si hay un payload en la base de datos y accedés al panel sin parchear, ejecutás la deserialización y bloqueás el acceso. Primero actualizá (o desactivá el plugin), después revisá.

Error 3: Limpiar la tabla logmeta sin actualizar el plugin. Eliminar los registros maliciosos sin actualizar a 3.1 deja el vector de ataque abierto. En horas, un nuevo payload puede entrar por el mismo camino. La limpieza de datos y el parche del plugin van juntos, en ese orden: primero el parche, después la limpieza. Más contexto en estrategias de defensa en WordPress.

Si querés profundizar en esto, tenemos un análisis completo sobre CVE-2026-7635.

Para profundizar, revisá nuestro análisis de CVE-2026-7635.

Preguntas Frecuentes

¿Qué es CVE-2026-7635 y cómo afecta mi WordPress?

CVE-2026-7635 es una vulnerabilidad de inyección de objetos PHP en el plugin coreActivity (versiones hasta 3.0). Un atacante sin autenticación puede enviar un payload serializado en el header User-Agent durante cualquier evento loggeable. Cuando un administrador abre la página de Logs, el plugin ejecuta el payload mediante maybe_unserialize(), generando un error fatal que bloquea el acceso al panel de logs de forma permanente.

¿Cómo sé si estoy usando la versión vulnerable de coreActivity?

Andá a Plugins → Plugins instalados en tu panel de WordPress y buscá coreActivity. Si la versión es 3.0 o inferior, estás en el rango afectado. La versión 3.1 es la primera con el parche aplicado. Si no tenés coreActivity instalado, no te afecta este CVE.

¿Qué hacer si el panel de logs ya está bloqueado por esta vulnerabilidad?

Si el panel de Logs ya no carga, no intentes acceder de nuevo desde WordPress. Desactivá el plugin directamente renombrando su carpeta vía SSH (de coreactivity a coreactivity_disabled) o editando la opción active_plugins en la tabla wp_options. Con el plugin desactivado, limpiá los registros sospechosos en logmeta, actualizá a versión 3.1 y reactivá.

¿Cómo actualizo coreActivity a versión segura?

Desde el panel de WordPress: Escritorio → Actualizaciones, o Plugins → Plugins instalados → coreActivity → Actualizar. Antes de hacerlo, generá un backup completo del sitio. Después de actualizar, confirmá que la versión instalada es 3.1 o superior y accedé a la página de Logs para verificar que carga sin errores.

¿Cómo funcionan los ataques de inyección de objetos PHP?

PHP permite serializar objetos a texto para almacenarlos o transferirlos, y deserializarlos después para reconstruir el objeto original. El problema surge cuando se deserializan datos de origen externo sin validar su procedencia. Un atacante puede construir un objeto serializado con propiedades manipuladas que, al deserializarse, ejecutan código a través de métodos especiales de PHP (__wakeup, __destruct). En CVE-2026-7635, el payload pasa a DeviceDetector::setUserAgent(), que espera una cadena y recibe un objeto, generando un error fatal.

Conclusión

CVE-2026-7635 llegó publicada el 13 de mayo de 2026 con CVSS 8.1 y una mecánica que debería preocupar a cualquier administrador WordPress que use coreActivity. No solo porque permite un DoS desde el primer request, sino porque apaga exactamente la herramienta que usarías para detectar y responder al ataque. Es un vector que borra sus propias huellas bloqueando los logs.

El parche existe y está en la versión 3.1. Si usás coreActivity, actualizá hoy, no mañana. Si ya notaste que la página de Logs no carga o genera errores fatales, asumí que hay un payload en tu base de datos y seguí el procedimiento de recuperación: desactivar vía SSH, limpiar logmeta, actualizar, reactivar. En ese orden.

Esta vulnerabilidad es un recordatorio de que los plugins de auditoría y seguridad merecen el mismo nivel de atención en actualizaciones que el resto. Ponele que un plugin de logging mal parcheado es peor que no tener logging: te da la ilusión de visibilidad mientras un atacante opera a ciegas de tu parte.

Fuentes

• INCIBE-CERT — Registro oficial CVE-2026-7635 con vector CVSS y descripción técnica
• Patchstack — Base de datos de vulnerabilidades en plugins WordPress
• GitHub dev4press — Repositorio oficial del plugin coreActivity
• Wordfence Threat Intelligence — Base de datos de vulnerabilidades WordPress
• Vulnerabilidades WordPress semanales abril-mayo 2026 — Contexto del período