c4: Drei offene Lücken ohne Herausgeber

Im letzten Artikel zu c4 endeten wir mit einer offenen Frage: Vier hohe Funde waren behoben und veröffentlicht, aber kurz darauf hat codecentric das Repository archiviert. Aus demselben Lauf lagen noch drei kleinere Funde in der Warteschlange, und der private Meldeweg war mit dem Archiv tot. Wir hatten geschrieben, dass wir uns ansehen, welche Wege dann noch bleiben. Das ist die Antwort.

Worum es geht

Drei Funde aus dem Scan vom 24. Juli wurden nie behoben. Sie sind weniger schwer als die vier Kontoübernahme- und Injection-Lücken aus dem ersten Teil, aber real, und durch die Archivierung bleiben sie dauerhaft offen.

Keiner dieser Funde übernimmt für sich allein das System. Zusammen sind sie das, was eine Anmeldeseite angreifbarer macht: eine Adressenliste zum Durchprobieren, eine Weiterleitung fürs Phishing und eine Sitzung, die sich festnageln lässt. Für eine selbst gehostete Plattform, deren Anmeldung alles andere trägt, ist das kein Randthema.

Warum wir sie überhaupt öffentlich machen

Der normale Weg wäre: privat melden, der Maintainer behebt und veröffentlicht, wir berichten danach. Genau das ist bei den vier hohen Funden passiert. Für diese drei gibt es diesen Weg nicht mehr. Ein archiviertes Repository nimmt keine Meldungen und keine Korrekturen mehr an, und codecentric wird keinen Fix mehr bauen.

Damit stehen die Lücken ohnehin im Code, für jeden lesbar, der nachschaut. Wer die Software noch betreibt, erfährt aber von niemandem davon. Vertraulichkeit schützt hier kein Geheimnis mehr, sie hält nur die Betreiber im Dunkeln, die handeln könnten. Deshalb haben wir eigene Advisories geschrieben, eines pro Fund, mit Beschreibung, betroffenen Versionen und einem Patch, der sich sauber auf die letzte Version 10.0.2 anwenden lässt. Sie liegen in unserem Advisory-Repository unter den Kennungen KBS-2026-001 bis 003.

Der CVE-Weg führt über den Finder

Eine Lücke bekommt erst dann eine CVE-Nummer, wenn jemand sie beantragt. Üblicherweise macht das der Hersteller oder ein Projekt mit eigener Zuständigkeit. codecentric ist keine solche Stelle, und selbst wenn, würde ein archiviertes Projekt den Antrag kaum noch stellen.

Dafür gibt es die MITRE-Stelle für Fälle, die sonst niemand abdeckt. Ihr Antragsformular steht ausdrücklich auch Findern offen, nicht nur Herstellern. Wir haben für alle drei Funde eine CVE angefragt, mit unseren Advisories als öffentlicher Beleg. Vergeben werden die Nummern erst nach einem Review, nicht sofort. Sobald sie da sind, tragen wir sie hier und in den Advisories nach.

Wichtig zur Einordnung: Wir können eine CVE beantragen und veröffentlichen, aber nie ein Advisory im Namen von codecentric. Das eine ist eine Kennung mit einem Beleg, das andere wäre eine Aussage im Namen eines fremden Projekts.

Was Betreiber tun sollten

Wer die c4 GenAI Suite noch im Haus hat, kann an diesen drei Punkten konkret ansetzen.

Für alle drei Funde liegt in den Advisories ein Patch, der auf 10.0.2 passt. Wer einen eigenen Fork pflegt, spielt sie dort ein. Wer das nicht will, kann zwei der drei auch am Reverse Proxy entschärfen: Anfragen mit einem Pfad, der mit // oder /\ beginnt, ablehnen fängt den Open Redirect ab, und ein Ratenlimit auf die Anmeldung bremst das Durchprobieren von Adressen. Die Session-Fixation braucht den Code-Fix oder zumindest sauber getrennte Subdomains und durchgehendes HTTPS.

Darüber steht die größere Entscheidung, die schon im ersten Teil stand: Eine Software ohne Herausgeber weiterzubetreiben ist möglich, aber eine bewusste Entscheidung mit Aufwand, kein Zustand, in den man hineinrutscht. Wer bleibt, braucht einen eigenen Fork, jemanden für die Abhängigkeiten und einen Plan für den Wechsel.

Warum dieser Fall jetzt einen Namen trägt

Auf unserer Statusseite stand c4 schon unter dem Klarnamen, wegen der vier veröffentlichten Funde. Die drei hier haben wir bisher ohne Details geführt, nach unserer Regel, dass eine gemeldete Lücke anonym bleibt, solange sie offen ist. Diese Regel schützt Projekte, die noch an einem Fix arbeiten. Bei einem archivierten Projekt gibt es diesen Fix nicht mehr, und das Schweigen schützt dann niemanden außer der Lücke. Deshalb nennen wir sie jetzt.

Interessant an diesem Fall ist vor allem die Frage dahinter: Was passiert mit einer verantwortungsvollen Meldung, wenn das Gegenüber verschwindet? Die Antwort, die wir hier ausprobiert haben: selbst dokumentieren, einen anwendbaren Patch danebenlegen und über den Finder-Weg eine CVE beantragen, damit die üblichen Scanner den Fall überhaupt sehen. Das ist mehr Arbeit als ein privater Report, aber es ist der Unterschied zwischen einer Lücke, die stillschweigend im Netz steht, und einer, die benannt und behebbar ist.