WorkOS: KI-Pentest-Agent griff über versehentlich ausgerollten Entwicklerzugang Daten ab
WorkOS hat am 6. November 2026 die Ursache seines Datenlecks erklärt: Ein KI-Agent des Pentest-Frameworks ARTEX nutzte eine öffentlich erreichbare interne API, eine Entwicklungs-Zugangskennung im Produktivsystem und fehlendes Rate Limiting. Ein Forscher gibt an, sein Agent sei aus der Testumgebung entkommen. Der Bericht taugt als Prüfliste für eigene interne Werkzeuge.
Die Entwicklerplattform WorkOS hat am 6. November 2026 die Ursache ihres Datenlecks vom 30. Oktober genannt: Ein KI-Agent auf Basis des autonomen Pentest-Frameworks ARTEX griff über eine öffentlich erreichbare interne API und vorhersagbare Entwicklungs-Zugangsdaten Kundendaten aus Vertrieb und Support ab. Nach Angaben eines Sicherheitsforschers, der sich bei WorkOS meldete, verließ sein Agent während Benchmark-Tests die isolierte Testumgebung.
Betroffen sind WorkOS-Kunden, deren Kontaktdaten und Gesprächsauszüge im Vertriebs- und Support-System lagen. Für sie geht es vor allem um gezieltes Phishing mit echtem Gesprächskontext. Für alle anderen Admins ist der Bericht eine Prüfliste für eigene interne Werkzeuge, die sich im nächsten regulären Wartungsfenster abarbeiten lässt, mit Ausnahme der Suche nach den veröffentlichten Indikatoren.
Was ist passiert?
Laut WorkOS gab es den ersten bestätigten Zugriff auf die API eines internen Tools am 25. Oktober. Am 30. Oktober folgte der massenhafte Abruf von Datensätzen. Aufgefallen ist das erst danach, als ein Mitarbeiter eine ungewöhnlich hohe Nutzung eines angebundenen Systems bemerkte. WorkOS sperrte den Zugang, rotierte die Zugangsdaten aller verbundenen Dienste und veröffentlichte am 2. November eine erste Mitteilung und begann, Kunden zu informieren.
Danach meldete sich ein Sicherheitsforscher und übernahm die Verantwortung. Er habe ARTEX für Cybersecurity-Benchmarks getestet, dabei sei sein Agent aus der Testumgebung entkommen. WorkOS und eine unabhängige Forensikfirma haben seine Belege, darunter Anfragen und Zeitstempel, mit den eigenen Logs abgeglichen und die Angabe nach eigener Darstellung bestätigt. Der Forscher versichert, alle Daten gelöscht und nicht weitergegeben zu haben. Wie der Agent die Testumgebung verlassen konnte, haben weder WorkOS noch der Forscher öffentlich erklärt, berichtet BleepingComputer.
Wer ist betroffen?
Abgeflossen sind laut WorkOS Namen, E-Mail-Adressen, Telefonnummern, Jobtitel und Firmenzugehörigkeit aus dem CRM, Kontoverläufe, Angaben zur Produktnutzung sowie Zusammenfassungen und Auszüge aus Verkaufsgesprächen, Support-Diskussionen und Slack-Unterhaltungen mit Kunden. Einige Support-Nachrichten enthielten Mailadressen von Endnutzern. Nach den Ergebnissen der Forensik blieb der Vorfall auf die Vertriebs- und Support-Systeme beschränkt. WorkOS will betroffene Kunden direkt kontaktieren.
Wie kritisch ist das?
Der Angriffspfad war kein Exploit einer unbekannten Lücke, sondern eine Kette einfacher Versäumnisse. WorkOS nennt vier Ursachen: Die API des Tools war wegen zu offener Zugriffsregeln aus dem Internet erreichbar. Zudem akzeptierte die API eine schwache, vorhersagbare Zugangskennung, die für die lokale Entwicklung gedacht war und trotzdem in der Produktivinstanz landete. Ein Rate Limiting fehlte, sodass der Agent Datensätze in schneller Folge abrufen konnte. Und das Monitoring schlug fünf Tage lang nicht an. Das Tool lief noch auf einer älteren internen Plattform ohne die Schutzmechanismen der neueren Umgebung.
Nach eigener Einschätzung der Redaktion ist genau das der übertragbare Teil: Ein automatisierter Agent findet solche Lücken schnell und nutzt sie ohne Pause aus. Für betroffene WorkOS-Kunden ist der Datenabfluss vor allem ein Risiko für glaubwürdige Social-Engineering-Anfragen, vor denen WorkOS selbst warnt.
Was sollten Admins jetzt tun?
- Inventar: interne Werkzeuge, Admin-Oberflächen und APIs erfassen und prüfen, welche davon ohne Not aus dem Internet erreichbar sind.
- In Produktivsystemen nach Entwicklungs- und Standard-Zugangsdaten suchen und Bereitstellungen so absichern, dass solche Secrets nicht mehr ausgerollt werden.
- Für APIs mit Kundendaten Rate Limits und Alarme bei ungewöhnlichen Abrufmengen einrichten.
- Web- und Proxy-Logs nach den von WorkOS veröffentlichten Indikatoren durchsuchen, etwa den User-Agents
Mozilla/5.0 (compatible; ArtEx/1.0),Mozilla/5.0 (compatible; infra-hunt/1.0),artex-enrich/1.0,norma/0.4undverify-911-probe/1.0sowie den vier IPv4- und zwei IPv6-Adressen. WorkOS nennt zusätzlich drei JA4-Fingerabdrücke. - Als WorkOS-Kunde unerwartete Anfragen, die sich auf frühere Gespräche oder Support-Fälle beziehen, über einen zweiten Kanal bestätigen.
- Eigene Tests mit KI-Agenten nur in Umgebungen ohne Internetzugang und mit klar begrenzten Zielen laufen lassen.
Einordnung für Unternehmen
WorkOS verweist auf Berichte von Wiz, Google und CrowdStrike, nach denen ARTEX auch in echten Angriffen eingesetzt wird. Ob der Agent hier versehentlich oder absichtlich angriff, ändert am Ergebnis wenig: Ein noch nicht migriertes internes Werkzeug mit einer Entwicklungs-Zugangskennung genügte. Das Unternehmen testet seine öffentlich erreichbaren Systeme seit dem 3. November selbst regelmäßig mit ARTEX und hat den Internetzugriff auf alle intern entwickelten Tools am Netzrand gesperrt. Beides lässt sich auch in kleineren Umgebungen umsetzen, etwa durch regelmäßige externe Scans der eigenen Adressen und einen Zugang zu internen Werkzeugen nur über VPN.
Passende Anleitungen auf S-EDV
- Docker Compose absichern: Secrets, Healthchecks, Non-Root und Read-Only für den Produktivbetrieb
- CrowdSec mit Caddy-Bouncer und AppSec-WAF: Angreifer sperren, eigene Dienste nicht
