Beim Reverse Engineering eines Legal-AI-Tools im Wert von einer Milliarde US-Dollar wurden mehr als 100.000 vertrauliche Dateien offengelegt

• Bei der Analyse der API der Rechts-KI-Plattform Filevine wurde eine schwerwiegende Schwachstelle entdeckt, die vollen Administratorzugriff ohne Authentifizierung vergab.
• Der Forscher nutzte Subdomain-Enumeration, um die Unterdomäne margolis.filevine.com zu finden, identifizierte den AWS API-Endpunkt und sendete Testanfragen.
• Bei einer einfachen POST-Anfrage wurde eine Antwort ohne Authentifizierungs-Token zurückgegeben, die ein Administrator-Token mit Vollzugriff auf das gesamte Box-Dateisystem enthielt.
• Mit diesem Token konnten rund über 100.000 „confidential“-Dokumente gefunden werden, darunter äußerst sensible Daten aus den Bereichen Medizin, Recht und Gehaltsabrechnung.
• Filevine reagierte nach der Meldung sofort mit der Behebung; der Fall zeigt die Bedeutung der Sicherheitsverwaltung bei KI-basierten Rechtsdiensten.

---

Entdeckung und Offenlegung der Schwachstelle

• Am 27. Oktober 2025 meldete der Forscher die Schwachstelle per E-Mail an das Sicherheitsteam von Filevine.
  • Am 4. November erkannte Filevine das Problem und antwortete mit einem zügigen Patchplan.
  • Am 20. November prüfte der Forscher die Patch-Implementierung und teilte mit, dass er den Blog-Beitrag veröffentlichen werde.
  • Am 21. November bestätigte Filevine die Fertigstellung des Patches und bedankte sich.
  • Am 3. Dezember wurde der Beitrag im technischen Blog veröffentlicht.
• Filevine zeigte eine schnelle und professionelle Reaktion über den gesamten Prozess hinweg und wird als Best Practice für verantwortungsbewusste Sicherheitsveröffentlichungen angesehen.

Hintergrund: Filevine und der Markt für juristische KI

• Filevine ist eine schnell wachsende Legal-AI-Plattform mit einer Bewertung von über 1 Milliarde US-Dollar.
• Rechtsanwaltskanzleien verarbeiten auf dieser Plattform äußerst vertrauliche Daten.
• Der Forscher hatte durch seine Projekterfahrung an der Yale Law School die Gelegenheit, die Daten-Sicherheitsarchitektur von Filevine zu prüfen.

Ablauf des Reverse Engineerings

• Aufgrund der Zugriffsbeschränkungen von Filevine nutzte der Forscher Subdomain-Enumeration, um eine öffentliche Demo-Umgebung zu finden.
• Er entdeckte die Unterdomäne margolis.filevine.com, doch die Seite lud nicht, daher analysierte er mit den Chrome-Entwicklertools die Netzwerk-Anfragen.
• In einer JS-Datei wurde der Code POST await fetch(${BOX_SERVICE}/recommend) gefunden und bestätigt, dass die BOX_SERVICE-Variable auf einen AWS API-Endpunkt zeigt.
• Als die Anfrage {"projectName":"Very sensitive Project"} an /prod/recommend gesendet wurde, wurde eine Antwort ohne Authentifizierung zurückgegeben.

Offenlegung des Admin-Tokens und Auswirkungen

• Die Antwort enthielt ein Box-API-Administrator-Token (boxToken) mit Vollem Zugriff.
• Dieses Token ermöglichte Zugriff auf das gesamte interne Box-Dateisystem einer Kanzlei.
  • Damit waren alle Daten, wie Dokumente, Protokolle und Benutzerdaten, einsehbar.
• Bei der Suche nach dem Schlüsselwort “confidential” wurden rund 100.000 Ergebnisse zurückgegeben.
• Der Forscher stoppte sofort die weiteren Tests und meldete die Schwachstelle an Filevine.
• Hätte ein böswilliger Angreifer dieses Token genutzt, hätten HIPAA-geschützte Dokumente, gerichtliche Anordnungen und interne Gehaltsunterlagen offengelegt werden können.

Sicherheitshinweise

• Im Konkurrenzkampf um KI-Einführung ist es für Unternehmen essenziell, ihre Datenschutz- und Sicherheitsstrukturen zu verstärken.
• Insbesondere KI-Dienste in besonders sensiblen Sektoren wie Recht und Medizin müssen strikte Sicherheitsprüfungen aufrechterhalten.
• Dieser Fall zeigt klar, welche Risiken ein Versagen bei Authentifizierungs- und Berechtigungsverwaltung in KI-basiertem SaaS verursachen kann.

[GN⁺]

Hacker-News-Kommentar

• Es überrascht mich immer wieder, dass es so lange dauert, solche offensichtlichen Sicherheitslücken einzuordnen und zu beheben.
  Offenlegung am 27. Oktober und E-Mail-Bestätigung erst am 4. November – in der Zwischenzeit war praktisch das gesamte Client-Dateisystem offengelegt.
  Der eigentliche Fix war vermutlich ein Patch von weniger als einer Stunde; selbst mit QA-Tests sollte das nicht so lange dauern.
  Man fragt sich, ob security@-E-Mails von niemandem gelesen werden, ob jemand im Urlaub war oder ob so viel Spam eingeht, dass echte Probleme untergehen.

  • Meiner Erfahrung nach liegen solche Verzögerungen an Organisationsstruktur und Projektmanagement-Problemen.
    Das Security-Team betreut die security@-Mailbox, aber das Team, das den Bug tatsächlich beheben muss, ist ein anderes, wodurch die Weitergabe kompliziert wird.
    Allein das Team zu finden, dem der Code gehört, dauert Wochen, und bei vollen Roadmaps ist es schwer, die Priorität hochzusetzen.
    Wenn dann noch die Freigabe der Rechtsabteilung nötig ist, verzögert sich die Reaktion weiter.
    Clevere Unternehmen geben dem Security-Team Notfallbefugnisse, aber wenn das missbraucht wird, entsteht intern schnell Ermüdung.
  • In den meisten Fällen geht es weniger darum, dass „niemand die Security-Mailbox liest“, sondern darum, dass eine Person, die sich damit auskennt, gleichzeitig 12 andere Dinge bearbeitet.
    Der Security-Patch ist ein Fix von einer Stunde, aber wegen interner Freigaben und der Suche nach dem Code-Owner dauert es zwei Wochen.
    Das eigentliche Problem ist am Ende die Entropie der Organisation.
  • In der security@-Mailbox landen heute einfach zu viele gefälschte Reports.
    LLMs erzeugen plausibel wirkende Schwachstellenberichte, sodass Fachleute manchmal Stunden verschwenden.
    Deshalb prüfen manche Unternehmen solche Mails nur während der Arbeitszeit.
  • Spam gibt es tatsächlich viel, aber nur ein paar Mails pro Tag – kein Grund, so eine schwere Schwachstelle nicht sofort zu patchen.
    Wahrscheinlich war, wie gesagt, die zuständige Person im Urlaub.
  • In dem globalen Response Center, in dem ich arbeite, sitzen 600 Leute, und es gibt 26.000 priorisierte Issues.
    Je komplexer Systeme werden, desto mehr Probleme entstehen statt weniger.
    Letztlich arbeiten wir alle unter der Illusion, dass „wir das schon bewältigen können“.

• Wenn dieses Unternehmen mit 1 Milliarde Dollar bewertet wurde, hätte allein diese grundlegende Schwachstelle einen Schaden in dieser Größenordnung verursachen können.
  Wenn sie von jemand Böswilligem entdeckt worden wäre, hätte das irreparabel sein können.
  Es hätten sämtliche Kundendaten abfließen können, also hätte man dem Entdecker eine Belohnung zahlen sollen.

  • Genau. Solche Schwachstellen könnten an Ransomware-Gruppen verkauft und für Hunderttausende Dollar gehandelt werden.
    Danach wären Datenabfluss, Erpressung, Klagen und Bußgelder gefolgt.
    Deshalb wenden sich manche Hacker statt an Whitehats lieber an den Grauen Markt.
  • Dafür hätte es wirklich eine große Belohnung geben müssen.

• Ich arbeite bei einem Finanzunternehmen, und alle wundern sich, warum man Kundendaten SaaS X anvertraut, aber bei AI SaaS Y keine Steuerunterlagen hochladen darf.
  Meiner Meinung nach wirkt die AI-Branche derzeit wie der Wilde Westen.
  Alles entwickelt sich so schnell, dass Sicherheitsprozesse ausgelassen werden.
  Dieser Vorfall zeigt das sehr deutlich.

  • FileVine ist zwar ein Legal-AI-Tool, aber dieses Problem hatte nichts mit AI selbst zu tun.
    Es sieht einfach nach einem Problem bei der Box-API-Integration aus.
  • Zur Einordnung: Das Unternehmen wurde 2014 gegründet und hat LLM-Funktionen erst vor Kurzem ergänzt.
    Reuters-Artikel
  • Wenn SaaS X IAM-Funktionen bereitstellt und eigene Zugriffsrichtlinien durchsetzt, ist das vergleichsweise sicher.
    Wenn SaaS Y dagegen nur sagt „Vertrau uns deine Daten an, das ist sicher“, wäre ich misstrauisch.
  • Aber eigentlich sollte man zuerst fragen, warum man SaaS X überhaupt vertraut hat.
  • Das Interessante ist, dass diese Schwachstelle nichts mit AI zu tun hatte und bei praktisch jedem SaaS-Unternehmen hätte auftreten können.

• Dieser Vorfall ist ein Zusammenprall von „Startup-Kultur, in der APIs schnell zusammengeklickt werden“ und „Rechts- und Gesundheitsbranchen, in denen ein Datenleck das Leben ruinieren kann“.
  Das Bug-Muster stammt gefühlt aus den 2010ern, wird aber mit AI-Marketing von 2025 überdeckt.
  Durch die Zentralisierung von Dokumenten für das Training von AI-Modellen wird der potenzielle Schaden im Fall eines Vorfalls viel größer.
  Im Vertrieb muss der Datenzugang leicht sein, um Deals abzuschließen, daher wird das Prinzip der geringsten Rechte nach hinten verschoben.
  Am Ende glauben Anwälte, sie kaufen einen „AI-Assistenten“, tatsächlich geben sie aber externen Zugriff auf das gesamte institutionelle Gedächtnis.
  Die eigentliche Frage ist: „Wie viele dieser Systeme würden einen echten Red-Team-Test bestehen?“

  • Schon ein bisschen komisch. Das Unternehmen veranstaltet eine Cybersecurity-Show und baut gleichzeitig ein LLM-Wurmloch, das alles umgeht.
    Das Problem ist, dass nichttechnische Führungskräfte AI nicht verstehen und nur Marketingparolen rufen.
    Immerhin gefällt mir, dass ich zweimal eine Weltraum-Metapher benutzt habe.

• Das Filevine-Team hat während des gesamten Offenlegungsprozesses professionell und schnell reagiert.
  Es hat die Schwere des Problems anerkannt, es behoben und transparent kommuniziert.
  Deshalb finde ich, dass man in solchen Fällen den Firmennamen nicht unbedingt öffentlich nennen muss.
  Wenn das Problem gelöst wurde, muss man das Unternehmen nicht noch extra bloßstellen.

  • Aber bei einem Responsible-Disclosure-Verfahren ist es üblich, den Firmennamen zu nennen.
    Nur so kann die Branche sehen, welche Unternehmen Meldungen ernst nehmen.
  • Ethische Offenlegung bedeutet, dass beide Seiten die technischen Details gemeinsam veröffentlichen.
    Das bleibt dann als gutes Beispiel für Hacker und Unternehmen bestehen.
  • Wenn man Fehlverhalten verschweigt, verliert man Transparenz und Vertrauen.
  • Bei einem so ernsten Problem wie diesem sollten Kunden Bescheid wissen.
    Außerdem könnten andere AI-SaaS-Anbieter denselben Fehler vermeiden, wenn sie diesen Beitrag lesen.

• Sicherheitszertifizierungen wie SOC2 und HIPAA wirken wie eine Art „Security-Theater“.
  Die wirklich wichtigen Punkte werden ignoriert, stattdessen gibt es formale Screenshots und Dokumentationsarbeit im Übermaß.

  • SemiAnalysis hat solche Zertifizierungen als so wichtig wie eine FAA-Zulassung dargestellt, wurde dann aber selbst wegen einfacher fehlender Sicherheitskontrollen gehackt.
    Passender Beitrag
    Am Ende sind das keine echte Sicherheit, sondern nur per Geld gekaufte Checklisten-Häkchen.

• Bei Security-Software gibt es in Sachen Usability und Komplexität weiterhin viel Verbesserungsbedarf.
  Als ich bei Google und Meta gearbeitet habe, waren die ACL-Systeme so komplex, dass ich vier Jahre gebraucht habe, um sie wirklich zu verstehen.
  Solche Systeme sind für nichttechnische Unternehmen völlig unbenutzbar.
  Deshalb bekomme ich eher Lust, ein Startup zur Vereinfachung von Sicherheit zu gründen.
  Das scheint mir ein viel schwierigeres Problem zu sein als AI.

• Es ist wirklich gut, dass dieses Unternehmen die Veröffentlichung des Blogposts erlaubt hat.
  Ich habe früher auch einmal eine große Schwachstelle gefunden, aber das Unternehmen hat die Veröffentlichung verhindert.

  • „Braucht man dafür überhaupt Erlaubnis?“ Man kann es einfach verantwortungsvoll offenlegen.
  • Warum sollte das Unternehmen die Kontrolle über die Veröffentlichung haben? Wenn man den Meldeprozess eingehalten hat, sollte man danach frei darüber schreiben können.

• Dieser Angriff war überhaupt nicht ausgefeilt.
  Filevine schreibt auf seiner Website, dass es Penetrationstests durchführt, daher ist es kaum zu glauben, dass so etwas übersehen wurde.
  Es wirkt, als hätte man Bug Bounties mit Penetrationstests verwechselt.
  Dafür gibt es wirklich keine Entschuldigung.

• Es gibt derzeit so viele Startups im Bereich „Healthcare + AI“, dass ich befürchte, wir werden in den nächsten Monaten ein großes HIPAA-Datenleck erleben.
  Verwandte Beispiele finden sich auch in diesem Thread.