OptinMonster, TrustPulse, PushEngage : un vol de clé CDN transforme 3 plugins en porte dérobée

Une faille déjà connue dans un plugin de sauvegarde a permis à des attaquants de voler une clé d'API chez Awesome Motive, l'éditeur d'OptinMonster, et de s'en servir pour injecter du code malveillant directement dans les fichiers distribués par leur CDN à trois plugins : OptinMonster (1,2 million de sites), TrustPulse et PushEngage. Aucune mise à jour de plugin n'était nécessaire pour être touché : le code arrivait à chaque chargement de page, depuis l'extérieur. Si votre site utilise l'un de ces trois outils, une réparation de site WordPress piraté peut être nécessaire même si vous n'avez jamais cliqué sur "Mettre à jour".

OptinMonster, TrustPulse, PushEngage : trois plugins, un seul point de défaillance

Awesome Motive est l'éditeur derrière plusieurs outils marketing très utilisés sur WordPress : OptinMonster (popups et génération de leads, plus de 1,2 million de sites), TrustPulse (notifications de preuve sociale) et PushEngage (notifications push). Les trois partagent un point commun technique : ils chargent une partie de leur code JavaScript directement depuis l'infrastructure CDN de l'éditeur, plutôt que de l'embarquer entièrement dans le plugin installé sur chaque site.

Cette architecture est courante et généralement sans risque - elle permet de déployer des correctifs rapidement sans attendre une mise à jour de plugin. Mais elle déplace aussi le point de confiance : si l'infrastructure qui sert ces fichiers est compromise, chaque site qui charge ce script l'est aussi, instantanément, sans qu'aucune action de l'utilisateur n'entre en jeu.

La chaîne de compromission : d'UpdraftPlus au CDN d'Awesome Motive

C'est exactement ce qui s'est produit. Selon le rapport de Sansec, les attaquants ont exploité une vulnérabilité que nous avions documentée quelques jours plus tôt : la faille de contournement d'authentification d'UpdraftPlus (CVE-2026-10795). Cette faille a permis d'accéder à un serveur de l'environnement d'Awesome Motive qui hébergeait leur site web marketing - un serveur a priori sans rapport direct avec le code des plugins eux-mêmes.

Ce serveur stockait une clé d'API donnant accès au compte CDN de l'entreprise. Une fois cette clé volée, les attaquants ont modifié directement les fichiers JavaScript distribués par ce CDN : a.omappapi.com/app/js/api.min.js, a.opmnstr.com/app/js/api.min.js et a.optnmstr.com/app/js/api.min.js pour OptinMonster, a.trstplse.com/app/js/api.min.js pour TrustPulse, et clientcdn.pushengage.com/sdks/pushengage-web-sdk.js pour PushEngage.

Le mécanisme exact du script malveillant

Le code injecté dans ces fichiers JavaScript ne s'active pas pour tout le monde. Il commence par une série de vérifications d'évasion : il s'arrête immédiatement s'il détecte navigator.webdriver (signe d'un navigateur automatisé), un navigateur headless, ou une fenêtre de taille nulle - des techniques classiques pour éviter d'être repéré par des outils de sécurité automatisés ou des bots d'analyse.

Le script ne se déclenche que dans un contexte d'administration WordPress : présence de chemins wp-admin, de la barre d'administration, ou de cookies d'authentification. Une fois ce contexte confirmé, il tente de créer un compte administrateur via quatre méthodes de repli successives - le formulaire user-new.php, admin-ajax.php, et l'endpoint REST wp/v2/users - pour maximiser ses chances de réussite même si l'une des méthodes est bloquée. Les identifiants récupérés sont ensuite chiffrés en XOR puis encodés en base64 avant d'être envoyés au serveur de commande.

Ce que la porte dérobée installe sur votre site

Une fois un accès administrateur obtenu, le malware dépose silencieusement un plugin PHP conçu pour se masquer activement de l'interface d'administration, sous le nom "Content Delivery Helper" (version affichée : 2.7.1) ou "Database Optimizer" (version 2.9.4) - deux noms choisis pour paraître inoffensifs, voire utiles.

Ce faux plugin expose un véritable shell web : un paramètre ?developer_api1_fm permet d'exécuter des commandes système directement (system($_POST['cmd'])), et un second point d'entrée via developer_api1_eval exécute du code PHP arbitraire encodé en base64. Le canal de commande et contrôle utilise le domaine tidio.cc, enregistré le 28 avril 2026 - un nom choisi pour ressembler au widget de chat légitime Tidio - hébergé à l'adresse IP 84.201.6.54.

Les indicateurs de compromission à vérifier immédiatement

Chronologie de l'incident

• 1
  28 avril 2026

  Le domaine de commande et contrôle tidio.cc est enregistré et son certificat TLS émis, plusieurs semaines avant l'attaque elle-même.
• 2
  12 juin 2026, 22h17 UTC

  Première détection confirmée du code malveillant dans les fichiers JavaScript d'OptinMonster et TrustPulse servis par le CDN.
• 3
  13 juin 2026, 13h28 UTC

  Sansec publie son rapport d'alerte détaillant le mécanisme de l'attaque.
• 4
  13 juin 2026, 19h02 UTC

  Les fichiers JavaScript d'OptinMonster et TrustPulse sont nettoyés côté CDN. PushEngage continue de servir du code injecté.
• 5
  14 juin 2026, 8h44 UTC

  Le code malveillant est retiré du CDN de PushEngage.
• 6
  14-15 juin 2026

  Patchstack documente 271 tentatives de création de compte administrateur frauduleux sur 13 sites, majoritairement via l'endpoint REST wp/v2/users.
• 7
  15 juin 2026, 0h25 UTC

  Awesome Motive publie ses avis d'incident officiels, confirme la compromission et annonce la rotation de l'ensemble de ses identifiants, dont la clé d'API CDN.

Ce qu'il faut faire maintenant

Si vous utilisez plusieurs outils marketing tiers sur votre site et n'avez pas le temps de suivre chaque alerte de sécurité touchant leurs éditeurs, c'est exactement ce que couvre un contrat de maintenance WordPress : veille sur l'ensemble de votre stack logicielle, pas seulement sur les plugins installés localement.

FAQ - Attaque supply chain OptinMonster, TrustPulse, PushEngage

Le CDN compromis a-t-il été nettoyé ? Suis-je protégé maintenant ?

Oui, Awesome Motive a nettoyé les fichiers JavaScript servis par son CDN et a migré son infrastructure vers un nouveau serveur. Mais cela ne protège pas les sites déjà compromis pendant la fenêtre d'exposition : si une porte dérobée a déjà été installée sur votre site avant le nettoyage, elle y reste tant que vous ne l'avez pas supprimée manuellement.

Pourquoi cette attaque n'apparaît-elle pas dans les mises à jour du plugin ?

Parce que le code malveillant n'a jamais été distribué via une mise à jour de plugin. Les fichiers piégés étaient chargés directement depuis le CDN d'Awesome Motive à chaque visite, indépendamment de la version installée. Un site avec OptinMonster parfaitement à jour était exposé exactement comme un site avec une version ancienne.

Le backdoor reste-t-il actif si le CDN est nettoyé ?

Oui. Une fois installée sur votre site, la porte dérobée fonctionne de façon totalement indépendante du CDN. Le nettoyage du CDN empêche de nouvelles infections, mais ne supprime rien de ce qui est déjà installé sur les sites touchés avant cette date.

Quel est le lien avec la faille UpdraftPlus ?

C'est la cause racine de tout l'incident. Les attaquants ont exploité une faille critique d'UpdraftPlus (CVE-2026-10795) pour accéder à un serveur de l'environnement d'Awesome Motive qui hébergeait son site marketing. Ce serveur stockait une clé d'API CDN - c'est cette clé qui a été volée et utilisée pour l'attaque.

Comment le faux plugin échappe-t-il à la détection dans le tableau de bord ?

Le plugin malveillant masque activement sa présence dans la liste des extensions de l'administration WordPress, tout en restant pleinement fonctionnel sur le serveur. La vérification doit se faire directement dans le système de fichiers via FTP, pas en se fiant uniquement à ce qui s'affiche dans Extensions → Extensions installées.

La confiance se transmet, les failles aussi

Cet incident relie trois éditeurs, trois plugins et une faille déjà connue en une seule chaîne de compromission. Personne n'a eu besoin d'attaquer OptinMonster directement : il a suffi de trouver le maillon le plus faible de l'écosystème qui l'entoure, à savoir un serveur marketing protégé par un plugin de sauvegarde non corrigé.

La compromission du pipeline de build de ShapedPlugin et le rachat d'éditeurs de plugins légitimes documentés précédemment sur ce blog suivaient des mécanismes différents, mais racontent la même histoire : la confiance qu'on accorde à un plugin dépend de bien plus que son propre code. Elle dépend de la sécurité de chaque service tiers, chaque CDN, chaque serveur que cet éditeur utilise en coulisses - une chaîne dont la solidité se mesure à son maillon le plus faible, pas au plus solide.