Een aanvaller heeft geknoeid met vertrouwde JavaScript-bestanden die worden gebruikt door actieve WordPress-sites PushEngage, OptinMonsterEn TrustPulsewaardoor deze bestanden een manier worden om in te breken op de sites.
Toen een sitebeheerder was ingelogd terwijl het bestand werd geladen, maakte de code een beheerdersaccount aan onder controle van de aanvaller en installeerde een verborgen plug-in die een weg terug naar binnen opende. Gewone bezoekers activeerden deze niet.
Elke site die werd getroffen, moet als gecompromitteerd worden behandeld. Alle drie de plug-ins worden beheerd door één bedrijf, Awesome Motive, dat vanaf 15 juni geen commentaar had gegeven op de twee grotere plug-ins.
Beveiligingsbedrijf Sansec maakte de bredere campagne op 13 juni bekend en ontdekte dat dezelfde kwaadaardige code in JavaScript voor alle drie de plug-ins werd gebruikt.
PushEngage volgde een dag later met zijn eigen incidentmelding, waarin werd bevestigd dat een aanvaller geknoeide kopieën van zijn script had aangeboden en dat sites die deze laadden, konden worden overgenomen.
PushEngage, jaren geleden overgenomen door Awesome Motive, is tot nu toe de enige van de drie die richtlijnen geeft; OptinMonster- en TrustPulse-gebruikers hebben niets officieels gehoord.
Het venster was niet voor elke plug-in hetzelfde. Sansec zag de kwaadaardige code in OptinMonster en TrustPulse slechts ongeveer 25 minuten op 12 juni, eerst rond 22:17 UTC en verdwenen om 22:42 uur. De blootstelling van PushEngage duurde langer: enkele uren op 12 juni, en het script werd tot 14 juni nog steeds geserveerd vanaf een aantal CDN-servers.
Dus de twee plug-ins met de meeste sites hadden het kleinste venster, en PushEngage het grootste.
Sansec schat dat de drie plug-ins samen meer dan 1,2 miljoen sites bereiken, het grootste deel van OptinMonster, dat alleen al meer dan een miljoen actieve installaties heeft. De WordPress-plug-in van PushEngage heeft meer dan 9.000. Dat cijfer is bereik, geen schade: het telt sites waarop de plug-ins draaien, niet sites waarop is ingebroken.
Hoe de aanval werkte
Het vergiftigde script deed niets bij een normale paginaweergave. Het werkte alleen wanneer een ingelogde WordPress-beheerder het laadde, en gebruikte vervolgens de sessie van die beheerder om het over te nemen.
Dat ontwerp is ook de reden waarom het WordPress-dashboard je niet kan vertellen of je bent geraakt: de achterdeur is gebouwd om buiten de beheerdersschermen te blijven, dus de enige betrouwbare controle vindt plaats op de server zelf.
In het geval van PushEngage waren de bestanden waarmee werd geknoeid de normale embeds, pushengage-web-sdk.js en pushengage-subscription.js, aangeboden vanaf clientcdn.pushengage.com, het content-delivery-netwerk dat het script van PushEngage naar klantensites pusht. OptinMonster en TrustPulse werden getroffen via afzonderlijke Awesome Motive CDN-eindpunten.
PushEngage zegt dat de rest van zijn systemen onaangeroerd is gebleven: er is geen teken gevonden dat de hoofdapplicatie of de servers met klantgegevens zijn bereikt.
Volgens het eigen account van PushEngage, zodra het script werd uitgevoerd terwijl een beheerder was ingelogd,:
- gebruikte de sessie van die beheerder om met volledige machtigingen te handelen,
- een nieuw beheerdersaccount aangemaakt onder controle van de aanvaller,
- een plug-in geïnstalleerd die niet in het dashboard verschijnt, en
- stuurde de nieuwe inloggegevens en site-informatie naar tidio(.)cc, een nepdomein dat eruitzag als het echte tidio.com.
Sansec vond dezelfde volgorde voor alle drie de plug-ins. Het tidio(.)cc-domein werd op 28 april, weken voor de aanval, geregistreerd, wat wijst op een geplande operatie en niet op een snelle inbraak.
De verborgen plug-in is de echte prijs. Het opent een zogenaamde webshell, een extern commandokanaal: iedereen die de juiste URL kent, kan code op de server uitvoeren zonder in te loggen. Van daaruit kan de aanvaller elk bestand lezen of wijzigen, de database kopiëren, meer backdoors plaatsen, card-skimming-code injecteren, bezoekers omleiden of gegevens stelen.
Het extra beheerdersaccount is een eenvoudige manier om terug te keren als u de plug-in verwijdert maar het account mist. En omdat de aanvaller vrijelijk code kan uitvoeren, is het verwijderen van de genoemde plug-in en het account mogelijk niet voldoende; zowel Sansec als PushEngage zeggen te veronderstellen dat er nog andere achterdeurtjes kunnen blijven bestaan.
Hoe de aanvaller binnenkwam
Dit is het deel waarover de twee accounts het niet eens zijn. PushEngage zegt dat de aanvaller eerst heeft ingebroken in de server waarop de marketingwebsite draait, via een bekende fout in Opwaartse luchtstroomPluseen WordPress-back-upplug-in. Die server staat los van de systemen waarop het product draait en klantgegevens worden opgeslagen.
Wat er toe deed was niet de server zelf, maar een sleutel die erop zat: een CDN API-sleutel. Met die sleutel hoefde de aanvaller niet in te breken in de hoofdsystemen van PushEngage. Het kon eenvoudigweg de bestanden wijzigen die het CDN al aan klantensites leverde.
Sansec is er niet van overtuigd dat het instappunt rond is. Er staat dat het geschonden systeem nog steeds onbekend is, met de eigen servers van Awesome Motive als meest waarschijnlijke plaats, het CDN-account mogelijk en de CDN-provider, BunnyNet, onwaarschijnlijk.
De publieke analyse van Sansec onderzoekt of onderschrijft de UpdraftPlus-theorie niet; dat account komt alleen van PushEngage, over zijn eigen omgeving. UpdraftPlus heeft een aparte bug voor het omzeilen van authenticatie, CVE-2026-10795, die door Wordfence met een 8,1 wordt beoordeeld (hoge ernst); het is nu gepatcht en Wordfence heeft aanvallen gemeld, dus iedereen die UpdraftPlus gebruikt, zou hoe dan ook moeten updaten.
Of de bug iets met deze inbraak te maken heeft, is niet bevestigd. Behandel het toegangspunt als onrustig.
Wat u moet controleren en doen
Volgens de tijdlijn van Sansec waren de OptinMonster- en TrustPulse-bestanden op 13 juni schoon, terwijl het script van PushEngage tot 14 juni op sommige CDN-servers bleef hangen. PushEngage zegt dat het nog steeds aan het exacte venster werkt en sindsdien de slechte bestanden heeft vervangen, de CDN-cache heeft gewist, de CDN-sleutel en alle bijbehorende inloggegevens heeft gewijzigd en de marketingsite naar een nieuwe infrastructuur heeft verplaatst.
Niets van dat alles ruimt een site op die al is overgenomen.
Omdat de achterdeur zich voor het dashboard verbergt, kun je een compromis niet uitsluiten door naar WordPress te kijken. Als uw site tijdens de dreigingsperiode een van de drie plug-ins heeft uitgevoerd, is het enige betrouwbare antwoord een scan op de server.
Probeer het niet op te lossen door te raden of u ingelogd was; de meeste eigenaren kunnen dat hoe dan ook niet bewijzen. Beschouw de onderstaande stappen als de basislijn.
- Voer een serverscan uit. Iedereen die PushEngage, OptinMonster of TrustPulse actief had tijdens deze periode, zou de server rechtstreeks moeten scannen. Bij een browser- of dashboardcontrole wordt een payload over het hoofd gezien die alleen werd uitgevoerd voor ingelogde beheerders. (Sansec zag dezelfde payload op alle drie de plug-ins, maar heeft niet bevestigd dat OptinMonster en TrustPulse op dezelfde manier of in hetzelfde venster werden geleverd als PushEngage.)
- Controleer het bestandssysteem, niet het dashboard. Zoek onder wp-content/plugins naar mappen met de naam content-delivery-helper (“Content Delivery Helper”) of database-optimizer (“Database Optimizer”). Vertrouw op wat er op de schijf staat. Verwijder alle beheerdersaccounts die u niet heeft gemaakt, vooral developer_api1 of iets dat overeenkomt met dev_xxxxxx.
- Controleer uw logboeken. Bekijk de toegangslogboeken van de webserver van 12 juni tot 14 UTC voor uitgaand verkeer naar tidio.cc, inclusief de /cdn-cgi/-paden, en naar de server van de aanvaller op 84.201.6.54.
- Als je iets vindt, ga dan uit van het ergste. Roteer alles: beheerderswachtwoorden, API-sleutels, databasegegevens en de geheime sleutels (salts) in wp-config.php. Als de code op de server wordt uitgevoerd, kan er meer persistentie overblijven.
