Das Problem des stillen Patches: Warum ‚behoben‘ nicht ‚offengelegt‘ heißt

Ein stiller Patch ist die Behebung einer Sicherheitslücke, die ohne CVE, ohne veröffentlichtes Advisory und ohne Benachrichtigung an die Person ausgeliefert wird, die sie gemeldet hat. Für einen Verteidiger ist ein stiller Patch nicht von einer ausgebliebenen Behebung zu unterscheiden: Sie können ihn nicht zitieren, nicht überprüfen und nicht feststellen, ob die Version, die Sie einsetzen, ihn enthält. Eine vollständige Offenlegung ist mehr als gemergter Code. Sie besteht aus einem behobenen Build mit benannter Version, einer CVE-Kennung, einem veröffentlichten Advisory, einer Benachrichtigung an den Forscher und öffentlicher Anerkennung. Fehlt eines davon, ist „behoben“ nur eine private Behauptung, kein Sicherheitsergebnis.

Die meisten Programme zur Schwachstellen-Offenlegung (VDPs) behandeln den gemergten Pull Request als Ziellinie. Dabei ist er erst die Halbzeit. Die Hälfte aus Melden und Belohnen – Eingang, Sichtung, Prämie – bekommt die ganze Aufmerksamkeit und alle Werkzeuge. Die Hälfte aus Beheben und Offenlegen – der Teil, der erst beginnt, nachdem der Code behoben ist – ist die Stelle, an der selbst sorgfältige Programme klammheimlich scheitern. Das ist die Geschichte davon, erzählt anhand des klarsten aktuellen Beispiels dafür, bei dem genau das schiefgegangen ist.

Der Cursor-Fix, den niemand überprüfen konnte

Im Juli 2026 spaltete sich die Berichterstattung über eine Cursor-Schwachstelle an einer Frage, die niemals mehrdeutig sein sollte: War sie behoben oder nicht?

So lief es ab. Am 15. Dezember 2025 meldete die KI-Sicherheitsfirma Mindgard eine Schwachstelle zur Codeausführung unter Windows in der Cursor-IDE an [email protected]. Der Mechanismus ist in seiner Einfachheit heimtückisch: Eine bösartige git.exe, die im Wurzelverzeichnis eines geklonten Repositorys platziert wird, wird automatisch ausgeführt, sobald das Projekt geöffnet wird. Cursor führt git rev-parse --show-toplevel aus, und weil die Windows-Suchreihenfolge zuerst das Arbeitsverzeichnis und erst danach die Systempfade prüft, läuft die Binärdatei des Angreifers statt des echten Git – mit den Rechten des Entwicklers und ohne jede Rückfrage. Mindgard bestätigte die Verwundbarkeit bis einschließlich Cursor 3.2.16, getestet am 30. April 2026.

Dann wurde es still um die Meldung. Laut Mindgards Zeitleiste blieben Nachfragen im Februar, März und April 2026 unbeantwortet. Am 1. Juni 2026 kündigte Mindgard an, zu veröffentlichen. Am 14. Juli 2026 folgte die Tat – eine vollständige technische Aufarbeitung, 213 Tage nach der ersten Meldung.

Erst dann sagte ein Cursor-Sprecher gegenüber Dark Reading, das Unternehmen habe „das Problem am 13. Juli 2026 angegangen“ und werde Mindgard kontaktieren. Doch dieser angebliche Fix nannte keine behobene Version, brachte kein veröffentlichtes Advisory und trug keine CVE. The Hacker News sichtete Cursors veröffentlichte Security Advisories und fand mit Stand 15. Juli keinen Eintrag zu dem Problem. Cursor 3.11 war am 10. Juli erschienen – vor dem angeblichen Fix vom 13. Juli –, sodass der letzte öffentliche Build, auf den irgendjemand verweisen konnte, ihn nicht enthielt.

Deshalb berichteten seriöse Medien den Fehler als weiterhin ungepatcht, selbst nachdem der Anbieter ihn für behoben erklärt hatte. Beides war „wahr“, weil der Fix nur als nicht überprüfbare Behauptung existierte. Ein Patch, den niemand zitieren, bestätigen oder einer Version zuordnen kann, ist im operativen Sinne kein Patch. Genau dieser Widerspruch ist die ganze Lektion.

Was ist ein stiller Patch?

Ein stiller Patch ist eine Behebung, die eine sicherheitsrelevante Schwachstelle schließt, aber nie als Sicherheitsthema kenntlich gemacht wird: kein CVE, oft kein Advisory, manchmal in einem thematisch fremden Release vergraben. Der Code ändert sich; der Welt wird nie gesagt, was sich geändert hat oder warum. Eine vollständige Offenlegung besteht dagegen aus fünf Teilen:

1. Ein behobener Build mit benannter Version. „Behoben in 3.12.0“, nicht bloß „behoben“.
2. Eine CVE-Kennung, damit die Schwachstelle einen stabilen, durchsuchbaren Namen hat.
3. Ein veröffentlichtes Advisory, das die Schwachstelle, die betroffenen Versionen und die Gegenmaßnahme beschreibt.
4. Eine Benachrichtigung an den Forscher, dass der Fix ausgeliefert wurde.
5. Öffentliche Anerkennung für den Forscher, der sie gefunden hat.

Fehlt auch nur einer dieser Punkte, können Nutzer die einzige Frage nicht beantworten, die für sie zählt: Bin ich sicher, und in welcher Version?

Warum Anbieter das tun – harmlose und eigennützige Gründe

Die Gründe bewegen sich über ein ganzes Spektrum. Am harmlosen Ende: Ein Maintainer hat nie bemerkt, dass ein Fehler eine Sicherheitsdimension hatte, oder ein winziges Team hat keinen Prozess, um ein CVE anzufordern und ein Advisory zu schreiben. Am eigennützigen Ende: die Scheu, öffentlich einzugestehen, dass die Schwachstelle existierte, die Angst vor dem Eindruck nach außen oder die Hoffnung, dass eine stille Behebung das Problem verschwinden lässt.

Die Absicht ändert nichts am Ergebnis. Ob das Schweigen von einem überlasteten Maintainer oder einem nervösen PR-Team kommt – der Verteidiger am Ende der Kette bekommt dasselbe: einen Fix, den er nicht sehen kann.

Warum ein stiller Patch Angreifern hilft, nicht Ihnen

Ein stiller Patch schützt Nutzer nicht. Er verschafft Angreifern einen Vorsprung vor ihnen. Das ist der widersinnige Teil, und es lohnt sich, ihn klar auszusprechen.

Tod Beardsley von Rapid7 hat es so formuliert: „Wenn Sie still patchen, teilen Sie Details zur Schwachstelle ausschließlich versierten, kriminellen Angreifern mit.“ Hier liegt die Asymmetrie. Sobald ein Fix in eine öffentliche Codebasis gelangt, vergleichen motivierte Angreifer den behobenen und den unbehobenen Build per Diff, rekonstruieren die Schwachstelle aus der Änderung und machen sie zur Waffe – oft binnen Tagen. Diese Arbeit liegt problemlos in Reichweite jedes fähigen Gegners, der die Commit-Historie mit Absicht liest.

Verteidiger tun das nicht. Sie analysieren nicht jeden stillen Commit in jeder Abhängigkeit per Reverse Engineering. Sie verlassen sich auf Advisories, die ihnen sagen, was sich geändert hat und ob es zählt. Ein stiller Patch zieht also eine scharfe Trennlinie: Die Schwachstelle wird für die kleine Gruppe, die bereit ist, nach ihr zu jagen, vollständig sichtbar – und bleibt für die große Gruppe unsichtbar, die gepatcht hätte, wenn ihr nur jemand Bescheid gegeben hätte. Ausgerechnet die Leute, die planmäßig aktualisieren, die Advisories lesen, die alles richtig machen, bleiben ungeschützt – während die Angreifer diejenigen sind, die „benachrichtigt“ wurden.

Schweigen erkauft keine Sicherheit durch Verschleierung. Es erkauft dem Angreifer einen Vorsprung.

Die Hälfte des Lebenszyklus, die alle vergessen

Die meisten Teams modellieren den Offenlegungs-Lebenszyklus als: Meldung → Sichtung → Behebung. Das vollständige Modell hat drei weitere Schritte fest ans Ende geschweißt: → CVE → Advisory → Benachrichtigung. Dieser Nachlauf ist keine Höflichkeit. Normen schreiben ihn fest.

ISO/IEC 29147 (Schwachstellen-Offenlegung) und ISO/IEC 30111 (Umgang mit Schwachstellen) definieren die Pflichten des Anbieters, und ein veröffentlichtes Advisory ist ausdrücklich eine davon: eine Beschreibung der Schwachstelle, der betroffenen Versionen und der Gegenmaßnahme, idealerweise im maschinenlesbaren Format CSAF 2.0, damit Scanner und nachgelagerte Teams es automatisch verarbeiten können. Bei koordinierter Offenlegung erscheint das Advisory gleichzeitig mit oder kurz nach dem Fix. „Nie“ ist keine Option, die die Norm vorsieht.

Es gibt außerdem Fristen, und sie messen den gesamten Weg bis zur öffentlichen Offenlegung, nicht nur den Merge:

Das sind die in der Branche akzeptierten Fairness-Fenster. An jedem einzelnen davon gemessen ist eine im Dezember bestätigte Meldung, der im darauffolgenden Juli noch immer ein Advisory oder CVE fehlt, nicht „in Bearbeitung“. Sie ist nach jedem existierenden veröffentlichten Maßstab überfällig.

Ein CVE ist nicht optional – und Anbieter vergeben ihre eigenen

Die häufigste Ausrede für ein fehlendes CVE – dass die Vergabe schwierig oder abgeschottet sei – hält der Realität, wie das System tatsächlich funktioniert, nicht stand. CVE-IDs werden von CVE Numbering Authorities (CNAs) vergeben, und viele Anbieter sind ihre eigene CNA. Wo ein Anbieter das nicht ist, können CNAs von Drittanbietern, CERTs und Plattformen wie HackerOne stellvertretend vergeben. Anbieter zu sein ist kein Hindernis für ein CVE; es ist oft der einfachste Weg zu einem.

Cursors eigene Bilanz beweist es. Andere Cursor-Schwachstellen aus dem Jahr 2026 bekamen durchaus CVEs und Advisories: die MCP-Trust-Bypass-RCE von Check Point, die „DuneSlide“-Zero-Click-Prompt-Injection-RCEs von Cato Networks und die von SecurityWeek behandelten RCE-Schwachstellen auf Betriebssystemebene. Der Apparat existierte und funktionierte. Er wurde nur nie auf die git.exe-Meldung gerichtet. Damit ist das Schweigen eine Prozesslücke, keine Fähigkeitslücke – eine Entscheidung darüber, welche Meldungen die volle Behandlung erhalten und welche stillschweigend fallen gelassen werden.

„Behoben, aber nicht offengelegt“ ist ein SLA-Verstoß, kein geschlossenes Ticket

Hier ist die Umdeutung, die verändert, wie Sie ein Programm führen. Die meisten VDPs haben einen Endstatus, der bedeutet „wir haben es behoben“: resolved, fix_verified, closed, paid. Eine Meldung erreicht ihn in dem Moment, in dem der Patch gemergt wird, und das Ticket verschwindet vom Board.

Dieser Status ist eine Lüge durch Auslassung. Eine Meldung, die behoben ist, aber kein CVE, kein Advisory und keine Benachrichtigung des Forschers hat, ist nicht abgeschlossen. Sie verstößt – gegen die Arbeit des Forschers, gegen das Recht der Nutzer zu erfahren, dass sie gefährdet sind, und gegen die Normen, die definieren, was Offenlegung bedeutet. Die Cursor-Meldung war nach der eigenen Darstellung des Anbieters am 13. Juli „behoben“. Zugleich verstieß sie in allen drei Punkten. Beides war wahr, weil „behoben“ und „offengelegt“ unterschiedliche Zustände sind – und nur einer von ihnen verfolgt wurde.

Der Wirkungsradius macht die Kosten greifbar. Cursor hat mehr als 1 Million täglich aktive Nutzer, mehr als 1 Million zahlende Abonnenten und über 50.000 Unternehmen, die es einsetzen. Jeder von ihnen blieb während der gesamten Offenlegungslücke ohne Antwort auf die Frage „Bin ich sicher, und in welcher Version?“, weil die Antwort nie veröffentlicht wurde. Ein stiller Patch skaliert seinen Schaden mit der Größe der Nutzerbasis, die er im Dunkeln lässt.

Behandeln Sie „behoben, aber nicht offengelegt“ so, wie Sie eine verpasste Bestätigungs-SLA bereits behandeln: als Verstoß, der rot aufleuchtet, nicht als Ticket, das sich stillschweigend schließt.

Eine umsetzbare Offenlegungs-Checkliste

Die Leerstelle, die keine Vorfallberichterstattung füllt, ist die operative: Wie machen Sie es unmöglich, einen stillen Patch im eigenen Programm als erledigt zu verbuchen? Hier ist die Checkliste. Sie ist bewusst auf denselben Schienen umsetzbar, die Eingang und Sichtung bereits verfolgen.

1. Führen Sie einen Endstatus disclosed ein. Eine Meldung ist bei fix_verified nicht fertig; sie muss disclosed durchlaufen. Lassen Sie diesen Status den Abschluss genauso absichern, wie resolved es heute tut. Keine Offenlegung, kein Abschluss.
2. Lösen Sie bei fix_verified eine CVE-Anfrage aus. Der Übergang in „behoben“ sollte automatisch eine CVE-Anfrage anstoßen oder eröffnen – an Ihre Anbieter-CNA oder eine externe CNA – und die vergebene ID an der Meldung speichern. Keine ID, kein Abschluss.
3. Hängen Sie eine Advisory-Vorlage und einen Veröffentlichungsschritt an. Nutzen Sie Ihren öffentlichen Sicherheitsrichtlinien-Bereich erneut, um ein Advisory zu veröffentlichen – betroffene Versionen, Gegenmaßnahme und Anerkennung, im CSAF-Format aufbereitet, damit Maschinen es lesen können. Die Vorlage verwandelt „ein Advisory schreiben“ von einem leeren Blatt in ein Formular.
4. Setzen Sie eine Offenlegungsfrist darauf. Fügen Sie eine Offenlegungs-SLA hinzu – „Advisory veröffentlicht innerhalb von N Tagen nach fix_verified“ – und leiten Sie sie durch dieselbe Gefährdet- und Verstoß-Mechanik, die Sie bereits für die Bestätigung verwenden. Über N Tage hinaus wird daraus ein Verstoß auf dem Board, der an die Bereitschaft gemeldet wird, kein unsichtbares geschlossenes Ticket.
5. Bündeln Sie Anerkennung und Benachrichtigung. Verknüpfen Sie die Forscher-Anerkennung des Advisorys mit Ihrem Weg zu Hall of Fame und Reputation und senden Sie eine Nachricht „Ihre Meldung ist jetzt öffentlich“ über Ihr bestehendes Register der Forscherkommunikation. Der Kreis schließt sich bei der Person, die ihn eröffnet hat.

Führen Sie das durch, und eine Meldung kann „erledigt“ physisch nicht erreichen, solange sie ein stiller Patch ist. Das Status-Board erzwingt Offenlegung genauso, wie es bereits Sichtung erzwingt.

Wie Kit einen stillen Patch vom Board fernhält

Kits CSIRT-Vertical betreibt die Hälfte aus Melden und Belohnen eines VDP bereits auf SLA-Schienen, und genau das ist der Unterbau, den die Offenlegungs-Hälfte braucht. Um klarzustellen, was ausgeliefert ist und was dieser Artikel vorschlägt: Die SLAs für Bestätigung und schweregradabhängige Behebung, die Statusmechanik für Gefährdet und Überschritten, die Bereitschaftseskalation, auditierbare Statusübergänge, die nachgelagerte Compliance-Synchronisierung und der Weg zur Hall-of-Fame-Anerkennung sind allesamt verfügbare Funktionen. Kit hatte mit dem Cursor-Fehler nichts zu tun, und kein Werkzeug hindert einen Anbieter daran, schlechten Code zu schreiben.

Was Kits Architektur sehr wohl bietet, ist der Unterbau, der einen stillen Patch strukturell schwer zu verbergen macht:

• SLA-Fristen mit Gefährdet- und Überschritten-Zuständen, bereits angewandt auf Ziele für Bestätigung und schweregradabhängige Behebung. Auf demselben Fristenmechanismus läuft eine Offenlegungs-SLA: „Advisory veröffentlicht innerhalb von N Tagen“ durchläuft denselben Überschreitungs-Pfad.
• Bereitschaftseskalation, damit eine verstreichende Frist einen Menschen alarmiert, statt still zu altern – der Unterschied zwischen der Cursor-Meldung, die monatelang unbeantwortet liegen blieb, und einer überschrittenen Frist, die an die Oberfläche kommt.
• Auditierbare Statusübergänge pro Meldung, sodass das Hinzufügen eines disclosed-Zustands, der den Abschluss absichert, eine Erweiterung des bestehenden Lebenszyklus ist, kein neues System.
• Nachgelagerte Compliance-Synchronisierung und ein Weg zur Hall-of-Fame-Anerkennung, sodass die Forscher-Anerkennung eines Advisorys und die Benachrichtigung „Sie sind jetzt öffentlich“ auf bereits vorhandenen Schienen fahren.

Ein stiller Patch ist strukturell ein SLA-Verstoß, den kein aktuelles Werkzeug misst. Kit misst SLA-Verstöße bereits. Dieselbe Disziplin auf die Offenlegung zu richten, ist der richtige Schritt – und sie gehört auf dasselbe Board, das Bestätigung und Sichtung verfolgt.

Das Fazit: Offenlegung ist ein Statusübergang, kein Merge

Ein Programm zur Schwachstellen-Offenlegung ist nicht fertig, wenn der Patch ausgeliefert wird. „Behoben, aber nicht offengelegt“ ist ein Verstoß gegen die Meldung, gegen die Arbeit des Forschers und das Recht der Nutzer zu erfahren, was los ist – und es sollte rot aufleuchten, auf demselben Board, das Bestätigung und Sichtung verfolgt.

Die Cursor-Geschichte ist kein einmaliger Skandal. Sie ist der Standard-Fehlerfall jedes Programms, dessen Lebenszyklus klammheimlich bei „gemergt“ endet. Die Lösung liegt nicht in mehr Sorgfalt beim Beheben – diese Teams beheben bereits sorgfältig. Sie liegt darin, das CVE, das Advisory, die Benachrichtigung und die Anerkennung als verpflichtende Statusübergänge zu behandeln, die eine Meldung durchlaufen muss, bevor sie als erledigt gelten darf.

Wenn Sie die Eingangsseite aufbauen, beginnen Sie mit So richten Sie ein Programm zur Schwachstellen-Offenlegung ein. Was passiert, wenn die Beziehung schon vor dem Fix zerbricht, lesen Sie unter wenn Forscher an die Öffentlichkeit gehen und in unserer Sicht auf SLAs und Fairness bei Bug-Bounty-Auszahlungen. Und wenn Sie nach Europa verkaufen, verwandeln die verpflichtenden Offenlegungspflichten des EU Cyber Resilience Act den Advisory-Schritt von einer Best Practice in geltendes Recht. Das ist das Schlusskapitel von allen: Die Meldung ist erst erledigt, wenn sie offengelegt ist.