Si recibió un correo electrónico mío que le remite a esta página, es porque su sitio web parece estar ejecutando una versión de Events Manager (el plugin de WordPress events-manager, de Marcus Sykes / wp-events-plugin.com) que cae dentro del rango afectado por un problema de seguridad conocido. Esta página explica en qué consiste el problema, cómo determinar si le afecta siquiera, y cómo actualizar.

Antes de nada, el dato más importante sobre este aviso: una versión dentro del rango afectado no significa por sí sola que su sitio esté expuesto. El problema descrito a continuación solo es explotable cuando Events Manager está configurado para aceptar reservas de visitantes que no han iniciado sesión (el “No-User-Account Booking Mode” del plugin, su modo de reserva sin cuenta de usuario). Si su sitio exige una cuenta para reservar, o no acepta reservas en absoluto, es muy probable que no esté expuesto ni siquiera en una versión afectada. Puedo leer la versión de su plugin a partir de archivos públicos, pero no puedo ver su configuración de reservas, por lo que se trata de un aviso preventivo, no de un hallazgo confirmado sobre su sitio.

El problema es CVE-2026-12987, una inyección de objetos PHP no autenticada que desemboca en una inyección SQL en el sistema de reservas del plugin. La autoridad que asignó el CVE no publicó una puntuación de gravedad; Patchstack valora ese mismo hallazgo en 8,8 sobre 10 (alta). Afecta a las versiones 4.0.0 hasta 7.3.6 y está corregido en 7.3.7. Si está ejecutando una versión afectada, actualice Events Manager a 7.3.7 o posterior (se recomienda la versión actual de la línea 7.4.x). No hay indicios de que este problema se esté explotando en ningún sitio.

Una palabra sobre la urgencia, porque este es el aviso más condicional que he enviado: cuánto le importa depende casi por completo de ese ajuste de reservas. Si las reservas de su sitio exigen iniciar sesión, actualizar es mantenimiento rutinario del plugin. Si su sitio sí acepta reservas públicas de visitantes sin cuenta, trate la actualización como una prioridad: en esa configuración, el fallo podría permitir a un atacante leer datos de la base de datos de su sitio (como hashes de contraseñas y claves secretas) sin iniciar sesión. Incluso entonces, esta página es un aviso preventivo, no un informe de incidente, y no implica ninguna respuesta de emergencia.

Este es un fallo de un plugin, no un fallo del núcleo de WordPress. Un WordPress totalmente actualizado no le protege si el propio plugin Events Manager está en una versión afectada.

¿Es legítimo este mensaje?

Sí. Se trata de un aviso de buena fe, según el principio de la divulgación responsable, de un investigador de seguridad independiente. No le pido dinero, contraseñas ni acceso a su sitio, y no he intentado entrar en él, subir nada ni explotar nada.

Lo único que hice fue mirar archivos visibles públicamente que su sitio web ofrece a cada visitante (del mismo modo que su página de inicio es pública) y anotar el número de versión que el plugin Events Manager publica en su archivo readme.txt público. En concreto, no toqué el sistema de reservas, y nada en esta comprobación toca sus datos, su área de administración ni ninguna parte privada de su sitio (hay más detalle en Qué hice y qué no hice más abajo).

Si desea verificar quién soy, consulte los datos de contacto al final de esta página y la página Acerca de.

Por qué importa

Events Manager es uno de los plugins de eventos y reservas más veteranos de WordPress (en el directorio oficial desde 2008, con alrededor de 6,3 millones de descargas a lo largo de su vida). Permite a un sitio publicar eventos y aceptar reservas para ellos, incluidas, si el operador lo decide, reservas de visitantes que no tienen una cuenta de usuario en el sitio.

En las versiones afectadas, cuando un visitante envía una reserva, los campos de registro personalizados que rellena se almacenan como datos de la reserva, y cuando el plugin carga después esa reserva desempaqueta (“deserializa”) los datos almacenados sin restringir lo que se les permite contener. Por tanto, una entrada especialmente diseñada puede convertirse en objetos de programa elegidos por el atacante (inyección de objetos PHP), y una cadena de tales objetos alcanza una consulta a la base de datos que no está correctamente parametrizada (inyección SQL). El efecto práctico en un sitio con la configuración vulnerable: un atacante sin cuenta y sin iniciar sesión podría leer datos arbitrarios de la base de datos del sitio, como hashes de contraseñas y las claves secretas que usa WordPress.

Dos cosas mantienen esto en perspectiva. Primero, el punto de entrada es el formulario público de reservas, así que el ataque solo funciona donde un visitante que no ha iniciado sesión puede enviar una reserva. Esa es exactamente la condición previa del “No-User-Account Booking Mode”: si reservar en su sitio exige una cuenta, la ruta vulnerable no es accesible para visitantes anónimos, y es muy probable que su sitio no esté expuesto ni siquiera en una versión afectada. Segundo, se trata de un problema de lectura de datos, no de una toma de control del servidor ni del administrador: no permite por sí solo a un atacante ejecutar código en su servidor ni entrar en su área de administración. Y, para repetirlo con claridad, no hay indicios de explotación activa: no figura en el catálogo de vulnerabilidades explotadas conocidas de CISA, su puntuación de probabilidad de explotación (EPSS) es casi nula, y no tengo constancia de informes de explotación.

Si mi correo citaba este problema, significa que la versión que informa su sitio cae dentro del rango afectado. No he probado si su sitio concreto es explotable, y no puedo ver cómo está configurado su sistema de reservas; lo único que observé es que el sitio informa de una versión afectada.

¿Estoy afectado?

Dos preguntas lo deciden, en este orden.

Primero: ¿acepta reservas de visitantes que no han iniciado sesión? Esta es la pregunta decisiva, y solo usted puede responderla.

  • Si las reservas de su sitio exigen una cuenta o un inicio de sesión, o su sitio no acepta reservas en absoluto, es muy probable que no esté expuesto, ni siquiera en una versión afectada. Aun así se recomienda actualizar, como mantenimiento ordinario.
  • Si su sitio acepta reservas de visitantes sin cuenta (Events Manager lo llama “No-User-Account Booking Mode”), el problema le afecta, y debería actualizar sin demora.
  • Para comprobarlo: en la administración de WordPress, busque en los ajustes de reservas de Events Manager la opción que permite reservas sin cuenta de usuario. O simplemente pruébelo desde fuera: abra una de sus páginas de evento en una ventana de navegación privada y vea si puede rellenar y enviar una reserva sin que se le pida iniciar sesión.

Segundo: ¿qué versión está ejecutando? No tiene que creer en mi palabra.

Desde el manifiesto público (sin necesidad de iniciar sesión): abra yourdomain.com/wp-content/plugins/events-manager/readme.txt en un navegador. Tenga en cuenta que este plugin distribuye su readme como readme.txt (en minúsculas). La línea Stable tag: cerca de la parte superior es la versión que informa su instalación, y este es el mismo archivo público que leí.

Desde el área de administración de WordPress (si tiene acceso):

  1. Inicie sesión en su panel de WordPress (normalmente en yourdomain.com/wp-admin).
  2. Vaya a Plugins luego Plugins instalados.
  3. Busque Events Manager y anote la versión que se muestra bajo su nombre.

Después aplique esta regla, y tenga en cuenta que las versiones se comparan de forma numérica, no alfabética:

  • 4.0.0 hasta 7.3.6: potencialmente afectada (sujeta a la cuestión del modo de reserva de más arriba), actualice ahora.
  • 7.3.7 o más reciente: ya corregida. Esto incluye 7.3.7.1, que fue una corrección posterior de una regresión de visualización sin relevancia para la seguridad, no una segunda versión de seguridad: tanto 7.3.7 como 7.3.7.1 contienen la corrección de seguridad. También incluye todas las versiones actuales de la línea 7.4.x.
  • Anterior a 4.0: no afectada por este problema. El tratamiento vulnerable de los datos de reserva apareció por primera vez en la reescritura 4.0 del plugin, así que las versiones anteriores no lo arrastran (una versión tan antigua tiene muchos otros motivos para actualizarse, pero este aviso no es uno de ellos).
  • No se deje engañar por el orden del texto: Events Manager usaba cadenas de versión como 5.99912 antes de 6.0 (el proveedor estuvo estancado en un esquema de numeración 5.999.x hasta 6.0), y una versión así es una versión antigua por debajo de 6.0, dentro del rango afectado, no algo más reciente que 7. Compare cada número por separado en lugar de leer la versión como texto.

Cómo actualizar

La vía más segura es actualizar a través del propio WordPress, y hacer antes una copia de seguridad:

  1. Haga una copia de seguridad de su sitio (archivos y base de datos) antes de realizar cambios. La mayoría de los proveedores de alojamiento ofrecen copias de seguridad con un solo clic, o use un plugin de copia de seguridad de WordPress.
  2. En la administración de WordPress, vaya a Escritorio luego Actualizaciones, o Plugins luego Plugins instalados. Si aparece una actualización de Events Manager, instálela desde aquí.
  3. Si prefiere la línea de comandos, WP-CLI hace lo mismo: wp plugin update events-manager.
  4. Si no aparece ninguna actualización, puede obtener la última versión directamente desde la página del plugin en el directorio de WordPress.org, Events Manager, y actualizar mediante Plugins luego Añadir nuevo plugin luego Subir plugin.
  5. Después de actualizar, confirme el nuevo número de versión (7.3.7 o posterior; se recomienda la versión actual de la línea 7.4.x) con los pasos anteriores, y compruebe que sus páginas de eventos y reservas funcionan con normalidad.

Ya que está en ello, conviene confirmar que el núcleo de WordPress y sus demás plugins están actualizados, ya que el mismo principio se aplica a todos ellos.

Después de actualizar

Actualizar a 7.3.7 o posterior cierra el problema, y para la mayoría de los sitios esa es toda la tarea. No hay indicios de que este fallo se haya explotado en ningún sitio, así que no se requiere una respuesta de emergencia: no necesita tratar su sitio como comprometido ni ponerlo fuera de línea.

Merece la pena plantearse un seguimiento, y está condicionado a la misma cuestión de las reservas. Si su sitio aceptaba reservas públicas de visitantes sin cuenta mientras estaba en una versión afectada, entonces los datos que el fallo podía alcanzar (el contenido de la base de datos, incluidos hashes de contraseñas y claves secretas) eran al menos teóricamente legibles, aunque no hay pruebas de que nadie lo hiciera. En ese caso, son sensatas dos precauciones rutinarias:

  • Eche un vistazo a las reservas y la actividad de usuarios recientes en busca de algo que parezca fuera de lugar, del modo habitual en que revisaría la actividad del sitio.
  • Rote los secretos que viven en su base de datos y su configuración: regenere las claves secretas y los “salts” de WordPress en wp-config.php (los nuevos valores están a un clic en el generador de claves secretas oficial; cambiarlos cierra la sesión de todos los usuarios una vez), y cambie la contraseña de su base de datos desde el panel de su alojamiento. Dado que los hashes de contraseñas estaban entre los datos teóricamente legibles, que las cuentas de administrador renueven sus contraseñas es un paso adicional razonable.

Trate esto como el mantenimiento de seguridad ordinario, no como una respuesta a incidentes. Si las reservas de su sitio siempre han exigido iniciar sesión (o no acepta reservas), actualizar por sí solo es suficiente.

Qué hice y qué no hice

Para ser totalmente transparente sobre la comprobación que hay detrás de mi correo: solo leí archivos públicos que su sitio ya ofrece a cada visitante, en concreto el archivo readme.txt público del plugin y su página de inicio. No accedí a su área de administración de WordPress, a su base de datos ni a ninguna parte privada del sitio. En particular, no toqué la ruta de reservas vulnerable, y no probé ni exploté nada.

Se trata de una observación basada en la versión: su sitio informa de una versión dentro del rango afectado. Como este problema depende de la configuración, un sitio en ese rango puede no estar expuesto en absoluto (si las reservas exigen iniciar sesión, o no se aceptan reservas), y también puede estar ya mitigado por otros medios, como un cortafuegos de aplicaciones web. Este aviso no es una afirmación de que su sitio fuera explotable en el momento en que lo comprobé.

No tengo webmaster / estoy atascado

Si usted no es la persona que mantiene el sitio, reenvíe esta página a quien lo haga (su desarrollador web, agencia o proveedor de alojamiento). Reconocerán los pasos anteriores con rapidez.

Si mantiene el sitio usted mismo y se atasca, con gusto le ayudo a orientarse en la dirección correcta sin coste alguno. Póngase en contacto usando los datos de abajo.

Contacto

Evan Harris, investigador de seguridad

Me pongo en contacto por problemas como este únicamente para ayudar a los operadores a asegurar sus sitios. Si prefiere que no se le vuelva a contactar, simplemente dígamelo y lo respetaré.

Referencias

Avisos oficiales y seguimiento

Proveedor / plugin