El ataque a Brevo (Sendinblue): cómo un formulario de newsletter sirvió malware a más de 100.000 webs
Brevo, la plataforma de email marketing que antes se llamaba Sendinblue y que usan muchas pymes españolas para sus newsletters, sufrió el 14 de septiembre de 2026 un ataque a su cadena de suministro. Durante unas cinco horas, los scripts que sus clientes tienen pegados en su web (el formulario de suscripción, el chat y el código de seguimiento) sirvieron código malicioso a quien los visitaba. La firma de seguridad Sansec calcula que más de 100.000 webs cargaban esos scripts. Ninguna de esas empresas había hecho nada mal: el problema estaba en el proveedor.
Si su web usa Brevo y alguien de su equipo entró en el escritorio de WordPress el 14 de septiembre por la tarde, revise los plugins hoy. La puerta trasera que se instalaba no aparece en la lista normal de plugins.
Qué pasó
El origen fue una clave de acceso a Cloudflare, el servicio que Brevo usa para distribuir sus ficheros, que estaba escrita dentro del código fuente de Brevo, tenía permisos totales y no se cambiaba nunca. Alguien la obtuvo, probablemente a finales de agosto, y el 14 de septiembre la usó para colocar un pequeño programa en la red de Cloudflare que modificaba los ficheros de Brevo en el camino entre sus servidores y el navegador del visitante.
Por eso el ataque fue tan difícil de ver: los ficheros originales en los servidores de Brevo estaban limpios. Lo que llegaba al navegador, no. Además, el código malicioso eliminaba las cabeceras de seguridad que podrían haberlo delatado y se mantenía inactivo ante buscadores, escáneres automáticos y desarrolladores.
Cronología (hora peninsular)
| Hora | Qué ocurrió |
|---|---|
| Finales de agosto | Primer uso indebido de la clave robada, según Brevo, sin ataques a clientes |
| 14/9, 17:01 | El código malicioso empieza a servirse en brevo.com |
| 14/9, 18:07 | Se extiende a los scripts que los clientes tienen en sus webs y a los formularios |
| 14/9, 21:33 | Brevo abre el incidente de seguridad |
| 14/9, 22:30 | Brevo retira el código malicioso |
| 15/9 | Los dominios del atacante dejan de funcionar |
Qué veían los visitantes
El ataque tenía dos caras, según quién visitara la web:
- Visitantes normales: una pantalla completa que imitaba la comprobación «verifique que es humano» de Cloudflare. Pedía pulsar Windows + R, luego Control + V y después Intro. Es la técnica conocida como ClickFix: la página ha copiado antes un comando en el portapapeles, y esos tres pasos lo ejecutan. El comando descargaba malware en el equipo. Ni Brevo ni Sansec han publicado qué malware era.
- Administradores de WordPress con la sesión iniciada: no veían nada. El script aprovechaba su sesión para instalar y activar en segundo plano un plugin llamado «Web Media Optimizer», una puerta trasera que se copia en la carpeta mu-plugins y se oculta de la lista de plugins del escritorio.
También recibieron la trampa quienes pulsaron el enlace de baja de una newsletter de Brevo durante esas horas.
Qué revisar si su web usa Brevo
1. Confirme si su web cargaba scripts de Brevo
Busque en el código de su web, o en los plugins de WordPress, referencias a brevo.com, sendinblue.com o sibforms.com. Los afectados fueron tres: el formulario de suscripción, el chat (Brevo Conversations) y el cargador del código de seguimiento (sdk-loader.js). Si usa el plugin oficial de Brevo para WordPress, lo más probable es que cargara alguno de ellos.
2. Si tiene WordPress, busque la puerta trasera
- Entre por FTP o por el gestor de archivos del hosting y mire la carpeta wp-content/mu-plugins. Si existe y contiene algo que usted no instaló, es una mala señal. El escritorio de WordPress no muestra todo lo que hay ahí.
- Compare las carpetas de wp-content/plugins con la lista de plugins del escritorio. Cualquier carpeta que no aparezca en la lista merece una revisión.
- Si tiene acceso a los registros del servidor, busque en el 14 de septiembre peticiones a /wp-admin/update.php?action=upload-plugin seguidas de una activación de plugin.
Si encuentra el plugin, no basta con borrarlo. Cambie las contraseñas de todos los administradores de WordPress, del hosting, del FTP y de la base de datos, revise si hay usuarios administradores nuevos y, si puede, restaure una copia de seguridad anterior al 14 de septiembre.
3. Revise su cuenta de Brevo
Brevo asegura que su aplicación, su API, el envío de correos y los datos de las cuentas no se vieron afectados. Aun así, recomienda que quien entrara en brevo.com aquel día cambie la contraseña y revise sus claves de API. Es una tarea de diez minutos que conviene hacer.
4. Si alguien siguió las instrucciones del falso captcha
Trate ese ordenador como comprometido: desconéctelo de la red, analícelo con un antivirus actualizado o, mejor, reinstálelo, y cambie desde otro equipo las contraseñas que se usaran en él, empezando por el correo y la banca. Si tiene clientes que visitaron su web aquel día, valore con su asesor si corresponde avisarles.
No fue el único incidente de Brevo en septiembre
Cuatro días antes, el 10 de septiembre, un fallo en el inicio de sesión único (SSO) de Brevo permitió a unos atacantes entrar en 138 cuentas de clientes y enviar phishing desde ellas. El caso más conocido fue el del fabricante de carteras de criptomonedas Trezor, cuyos suscriptores recibieron falsas alertas de seguridad. Brevo no ha vinculado los dos incidentes y, por lo publicado, son independientes.
La lección: cada script de terceros es una puerta
Lo importante de este caso no es Brevo. Es que la línea de código que el proveedor le pide pegar en su web le da a ese proveedor, y a quien consiga suplantarlo, control total sobre lo que ven sus visitantes. Lo mismo vale para el chat, el píxel de publicidad, el widget de reseñas o el banner de cookies. Hay tres medidas que reducen mucho el riesgo:
- Menos scripts. Haga inventario de lo que carga su web desde fuera y quite lo que ya no use. Cada script que se elimina es un riesgo menos.
- Una política de seguridad de contenidos (CSP) estricta. Es una cabecera del servidor que indica al navegador desde qué dominios exactos puede cargar código. En este ataque, el código malicioso venía de dominios del atacante: una CSP bien cerrada lo habría bloqueado o, como mínimo, habría avisado.
- Integridad de subrecursos (SRI) cuando sea posible. Consiste en añadir a la etiqueta del script una huella del fichero: si alguien lo altera, el navegador se niega a ejecutarlo. Solo funciona con ficheros de versión fija, y muchos proveedores, Brevo incluido, sirven ficheros que cambian, pero conviene pedírselo y usarlo donde se pueda.
Una web estática, sin WordPress, elimina además la parte más dañina de este ataque: no hay escritorio de administración ni plugins que instalar a escondidas. En nuestro artículo sobre cómo pasar de WordPress a una web estática explicamos cuándo merece la pena.
Conclusión práctica
El ataque a Brevo duró unas horas y ya está resuelto, pero una puerta trasera instalada aquel día puede seguir hoy en su WordPress sin que nadie la vea. Si su web usa Brevo, dedique media hora a revisar la carpeta mu-plugins y a cambiar contraseñas. Y aproveche para preguntarse cuántos scripts de terceros carga su web y quién controla cada uno.
Si prefiere que lo revisemos nosotros, comprobamos su web, limpiamos lo que haga falta y dejamos configuradas las cabeceras de seguridad para que el próximo incidente de un proveedor no llegue a sus visitantes.
Fuentes
Información actualizada a 28 de octubre de 2026. Brevo da el incidente por resuelto desde el 28 de septiembre.
- BleepingComputer: el ataque a Brevo inyectó scripts ClickFix en webs de clientes
- SecurityWeek: malware en más de 100.000 webs
- Security Affairs: alcance del ataque
- Rescana: cronología, indicadores y recomendaciones
- gBlock: scripts afectados y plugin malicioso de WordPress
- Malwarebytes: el incidente previo con cuentas de Brevo (10/9)