Bei der aktuellen Angriffswelle gegen Ghost CMS ist nicht nur die Schwachstelle interessant, sondern die Rolle, die das kompromittierte System danach spielt. Ausgenutzt wird eine als kritisch beschriebene SQL-Injection-Lücke mit der Kennung CVE-2026-26980. Über sie schleusen Angreifer bösartigen JavaScript-Code in betroffene Ghost-Instanzen ein. Dieser Code stößt anschließend ClickFix-Abläufe an.
Das klingt zunächst nach einem klassischen CMS-Vorfall: Eingabe nicht ausreichend geprüft, Datenbankabfrage manipulierbar, fremder Code landet dort, wo er nicht hingehört. Operativ ist der Fall aber unangenehmer. Ein kompromittiertes Content-Management-System ist kein isolierter Serverfehler. Es ist eine Ausspielplattform. Wer dort JavaScript unterbringt, berührt nicht nur die Infrastruktur des Betreibers, sondern auch die Besucher, Redakteure, Admins und alle eingebetteten Vertrauensbeziehungen rund um die Website.
SQL Injection als Einstieg, JavaScript als Hebel
SQL Injection gehört zu den ältesten Fehlerklassen im Web. Trotzdem bleibt sie relevant, weil sie an einer besonders empfindlichen Stelle ansetzt: zwischen Anwendung und Datenbank. Wenn eine Anwendung Nutzereingaben so verarbeitet, dass sie Datenbankbefehle verändern können, wird aus einer normalen Anfrage ein Werkzeug für Manipulation. Je nach Anwendung kann das bedeuten: Daten auslesen, Inhalte verändern, Konfigurationen beeinflussen oder Code indirekt in Seiten platzieren.
Im hier beschriebenen Fall geht es um Ghost CMS und CVE-2026-26980. Die Angreifer nutzen die Schwachstelle nicht nur für Zugriff, sondern zur Platzierung von JavaScript. Das ist ein wichtiger Unterschied. Der Schaden endet nicht bei der Datenbank. Die kompromittierte Website wird zum Träger einer zweiten Angriffsstufe. Der Besucher sieht möglicherweise eine vertraute Seite, der Browser lädt aber zusätzlich fremden Code.
Für Verteidiger ist das eine ungünstige Lage. Eine Website kann äußerlich unverändert wirken. Inhalte, Layout, Domain, Zertifikat: alles sieht aus wie erwartet. Die Veränderung steckt in einem Script, in einem Eintrag, in einer ausgelieferten Ressource. Solche Manipulationen fallen selten durch offensichtliche Defacements auf. Sie fallen durch Telemetrie, Content-Integritätsprüfungen, ungewöhnliche Requests oder Hinweise von Dritten auf.
Warum ClickFix in diesem Kontext gefährlich ist
ClickFix-Angriffe setzen nicht primär auf eine technische Ausnutzung im Browser, sondern auf gelenkte Nutzeraktionen. Der Nutzer wird dazu gebracht, ein angebliches Problem zu beheben, eine Anweisung zu kopieren, etwas auszuführen oder einem vermeintlichen Reparaturschritt zu folgen. Die technische Schwachstelle liefert dabei die Bühne. Die eigentliche Wirkung entsteht durch Social Engineering.
Genau deshalb passt kompromittiertes JavaScript in einem CMS so gut zu diesem Muster. Eine bekannte Website verleiht dem Angriff Glaubwürdigkeit. Der Hinweis erscheint nicht auf einer offensichtlich dubiosen Domain, sondern im Kontext einer Seite, die der Nutzer möglicherweise kennt oder über eine Suchmaschine erreicht hat. Das senkt die Skepsis. Für Angreifer ist das wertvoller als ein weiteres Phishing-Template auf Wegwerf-Infrastruktur.
ClickFix ist zudem schwerer sauber zu klassifizieren als ein direkter Exploit. Ein klassischer Malware-Download lässt sich blockieren. Eine verdächtige Datei kann signaturbasiert erkannt werden. Bei ClickFix verschiebt sich der Angriff in eine Grauzone aus Webinhalt, Nutzerführung und lokaler Aktion. Technische Kontrollen greifen dort nicht immer an der ersten Stelle. Sie müssen Browser, Endpoint, Skriptausführung, Zwischenablage, Kommandozeilenaufrufe und Nutzerkontext zusammendenken.
Das CMS als Lieferkette im Kleinen
Bei CMS-Schwachstellen wird oft zu eng auf den einzelnen Betreiber geschaut. Natürlich muss dieser patchen, prüfen, bereinigen. Aber ein populäres CMS ist auch Teil einer kleinen Lieferkette. Agenturen betreuen mehrere Instanzen. Themes und Plugins werden wiederverwendet. Admin-Zugänge liegen bei Dienstleistern. Inhalte werden in Newsletter, Social-Kanäle oder Partnerseiten eingebettet. Eine Manipulation in einem CMS kann deshalb mehr Reichweite bekommen, als die einzelne Website vermuten lässt.
Ghost CMS wird von Publikationsprojekten, Unternehmen und unabhängigen Medien genutzt. Gerade solche Systeme besitzen ein Grundvertrauen: Wer dort liest, erwartet Inhalt, nicht Interaktion mit Sicherheitsanweisungen. Wenn ein Angreifer diesen Kontext für ClickFix missbraucht, wird redaktionelle Infrastruktur zur Täuschungsfläche.
Das ist kein exklusives Ghost-Problem. Die Lehre ist breiter: Jede Webanwendung, die Inhalte aus Datenbankfeldern ausliefert und Script-Ausführung zulässt oder nicht ausreichend begrenzt, kann bei einer Injection-Schwachstelle zur Verteilinstanz werden. Content Security Policy, Eingabevalidierung, Output-Encoding und saubere Rechte in der Datenbank sind deshalb keine dekorativen Härtungsmaßnahmen. Sie entscheiden darüber, ob ein Fehler lokal bleibt oder in die Browser der Besucher weitergereicht wird.
Was Betreiber jetzt nüchtern prüfen sollten
Für Betreiber betroffener oder potenziell betroffener Ghost-Installationen steht zuerst die Bestandsaufnahme an: Welche Instanzen laufen? Welche Versionen? Welche externen Themes, Integrationen und administrativen Zugänge sind aktiv? Danach folgt die Suche nach unautorisierten Script-Einträgen, veränderten Templates, auffälligen Datenbankinhalten und ungewöhnlichen ausgehenden Requests. Auch Logs rund um den Beginn der Kampagne sind wichtig, sofern sie noch vorhanden und belastbar sind.
Eine reine Entfernung sichtbarer JavaScript-Fragmente reicht nicht. Wenn die SQL-Injection tatsächlich ausgenutzt wurde, muss geklärt werden, ob weitere Änderungen vorgenommen wurden. Dazu gehören Benutzerkonten, API-Schlüssel, Webhooks, Integrationen und Deployment-Zugänge. Wo ein CMS einmal als Schreibfläche missbraucht wurde, ist die Frage nach Persistenz naheliegend.
Auf der Client-Seite sollten Sicherheitsverantwortliche ClickFix-Indikatoren ernst nehmen: ungewöhnliche Aufforderungen zum Kopieren von Befehlen, Hinweise auf angebliche Browser- oder Systemprobleme, Umleitungen über vertraut wirkende Seiten. Solche Fälle gehören nicht nur ins Awareness-Training, sondern in die Erkennung. Endpoint-Regeln, die verdächtige Kommandozeilenketten nach Browserinteraktionen markieren, können hier mehr leisten als ein weiterer Warnhinweis im Intranet.
Ein alter Fehler in moderner Verpackung
Der Vorfall zeigt, wie wenig trennscharf alte und neue Angriffsmuster geworden sind. SQL Injection ist alt. Bösartiges JavaScript ist alt. Social Engineering ist alt. In der Kombination entsteht trotzdem ein wirksamer Ablauf: technische Lücke, vertrauenswürdige Website, gelenkte Nutzerhandlung.
Für Verteidiger ist das eine unbequeme, aber klare Botschaft. CMS-Härtung ist nicht nur Website-Pflege. Sie ist Bestandteil der Sicherheitsarchitektur. Wer publiziert, liefert Code an Browser aus. Wird diese Lieferkette manipuliert, beginnt der Angriff nicht beim Download einer Datei, sondern beim Aufruf einer Seite, die gestern noch unauffällig war.
