Résumé
Nous répondons à un incident de sécurité affectant PushEngage. Un attaquant a accédé à des identifiants de notre réseau de diffusion de contenu (CDN) et les a utilisés pour distribuer une version falsifiée du fichier JavaScript que ces produits livrent aux sites clients. Pendant une courte période, les sites qui intègrent notre script ont chargé ce fichier modifié directement depuis notre CDN.
Le code malveillant ne s'est activé que pour les administrateurs WordPress connectés. Lorsqu'il s'exécutait sur un site affecté, il tentait de créer un compte administrateur caché et d'installer un plugin de porte dérobée dissimulée, puis envoyait des données à un serveur contrôlé par l'attaquant. Les visiteurs ordinaires du site n'étaient pas ciblés, mais comme le code peut donner à un attaquant le contrôle d'un site, tout site affecté doit être considéré comme compromis.
Portée – ce qui a été et ce qui n'a pas été atteint :
Nos serveurs d'applications, notre code source et les systèmes qui stockent les informations de votre compte PushEngage sont hébergés séparément et n'ont pas été compromis. Nous n'avons aucune preuve que les données de compte ou les informations personnelles détenues par nous aient été consultées. La compromission s'est limitée à notre serveur de site Web marketing et, via une clé API CDN qui y était stockée, à notre compte CDN. Il est important de noter que cela ne réduit pas l'urgence pour les propriétaires de sites affectés : le fichier livré à votre site a été falsifié, c'est pourquoi les étapes ci-dessous sont toujours importantes si vous étiez dans la fenêtre d'exposition.
Qui doit agir maintenant : Si votre site avait PushEngage actif et qu'un administrateur était connecté pendant la fenêtre d'exposition ci-dessous, veuillez considérer votre site comme compromis et suivre [Ce qu'il faut vérifier et faire](#what-to-check-and-do) immédiatement. Les vérifications les plus fiables s'effectuent sur votre serveur, pas dans le tableau de bord WordPress.
Fenêtre d'exposition
D'après les journaux de notre fournisseur CDN, la configuration non autorisée avec des fichiers falsifiés était en place pendant environ plusieurs heures le 12 juin 2026 (UTC). Pour un sous-ensemble d'utilisateurs, elle a continué d'être servie jusqu'au 14 juin (UTC) depuis certains emplacements périphériques du CDN. Nous continuons de confirmer la période précise pendant laquelle le contenu affecté a été servi, et mettrons à jour cet avis à mesure que des détails supplémentaires seront vérifiés.
Seuls les sites qui ont chargé le script affecté avec un administrateur connecté pendant cette fenêtre ont pu être compromis.
Les fichiers affectés étaient les scripts d'intégration standard servis depuis :
- https://clientcdn.pushengage.com/sdks/pushengage-web-sdk.js (PushEngage)
- https://clientcdn.pushengage.com/sdks/pushengage-subscription.js (PushEngage)
Ce qui s'est passé
Un attaquant a exploité une vulnérabilité connue dans un plugin WordPress tiers (UpdraftPlus) pour accéder au serveur hébergeant notre site Web marketing. Ce serveur est entièrement séparé : hôte différent, infrastructure différente des serveurs d'applications qui exécutent PushEngage et qui stockent les données clients.
Sur le serveur marketing, l'attaquant a trouvé une clé d'API pour notre compte CDN. En utilisant cette clé, il n'a pas eu besoin de toucher notre origine d'application du tout. Il a modifié les fichiers que notre CDN servait, de sorte que le script falsifié a été livré aux sites qui l'intégraient pendant une période limitée avant que nous ne détectons et annulions le changement.
Nous avons depuis remédié le site marketing, l'avons migré vers un nouveau serveur et avons fait pivoter toutes les informations d'identification, y compris la clé d'API CDN.
Ce que le code malveillant a fait
Sur un site affecté, lorsqu'un administrateur connecté chargeait une page, le code tentait de :
- Confirmer qu'il s'exécutait dans un contexte d'administrateur WordPress, puis collecter les jetons de sécurité nécessaires pour agir en tant que cet administrateur.
- Créer un compte administrateur caché. Les comptes connus incluent developer_api1 ([email protected]) et des comptes aléatoires de la forme dev_xxxxxx.
- Installer un plugin de backdoor auto-dissimulant qui se cache du tableau de bord et expose un shell web non authentifié et un point de terminaison d'exécution de code — accordant effectivement un contrôle total du site.
- Envoyer les nouvelles informations d'identification et les détails du site à un serveur contrôlé par l'attaquant.
Étant donné que la backdoor se cache des écrans d'administration WordPress, le tableau de bord seul ne vous indiquera pas si vous êtes affecté. Les vérifications fiables se font sur le système de fichiers du serveur et via un scan côté serveur.
Ce qu'il faut vérifier et faire
Si vous aviez PushEngage en cours d'exécution sur votre site Web ET qu'un administrateur s'est connecté à votre site WordPress pendant la fenêtre d'exposition, faites ce qui suit dès que possible. Si vous n'êtes pas sûr qu'un administrateur était connecté, il est plus sûr de vérifier.
- Supprimez les comptes d'administrateur non autorisés. Recherchez developer_api1 / [email protected] et tous les comptes dev_xxxxxx inattendus, et supprimez-les.
- Vérifiez le système de fichiers – pas seulement le tableau de bord – pour la backdoor plugin. Sous wp-content/plugins, recherchez content-delivery-helper (« Content Delivery Helper ») ou database-optimizer (« Database Optimizer »). Le déguisement tourne, faites donc confiance à ce qui est sur le disque plutôt qu'à ce que montre le tableau de bord. Supprimez tout ce que vous trouvez.
- Exécutez un scan de logiciels malveillants côté serveur. Comme la charge utile ne s'exécutait que pour les administrateurs connectés, les vérifications du tableau de bord et côté client ne sont pas fiables ; un scan côté serveur est le moyen le plus fiable de trouver la backdoor ou toute autre modification.
- Si vous trouvez un indicateur ci-dessus, supposez une compromission complète et faites pivoter tout : mots de passe d'administrateur, clés d'application/API, informations d'identification de la base de données et vos clés/sels de sécurité WordPress dans wp-config.php. La backdoor a permis une exécution de code arbitraire, donc une persistance supplémentaire peut exister.
Si vous ne trouvez aucun de ces indicateurs et qu'aucun administrateur n'était connecté pendant la fenêtre, votre site est très probablement non affecté et aucune action n'est requise au-delà de l'hygiène standard (activer l'authentification à deux facteurs, maintenir les logiciels à jour).
Ce que nous avons fait jusqu'à présent
- Détection de la falsification et annulation immédiate des fichiers CDN affectés ; purge du cache CDN afin que des fichiers propres soient servis.
- Révocation et rotation de la clé d'API CDN et de toutes les informations d'identification associées.
- Remise en état du site marketing compromis et migration vers un nouveau serveur sur une infrastructure distincte.
- Confirmation que nos serveurs d'applications, notre code source et nos systèmes de données clients, qui se trouvent sur une infrastructure distincte, ne montrent aucune preuve d'accès.
- Mobilisation de notre équipe de sécurité et collaboration avec notre fournisseur de CDN pour obtenir les journaux de livraison.
Statut et risques en cours
Notre configuration CDN a été corrigée et les fichiers falsifiés ont été supprimés, les identifiants affectés ont été réinitialisés et le point d'entrée sur notre serveur marketing a été remis en état.
La remise en état de nos systèmes ne nettoie pas un site qui a déjà été compromis. Si votre site a été affecté pendant la fenêtre d'exposition, le compte administrateur non autorisé et le plugin de porte dérobée caché restent en place jusqu'à ce que vous les supprimiez en suivant les étapes ci-dessus. Nous vous recommandons d'agir rapidement. Nous mettrons à jour cette page si des informations supplémentaires pertinentes apparaissent.
Indicateurs de compromission
Pour les propriétaires de sites et les équipes de sécurité :
Comptes non autorisés :
- developer_api1 / [email protected] (compte opérateur corrigé)
- dev_xxxxxx / [email protected] (comptes aléatoires)
Masquages de plugins de porte dérobée (en rotation ; vérifiez le système de fichiers) :
- content-delivery-helper “Content Delivery Helper” v2.7.1
- database-optimizer “Database Optimizer” v2.9.4
Infrastructure de l'attaquant :
- tidio.cc (domaine d'apparence similaire — PAS le légitime tidio.com)
Chaînes uniques :
- jX9kM2nP4qR6sT8v (clé de chiffrement utilisée par le malware)
- WPM File Manager & Shell (interface de shell de porte dérobée)
Contact
Si vous avez des questions, besoin d'aide pour vérifier votre site ou si vous remarquez quelque chose d'inhabituel, contactez-nous à [email protected]. Nous donnons la priorité aux demandes liées à cet incident et nous mettrons à jour cette page.
La protection de nos clients est une priorité pour nous. Nous comprenons que cet incident puisse être préoccupant et nous regrettons toute perturbation qu'il a causée. Les informations ci-dessus reflètent notre enquête à ce jour, et nous mettrons à jour cette page au fur et à mesure que des détails supplémentaires seront confirmés.
