Fünf Timeout::Error-Events von einem einzigen Client innerhalb von dreißig Minuten, alle aus dem OtherMarkup-Renderer, während er auf .org-Dateien herumkaut. Das ist die Schwelle, die GitLabs Security-Team vorschlägt, um Angriffsversuche auf CVE-2026-110264 zu erkennen, und sie geht mir nicht aus dem Kopf. Die meisten GitLab-Instanzen, die ich über die Jahre administriert habe, haben nie absichtlich auch nur ein einziges Org-mode-Dokument gerendert. Jede einzelne davon hätte aber eins für einen anonymen Fremden gerendert, und genau das ist, wie sich jetzt zeigt, das ganze Problem.

Zuerst die Fakten, kurz, denn die brauchst du vor allem anderen. Am 21. Oktober 2026 hat GitLab außerhalb des regulären Zyklus einen kritischen Patch für CE und EE veröffentlicht: 19.5.1, 19.4.3, 19.3.6, 19.2.9, 19.1.9, 19.0.10 und 18.11.13. Der Bug ist ein Integer Overflow (CWE-190) in der Art, wie Rubys Regex-Engine Onigmo mit Patterns umgeht, die angreiferkontrollierter Org-Content über org-ruby formen kann. Eine Größenberechnung läuft über, Speicher wird angefasst, wo er nichts zu suchen hat, und unter den richtigen Bedingungen bekommt ein nicht authentifizierter Nutzer Codeausführung auf dem Server. Der Vektor lautet CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:H, das ergibt glatte 10.0. Betroffen ist alles bis zurück zur 7.0-Linie. GitLab.com und die genannten Dedicated-Versionen sind bereits gefixt. Wenn du selbst hostest: Hör auf zu lesen, mach das Upgrade und komm dann zurück. Und prüf, ob Puma und Sidekiq wirklich mit dem neuen Build neu gestartet sind, denn ein Paket, das zwar installiert ist, aber nicht läuft, hat gar nichts repariert.

Was mich stört, ist weniger der Overflow selbst als die Stelle, an der das Loch war. Speicherfehler in Regex-Engines, die in C geschrieben sind, sind eine alte, vertraute Sorte Ärger, und ich gönne der Go-Fraktion ein, zwei Sätze lang ihre Selbstzufriedenheit wegen der Bounds Checks. Was mich nicht loslässt: Eine Code-Forge, also ein Werkzeug, dessen Job es ist, unseren Quellcode und unsere Deploy Keys zu verwahren, hat für nicht authentifizierte Besucher einen Nischen-Dokumentrenderer laufen lassen, und dieser Pfad führte direkt in nativen Code. Niemand in einem typischen Plattformteam hat sich je hingesetzt und beschlossen, dass anonyme Nutzer den Server dazu bringen dürfen, Regexes aus Emacs-Notizen zu kompilieren. Das kam im Paket mit „wir rendern deine README hübsch“, das klang harmlos, und jahrelang war es das auch.

Der stärkste Einwand verdient ein faires Gehör, denn ich stimme ihm halb zu. Du kannst nicht vorhersagen, welcher Parser den nächsten Bug hat. Wirf Org-mode raus, und im nächsten Quartal ist es AsciiDoc, der Markdown-Sanitizer oder der Thumbnail-Generator. Die Leute, die in Org-Dateien leben, sind echte Nutzer mit echten Bedürfnissen, und ein Anbieter, der nur das absolute Minimum ausliefert, liefert am Ende ein schlechteres Produkt. Patchen ist die einzige Lösung, die skaliert, und GitLab hat sieben Branches im selben Release gepatcht. Das ist fair. Wenn du daraus mitnimmst, jedes Feature bis auf ein nacktes Textfeld abzuspecken, verlierst du diese Diskussion gegen deine Nutzer, und zwar völlig zu Recht.

Meine Antwort darauf: Es muss nicht alles oder nichts sein. Entscheidend ist, wer den Renderer überhaupt erreichen kann. Ein Renderer, den nur authentifizierte Projektmitglieder auslösen können, ist ein Bug, der auf einen Insider wartet. Ein Renderer, den jeder Client im Netz ohne Login auslösen kann, ist ein Bug, der auf das ganze Internet wartet, und genau das sagen dir AV:N und PR:N im Vektor-String. Nischenformate auf öffentlichen, nicht authentifizierten Pfaden sollten pro Instanz opt-in sein und als Zeile im Admin-Panel auftauchen, die du abschalten kannst. Im Moment sind sie eine emergente Eigenschaft des Abhängigkeitsbaums. Die Hinweise zur Erkennung machen den Preis greifbar: Ein nativer [BUG]-Crash mit Frames wie onig_compile oder match_at ist der laute Ausgang, und GitLab sagt ganz offen, dass ein erfolgreicher Exploit leise ablaufen kann. Aus einem Pfad, von dem du nichts wusstest, kannst du dich nicht mit Monitoring herausretten.

Jetzt dreh das Ganze um und richte es auf unseren eigenen Code, denn PHP-Apps stecken voller genau dieses Musters. Wir bauen PCRE-Patterns aus Nutzereingaben, in Suchfiltern, Highlight-Helpern und Routing-Tabellen. Wir liefern BBCode- und Markdown-Parser aus, Wiki-Syntax-Erweiterungen und „Füg einfach alles ein“-Vorschauen, oft auf Seiten, die keinen Login verlangen. Die PHP-Seite gibt dir ordentliche Leitplanken: preg_quote gibt es, pcre.backtrack_limit gibt es, und die Engine wird seit Jahren gehärtet. Leitplanken helfen aber nur auf Codepfaden, an die sich noch jemand erinnert. Ich wette einen guten Kaffee, dass die meisten gewachsenen Laravel- oder Symfony-Codebasen mindestens einen öffentlichen Endpoint haben, dessen Rendering-Pipeline niemand im aktuellen Team je gelesen hat.

Also ja: zuerst patchen, deine Workhorse- und Sidekiq-Logs sichern, bevor du zu eifrig neu startest, und Tokens rotieren, wenn die Instanz offen im Netz stand und im Audit-Log irgendetwas komisch aussieht. Dann nimm dir einen Nachmittag für die weniger glamouröse Arbeit: Schreib jedes Format und jede nutzerbeeinflusste Regex auf, die deine Systeme für jemanden verarbeiten, der sich nicht angemeldet hat, und frag bei jedem Eintrag, ob er seinen Platz verdient. Die Liste ist schnell geschrieben. Erst wenn du Einträge davon streichen willst, fängt die eigentliche Diskussion an.

Und damit zu dem, was ich gern von dir hören würde. Als du zuletzt ein selbst gehostetes Tool oder deine eigene App auditiert hast, bist du da auf einen Renderer oder Parser gestoßen, der für anonymen Traffic offen war, ohne dass irgendwer erklären konnte, wozu? Und als du vorgeschlagen hast, ihn abzuschalten, wer hat sich dagegen gewehrt, und hatte die Person recht?