Es ist 6:48 Uhr an einem Donnerstag im Juni, als Markus Hagedorn, geschaeftsfuehrender Gesellschafter der Westfaelischen Pumpentechnik Hagedorn GmbH in Guetersloh, auf dem Weg zur Kaffeemaschine kurz die eigene Firmenseite aufruft. Gewohnheit. Was er sieht, laesst ihn den Becher abstellen: Statt der vertrauten Startseite mit den Tauchpumpen und dem Slogan "Foerdertechnik aus Ostwestfalen seit 1971" prangt dort eine fremde Seite. Pillenwerbung, kyrillische Schrift, ein Wust aus Links. Darunter, kaum sichtbar, ein nachgeladenes Skript, das jeden Besucher auf eine gefaelschte Login-Seite umleitet.

Was Markus Hagedorn in diesem Moment noch nicht weiss: Der Einbruch geschah nicht ueber eine raffinierte Hacker-Operation, nicht ueber eine Phishing-Mail an die Buchhaltung, nicht ueber einen Innentaeter. Er geschah ueber ein Plugin, von dessen Existenz im Unternehmen niemand mehr wusste - und ueber eine einzige HTTP-Anfrage, die ein automatisierter Scanner irgendwann in der Nacht abgesetzt hatte.

Das Einstiegsszenario: ein Asset, das niemandem gehoert

Die Webseite der Hagedorn GmbH war 2019 von einer regionalen Agentur gebaut worden. WordPress, ein gekauftes Theme, ein gutes Dutzend Plugins. Die Agentur hatte das Projekt sauber uebergeben, eine Rechnung gestellt und sich dann anderen Kunden zugewandt. Im Unternehmen selbst gab es keine eigene IT-Abteilung im klassischen Sinne - die EDV betreute ein Zweimann-Team, das sich um ERP, Warenwirtschaft, die CNC-Maschinen-Anbindung und die Mailserver kuemmerte. Die Webseite? "Laeuft beim Hoster, da muessen wir nichts machen." Ein Satz, den der EDV-Leiter Thomas Brinkmann in den vergangenen sieben Jahren oft gesagt hatte. Und der im Kern das ganze Problem beschreibt.

Denn die Webseite lief eben nicht einfach. Sie alterte. Das Theme erhielt seit 2022 keine Updates mehr, weil die Lizenz nicht verlaengert worden war. Mehrere Plugins waren verwaist. Und eines davon - ein Customizer-Framework namens Kirki, das urspruenglich nur als Abhaengigkeit des Themes installiert worden war - hatte sich im Mai 2026 als verwundbar herausgestellt. CVE-2026-8206, CVSS 9.8, ein Logikfehler im Passwort-Reset, der es einem unauthentifizierten Angreifer erlaubt, den Zuruecksetzen-Link fuer ein beliebiges Konto an eine selbst gewaehlte Adresse schicken zu lassen. Die korrigierte Version 6.0.7 war seit dem 18. Mai verfuegbar. Auf der Seite der Hagedorn GmbH lief Version 6.0.4.

Die technische Analyse: warum genau diese Luecke so gefaehrlich ist

Um zu verstehen, wie ein einzelner Request eine vollstaendige Uebernahme ermoeglicht, lohnt ein Blick auf den Mechanismus. Ein regulaerer Passwort-Reset funktioniert nach einem simplen Prinzip: Der Nutzer gibt seinen Benutzernamen an, das System schlaegt die hinterlegte E-Mail-Adresse nach und schickt den Reset-Link genau dorthin. Der entscheidende Sicherheitsanker ist, dass der Nutzer keinen Einfluss darauf hat, wohin der Link geht - er muss Zugriff auf das hinterlegte Postfach haben.

Die verwundbare Kirki-Funktion handle_forgot_password() brach genau diesen Anker. Sie nahm aus dem Request sowohl einen Benutzernamen als auch eine E-Mail-Adresse entgegen. Sie pruefte zwar korrekt, ob der Benutzername existiert - verwendete dann aber fuer den Versand die vom Angreifer mitgelieferte Adresse statt der im System hinterlegten. Vereinfacht ausgedrueckt: Der Tuersteher kontrolliert den Ausweis, oeffnet dann aber die Tuer, die der Besucher ihm zeigt, statt der, die zum Ausweis gehoert.

// Vereinfachte Darstellung der fehlerhaften Logik
$user = get_user_by_login($_POST['username']);   // korrekt: Nutzer existiert?
if ($user) {
    $ziel = $_POST['email'];                      // FEHLER: Angreifer-Adresse
    send_password_reset_link($user, $ziel);       // Link geht an den Angreifer
}

Korrekt waere gewesen, die Zieladresse aus dem Benutzerobjekt zu ziehen ($user->user_email) und den uebergebenen E-Mail-Parameter schlicht zu ignorieren oder gegen die hinterlegte Adresse zu validieren. Ein Detail von wenigen Zeilen Code - mit katastrophalen Folgen. Genau solche Logikfehler, die sich der statischen Analyse oft entziehen, sind ein Grund, warum saubere Softwareentwicklung und Code-Reviews mit Sicherheitsfokus kein Luxus, sondern Grundhygiene sind.

Das eigentlich Perfide: Der einzige "Geheimnis-Baustein", den ein Angreifer benoetigt, ist ein gueltiger Benutzername. Und der ist bei WordPress notorisch schlecht geschuetzt. Viele Installationen verwenden noch immer admin. Andere zeigen den Login-Namen oeffentlich als Autorennamen unter jedem Blogbeitrag an, abrufbar ueber die REST-API unter /wp-json/wp/v2/users. Der Angreifer muss also nicht einmal raten.

Die User Story: 72 Stunden bei Hagedorn

Donnerstag, 6:48 Uhr. Markus Hagedorn ruft Thomas Brinkmann an, noch bevor der im Buero ist. Brinkmann faehrt den Rechner hoch, ruft die Seite auf - und sieht dasselbe. Sein erster Reflex: "Das ist der Hoster, da muss was kaputt sein." Der zweite, fuenf Minuten spaeter, als er sich ins WordPress-Backend einloggen will und sein Passwort nicht mehr funktioniert: "Wir wurden uebernommen."

Donnerstag, 8:15 Uhr. Brinkmann holt sich Unterstuetzung. Gemeinsam mit einem externen Dienstleister - der Konstellation, die im Mittelstand bei einem Vorfall die Regel ist - beginnt die Aufarbeitung. Der Zugriff aufs Backend gelingt nur noch ueber den Datenbankzugang des Hosters. Dort der erste Schock: Neben dem bekannten Admin-Konto existieren zwei weitere Administratoren, angelegt am 29. Mai um 03:14 Uhr und 03:17 Uhr nachts. Die Namen wirken zufaellig generiert.

Donnerstag, 11:30 Uhr. Die Logs des Hosters - gluecklicherweise vorhanden, wenn auch nur 30 Tage rueckwirkend - zeichnen ein klares Bild. In der Nacht des 29. Mai eine Serie von POST-Anfragen an admin-ajax.php, alle mit der action des Kirki-Passwort-Resets, alle mit dem Benutzernamen des Hauptadministrators und wechselnden externen E-Mail-Adressen. Ein Treffer genuegte. Danach: Login mit dem zurueckgesetzten Konto, Anlage der beiden Schatten-Admins, Installation eines boesartigen Plugins, das die Weiterleitung und das Skimming-Skript einschleuste.

Donnerstag, 14:00 Uhr. Die entscheidende Frage im Raum: Ist nur die Webseite betroffen - oder mehr? Lag der Webserver im selben Netzsegment wie die Warenwirtschaft? Wurden auf der kompromittierten Seite Kundendaten verarbeitet, etwa ueber das Kontaktformular oder einen Newsletter? Die Antwort faellt zwiespaeltig aus. Die Webseite lief isoliert beim Hoster, getrennt von der internen Infrastruktur - ein Gluecksfall, der nicht geplant, sondern historisch gewachsen war. Aber: Das Kontaktformular speicherte Anfragen inklusive Name, Firma, E-Mail und Telefonnummer in der WordPress-Datenbank. Auf diese Daten hatten die Angreifer drei Wochen lang Zugriff.

Freitag. Die Seite wird komplett neu aufgesetzt - sauberes WordPress, aktuelle Plugins, das alte Theme durch ein gepflegtes ersetzt. Die kompromittierte Installation wird forensisch gesichert und dann verworfen. Brinkmann und Hagedorn sitzen am Nachmittag zusammen und stellen die unbequeme Frage: Haetten sie es kommen sehen muessen?

Montag. Die wohl wichtigste Stunde der ganzen Woche. Die Hagedorn GmbH faellt unter die NIS2-Pflichten - 130 Mitarbeitende, Zulieferer fuer kritische Infrastruktur im Wasserbereich. Die Frage, ob der Vorfall meldepflichtig ist und ob personenbezogene Daten aus dem Kontaktformular eine Meldung nach DSGVO an die Landesdatenschutzbehoerde erfordern, beschaeftigt das Unternehmen mehr als der technische Schaden. Denn der technische Schaden war reparabel. Die Erkenntnis, drei Wochen lang unbemerkt kompromittiert gewesen zu sein, war es nicht.

Die breitere Einordnung: die Webpraesenz als blinder Fleck

Die Geschichte der Hagedorn GmbH ist fiktiv - aber jedes Element darin ist Realitaet in tausenden deutschen Mittelstandsunternehmen. WordPress betreibt einen erheblichen Anteil aller Webseiten weltweit, und seine Staerke - das riesige Plugin-Oekosystem - ist zugleich seine groesste Angriffsflaeche. Das Plugin Kirki war im Mai 2026 nur eines von mehreren prominenten Beispielen: Parallel exponierte die Luecke im Plugin Burst Statistics ueber 200.000 Seiten, und WP Maps Pro wurde ausgenutzt, um eigenstaendig Administrator-Konten anzulegen. Das Muster wiederholt sich Monat fuer Monat.

Was diese Vorfaelle verbindet, ist nicht die technische Raffinesse, sondern ein organisatorisches Versagen: Die Webseite faellt durch alle Raster der IT-Governance. Sie ist kein Teil des Patch-Managements, weil sie "beim Hoster laeuft". Sie taucht in keinem Asset-Inventar auf, weil sie als Marketing-Werkzeug gilt, nicht als IT-System. Sie wird nicht ueberwacht, weil niemand sich zustaendig fuehlt. Sie ist - im klassischen Sinne - Schatten-IT, obwohl sie offen im Netz steht und das oeffentlichste aller Unternehmens-Assets ist.

Hinzu kommt eine Verschiebung der Bedrohungslandschaft, die wir bei pleXtec seit Monaten beobachten: Rund zwei Drittel aller erfolgreichen Angriffe basieren inzwischen auf kompromittierten Identitaeten, nicht auf klassischer Schadsoftware. CVE-2026-8206 ist das Lehrbuchbeispiel - kein Exploit im technischen Sinne, sondern die Uebernahme einer Identitaet ueber einen fehlerhaften Reset-Mechanismus. Wer Identitaet nicht als zentrale Verteidigungslinie begreift, verteidigt die falsche Mauer. Mehr dazu in unserem Schwerpunkt zur Informationssicherheit.

Handlungsempfehlungen: die Webpraesenz vom Stiefkind zum verwalteten Asset machen

1. Inventarisieren Sie Ihre Webpraesenz wie jedes andere IT-System. Erfassen Sie jede oeffentlich erreichbare Domain, jede Subdomain, jedes CMS, jedes Plugin samt Version. Sie koennen nur schuetzen, was Sie kennen. Eine Webseite, die in keinem Inventar steht, hat auch keinen Verantwortlichen - und kein Verantwortlicher bedeutet keine Pflege.

2. Etablieren Sie einen verbindlichen Update-Rhythmus. Kern-CMS, Themes und Plugins gehoeren in einen festen Patch-Zyklus mit definierten Fristen fuer kritische Schwachstellen. Im Fall Kirki lagen zwischen Patch (18. Mai) und der Angriffswelle nur wenige Tage. Wer hier nicht binnen 72 Stunden reagieren kann, verliert das Rennen gegen automatisierte Scanner.

3. Reduzieren Sie die Angriffsflaeche. Jedes Plugin, das Sie nicht aktiv benoetigen, ist Risiko ohne Nutzen. Deinstallieren Sie verwaiste Erweiterungen vollstaendig - deaktiviert reicht nicht, denn verwundbarer Code bleibt auf dem Server. Pruefen Sie regelmaessig, ob Themes und Plugins noch von ihren Herstellern gepflegt werden.

4. Haerten Sie Identitaeten und Zugaenge. Verbannen Sie generische Benutzernamen wie admin. Entkoppeln Sie den oeffentlich angezeigten Autorennamen vom Login-Namen. Erzwingen Sie Zwei-Faktor-Authentifizierung fuer alle Backend-Konten - im Fall Hagedorn haette ein zweiter Faktor die Uebernahme trotz Reset-Link verhindert. Beschraenken Sie den Zugriff aufs Admin-Backend per IP-Allowlist, wo moeglich.

5. Trennen Sie die Webseite vom internen Netz. Die Hagedorn GmbH hatte Glueck, dass ihre Seite isoliert beim Hoster lief. Machen Sie aus diesem Glueck Absicht: Eine oeffentliche Webseite darf niemals im selben Netzsegment wie ERP, Dateiserver oder Produktionssysteme stehen. Behandeln Sie sie als das, was sie ist - ein nach aussen exponiertes, potenziell feindliches System.

6. Etablieren Sie Monitoring und ein Notfallkonzept. Datei-Integritaetspruefung, Alarmierung bei neuen Admin-Konten, regelmaessige externe Erreichbarkeits- und Defacement-Checks. Drei Wochen unbemerkte Kompromittierung wie bei Hagedorn duerfen nicht vorkommen. Und definieren Sie vorab, wer im Ernstfall was tut - inklusive der Frage nach Melde- und Dokumentationspflichten unter NIS2 und DSGVO.

Ausblick: Regulatorik macht den blinden Fleck zur Chefsache

Was bisher als laessliche Nachlaessigkeit durchging, wird 2026 zum handfesten Compliance-Risiko. Unter NIS2 gehoeren auch oeffentlich erreichbare Systeme zur Angriffsflaeche, fuer die die Geschaeftsleitung persoenlich haftet - und ein Sicherheitsvorfall ist binnen 24 Stunden meldepflichtig. Der Cyber Resilience Act nimmt ab September 2026 zusaetzlich Hersteller digitaler Produkte in die Pflicht, aktiv ausgenutzte Schwachstellen zu melden. Und wo, wie bei Hagedorn, personenbezogene Daten ueber ein Kontaktformular in die falschen Haende geraten, greift zusaetzlich die DSGVO.

Die Botschaft ist eindeutig: Die Zeit, in der die Firmenwebseite als harmloses Marketing-Anhaengsel galt, ist vorbei. Sie ist ein vollwertiges IT-System mit oeffentlicher Angriffsflaeche, regulatorischer Relevanz und direkter Verbindung zur Reputation des Unternehmens. Wer sie weiter wie ein Stiefkind behandelt, riskiert genau den Donnerstagmorgen, den Markus Hagedorn erlebt hat.

Bei pleXtec helfen wir mittelstaendischen Unternehmen dabei, ihre gesamte digitale Angriffsflaeche - von der vergessenen WordPress-Seite bis zur Kerninfrastruktur - sichtbar zu machen, zu haerten und kontinuierlich zu ueberwachen. Wenn Sie nicht sicher sind, was unter Ihrer Domain alles laeuft und wer dafuer zustaendig ist, ist das bereits der wichtigste Grund, mit uns zu sprechen. Eine erste Einschaetzung erhalten Sie ueber unser Kontaktformular oder unsere Leistungsuebersicht.