Incident-Response on Schallberts Blog

PHP2shell: Kritische Sicherheitslücken

Schallbert — Wed, 21 Oct 2026

Schritt 1 Erkennen: Wir haben ein Problem.

TLDR: PHP hat ganz aktuell zwei kritische Schwachstellen, die Remote Code Execution ermöglichen. Ihre IDs: CVE-2026-109618 und CVE-2026-109619. Da ihre Ursachen nicht im Frontend sondern in der Engine stecken, hilft nur ein Update auf PHP 8.5.12, 8.4.27, 8.3.36, oder 8.2.35.

“PHP nutze ich nicht auf meiner Website”, denke ich, als ich heute Vormittag die folgende Nachricht erhalte:

“Hi, kurzer Hinweis: Gegebenenfalls […] alles was php nutzt, erstmal abklemmen, […] Patch kommt später heute.”

Oder bin ich doch betroffen…? Immerhin nutze ich eine managed Nextcloud-Instanz, und Nextcloud ist doch u.A. in PHP geschrieben…? Während ich diese Zeilen schreibe, wird ein Fix für Nextcloud verfügbar. Alles muss also sehr schnell gehen. Heute werden unter Garantie viele Überstunden gemacht.

Status 21.10.2026, 10:30 MESZ

Spulen wir zehn Stunden zurück. Es gibt noch keinen Fix. Die Information über die CVEs wurde geleakt und ist jetzt selbst bereits ein paar Stunden alt. Laut Wikipedia nutzen 69% aller Websites PHP. Das Ausnutzen einer so hochkritischen Lücke (Score 9.2) bei einer derart weitverbreiteten Technologie hat erwartbar massive Auswirkungen. Entsprechend nervös ist “das Internet”.

“[…] organisations should consider isolating internet-facing applications from public networks until a fix is applied and verified. CERT-EU, pulled 21.10.2026, 10:40

Interessant, die Empfehlung ist also ernsthaft “erstmal vom Netz nehmen”.

Schritt 2 Sofortmaßnahmen: Nextcloud vom Netz trennen

Um einem möglichen Angriff zuvor zu kommen versuche ich folglich, meine Instanz vom Netz zu nehmen. Dafür logge ich mich bei meinem Hoster ein, wechsle auf das Tab “Einstellungen”, und klicke auf den Reiter ownCloud Console. Dies ist Nextclouds command-line interface.

Dort muss ich feststellen, dass kein Befehl zum Abschalten oder de-publishing zur Verfügung steht. Also wähle ich den Nächstbesten:

occ maintenance:mode --on

Ich versetze meine Instanz also in den Wartungsmodus. Dies verhindert neue Logins und friert die Datenbank ein. Anschließend lese ich mich ein wenig in die CVEs ein um herauszufinden, ob mein Schritt genügt.

Tut er wohl nicht.

In verschiedenen Foren und auf HackerNews erfahre ich, dass eine nicht authentisierte Anfrage bereits den Angriff auslösen kann, bevor überhaupt PHP-Code auf der Serverseite ausgeführt wird.

Es ist also egal, in welchen Zustand ich meine Instanz versetze - solange sie am Netz ist, bleibt sie angreifbar.

Schritt 3 Vorläufige Eindämmung: Nextcloud-Instanz deaktivieren lassen

Ich finde auch mit Hilfe diverser Online-Suchanfragen keinen Weg, meine mangaged-Instanz abzuschalten. Ich überlege kurz, die Namensauflösung und das DNS-Routing zu killen. Mir wird aber schnell klar: Bis sich das durchpropagiert, ist der Fix längst draußen.

Status 21.10.2026 11:43 MESZ

Ich schreibe also ein Support-Ticket an meinen Hoster mit der Bitte um Hilfe beim Herunternehmen meiner Instanz.

Status 21.10.2026 12:01 MESZ

Ich erhalte eine Mail vom Hoster!

Tatsache, ich kann die Instanz nicht mehr erreichen und erhalte eine ERR_CERT_COMMON_NAME_INVALID-Meldung. Klicke ich diese weg, erscheint REQUESTED PAGE LOCKED. Gute Arbeit. Die Reaktionszeit meines Anbieters inlusive Rückmeldung an den Kunden betrug 18min.

Nun wechsle ich den Modus vom Akteur zum Beobachter. Ich sehe erste Exploit-Versuche (oder zumindest Beteuerungen davon) im Web und muss an eine Folie eines Vortrages denken (Zeitstempel 11:24), den ich vor kurzem gesehen habe: Security in the LLM age.

Dort zeigt ein Linux-Kernel Sachverständiger, dass wir in 2026 im Schnitt sieben Tage vor einem Patch in betroffener Software bereits Exploits in freier Wildbahn sehen.

discover --> disclose --> patch --> deploy

Diese traditionelle Ereigniskette funktioniert nur bei “langsamen” Angreifern gut. Wir benötigen etwas, um wieder vor die Lage zu kommen.

Schritt 4 Beobachten der Situation: Verfügbarkeit des Patches, Einspielen erster Betreiber

Laut Hackernews wird der Patch um etwa 16:00 MESZ verfügbar. Ich besorge mir den RSS-Feed meines Hosters und warte auf Meldung.

Status 21.10.2026 14:20 MESZ

Auch das Bundesamt für Sicherheit in der Informationstechnik hat einen BSI-IT-Sicherheitshinweis herausgegeben, wo mit der “Kritikalität 3/Orange” vor der Lücke gewarnt und folgendes angemerkt wird:

“Der Patch für die Schwachstelle ist heute 16 Uhr deutscher Zeit (14:00 UTC) angekündigt und sollte unverzüglich zu diesem Zeitpunkt installiert werden.” - BSI, 21.10.2026

Status 21.10.2026 16:34 MESZ

Mein Hoster meldet, dass die Patches nun verfügbar seien und mit der Implementierung begonnen würde. Betroffen sind nicht nur die Nextcloud-Instanzen, sondern auch seine komplette Administrationsoberfläche sowie sein Webmailer.

Status 21.10.2026 19:52 MESZ

Mein Hoster meldet Vollzug für die von ihm betriebenen Webhosting-Angebote und Managed Servers.

Status 21.10.2026 22:40 MESZ

Die Hetzner-Anwendung KonsoleH, über die ich meine Nextcloud-Instanz verwalte, ist down.

Status 21.10.2026 23:00 MESZ

KonsoleH ist wieder live (und gepatcht).

Schritt 5 Erkenntnis und Schlussfolgerung

Was lerne ich aus den Ereignissen dieses turbulenten Tages? Wie gehe ich in Zukunft mit Sicherheitslücken um? Und wie erkenne ich überhaupt, dass ein Problem vorliegt?

Nicht nur der Service als Ganzes ist angreifbar sondern auch seine Komponenten. –> Kenne alle Komponenten und achte auf Schwachstellen und Patches!
Die Gegenspieler sind (durch LLMs) unglaublich schnell geworden. –> Rechne mit Exploit vor Patch-Verfügbarkeit!

Eine Liste geeigneter Quellen für Verwundbarkeiten, Neuigkeiten und Patches stelle ich mir gerade zusammen. Sobald die Liste stabil ist, werde ich darüber berichten.

Schritt 6 Aktionen

Sensible Daten wenn möglich aus dem Netz nehmen. Gedankengang: Was wäre, wenn das weg kommt? Reicht Verfügbarkeit im LAN/Intranet?
Besseres Monitoring und Abuse detection sind nur konsequent: Früh erkennen, früh sperren, früh melden, früh abschalten, sofort patchen.
Standardbezugsquellen für Informationen zu verwendeter Software besorgen. CVE-List-Scanner bauen? HackerNews-Filter?

Nachtrag: 22.10.2026 09:30 MESZ

Der Hoster hat meine Nextcloud-Instanz gepatcht und wieder online genommen. Alle Systeme normal. Es gibt nun auch einen Wikipedia-Eintrag zum Thema, der sehr aktuell gehalten wird.

Schritt 7 Erste Reflektion

Nun sind ein paar Tage ins Land gegangen, seitdem die beiden Sicherheitslücken öffentlichkeiswirksam bekanntgemacht und Patches bereitgestellt wurden. Werfen wir mal einen Blick in die Netzlandschaft.

Status 24.10.2026 16:30 MESZ

Es gibt inzwischen viele, viele Machbarkeitsnachweise (PoC, Proof of Concept) für und über die Ausnutzung der PHP-Sicherheitslücken, allem voran auf der Plattform Github.

Ich selbst bin leider auf dem Themenfeld nicht sachkundig und muss mich auf die Einschätzung anderer verlassen, was Qualität dieser PoCs angeht, wie die es um die Ausnutzbarkeit in der freien Wildbahn wirklich bestellt ist und was die Hintergründe dazu betrifft, dass ausgerechnet diese Lücke medial so starke Resonanz zu erfahren scheint.

Im Allgemeinen gilt selbstverständlich “Erst patchen, dann nachfragen”. So habe ich es ja auch gemacht. Wenn ich noch einmal Felix von Leitner zitieren darf:

“Eine der Lektionen aus 20 Jahren Arbeit im Security-Umfeld ist, dass wenn einer behauptet, es gibt einen Bug, und der andere behauptet, der sei aber nicht exploitbar, dass sich dann im Nachhinein so gut wie immer raustellt, dass der doch exploitbar war.” - Feliks von Leitner aka Fefe, 12.April 2014, abgerufen am 24.10.2026

Zur Ausnutzbarkeit schreibt die sich selbst als Bedrohungsaufklärungsseite “Threat intelligence” bezeichnende flare.io, dass die meisten PoCs für PHP2shell nur in der Laborumgebung funktionierten. Auf echte Ziele seien sie kaum anwendbar - endweder, weil Betriebsinterna über die angegriffene Systeme erforderlich seien, weil sie andere Schwachstellen wie die Abschaltung von Speicherrandomisierung voraussetzen, oder weil die PoCs selbst “AI-Slop” darstellten: schlecht oder kaum validierte, mieserabel geschriebene Software, die mehr verspreche als sie halte.

Ähnlich äußert sich eliastaylor:

“There isn’t an easy exploit for this PHP vulnerability.” - https://eliastaylor.com/noexploit/, abgerufen am 24.10.2026

Sein Argument ist knapp zehn Stunden nach Veröffentlichung von Angriffsvektor und Patch, dass

keiner der Exploit-PoCs funktioniert, nicht einmal bei einer Standardinstallation und -Konfiguration von Pre-Patch-PHP
die beiden CVEs weit weniger kritisch sind als andere Sicherheitslücken der Geschichte (Heartbleed bei Open SSL wird exemplarisch genannt)
die Exploits alle nicht von echten Leuten handgeschrieben, sondern mit Hilfe von LLMs generiert seien

Der Kern der Argumentation geht dahin, dass Leute ihre Denkarbeit an Sprachmodelle abgäben und selbst gar nicht mehr prüften, ob das System tut was es sagt; geschweige denn den vom System geschriebenen Code läsen, verstünden und verbesserten. Bösartige Botnets würden noch immer von Menschen handgeschrieben, und das brauche seine Zeit, wenn die Lücken nicht offensichtlich und trivial auszunutzen seien.

Als kleine Übung für eine eigene Einschätzung der Lage empfehle ich die Lektüre der “Issue”-Diskussionen, die bei vielen PHP2Shell-PoCs auf Github öffentlich bereitstehen.

Das Große Medienecho hat aber auch etwas Gutes: Die Welt patcht anscheinend schnell. Ich habe mir die Resonanz auf diversen Foren, deutschen und internationalen, überflogen: Überall treiben Menschen ihre Hoster mit Patches vor sich her, diskutieren miteinander die Auswirkungen und welche betroffenen Anbieter bereits Updates herausgebacht haben.

Bleibt die Frage offen, wem das Ganze nützt. Ich habe schon ein paar Vermutungen. Für Schlussfolgerungen und meine Urteilsbildung ist es allderings noch zu früh.

Status 27.10.2026 17:00 MESZ

Die Sicherheitslücke gilt offiziell bestätigt als ausgenutzt.

Schritt 8 Beobachtungen analysieren und Informationskanäle justieren

Ich lege den Fokus nun auf Berichte zur Ausnutzung der Sicherheitslücken. Die Menge an POCs ist für Einzelpersonen unüberschaubar geworden. Erste Privatpersonen und Firmen wie Cloudflare haben begonnen, ein Capture The Flag auszuloben: Sie stellen absichtlich angreifbare PHP-Instanzen online und fordern auf, sie zu knacken und dies zu beweisen.

Ein sehr kluger Schritt, um die Spreu vom Weizen zu trennen. Auf diese Weise müssen die Leute ihre POCs gegen Sparringspartner ins Feld führen, die ihren Stack nicht offenlegen. Als zusätzliche Schwierigkeit fordern einige Anbieter auf, dass vorher außerdem andere ihrer Standard-Abwehrmechanismen wie Web Application Firewalls überwunden werden müssen. Schafft es ein POC hindurch, kann er als als unter realistischen Bedingungen durchgeführte Schwachstellenausnutzung gelten.

Den POC verstehen

Ich habe (dank an eliastaylor) den POC gefunden, welcher die “StealMyBitcoin” PHP2Shell-CTF gelöst hat. Interessant sind sowohl die Kommentare in der Python-Datei über den Mechanismus des Exploits als auch die Diskussion auf Github zu Modellvariante, Prompt und Konfiguration des verwendeten LLM.

Ich verstehe die Quellen und Kommentare rund um diesen POC so, dass er die Probleme der vorigen Versuche elegant löst:

PHP beim Multipart-Upload effektiv in die Speicherklemme bringen: Anstatt tausende Anfragen in kürzester Zeit zu senden (und zu hoffen, dass er den “richtigen” Worker-Thread trifft), verwendet diese Attacke “deeply nested field names”¹, welche die Payload gering, jedoch den Speicheraufwand mit nur einer Anfrage serverseitig explodieren lassen.

Dies geht gegen die Lücke CVE-2026-109618 “out-of-memory handling can interrupt PHP while internal request data is only partially initialized. Request cleanup may then treat the invalid data as valid”. Ziel des heap_consumer ist es nun, die herumliegenden, durch den Speicherüberlauf abgelaufene Daten zu manipulieren.

ASLR, randomisiertes Ablegen im Speicher umgehen: Anstatt ASLR im Feld zu ignorieren (oder in der Laborumgebung schlicht abzuschalten) müssen Speicherüberlauf, Manipulation und erneute Anfrage zum Einlesen der manipulierten Daten zwingend in derselben Session und auf demselben, überlasteten Worker geschehen². Ansonsten ist der betroffene Speicherbereich kaum wiederzufinden und wird irgendwann durch das System, welches den gestoppten Worker entdeckt, zurückgesetzt. Daher muss der Exploit den Schadcode bereits platziert haben, wenn PHP den zugehörigen Destruktor aufruft und damit schließlich die RCE ausführt.

Dies geht dann gegen die Zweite CVE im Bunde: CVE-2026-109619 “request-owned internal state can survive after its backing memory has been freed. A later request handled by the same worker may use that stale state before normal initialization resets it.”

Wäre jetzt cool hierzu mal eine PHP-Engine-Sachverständige zu hören :)

Damit steht auch der dunklen Seite in der Breite ein Exploit zur Verfügung, der bei “einfachen Zielen” ohne Härtung eine (automatisierte) Ausnutzung machbar erscheinen lässt.

Härtung

Lösen kann das Problem nur der Patch. Folgende Härtungsmaßnahmen können gegen diesen speziellen Angriffsvektor zumindest den Widerstand erhöhen:

Das Kommando PHP_SESSION_UPLOAD_PROGRESS, durch den der Angriff durchgeführt wird, gar nicht erst anbieten oder aber keine Anfragen in sehr kurzer Abfolge, in derselben Session, oder von derselben Maschine zulassen.
Die Anzahl Worker auf Maximum drehen, auch wenn dies auf die Leistung der Maschine geht. Dies macht das Wiedereinfangen und Ausnutzen desjenigen Workers schwieriger, welcher zuvor korrumpiert wurde.

Später am selben Tag

The Hacker News bestätigt die Ausnutzung und zählt betroffene Firmen bzw. Großkonzerne und Lieferanten auf. Der Tenor: Patchen, patchen, patchen!

Status 28.10.2026 21:30 MESZ

Cloudflare hat inzwischen neue Firewall-Regeln für ihre WAF veröffentlicht, die Angreifende schon vor Erreichen der Zielserver abfangen soll. Hackernews berichtet über konkrete Vorfälle mit ersten Schäden. Threat intelligence Firmen bestätigen dies.

Zum Abrunden des Status hier noch eine nette Sammlungsseite mit Informationen über x-2-shell-Schwachstellen.

Kritische Schwachstellen bei Gitea (und Forgejo)

Schallbert — Sun, 04 Oct 2026

Gewahrwerdung

Wie so oft beginnt auch diese Geschichte mit einem Netzwerk der menschlichen Kommunikation. Dieser unersetzliche Austausch hat schon viel zur Sicherheit der Software beigetragen, mit der ich diesen Blog betreibe. Nun kann ich eine weitere Sicherheitslücke schließen. Aber der Reihe nach.

Gitea als Angriffsziel

Ich hörte, dass die selbst gehostete Versionsverwaltungslösung Gitea eines meiner Bekannten Ziel einer Attacke geworden ist. Hierbei wurde eine RCE (Remote Code Execution) möglich und tatsächlich auch ausgeführt.

Warum ist Gitea ein attraktives Ziel?

Diebstahl von (Firmen)geheimnissen: Bei Zugriff auf Repositories ist vertraulicher Quellcode gefährdet, offengelegt zu werden.
Abfluss von Zugangsdaten: Wird ein größeres Produkt mit Schnittstellen in Gitea verwaltet, sind API keys, Konten und Passwörter in Gefahr, falls sie unverschlüsselt vorliegen. Abhilfe schaffen Tools wie git-secret; sie werden aber durch Einführen zusätzlicher Komplexität noch nicht flächendeckend eingesetzt.
Klassische Rechteeskalation: Unter Umständen kann man durch Ausbruch aus der Gitea-Software die ganze Maschine übernehmen.
Nutzen des runner: Schafft man es den Runner zu kapern, kann man auch ohne erweiterte Rechte Ressourcen der Hostmaschine in Beschlag nehmen und für eigene Zwecke missbrauchen (Stichwort Cryptominers in CI/CD).

Was ist eine RCE?

Eine Remote Code Execution ist ein erfolgreicher Angriff, bei dem nicht autorisierter Code ohne Zutun von Besitzer oder Administration der befallenen Ressource aus der Ferne über das Netzwerk eingespielt und ausgeführt werden kann.

Das Gitea-Ökosystem

Als Versionsverwaltung und forge gehört zum Basisumfang von Gitea die Möglichkeit, webbasiert und kollaborativ Software zu entwickeln und zu bauen. Daher ist vorgesehen, dass sich Nutzer registrieren und unter Umständen sogar Aktionen ausführen können, damit Software automatisiert gebaut und/oder ausgeliefert werden kann.

Genau dieses automatische Nachladen und Ausführen von Code kann böse Folgen haben, wenn Sicherheitslücken in der Verwaltungssoftware selbst bestehen.

Verwundbarkeit durch offene Registrierung

Lässt man als Betreiberin die Registrierung neuer Accounts (“self-registration”) in Giteas Konfiguration auf dem Standardwert DISABLE_REGISTRATION = false, so können sich Nutzerinnen selbst einschreiben, eigene Repository anlegen, issues aufmachen und alles tun, was ohne Adminrechte möglich ist.

Hat man zusätzlich noch den Standardwert REQUIRE_SIGNIN_VIEW = false gesetzt, können auch unauthentisierte Besucher öffentliche Repositories sehen, die Seiten von Gitea browsen und vor allem die öffentliche API des Gitea Endpoints ansprechen.

Verwundbarkeit durch Standardkonfiguration für Reverse Proxies

In der Standardkonfiguration des Gitea Docker image vertraut Gitea <V1.26.3 allen Proxies.

# gitea/app.ini

[security]
REVERSE_PROXY_LIMIT = 1
REVERSE_PROXY_TRUSTED_PROXIES = * # This is a vulnerability!

Die Sicherheitslücken

Womit haben wir es hier zu tun? Mit mehreren kritischen Sicherheitslücken des Ausmaßes 9.8/10 CVSS score, von denen es bekannte Fälle der Ausnutzung gibt.

Exkurs: Die CVSS-Bewertung

Zur Einordnung der Bewertung von “kritisch”: Die CVSS-Kriterien sind ähnlich aufgebaut wie in der klassischen Gefahren- und Risikoanalyse, einem Zweig der Ingenieurswissenschaften. Anders als dort liegt der Fokus allerdings nicht in der Analyse möglicher Fehlerfälle, Schweregrad, Eintritts- und Ausfallwahrscheinlichkeit oder Detektierbarkeit, sondern auf dem Schwierigkeitsgrad der Ausnutzung und möglicher Auswirkungen.

Bedeutung der CVSS-Einzelwerte

Je höher der CVSS-Wert, desto einfacher ist die Sicherheitslücke auszunutzen und desto gravierender sind mögliche Folgen hinsichtlich der Datensicherheitskriterien (Confidentiality, Integrity, Availability).

Das Bild oben zeigt eine Konstellation, in der eine mögliche Attacke aus der Ferne (Netzwerk) mit geringem Aufwand (Complexity, meint Systemhärtung) ohne Randbedingungen (Requirement, z.B. das Anfahren einer vulnerablen Stelle im Code, Vorhandensein eines bestimmten Zustandes des angegriffenen Systems, Auslösen einer race condition etc.), ohne zusätzliche Rechte (als Gast ohne Authentisierung oder Autorisierung) oder Interaktion mit dem User oder der Administratorin des Systems durchgeführt werden kann.

Das wäre für sich genommen noch nicht schlimm, wenn niemand das System benötigt Score 0.0 und nichts Interessantes darauf gespeichert ist. Liegen dort allerdings sensitive Daten Confidentiality, 8.7 oder zum Beispiel eine Datenbank, deren Werte sich nun manipulieren lassen Integrity, 8.7, oder wird auch nur die Verfügbarkeit von benötigten Daten eingeschränkt Availability, 8.7, befindet man sich bereits im Bereich High.

Mit diesem Wissen nehmen wir nun den Transfer auf die kritischen Lücken von Gitea vor.

CVE-2026-20896: Authentication bug in Gitea through reverse-proxies

Kommt ein Angreifer hinter den Reverse Proxy (oder ist gar kein Reverse Proxy vorgeschaltet), kann er eine Anfrage mit X-WEBAUTH-USER im Header direkt an die Gitea-Instanz senden und sich für einen Reverse Proxy ausgeben. Ist Gitea gleichzeitig darauf eingestellt, allen reverse proxies zu vertrauen REVERSE_PROXY_TRUSTED_PROXIES = *, so geht es davon aus, dass bereits authentisiert wurde und eine gültige Session vorliegt. Der Angreifer erhält also Nutzerrechte mit Schreibzugriff auf Repositories, obwohl er nicht mal einen Account angelegt hat.

Das eigentliche Lücke ist hier das unhinterfragte Vertrauen gegenüber dem Sender des Headers ohne weiteren Abgleich mit einem Session Token oder ähnlichem; das Annehmen desselben von fremden Quellen erzeugt lediglich die Verwundbarkeit.

Für diesen Bug gibt es Belege für bereits erfolgte Attacken.

CVE-2026-59774: File-read flaw for anything the Gitea Service Account can read

Diese kritische Sicherheitslücke basiert auf einer unzureichenden Eingabeprüfung des eingebauten Textrenderers von Gitea für org-mode Dateien. Eine detaillierte Beschreibung des Vektors und zu möglichen Wegen eines Angriffs kann auf Saytam Rastogis hervorragendem Blog nachgelesen werden.

Kurzgesagt kann sich ein Angreifer mit Zugriff auf zumindest ein öffentliches Repository eine bösartige .org-Datei zusammenbasteln, mit deren Hilfe er Giteas Konfiguration app.ini auslesen und damit auf darin enthaltene Secrets zugreifen kann, welche ihm erweiterte Rechte zugestehen oder ihn zumindest lateral auf dem System bewegen lassen.

Dies kann laut hacker news und Giteas eigenen Leuten zufolge beispielsweise auch dazu ausgenutzt werden, die Registration Token eines Runners auszulesen und selbigen zu übernehmen.

CVE-2026-60004: RCE allowing attacker with ordinary user rights to execute arbitrary shell commands as the Gitea OS user.

Diese Sicherheitslücke ist deswegen besonders schlimm, weil sie zusätzlich eine privilege escalation ermöglicht.

“The vulnerability in question is CVE-2026-60004 (CVSS score: 9.8), a case of remote code execution that allows an attacker with ordinary write access to a repository to execute arbitrary shell commands as the Gitea OS user.” thehackernews, Aug-2026

Das Ausnutzen dieser Lücke kann den Angreifer also die gesamte Gitea-Instanz übernehmen lassen, sofern er Schreibzugriff auf irgendein (evtl. sogar öffentliches) Repository hat.

Das Lagebild

Es gibt noch weitere kritische Sicherheitslücken, allerdings könen sich Angreifer mit einer Kombination der obigen Darstellungen ohne großen Aufwand

Als normale User auf dem Gitea-System bewegen, ohne sich registriert zu haben, und ohne SSH-Zugriff zu benötigen
Sich als Gitea-Service User ausgeben
Actions übernehmen oder sogar Workflows injizieren und ausführen
Mit etwas Mehraufwand die gesamte Instanz übernehmen, verschlüsseln, Lösegeld verlangen usw.

Was mein Bekannter erlebt hat betraf die Punkte eins und drei. Der Angriff wurde sehr wahrscheinlich automatisiert ausgeführt, nachdem das Internet auf verwundbare Instanzen gescannt worden war.

Zusammengefasst kann man im vorliegenden Fall von einer Mass-Exploitation Campaign für Cryptomining ausgehen.

Der Cryptominer

Bei meinem Bekannten wird folgende Datei als statisch gelinkte Executable (!) auf dem System abgelegt: gitea/data/gitea/sys_health_s3 Der Hash der Datei legt seiner Ansicht nach nahe, dass ein XMRig cyptominer als bösartige Payload eingesetzt wurde, der mit pool.hashvault.pro kommuniziert und dabei einen Großteil der verfügbaren CPU-Leistung für sich beansprucht.

Noch größerer Schaden möglich

Sogar für den auslegungsüberschreitenden Stöfall habe ich ein aktuelles (Sep-2026) Beispiel auf Hackernews finden können: Diebstahl von Quellcode, Sammlung von Zugangsdaten, Privilege escalation bis hin zum root-Zugriff auf das betroffene System.

Wie entdecke ich einen Angriff?

Schlimmstenfalls gar nicht. Sind Profis zielgerichtet am Werk, können allenfalls die Logdateien zum Zeitpunkt direkt nach dem Einbruch Aufschluss geben. Im Falle, dass man sie sofort liest und interpretieren kann. Aber ich schweife ab¹.

Dannoch sollte man sich folgende Fragen stellen:

Betreibe ich eine vulnerable Gitea-Version (<1.27.2)?
Verzichte ich auf eine Monitoring-Lösung, die bei Auffälligkeiten warnt?
Liegt eine ungewöhnlich hohe CPU-Last des Systems vor (Deutet auf Kryptominer-Befall hin)?
Für diesen konkreten Miner kann man zusätzlich nachsehen, ob auf dem System folgende Datei zu finden ist:

find / -name '.sys_health_s3' 2>/dev/null

Beantwortet man sich nur eine dieser Fragen mit ja, ist zügiges Handeln angebracht. Dabei ist durch den Schweregrad der Sicherheitslücken das gesamte Hostsystem als kompromittiert anzusehen, insbesondere wenn der Gitea-Container oder ein eventuell eingebundener Runner rootful läuft, also mit dem Docker Socket ausgestattet wurde.

Bei Befall: Quarantäne

Nächste Schritte: Sofort die betroffene Maschine isolieren und vom Netz nehmen. Die Container herunterfahren, Hostmaschine durchbooten und Updates nachladen. Aschließend die Docker Registry auf Stand bringen und über die Logdateien (Zeitstempel!) ermitteln, ob andere Teile des Systems betroffen sind. Für weitere Details siehe mein Artikel über einen selbsterlebten Angriff auf Gitea.

Lösungen

Gitea Updaten!

Gitea muss dringend auf eine Version >1.27.1 gebracht werden. Dafür kann beispielsweise die docker-compose.yml geändert und die Container danach durchgebootet werden:

# docker-compose.yml
gitea:
 image: gitea/gitea:latest
 container_name: gitea

Weitere Informationen zu aktuellen Fixes finden sich auf Giteas Blog. Der Major Release auf Version 27 löst eine ellenlange Liste an kritischen Sicherheitslücken. Ich habe in diesem Artikel nur ein paar davon herausgepickt, da sie mein direktes Umfeld betreffen und ihre Ausnutzung bekannt ist.

Gitea und Runner `rootless` ausführen

Führt das Ausnutzen einer Sicherheitslücke zum Verlust von Gitea oder dem Action Runner, sollte nicht auch noch das Hostsystem kompromittiert werden. Der Betrieb in einem Container kann den Schadensumfang deutlich reduzieren. Das Aufsetzen einer rootless-Lösung habe ich daher hier beschrieben.

Zusätzliche Maßnahmen (Härtung)

CVE-2026-20896: Netzwerkzugriff erschweren

Bei den folgenden Schritten folge ich der Empfehlung von d00ftech.

Einfügen des Adressraumes des selbst verwendeten Reverse Proxy. Dafür gilt erst einmal herauszufinden, unter welcher Adresse der Reverse Proxy im Netzwerk erreichbar ist. Auf meinem Server beispielsweise laufen Gitea und Reverse Proxy (Caddy) in Docker. Daher finde ich die IP-Adresse wie folgt:

docker inspect caddy \
 --format='{{range $name, $network := .NetworkSettings.Networks}}{{$name}}: {{$network.IPAddress}}{{"\n"}}{{end}}'
caddy-proxy: 172.20.0.2

Dieser Wert wird nun in der gitea/app.ini eingetragen:

[security]
REVERSE_PROXY_LIMIT = 1
REVERSE_PROXY_TRUSTED_PROXIES = 172.20.0.2/32

Direkten Netzwerkzugriff auf Gitea unter Umgehung des eigenen Reverse Proxy blockieren. Dazu darf der Port von Gitea (meist 3000) nicht in der Portfreigabe beispielsweise der Docker-Konfiguration erscheinen:

# docker-compose.yml
services:
 gitea:
 ports:
 - "3000:3000" # remove this!

CVE-2026-59774: Gitea updaten!

Es gibt zwar die Möglichkeit, den org-mode renderer in der app.ini zu deaktivieren (Siehe Gitea Documentation zum Thema), der weitaus bessere Weg ist aus meiner Sicht aber das Update von Gitea selbst!

CVE-2026-60004: Falls möglich Self-Registration abschalten

Der eigentliche Fix ist nur durch ein Update der Gitea-Version möglich. Für kleinere Instanzen mit wenigen Usern mag es zusätzlich zweckmäßig erscheinen, die Selbstregistrierung für neue User abzuschalten. Sie müssen eine Registrierung von nun an bei den Administratoren anfragen (sofern sie nicht eine der anderen oben beschriebenen CVEs ausnutzen).

# gitea/app.ini
[service]
DISABLE_REGISTRATION = true

Weitere hilfreiche Einstellungen sind:

REGISTER_EMAIL_CONFIRM = true # Requires user's email to be confirmed for registration to complete
ENABLE_OPENID_SIGNUP = false # Disallow logons via external API
REQUIRE_SIGNIN_VIEW = true # Force users to login before they can view content or use the public API

Ausblick und Fazit

Versionsverwaltungen sind sehr atttraktive Ziele für gleich einen ganzen Strauß an Angreifertypen: Von Cryptominern wegen der Möglichkeit der Ressourcenübernahme über Ransomware-Gruppen wegen der Quellcodedateien und möglicher Zugangsdaten bis hin zu hochprofessionellen, zielgerichteten Angreifern und staatlichen Akteuren dadurch, dass die Software eine Art Infrastruktur darstellt.

Daher:

“Alle Patches einspielen. Immer. Sofort. Ohne Ausnahmen.” - Felix von Leitner, sagt aber auch das BSI

Was mich ein wenig ratlos zurücklässt ist die schiere Zahl und Kritikalität der gestopften Sicherheitslücken (35 CVEs binnen eines Monats laut Giteas eigenem Blog!). Aus meiner blauäugigen Sicherheitsperspektive ist diese Lösung ein Schweizer Käse und ich bin mir nicht sicher, ob ich Gitea weiter betreiben sollte.

Sofort: Härtung durchführen

Na klar: Gitea auf latest bringen und die oben beschriebenen Härtungsmaßnahmen durchführen.

Kurzfristig: Automatische Updates

In den nächsten Tagen und Wochen werde ich mich damit beschäftigen, die Docker Registry automatisch nach Updates für meine Software zu durchsuchen und sie ebenso automatisch auf meinem Server auszurollen. Blog-Post dazu hier.

Mittelfristig: Her mit Monitoring

Ich werde mich auf die Suche machen nach einer kleinen und leichten Monitoring-Lösung, die Auffälligkeiten wie “CPU-Last ungewöhnlich hoch seit HH:MM:SS” meldet und healthchecks durchführen und überwachen kann. Dabei darf sie selbst kein Einfallstor dastellen, muss also praktisch ohne Rechte auskommen. Ob das wohl einfach möglich ist?

Mittelfristig 2: Weg mit den Secrets

Unverschlüsselte Secrets haben in Repositories nichts verloren. Selbst auf dem Server selbst ist eine .env-Datei, die dort herumliegt, als nicht mehr sicher zu werten. Auch hier werde ich mir Gedanken machen und entsprechend berichten, wenn ich eine Lösung ausgerollt habe.

Mittelfristig 3: News-Feeds einrichten

Hierunter fallen Abos z.B. von Newslettern oder RSS-Feeds idealerweise aller meiner Softwareanbieter, IT-Security-Institutionen oder -Journalisten und weiteren Quellen, aus denen ich Sicherheitslücken, Patches und Maßnahmen zur Systemhärtung entnehmen kann.

Langfristig: Mit Leuten weiterhin ins Gespräch gehen

Es endet wie es beginnt. Bevor ich Probleme mit meiner Software lösen kann, bevor ich überhaupt von den Problemen weiß, ja genau da! Ganz am Anfang, bevor ich überhaupt entschieden habe, welche Software ich einsetze, da stehen: Andere Menschen.

Leute, die ich fragen kann, um Hilfe bitten kann. Deren Zeit ich in Anspruch nehmen darf für eigene Belange. Die ich zum Beispiel per Messenger aus dem Nichts heraus anschreibe und aus ihrem Fokus reiße.

Leute, die sich besser auskennen als ich, die einen anderne Blick auf die Dinge haben, oder deren Meinung ich interessant finde.

Kolleginnen, auch Ehemalige, Bekannte und Freunde, Familie, die ich zufällig oder zielgerichtet auf einen Austausch treffe. Auf einen Kaffee, ein Eis, ein Kaltgetränk, zum Musizieren oder für einen Brettspielnachmittag.

Leute, die mir trotz der Unterbrechung und doofer Fragen freundlich und geduldig helfen. Die vielleicht kurz mit den Augen rollen, mir die Dinge dann aber doch noch ein weiteres mal erklären. Die meine Monologe, kritische Nachfragen und gelegentliche Gegenrede irgendwie tolerieren.

Leute, mit denen ich in einen Austausch treten kann, der am Ende hoffentlich beiden Seiten nützt.

Bei euch allen möchte ich mich bedanken. Mit Leuten wie euch wird alles viel einfacher. Auch der Betrieb dieses Blogs, wo so viel meiner Zeit hineingeht. Ich kann mit euch Entscheidungen diskutieren, erfahren wie ihr Dinge gemacht habt und warum genau so, die Perspektiven wechseln. Und neue Ideen entwickeln.

Bitte bleibt mir erhalten.

Verweis an “Fefe” Felix von Leitner. Zitat: “Annahmen […]: Wir werden angegriffen. Wir merken es zeitnah. Aller Erfahrung nach: Nein, tun wir nicht. Typischer Zeitraum vor Entdeckung von blinden Passagieren: Ein halbes bis fünf Jahre.” - aus dem Vortrag Hackback, Link führt zu Codeberg. ↩︎

Gitea stürzt ab: Zu viele Anfragen

Schallbert — Mon, 30 Jun 2025

Hier möchte ich kurz darstellen, wie ein Absturz eines Dienstes meinen Server über Stunden wiederholt lahmgelegt hat. Und dies so gründlich, dass ich nur aus der Konsole des Anbieters überhaupt einen Neustart durchführen konnte. Ich erkläre, wie es dazu kam und wie ich dieses und ähnliche Probleme in Zukunft vermeiden möchte.

Ich wurde angegriffen. Oder?

Ich saß gerade an einem Artikel, den ich später posten wollte. Zur Sicherheit erstellte ich wie üblich einen Commit und wollte ihn auf meine Gitea-Instanz schieben. Doch mein git push Befehl lief einfach nicht durch.

Verwundert versuchte ich, meine Webseite aufzurufen. Zurück kam:

Merkwürdig. Anschließend wollte ich mich auf meinem Server einloggen, um nach dem Rechten zu sehen: ssh <servername>. Wieder blieb das Terminal ohne Reaktion. Mist!

Timeout. Als letzte Rettung meldete ich mich bei meinem Hoster an und schaute auf die Graphen des Servers:

Oh, was ist denn da los? Nun versuche ich über die Weboberfläche, den Server herunterzufahren. Klappt auch nicht. Erst ein harter Neustart ist erfolgreich. Ich kann mich wieder per SSH einloggen und sehe, dass auch alle Docker-Container wieder ganz normal hochfahren.

Was war passiert?

Gut, dass ich eine Woche lang alle Logs aufbewahre. So und über die Auslastung der Maschine über Zeit kann ich einigermaßen rekonstruieren, was passiert ist.

Welche Logs helfen?

Crash lokalisieren! Auslösende Anwendung finden im kern.log, Zeitstempel notieren.
Gibt es systemweite Auswirkungen oder andere Dienste, die beeinträchtigt werden? Im syslog nachsehen.
Falls der Verdacht aufkommt, das System sei möglicherweise gehackt worden: auth.log hat die Details.
Sollte die betroffene Anwendung im Container laufen, helfen entsprechende Logs dort möglicherweise weiter.
Logs der Anwendung selbst sichten. Besonders die Zeit kurz vor dem Crash ist interessant.

Und hier nochmal im Detail die Logs, die ich mir für meine Verhalten angesehen habe und wo sie zu finden sind.

log name	purpose	relevant content for this issue
/var/log/syslog	System-wide (bare metal) messages	(docker) warning: “health check for container `<ID>` timeout” (containerd) error: “ttrpc: received message on inactive stream”
/var/log/auth.log	Contains authentication messages from external hosts, in my case mostly SSH	None
/var/log/kern.log	Logs all app, service, daemon and system crashes	Out of memory: Killed process `<ID>` (`<serviceName>`)
[.]/gitea/log/gitea.log	Protocol for requests, actions on Gitea’s web interface, repo changes etc.	`GET` requests, crash/restart indications
docker container logs `<containerID>`	Docker’s logs for the container in question	Received signal 15; terminating. (SIGTERM)

kern.log/syslog

Hier sehe ich neben dem Stack trace, was genau passiert ist. Die am besten verständlichste Meldung ist folgende:

Out of memory: Killed process `<ID>` (gitea)

Gitea ist also der Stecker gezogen worden, weil es praktisch alle Systemressourcen gezogen hatte. Wenn ich im Log nach oben scrolle, sehe ich ein paar Minuten vorher:

<timestamp> <machineName> dockerd[716]: level=warning msg="Health check for container <ID>"
<timestamp> <machineName> dockerd[716]: level=error msg="stream copy error: reading from a closed fifo"

Bereits hier sehe ich Warnungen, dass der gitea-Container nicht sauber arbeitet. Ein weiterer Vorteil, den das Einbauen von “Healthchecks” in der docker-compose.yml Datei hat. Über Zweck und Einbau von Healthchecks in docker hatte ich aus anderen Gründen bereits einen Artikel verfasst.

gitea.log

Folgender Log-Eintrag zeigt wegen eines Bugs in einem Submodul indirekt an, dass Gitea gerade neu gestartet ist:

cmd/web.go:205:serveInstalled() [W] Table system_setting Column version db default is , struct default is 1

Und weiter oben im Log nun:

Sehr interessant. Die highlight.css liegt in meinem öffentlichen Repo. Auf ihrer Grundlage erhält die Seite lectures.schallbert.de ihr Aussehen. Diese Datei ist ziemlich groß, fast 1MiB. Und sie wird hier gleich zig male geladen, und das praktisch für jeden Commit.

Nun schaue ich mir weitere Crashes in der Vergangenheit an. Immer sind es bursts von GET-Befehlen auf große Dateien oder die Anforderung von compares zwischen zwei Branches des Repository, die einem Aufhängen meines Servers vorausgehen.

Wer steckt dahinter?

Alle crash-auslösenden Requests kommen aus dem selben IP-Adressraum. Die Abstürze starteten bereits vor ein paar Wochen. Zumeist aber zu Tageszeiten, die ich (und anscheinend auch viele meiner LeserInnen) nicht mitbekamen. Und nach ein paar Minuten war der Server stets wieder im Normalbetrieb.

Oha, die Spur führt zu Google’s Cloud Platform (GCP).

Aber ich hatte doch Robots ausgesperrt?

In der Tat hatte ich die Suchmaschinenindexierung für Gitea gestoppt. Merkwürdig. Oder habe ich es hier gar nicht mit einer der Google-spiders oder “KI”-Scraper, sondern mit einem fiesen Hacker zu tun, der sich bei “Google Cloud” eine virtuelle Maschine gemietet hat?

Log-Recherche: Wie häufig wird die Datei angefragt?

Ein Spider würde ja höchstens einmal alle paar Wochen alle meine Seiten durchsuchen, richtig? Und sich hoffentlich nicht über meine robots.txt hinwegsetzen. Erst recht nicht würde ein Crawler mehrfach und in kurzen Abständen denselben Request stellen, oder?

Zum dies zu prüfen, suche ich in den *Gitea Logs nach Einträgen von GET-Anfragen auf einer der großen und damit ressourcenintensiv zu übertragenen Dateien:

gunzip gitea.log.<date.rotateID>
grep "<filename>" gitea.log.<date.rotateID>

In der Liste sehe ich, dass dieselbe Anfrage auf dieselbe Zieldatei von derselben IP-Adresse mehrfach und binnen Sekunden gestellt wird. Kurz vor dem Crash benötigt mein Server schon fast 4sec, um die Anfrage zu bedienen.

Auch sehe ich, dass sich die IP-Adresse alle paar Stunden ändert.

Einen DoS-Angriff parieren

Zusammenfassend muss ich zum Schluss kommen, dass ich aus dem Adressraum des GCP per Denial-of-service angegriffen werde.

Um ein bisschen mehr Hintergrundwissen zu sammeln, besuche ich ein paar Websites zum Thema. Dort lerne ich, dass gitea auf meinem Server unter einer Application Layer Attack zusammenbricht. Jetzt da ich weiß, was passiert und wie das Problem heißt, fällt das Finden von Lösungen gleich viel leichter 😅

Ich will mich natürlich nicht kampflos ergeben, indem ich meine Gitea-Instanz dauerhaft vom Netz nehme. Also, welche Optionen habe ich?

Mehr Ressourcen bereitstellen

Zugegeben, meine Maschine hat nur 40GB Speicher und 2GB VRAM sowie eine mickrige 2-Kern CPU aus 2009. Ich könnte einen leistungsfähigeren Server buchen, um Lastspitzen besser abreiten zu können. Doch dies würde den Angriff nicht verhindern, sondern nur seine Auswirkungen abmildern.

Rate limiting direkt im Webserver

Rate limiter begrenzen die Anzahl Anfragen eines Clients innerhalb eines Zeitfensters. Dadurch werden die Ressourcen des Servers geschont. Dies ist eine “weiche” Abwehr von Dos-Attacken, denn auslösende IP-Adressen werden mit einer Fehlermeldung kurzzeitig und sanft abgewehrt. Üblicherweise wird HTTP status code 429 “Too Many Requests” zurückgegeben, wenn der Limiter eingreift.

Gitea verfügt über keinen Rate Limiter. In meinem Setup läuft Gitea hinter einem reverse proxy, der von meinem Caddyserver bereitgestellt wird. Hier also müsste ich ansetzen. Für Caddy gibt es Rate limiter nur als externe Module, welche manuell in xcaddy nachinstalliert und eingerichtet werden müssen.

Blocken mit IP-table Regeln

Hier könnte man sich erneut fail2ban hernehmen und mehrfache Anfragen derselben Ressource von einer IP-Adresse schlicht blocken. Gitea hat in der Dokumentation eine Beschreibung der Einrichtung. In meinem Falle müsste ich für die Umsetzung dort weitermachen, wo ich bereits einmal aufgegeben hatte und damit nicht nur SSH, sondern auch normale Seitenaufrufe überwachen.

Für mich klingt diese Lösung am Sinnvollsten, denn sie trennt klar Funktionen in verschiedene Anwendungen auf. Ich nutze ausschließlich bei mir bereits verfügbare Applikationen: Caddy würde die Zugriffslogs bereitstellen und fail2ban müsste sie lesen und Filter in der Konfoguration jail.local so setzen, dass es sich wie ein Rate Limiter verhält.

Jetzt schaue ich mal, wie ich Caddy entsprechend mit fail2ban verbinden kann. Den weiterführenden Artikel Fail2ban mit Caddy einrichten verlinke ich direkt mal 🙂