Wenn CDN-Abhängigkeiten zur Bedrohung werden: Lektionen aus einem Domain-Übernahme-Fall

Jede Website ist ein Flickwerk aus eigenem Code und Code, den wir vertrauen. Während Entwickler viel Energie in die Absicherung des ersten Teils stecken, bekommt der zweite oft kaum Aufmerksamkeit. Ein aktueller Vorfall zeigt, warum das ein Fehler ist.

Die Geschichte einer ungewollten Domain

Stell dir folgendes Szenario vor: Ein beliebter CDN-Dienst versorgt jahrelang Tausende WordPress-Seiten mit statischen Inhalten. Dann schließt er seine Pforten, wird aufgekauft, der Betrieb eingestellt – und irgendwann läuft auch die Domainregistrierung aus. Jemand anderes sichert sich die Domain. Und plötzlich kontrolliert dieser Fremde alle Subdomains, über die jemals Assets ausgeliefert wurden.

Genau das ist mit netdna-ssl.com passiert – die Asset-Domain hinter MaxCDN, einem Service, auf den viele WP Engine-Kunden für statische Inhalte setzten. Als MaxCDN von StackPath überniert und schließlich eingestellt wurde, ließ jemand die Domain verfallen. Im Juli 2025 wurde sie neu registriert.

Der neue Besitzer erhielt damit Kontrolle über wildcard DNS für den gesamten Namespace *.wpengine.netdna-ssl.com. Jede Hash-basierte Subdomain, die deine Seite noch referenziert? Kontrolliert von einem Fremden, der eine Instagram-Download-Seite mit Google AdSense betreibt.

Warum du dir Sorgen machen solltest

Vielleicht denkst du jetzt: „Na und? Das nutzt doch niemand mehr. Alte Infrastruktur." Aber genau hier versagt unsere Intuition.

Forscher fanden heraus, dass allein auf GitHub etwa 4.000 Dateien noch Verweise auf diese alten Domains enthalten. Und es handelt sich nicht um längst aufgegebene Repositories – Projekte wie Mozillas webxr-polyfill, aber auch Websites von Kong, Nextcloud, Yale Daily News und vielen anderen Organisationen laden noch immer Assets von diesen deprecated Endpoints.

Noch beunruhigender: Cloudflare Radar führt netdna-ssl.com unter den globalen Top 20.000 Domains. Das bedeutet: Echte Browser lösen diesen Namen in erheblichem Umfang auf. Das sind keine archäologischen Kuriositäten – das sind aktive, lebendige Abhängigkeiten.

Das Problem mit der geladenen Waffe

Was diese Situation besonders heikel macht: Aktuell sind die alten Asset-URLs im Grunde kaputt. Der neue Besitzer hat Cloudflare mit einem Standard-SSL-Zertifikat eingerichtet, das die Apex-Domain und einige Proxy-Subdomains abdeckt – aber nicht das Wildcard-Muster für die Legacy-Asset-Hosts. Wenn ein Browser versucht, ein Script oder eine Font von einer Subdomain wie xyz123.wpengine.netdna-ssl.com zu laden, scheitert der TLS-Handshake.

Kurzfristig schützt das die Nutzer. Der Browser blockiert den Inhalt, anstatt ihn auszuführen. Aber bedenke: Der Angreifer hat bereits vollständige DNS-Kontrolle. Er hat bereits Monetarisierungs-Infrastruktur am Laufen. Er hat bereits Hosting eingerichtet. Das Einzige, was zwischen dieser Situation und einer Katastrophe steht, ist ein einziger Schalter in Cloudflare's Advanced Certificate Manager.

Sicherheitsexperten nennen das eine „geladene Waffe" – eine Schwachstelle, die aktuell nicht ausnutzbar ist, aber mit minimalem Aufwand katastrophal werden kann.

Das kennen wir doch

Wenn dir dieses Szenario bekannt vorkommt, dann porque wir es im Juni 2024 mit polyfill.io erlebt haben. Eine Domain, der das gesamte Web vertraute, wechselte die Besitzer, und über 100.000 Sites belieferten plötzlich ihre Nutzer mit Code von jemandem mit völlig anderen Absichten. Das Vertrauensmodell zerbrach, weil wir „diese Domain hat immer sichere Inhalte geliefert" mit „diese Domain wird immer sichere Inhalte liefern" verwechselt haben.

Die unbequeme Wahrheit: Wir bauen unsere Sicherheit auf Domains auf statt auf Code. Wenn Domains den Besitzer wechseln, erbt jede Seite, die ihnen vertraute, die neuen Absichten – egal welche.

Was du jetzt tun solltest

Prüfe deine Abhängigkeiten sofort. Durchsuche Codebasen, Datenbanken und Dokumentation nach Verweisen auf deprecated oder Drittanbieter-CDN-Domains. Geh nicht davon aus, dass ein abgeschalteter Service auch bedeutet, dass seine Domains inaktiv sind.

Erwäge Self-Hosting für kritische Assets. Wenn eine Font, ein Script oder ein Stylesheet essentiell für deine Anwendung ist, zieh es auf deinen eigenen Server. Die geringen Infrastrukturkosten wiegen leicht gegen das Risiko, dass Browser deiner Nutzer Code von einer vertrauenswürdigen Quelle laden.

Implementiere Subresource Integrity (SRI). Wenn du Drittanbieter-CDN-Ressourcen nutzen musst, füge kryptografische Hashes zu deinen <script>- und <link>-Tags hinzu. SRI stellt sicher, dass selbst wenn ein Angreifer die Kontrolle über eine Domain erhält, er keinen modifizierten Code ausliefern kann, ohne deine Integritätsprüfungen zu brechen.

Überwache deine Supply Chain. Dienste wie Report URI und verschiedene CSP-Monitoring-Tools können dich benachrichtigen, wenn unerwartete Domains in deinen Sicherheitsberichten auftauchen. Richte diese Alerts ein und nimm sie ernst.

Das große Bild

Dieser Vorfall zeigt eine fundamentale Spannung in der modernen Webentwicklung: Wir bauen auf Vertrauen, aber wir prüfen dieses Vertrauen selten im Zeitverlauf. Eine Abhängigkeit, die letztes Jahr noch völlig sicher war, könnte nächstes Jahr Malware ausliefern, wenn die Domain die Hand wechselt.

Bei NameOcean sprechen wir oft über Domain-Sicherheit – DNSSEC, SSL-Zertifikate, Registrar-Locks. Aber Geschichten wie diese erinnern uns daran, dass die eigentliche Sicherheitsherausforderung nicht nur darin besteht, eigene Domains zu schützen. Es geht auch darum, sorgfältig zu überlegen, welchen Domains wir überhaupt vertrauen – und Systeme zu haben, die erkennen, wenn dieses Vertrauen möglicherweise fehl am Platz ist.

Das Web basiert auf Vertrauen. Stell sicher, dass deines weise platziert ist.