Mitte Juni 2026 wurde bekannt: Über eine kompromittierte CDN-Auslieferung wurden auf mehr als 1,2 Millionen WordPress-Seiten potenziell bösartige Skripte ausgeliefert – über drei weit verbreitete Plugins, die eigentlich völlig unauffällig sind: OptinMonster, TrustPulse und PushEngage [Patchstack, Sansec]. Das Besondere daran: Es gab keine klassische Sicherheitslücke in den Plugins selbst. Der Angriff lief komplett am Plugin-Code vorbei.
Ich finde diesen Fall aus mehreren Gründen bemerkenswert – und deshalb schreibe ich hier ausführlicher darüber, auch wenn du selbst keines der drei Plugins nutzt. Die Methode zeigt etwas Grundsätzliches darüber, wie verwundbar WordPress heute ist.
Was ist passiert
OptinMonster, TrustPulse und PushEngage gehören alle zum Anbieter Awesome Motive und laden im Frontend ein kleines JavaScript-SDK von einem eigenen CDN nach. Genau dort haben Angreifer angesetzt: Sie verschafften sich über eine Schwachstelle in einem Drittanbieter-Plugin (UpdraftPlus) auf der Marketing-Website von OptinMonster Zugriff auf einen CDN-API-Key – und nutzten diesen, um die ausgelieferten JavaScript-Dateien direkt am CDN-Rand zu manipulieren [OptinMonster, Sansec].
Kein Plugin-Update war nötig, keine Zeile Code auf der eigenen Seite wurde verändert. Trotzdem bekamen Besucherinnen und Besucher – genauer: eingeloggte Administratoren – bösartigen Code ausgeliefert, sobald sie eine Seite mit einem der drei Plugins besuchten. Betroffen waren laut Sansec folgende Dateien:
- a.omappapi.com/app/js/api.min.js, a.opmnstr.com/app/js/api.min.js, a.optnmstr.com/app/js/api.min.js (OptinMonster)
- a.trstplse.com/app/js/api.min.js (TrustPulse)
- clientcdn.pushengage.com/sdks/pushengage-web-sdk.js (PushEngage)
Der Angriffszeitraum: OptinMonster und TrustPulse waren zwischen 12. Juni, 22:17 Uhr UTC, und 22:42 Uhr UTC betroffen. Bei PushEngage hielt sich der manipulierte Code auf einzelnen CDN-Servern bis zum 13./14. Juni [Patchstack].
Warum das so gefährlich ist
Der eingeschleuste Code lief im Browser der eingeloggten Administratorin oder des Administrators – mit deren echter Session und einem gültigen Sicherheits-Nonce. Er prüfte zuerst, ob er es wirklich mit einer echten WP-Admin-Umgebung zu tun hat (Admin-Bar, wp-admin-Pfade, Login-Cookie), versuchte anschließend über die REST-API, das klassische Formular oder ein verstecktes iFrame einen neuen Administrator-Account anzulegen – und lud danach ein Backdoor-Plugin nach, das sich aktiv vor der eigenen Plugin-Liste versteckt [Patchstack].
Schonmal daran gedacht, dass ein vollständig aktuelles, sauber gepflegtes WordPress trotzdem kompromittiert werden kann? Genau das ist hier passiert. Die Sicherheitslücke lag nicht bei dir, sondern beim CDN eines Zulieferers – ein Ort, an den die meisten Sicherheits-Checks gar nicht hinschauen.
Bist du betroffen?
Prüfe zuerst, ob eines der drei Plugins bei dir aktiv ist oder war. Falls ja, und falls im Zeitraum um den 12.–14. Juni 2026 eine eingeloggte Administratorin oder ein Administrator die Seite besucht hat, solltest du die Installation manuell kontrollieren – ein einfaches Update der Plugins reicht nicht, um eine bereits erfolgte Kompromittierung zu beseitigen [Patchstack].
Konkret prüfen
- Benutzerliste im WP-Adminbereich: Gibt es einen Account „developer_api1” oder Namen nach dem Muster „dev_xxxxxx” (sechs zufällige Zeichen), meist mit einer @gmail.com-Adresse?
- Ordner wp-content/plugins/ direkt auf dem Server ansehen (nicht nur im Dashboard!) – nach Plugins namens „content-delivery-helper” oder „database-optimizer” suchen. Das Backdoor-Plugin blendet sich in der Oberfläche selbst aus.
- Im Code nach den Parametern developer_api1_fm und developer_api1_eval suchen.
- Einen serverseitigen Malware-Scan laufen lassen, der über bekannte Dateinamen hinausgeht.
Findest du etwas davon: Passwörter aller Administratoren zurücksetzen, API-Keys und Datenbank-Zugangsdaten erneuern, die Security-Keys in der wp-config.php austauschen und die Domain tidio.cc auf Netzwerkebene blockieren [Patchstack].
Was das grundsätzlich bedeutet
Ich prüfe bei meinen Wartungskunden regelmäßig, welche externen Skripte und CDN-Verbindungen tatsächlich noch gebraucht werden – nicht weil ich Awesome Motive für unseriös halte, sondern weil jedes zusätzliche Drittanbieter-Skript ein zusätzlicher Angriffspunkt ist, den man selbst nicht kontrolliert. Dieser Fall zeigt das ziemlich deutlich: Eine „saubere” WordPress-Installation schützt nicht vor einem kompromittierten Zulieferer.
Zum Thema WordPress-Sicherheit habe ich vor Kurzem auch grundsätzlicher geschrieben, warum reine Plugin-Updates allein nicht mehr reichen: WordPress-Sicherheit 2026: Warum Updates allein nicht reichen.
Häufige Fragen
Reicht ein Plugin-Update, um das Problem zu beheben?
Nein. Die betroffenen Anbieter haben die manipulierten CDN-Dateien inzwischen bereinigt, ein reguläres Plugin-Update war dafür gar nicht nötig. Wenn deine Seite im Angriffszeitraum kompromittiert wurde, bleibt ein eventuell angelegter Admin-Account oder ein Backdoor-Plugin trotzdem bestehen, bis du ihn manuell entfernst.
Ich nutze keines der drei Plugins – muss mich das trotzdem interessieren?
Direkt betroffen bist du nicht. Der Fall lohnt trotzdem einen Blick, weil er zeigt, wie Angriffe über Drittanbieter-CDNs grundsätzlich funktionieren – und das kann jedes Plugin treffen, das externen Code nachlädt.
Woran erkenne ich, ob meine Seite betroffen war?
Am zuverlässigsten über die Benutzerliste (verdächtige Accounts) und einen Blick direkt in den Plugin-Ordner auf dem Server, nicht nur ins Dashboard. Bei Unsicherheit empfehle ich einen serverseitigen Malware-Scan.
Falls du unsicher bist, ob deine Seite betroffen ist, oder einfach nicht selbst durch Logs und Plugin-Ordner graben willst: Ich schaue mir das im Rahmen der WordPress-Wartung gerne für dich an. Schreib mir einfach über die Kontaktseite.