Vibe Coding und CVSS 10.0: Wie weit fünfzehn Minuten reichen

Die Wette war: Seine Website sei sicher, ich komme da nicht rein. Fünfzehn Minuten später hatte ich eine CVSS-10.0-Schwachstelle. Kein Sicherheitswissen, nur Claude Opus 4.6 und eine grobe Idee, wo man anfängt.

Ich bin kein Sicherheitsforscher, und nichts davon war Expertenarbeit.

Die API liegt offen

Ich habe das Modell gebeten, die Website nach einer öffentlich erreichbaren API zu durchsuchen, und kurze Zeit später eine vollständige Übersicht bekommen. Öffentlich zugänglich, ohne Login. APIs zu finden ist normalerweise nicht das Schwierige, das kommt erst, wenn man etwas damit anfangen will: Ein Token mit Admin-Rechten ist in den meisten Systemen keine einfache Sache. Hier war es keine große Hürde.

In drei Minuten zum Überblick

Mit dem Token ging es schnell: in unter drei Minuten hatte ich mehrere Systeme auf dem Tisch, und Unternehmensdaten, die eigentlich hinter Zugangsprüfungen liegen sollten, waren in verschiedenen Bereichen aufrufbar. Das System hat nicht gefragt, wer ich bin. An mehreren Stellen fehlte die Rollenprüfung komplett, auch dort, wo sie zwingend gewesen wäre.

Tiefer im System, in unter zehn Minuten

Ich habe weitergemacht. Keine fünf Minuten nach dem ersten Einblick hatte ich Zugriff auf Verwaltungsbereiche, die einer Admin-Rolle vorbehalten sein sollten, und die entsprechenden APIs waren flächendeckend offen, ohne wirksame Rollentrennung und ohne Prüfung der Berechtigung.

An dem Punkt habe ich aufgehört. Es war ein geschlossenes Testsystem, keine strafbare Handlung, nur die Frage, wie weit man kommt.

Was CVSS 10.0 heißt

Das Common Vulnerability Scoring System bewertet Sicherheitslücken auf einer Skala von null bis zehn. Ein Score von 10.0 ist das Maximum: vollständiger Systemzugriff möglich, keine Authentifizierung nötig, kein komplexer Angriff erforderlich. All das traf hier zu.

Was mit einem einzelnen Zugriff ohne Authentifizierung begann, wuchs durch mehrere offene Endpunkte zur vollständigen Systemübernahme. Einzeln wäre jede Lücke noch überschaubar gewesen, in der Kette nicht mehr. Mit diesem Zugriff wäre die gesamte Infrastruktur kompromittierbar gewesen: alles, was eine Admin-Rolle tun könnte, stand offen, ohne Fachkenntnisse, ohne Account, nur mit einem KI-Modell.

Wo Vibe Coding versagt hat

Vibe Coding beschreibt das schnelle Bauen von Software mit KI-Unterstützung, ohne tief in den Code einzutauchen. Das Ergebnis läuft, das Interface sieht gut aus, und was dabei oft fehlt, ist die Frage, wer welche Aktion tun darf und ob das bei jedem API-Call auch wirklich geprüft wird. Über das Thema haben wir aus einem anderen Blickwinkel schon einmal geschrieben.

Das ist kein Vorwurf gegen den Kollegen, diese Fehler entstehen, wenn der Fokus auf dem liegt, was das System tun soll, nicht darauf, was es verhindern soll. Wenn die Frage nach Berechtigungen nie gestellt wird, fehlt die Antwort im Code.

Rollenbasierte Zugriffskontrolle auf der API hätte die meisten dieser Wege von Anfang an versperrt: jeder Call prüft dann, wer fragt und ob das erlaubt ist, und ein Logging mit aktiver Überwachung hätte ungewöhnliche Zugriffe sichtbar gemacht, bevor größerer Schaden entsteht. Das ist Grundhygiene.

Broken Access Control ist nichts Neues. OWASP listet es als das Sicherheitsrisiko Nummer eins, seit Jahren ganz oben. Hier war die Berechtigungs-Prüfung nicht konsequent umgesetzt, und zwischen Gast, User und Admin wurde schlicht nicht unterschieden.

Wenn man die gefundenen Lücken nebeneinander legt, zeigen sich Muster, die in Vibe-Coding-Projekten wiederkehren:

• Admin-APIs akzeptierten die normale Kundenrolle als ausreichend und lieferten Verwaltungsdaten aus.

• API-Keys mit leerem Permissions-Feld hatten nicht etwa keine Rechte, sondern alle.

• Der Health-Endpoint verriet die genaue Version der Anwendung.

• Die Content-Security-Policy erlaubte es Fremd-Seiten, die Anwendung in einen iframe zu packen. Das ist die Einladung für Clickjacking.

• Rate-Limits waren an mehreren Stellen zu niedrig, um Missbrauch wirksam zu bremsen.

Was mir am längsten nachgegangen ist: der Bypass durch das leere Permissions-Feld. Ein Default-Wert, der in die falsche Richtung kippt. Niemand programmiert das absichtlich so. Es passiert, weil niemand die Frage gestellt hat, was bei einem leeren Feld eigentlich passieren soll.

Der Call danach und das Live-System

Nachdem ich die Schwachstelle gefunden hatte, haben wir uns zu einem intensiven Call zusammengesetzt, in dem ich ihm Schritt für Schritt gezeigt habe, wie die Angriffskette abgelaufen ist. Ich habe ihm damit eine schlaflose Nacht bereitet, und er hat sich trotzdem bedankt, dass ich es gefunden habe.

Ernster war noch etwas anderes: Die Schwachstelle war nicht nur auf dem Testsystem offen, sie ließ sich auch auf dem Live-System reproduzieren. Echte Daten, echte Infrastruktur, dieselbe Lücke. Er hat sich umgehend mit seinem Team an die Beseitigung gesetzt. Ich habe gefunden und dokumentiert, gelöst haben sie es intern, innerhalb weniger Tage.

Das eigentlich Erschreckende

Die Schwachstelle selbst ist nicht das Problem, das Problem ist die Geschwindigkeit. Fünfzehn Minuten, ein KI-Modell, keinerlei Ahnung von Sicherheitsforschung. Jemand mit schlechten Absichten hätte weniger Zeit gebraucht.

KI-Modelle senken die Hürde, Systeme zu analysieren, für uns, aber eben auch für andere. Wer früher Fachwissen gebraucht hätte, kann heute ein Modell fragen, und wenn die Infrastruktur diese Fragen beantwortet, ohne zu prüfen, wer fragt, wird das irgendwann jemand ausnutzen.

Und was dann passiert, ist kein technisches Problem mehr. Unternehmensdaten sind von einem Moment auf den nächsten unwiderruflich weg, der wirtschaftliche Schaden ist sofort real, und mit ihm die rechtlichen Konsequenzen: DSGVO-Meldepflicht, Schadensersatz, Vertrauensverlust. Das alles tritt ein, bevor überhaupt klar ist, wer angegriffen hat. Die Lücke zu finden war besser als das Gegenteil, auch wenn es eine schlaflose Nacht gekostet hat.

Wer einen Shop oder eine eigene Anwendung mit Custom-Code betreibt, sollte Access Control nicht dem Vibe überlassen. Wenn du dir unsicher bist, ob dein Setup an solchen Stellen sauber ist, melde dich bei uns. Wir machen Code-Reviews mit genau diesem Fokus.