Fremder Code auf deiner Seite

Auf einer durchschnittlichen Website läuft eine ganze Menge Code, der nicht von dort stammt. Ein Auswertungsskript, eine Kartendarstellung, ein Chat-Fenster, eine Schriftbibliothek, ein Bewertungs-Widget, ein Buchungssystem.

Jedes davon wird beim Aufruf von einem fremden Server geladen und im Browser deiner Besucher ausgeführt — mit denselben Rechten wie dein eigener Code. Es kann lesen, was auf der Seite steht, es kann die Seite verändern, es kann Formulareingaben mitlesen.

Dazu kommt die Ebene darunter: Plugins und Themes werden aus Quellen aktualisiert, die dir nicht gehören. Auch das ist fremder Code, nur mit noch weiterreichenden Rechten — direkt auf dem Server, mit Zugriff auf die Datenbank.

Die Größenordnung

Die Zahlen machen klar, wo das Risiko sitzt.

Im Jahr 2025 wurden im WordPress-Umfeld 11.334 neue Schwachstellen bekannt — 42 Prozent mehr als im Jahr davor.

Ihre Verteilung ist bemerkenswert:

• 91 Prozent in Plugins
• 9 Prozent in Themes
• Sechs in WordPress selbst, keine davon hochriskant

Das Risiko liegt also fast vollständig in dem, was man dazu installiert, nicht in der Software selbst.

Die Geschwindigkeit ist das eigentliche Problem. Der Median bis zur ersten massenhaften Ausnutzung liegt bei fünf Stunden. Und 46 Prozent der veröffentlichten Lücken hatten zum Zeitpunkt der Veröffentlichung noch gar keine Korrektur.

(Atlas, security/wordpress-attack-surface-2025-2026.md; threat-intel/patchstack-2026-state-of-wp-security.md)

Die Lieferkette ist inzwischen der Hauptweg

Der Angriff auf eine einzelne Website lohnt sich nicht. Der Angriff auf etwas, das auf hunderttausend Websites installiert ist, lohnt sich sehr.

Zwei Fälle aus dem April 2026 zeigen, wie das konkret aussieht:

Fall eins: Ein Anbieter hatte 31 Plugins aufgekauft. Im August 2025 wurde eine Hintertür eingebaut. Sie schlief acht Monate. Anfang April 2026 wurde sie für knapp sieben Stunden aktiviert. Über 20.000 Websites waren betroffen.

Fall zwei: Zeitgleich wurde der Aktualisierungsserver eines verbreiteten Slider-Plugins kompromittiert. Der Schadcode kam über den legitimen Aktualisierungskanal — also genau über den Weg, den man als sicher betrachtet. Über 800.000 Installationen.

Die Lehre daraus ist unbequem und schlicht: Wenn ein Plugin den Besitzer wechselt, ist das ein Ereignis in der Lieferkette.

Das Vertrauen, das man einem Plugin entgegenbringt, gilt dem Entwickler, der es gebaut hat, seiner Sorgfalt und seinem Ruf. Nach einem Verkauf gilt nichts davon automatisch weiter.

Praktisch heißt das: Bei einer Besitzerübernahme wird neu bewertet — genau wie beim ersten Mal. Wer ist der neue Anbieter? Was macht er sonst? Warum hat er gekauft?

Solche Übernahmen werden meist in einem Beitrag angekündigt, den kaum jemand liest. Es lohnt sich, bei Plugins, die auf vielen betreuten Websites laufen, auf solche Meldungen zu achten.

(Atlas, security/wordpress-supply-chain-attacks-2024-2026.md)

Kannst du erkennen, wenn sich ein Skript ändert?

Für eingebundene Dateien von fremden Servern gibt es dafür ein Verfahren: eine kryptografische Prüfsumme im HTML. Der Browser lädt die Datei, rechnet die Prüfsumme nach und führt sie nur aus, wenn sie stimmt.

<script src="https://cdn.example.com/bibliothek-3.2.1.js"
        integrity="sha384-…"
        crossorigin="anonymous"></script>

Was das erkennt: eine ausgetauschte Datei unter derselben Adresse — sei es durch ein kompromittiertes Auslieferungsnetz oder eine umgeleitete Anfrage.

Wofür es funktioniert: Dateien mit fester Adresse und fester Version. Eine Bibliothek, die auf Version 3.2.1 festgelegt ist, liefert bei jedem Abruf dieselben Bytes.

Wofür es prinzipiell nicht funktioniert — und das ist der wichtige Teil:

• Tag-Verwaltungssysteme. Sie stellen ihre Datei bei jedem Aufruf aus der aktuellen Konfiguration zusammen. Die Bytes sind bei jeder Anfrage andere. Es kann keine feste Prüfsumme geben.
• Adressen, die immer die neueste Fassung ausliefern. Sie ändern sich, sobald der Anbieter veröffentlicht.

Warum diese Unterscheidung wichtig ist: Solche Quellen sind ein bewusst eingegangenes Risiko, kein reparierbarer Mangel. Beides gleich zu melden wäre unehrlich — und praktisch schädlich, weil eine dauerhaft rote Zeile dazu führt, dass man die ganze Kategorie irgendwann überblättert.

Die richtige Frage bei solchen Quellen ist nicht „wie sichere ich sie ab", sondern „brauche ich sie".

(Atlas, security/subresource-integrity.md)

Die Kleinigkeit mit den neuen Fenstern

Ein Link, der sich in einem neuen Fenster öffnet, gibt der Zielseite eine Referenz auf das Fenster, aus dem er geöffnet wurde. Über diese Referenz kann die Zielseite die ursprüngliche Seite umleiten — der Besucher merkt es erst, wenn er zurückwechselt und dort etwas anderes vorfindet.

Die Absicherung ist ein Attribut:

<a href="https://example.com" target="_blank" rel="noopener">Zur Quelle</a>

Zur Einordnung: Moderne Browser wenden dieses Verhalten inzwischen von selbst an. Die ausdrückliche Angabe schadet nicht, hält die Absicht im Code fest und deckt die Fälle ab, in denen der Standard nicht greift.

Eine Variante, rel="noreferrer", unterbindet zusätzlich, dass die Herkunftsadresse übertragen wird.

(Atlas, security/subresource-integrity.md)

Der eine echte Notfall

Es gibt genau einen Befund an einer Website, der nicht „diesen Monat", sondern heute bearbeitet werden muss: ein Eintrag auf der Sperrliste, die die großen Browser gemeinsam nutzen.

Dann sehen Besucher statt deiner Website eine ganzseitige rote Warnung. Kein Besucher, keine Anfrage, kein Umsatz — und ein erheblicher Vertrauensschaden bei allen, die es sehen.

Der Umgang damit:

Das ist ein Vorfall, kein Optimierungspunkt. Die Reihenfolge:

1. Alle Zugangsdaten wechseln — WordPress, Datenbank, FTP, Hoster.
2. Dateien prüfen, insbesondere die Verzeichnisse, in denen Schadcode sich gern einnistet.
3. Aus einer bekannt sauberen Sicherung wiederherstellen. Hier zahlt sich eine lange Aufbewahrung aus: Wenn die Hintertür seit sechs Wochen liegt, ist die Sicherung von gestern ebenfalls betroffen.
4. Die Ursache finden.
5. Erst dann eine erneute Überprüfung beantragen.

Nur die Warnung wegklicken zu lassen, ohne die Ursache zu finden, führt regelmäßig zum zweiten Eintrag — und der wird schlechter behandelt als der erste.

Und umgekehrt eine Einordnung, die vor falscher Sicherheit bewahrt: Eine saubere Antwort ist kein Freibrief. Solche Listen melden, was bereits gefunden wurde. Eine frisch kompromittierte Website steht dort noch nicht.

Wie du das selbst prüfst

Die Liste der Dritten. Entwicklerwerkzeuge (F12), Reiter Netzwerk, Seite neu laden, nach Domain sortieren. Alles, was nicht deine eigene Adresse ist, ist ein Dritter. Schreib die Liste auf — es sind meistens mehr, als man erwartet.

Dann bei jedem Eintrag drei Fragen:

• Weiß ich, was das ist?
• Brauche ich das noch?
• Steht es in meiner Datenschutzerklärung?

Die dritte Frage verbindet dieses Thema mit dem Datenschutz: Dieselbe Liste beantwortet beide Fragen — welcher fremde Code läuft, und welche Empfänger die Datenschutzerklärung nennen muss. Zwei Pflichten, eine Liste.

Der Sperrlisten-Status. In der Google Search Console gibt es den Bereich „Sicherheitsprobleme". Steht dort nichts, ist an dieser Stelle alles in Ordnung.

Die Plugin-Ebene. Im Backend unter Plugins: Wann wurde zuletzt aktualisiert? Wird es noch gepflegt? Ein Plugin, das seit zwei Jahren kein Update bekommen hat, ist eine offene Rechnung.

Und einmal im Quelltext nach target="_blank" suchen — und schauen, ob rel dabeisteht.

Was zu tun ist

1. Reduzieren kommt vor Absichern. Jedes Skript, das du entfernst, musst du nicht mehr absichern. Das ist der wirksamste Schritt in diesem ganzen Feld — und er macht die Seite gleichzeitig schneller und die Datenschutzerklärung kürzer.

Bei fast jeder gewachsenen Website finde ich Zählpixel von Kampagnen, die vor Jahren liefen, und Widgets von Diensten, die längst gekündigt sind.

2. Automatische Aktualisierungen einschalten, wo es vertretbar ist. Bei fünf Stunden bis zur massenhaften Ausnutzung ist „ich mache die Updates am Monatsende" keine Strategie. Für kritische Bausteine, bei denen ein automatisches Update etwas kaputtmachen könnte, bleibt der geprüfte Weg über die Testumgebung — dann aber zeitnah.

3. Prüfsummen setzen, wo es geht: bei fest versionierten Bibliotheken von fremden Servern.

4. Bei den anderen die Frage stellen, ob sie sein müssen.

5. Die Liste der Dritten führen und zusammen mit der Datenschutzerklärung pflegen. Beides veraltet, wenn nur eines gepflegt wird.

6. Bei Besitzerwechseln neu bewerten.

7. Und eine Sicherung mit langer Aufbewahrung haben. Sie ist im Ernstfall der Unterschied zwischen einem halben Tag und einer Woche.

Was ich Kunden dazu sage: Die Frage ist nicht, ob man fremdem Code vertraut — ohne ihn ist eine moderne Website nicht zu bauen. Die Frage ist, wie vielen man vertraut. Fünf Dienste, die man kennt und pflegt, sind ein überschaubares Risiko. Zwanzig, von denen die Hälfte niemand mehr zuordnen kann, sind es nicht.

Quellen

• Atlas, security/wordpress-attack-surface-2025-2026.md — 11.334 neue Schwachstellen im WordPress-Umfeld im Jahr 2025 mit einem Zuwachs von 42 Prozent, die Verteilung mit 91 Prozent in Plugins, 9 Prozent in Themes und sechs im Kern ohne hochriskante darunter, der Median von fünf Stunden von der Veröffentlichung bis zur massenhaften Ausnutzung, der Anteil von 46 Prozent ohne Korrektur zum Veröffentlichungszeitpunkt, die Lieferkette als vorrangiger Angriffsweg, und automatische Aktualisierungen als Konsequenz aus der Fünf-Stunden-Spanne.
• Atlas, security/wordpress-supply-chain-attacks-2024-2026.md — der Vorfall vom April 2026 mit 31 aufgekauften Plugins, der im August 2025 eingebauten und acht Monate schlafenden Hintertür, ihrer Aktivierung für 6 Stunden 44 Minuten am 5. und 6. April 2026 und über 20.000 betroffenen Websites; die zeitgleiche Kompromittierung des Aktualisierungsservers eines verbreiteten Slider-Plugins mit Auslieferung des Schadcodes über den legitimen Aktualisierungsweg an über 800.000 Installationen; die Einordnung einer Plugin-Übernahme als Lieferkettenereignis mit der Notwendigkeit einer erneuten Vertrauensbewertung; und die Prüfsummen-Absicherung fremd eingebundener Skripte als Verteidigung.
• Atlas, security/subresource-integrity.md — das Prüfsummen-Attribut mit Algorithmuspräfix und Digest, die Notwendigkeit der Herkunftsangabe bei fremden Servern, das Blockieren bei Abweichung, was die Prüfung erreicht (fest versionierte Dateien, eigene Ressourcen, ausgetauschte Dateien unter derselben Adresse), die Auslieferungsmuster außerhalb ihrer Reichweite (pro Anfrage zusammengesetzte Dateien von Tag-Verwaltungssystemen, Adressen mit rollender Version) und die daraus folgende Einordnung als bewusst akzeptiertes Risiko statt reparierbaren Defekt samt der Begründung über dauerhaft rote Befunde, sowie noopener und noreferrer mit dem heutigen Browserstandard und dem Grund, die Beziehung trotzdem anzugeben, und die Inventarliste fremder Herkünfte mit ihrer Doppelfunktion für die Datenschutzerklärung.
• Atlas, threat-intel/patchstack-2026-state-of-wp-security.md — die Jahreszahlen 2025 und die Empfehlung einer Sicherungsaufbewahrung von 30 Tagen, damit eine kompromittierte Website auf einen Stand vor der Kompromittierung zurückgesetzt werden kann.
• Eigene Checkliste technisches-seo — keine Schadsoftware-Warnungen in der Search Console als Prüfpunkt sowie regelmäßige Sicherheits- und Plugin-Aktualisierungen.
• Eigene Prüfpraxis — die Vorgehensweise beim Sperrlisten-Vorfall in fünf Schritten mit dem Hinweis auf den zweiten Eintrag, die Einordnung einer sauberen Sperrlisten-Antwort als kein Freibrief, der Hinweis auf regelmäßig gefundene Zählpixel und Widgets aus beendeten Kampagnen, die Doppelnutzung der Diensteliste für Sicherheit und Datenschutzerklärung, und die abschließende Einordnung nach Anzahl statt Vorhandensein fremder Dienste.