Am 17.09.2026 kam eine Meldung des Nationalen Zentrums für Cybersicherheit. Schwachstelle in Gitea, der Software, mit der ich meinen Code versioniere: Über einen bestimmten Endpunkt lassen sich ohne Anmeldung Dateien vom Server lesen. Betroffen sind die Versionen 1.22.1 bis 1.27.0. Meine lief unter 1.25.5. Also direkt betroffen, würde man meinen.
Ich wollte nachprüfen, ob meine Gitea Instanz kompromittiert ist. Wie macht man das als Nicht-Entwickler? Ich frag Claude, er hat ja beim Setup bereits geholfen. Über das vollständige Anwendungslog, vom ersten Betriebstag im März bis zu diesem Nachmittag. Das Ergebnis war eindeutig: kein einziger Aufruf dieses Endpunkts. Von der gemeldeten Lücke war ich nicht betroffen.
Soweit so gut. Würde man meinen.
Betroffen war ich von etwas anderem, und das kam bei derselben Prüfung heraus. Auf meinem Server lagen 3054 Repositories. Eines davon war meins. Es existierten 211 Benutzerkonten, davon eines meins. Zwei fremde Prozesse rechneten unter dem Benutzer des Dienstes, einer davon seit dem 28.08.2026 um 18.59 Uhr, mit 374 Prozent Auslastung und 2.4 Gigabyte Arbeitsspeicher. In zwanzig Kalendertagen hatte er 74 Tage reine Rechenzeit verbraucht. Cryptomining. Mein Strom, meine Maschine, fremdes Konto.
Und während ich das las, war jemand eingeloggt. In derselben Viertelstunde, in der ich auf den Bildschirm schaute. Um 14.44 Uhr habe ich den Dienst abgeschaltet.
Jetzt der Teil, der mich doch etwas beschäftigt: Für all das brauchte es keine Sicherheitslücke.
Drei Zeilen, klassischer Anfängerfehler
Die Instanz war offen konfiguriert. Registrierung für jeden. Kein Captcha. Inhalte ohne Anmeldung sichtbar. Das sind drei Einstellungen, zwei davon im Auslieferungszustand. Wer sich registriert, darf ein Repository anlegen. Wer ein Repository anlegt, darf Git-Hooks hinterlegen, also kleine Skripte, die bei bestimmten Operationen automatisch ausgeführt werden. Das ist kein Fehler, sondern die Funktion der Software. Genau darüber wurde der Miner gestartet.
Ich hatte diese Instanz im März aufgesetzt. Sie lief. Sie war erreichbar, sie tat, was sie sollte, und ich habe monatelang nicht hingeschaut. Am 22.06.2026 legte jemand das erste Fremdkonto an. Ab dem 13.08.2026 kamen die Massenkonten, rund 1425 Repositories pro Stück, angelegt von einem Skript. Von der ersten fremden Registrierung bis zu dem Moment, in dem ich es bemerkte, vergingen 87 Tage. Die Bereinigung danach hat 26 Minuten gedauert.
Dieses Verhältnis ist die eigentliche Geschichte. Nicht der Angriff. Das Aufräumen war trivial. Das Merken hat drei Monate gebraucht.
«Läuft» ist kein Zustand, sondern eine Abwesenheit von Beschwerden
Warum habe ich nichts gemerkt? Weil nichts kaputtging. Die Website war online, der Newsletter funktionierte, die Automatisierungen liefen. Die Systemlast lag bei 6.97 statt bei 1.3, aber eine Systemlast schaut man sich nur an, wenn man einen Grund dazu hat.
Und der VPS kostet monatlich dasselbe, egal wie viel er rechnet. Hätte ich nach Verbrauch bezahlt, hätte mich die Rechnung informiert. Beim Pauschalpreis informiert einen niemand. Der einzige Bote war eine Zahl, die ich nicht angeschaut habe, weil ich keinen Anlass hatte, sie anzuschauen. Genau so sieht ein blinder Fleck aus: Er meldet sich nicht.
Was mich am Ende hinschauen liess, war eine Warnung zur falschen Sache. Die gemeldete Lücke ist bei mir nie ausgenutzt worden, die Meldung hatte mit dem, was tatsächlich lief, nicht das Geringste zu tun. Ohne sie würde der Miner heute weiterrechnen. Mein Server war also nicht durch Aufmerksamkeit geschützt, sondern durch einen glücklichen Zufall im Verteiler einer Behörde.
Das Cryptomining war dabei noch das Harmlose. Unangenehm war etwas anderes. In der Konfigurationsdatei des Containers stand das Passwort der PostgreSQL-Datenbank im Klartext, und dieselbe Datenbank nutzen bei mir auch andere Dienste. Wer im Container Code ausführen kann, kann diese Datei lesen. Ob das jemand getan hat, weiss ich nicht. Ich habe das Passwort geändert, alle abhängigen Dienste nachgezogen, die restlichen Systeme geprüft: keine fremden Jobs, keine fremden Schlüssel, kein Spam über das Newsletter-System. Es ist gut ausgegangen. Aber «es ist gut ausgegangen» ist kein Verdienst, das ist einfach nur Glück.
Was das mit meiner Arbeit zu tun hat
Ich berate Unternehmen dabei, KI und Automatisierung einzuführen. Ich sage denen, dass die Einstiegshürde gefallen ist. Dass man heute Dinge selber bauen kann, für die man vor drei Jahren eine Agentur gebraucht hätte. Das stimmt auch. Ich habe mir diesen Server mit KI-Unterstützung aufgebaut und das meiste davon funktioniert bis heute. Dasselbe Werkzeug hat mir an diesem Nachmittag gezeigt, was auf dem Server sonst noch läuft. Bauen und prüfen ging beides schnell. Dazwischen lagen drei Monate, in denen ich weder das eine noch das andere getan habe.
Nur: Was gefallen ist, ist die Hürde zum Bauen. Die Hürde zum Betreiben ist geblieben, wo sie war. Man lernt sie beim Bauen nicht mit, weil sie erst Monate später auftaucht, und zwar nicht als Fehlermeldung, sondern als jemand Fremdes, der Ihre Rechenleistung angenehmer findet als seine eigene.
«Bei uns gibt es nichts zu holen», ist der Satz, der in Betrieben schnell fällt, wenn dieses Thema aufkommt. Keine Kundendaten im System, kein Geld auf dem Server, also auch kein Grund für einen Angriff. Der Satz geht von einem Angreifer aus, der sich für Sie interessiert. Das tut hier niemand. Die 895 fremden IP-Adressen in meinen Logs gehören zu Skripten, die das halbe Netz nach offenen Registrierungen absuchen. Die Ware war nicht mein Code. Die Ware war meine Rechenleistung. Und die hat jedes Unternehmen, auch das mit den vierzehn Mitarbeitenden und der Excel-Buchhaltung.
Nicht härten, sondern abschaffen
Ich hätte die Instanz absichern können. Registrierung zu, Captcha an, Hooks einschränken, Monitoring einrichten. Eine Stunde Arbeit oder so.
Ich habe sie stattdessen gelöscht. Container weg, Datenvolumen weg, Subdomain weg. Die Versionierung läuft jetzt bei einem Anbieter, dessen Beruf es ist, so etwas zu betreiben. Das war keine Trotzreaktion, sondern eine Rechnung: Der Dienst hat mir eine Bequemlichkeit gebracht, die ich auch anderswo bekomme, und dafür eine dauerhafte Verantwortung verlangt, die ich nachweislich nicht getragen habe. Nicht weil ich es nicht könnte. Weil ich es nicht tue. Lazy bone in dieser Beziehung. Und sind wir ehrlich: Für meine Website ist es auch overkill. Sie basiert zu 90% auf HTML, das statisch auf einem Server liegt und über ein Framework ausgespielt wird. Die Verisonierung ist eher als Backup und Verständnis für vergangene Anpassungen gedacht.
Das ist die Frage, die wir vielleicht in Projekten stellen sollten: Nicht «können wir das absichern», sondern «wer schaut da in sechs Monaten hin». Wenn auf diese Frage kein Name kommt, sondern eine Rolle oder ein «das machen wir dann schon», dann ist die Antwort bereits gefallen. Selbst betreiben heisst nicht aufsetzen. Es heisst aktualisieren, beobachten, zuständig sein. Dauerhaft und namentlich.
Die Diskussionen gehen manchmal aber in die andere Richtung: Eigener n8n-Server, ein selbst gehostetes KI-Modell, einen Chatbot auf eigener Infrastruktur. Meist mit dem Argument Datenschutz, manchmal mit dem Argument Kosten. Beides kann richtig sein. Aber beide Argumente gelten nur, solange jemand das Ding auch betreibt. Ein selbst gehosteter Dienst, um den sich niemand kümmert, ist kein Datenschutz. Er ist eine offene Tür mit Ihrem Namen daran.
Das soll nicht als Warnung verstanden werden. Sondern als Reflexion und Denkanstoss, weil mein eigener Server zwanzig Tage lang für jemand anderen gerechnet hat, während ich Unternehmen erklärt habe, wie man KI sauber einführt.
Man selbst hat nie ausgelernt. Seine Routinen gehören ständig hinterfragt. Und wenn neue Elemente in einen Alltag kommen, müssen diese auch richtig gepflegt werden. Das braucht Zeit, Wissen oder die richtigen Fragen, an das passende Modell.