Wie Hacktron Rocket.Chat rund um die Uhr absichert

30.06.2026
Rocket.Chat
Hacktron Review

7 Min.

Durchschnittlich 1 bis 2 Minuten: für die Sicherheitsprüfung eines PR
17 echte Schwachstellen: in den ersten 20 Tagen gefunden und triagiert
73 % der gefundenen Probleme: waren handlungsrelevant und wurden bearbeitet

„Wir können Sicherheitsscans jetzt auf alle unsere PRs ausweiten.

„Hacktron markiert mögliche Probleme, sodass wir unseren Review-Aufwand auf die Pull Requests konzentrieren können, die mehr Aufmerksamkeit brauchen.“

Julio Araujo
Leiter Sicherheit

Über Rocket.Chat

Rocket.Chat ist eine quelloffene, vollständig anpassbare Kommunikationsplattform, die von Teams in Behörden, Verteidigung und Unternehmen weltweit genutzt wird. Bei Software dieser Größe und Verbreitung hat Sicherheit höchste Priorität, und einer der günstigsten Zeitpunkte, um Sicherheitslücken abzufangen, liegt früh im Softwareentwicklungszyklus, durch besseres Design und kontinuierliche Code-Reviews, bevor der Code in Produktion geht.

Die Herausforderung: eine wachsende Lücke zwischen Codetempo und Security-Review

Schon vor KI machte das Verhältnis von Entwicklern zu Sicherheitsingenieuren es unpraktikabel, jeden PR sorgfältig auf Schwachstellen zu prüfen. Jetzt, da KI beschleunigt, wie schnell Code geschrieben und ausgeliefert wird, ist es wichtiger denn je, jede Änderung auf Sicherheit zu prüfen.

„Wir haben schlicht nicht genug Sicherheitsingenieure, um jeden PR gründlich zu prüfen. Klassische SAST-, SCA- und Secret-Scanning-Tools können sehr nützlich sein, und wir nutzen sie weiterhin, aber ihnen fehlt oft der Kontext, um komplexe Probleme wie Schwachstellen in der Geschäftslogik zu erkennen.

„Außerdem tun sie sich schwer damit, über mehrere Schritte hinweg zu schlussfolgern oder Schwachstellen zu verketten, um zu verstehen, wie ein System tatsächlich ausgenutzt werden könnte.“

Julio Araujo
Leiter Sicherheit

Mit Hacktron das Security-Review auf jeden PR ausweiten

Um diese Lücke zu schließen, nutzt Rocket.Chat Hacktron Review für kontinuierliche Code- und Security-Reviews rund um die Uhr und fängt so teure Schwachstellen ab, bevor sie in Produktion gelangen.

Bei jedem PR macht Hacktron Folgendes:

Es führt ein gründliches Security-Review der Codeänderungen durch.
Es markiert Schwachstellen direkt im PR mit klaren Kommentaren.
Es ermöglicht Entwicklern, handlungsrelevante Probleme vor dem Merge zu beheben.
Es hilft dem Sicherheitsteam, Befunde mit niedrigerer Priorität zu verfolgen und gebündelt in regelmäßigen Abständen zu beheben.
Es hält das Security-Review kontinuierlich, statt sich nur auf regelmäßige Audits oder manuelle Reviews zu verlassen.

„Hacktron lernt mit der Zeit aus unserer Codebasis und unserem Feedback.

„Je mehr Kontext wir zur beabsichtigten Funktionalität, zu akzeptierten Risiken und zu Sicherheitsanforderungen liefern, desto seltener werden falsch positive Befunde. Das verbessert die Genauigkeit und verkürzt die Zeit, die wir mit der Triage von Nicht-Problemen verbringen.“

Julio Araujo
Leiter Sicherheit

Sehen wir uns eine Analyse der Reviews von Hacktron bei Rocket.Chat an: welche Arten von Schwachstellen es findet, wie genau diese Befunde sind und wie es dem Team hilft, schneller auszuliefern. In den ersten 20 Tagen prüfte es 155 PRs und deckte echte Probleme auf. Dazu gehören ein kritischer Autorisierungsfehler, durch den jeder angemeldete Benutzer den vollständigen Datenexport eines anderen Benutzers hätte herunterladen können, zwei kritische Fehler in Apple OAuth, die die Login-Grenze über alle Deployments hinweg schwächten, und einige XSS-Schwachstellen.

Analyse der Befunde

In den ersten 20 Tagen (5. bis 25. Juni 2026) prüfte Hacktron jeden eingehenden Pull Request und führte dabei 490 Scans über 10.744 geänderte Dateien aus. Hier ist eine Aufschlüsselung der geprüften PRs, der gefundenen Probleme, ihrer Triage und des tatsächlichen Schweregrads der echten Befunde.

Jeder PR wurde automatisch geprüft, und die Reviews selbst dauerten bei einem typischen PR ~1–2 Minuten (im Median 1,4 Minuten, beim 95. Perzentil 5,3 Minuten), schnell genug, um in der CI zu laufen, ohne jemanden auszubremsen. Wichtig ist allerdings, dass sich Hacktron bei einem PR mit vielen Änderungen die Zeit nimmt, gründlich zu testen.

Welche Arten von Schwachstellen findet es?

Die entscheidende Frage ist nun, welche Arten von Schwachstellen es gefunden hat. Hacktron gleicht nicht einfach Muster ab. Es liest den Code und denkt darüber nach wie ein Sicherheitsforscher. Entsprechend deckten die Befunde den Großteil der OWASP Top 10 ab: fehlerhafte Zugriffskontrolle, Umgehungen von Authentifizierung und 2FA, XSS, SSRF und Open Redirects, kryptografische Fehler, offengelegte Secrets und Fehler in der Geschäftslogik.

Sehen wir uns die 3 wichtigsten Schwachstellen, die Hacktron gefunden hat, im Detail an.

Kontoübernahme über Apple OAuth

Dies ist die erste Schwachstelle, die Hacktron direkt nach der Integration in die Workflows von Rocket.Chat gefunden hat, und es ist ein sehr eleganter und kritischer Bug.

Ein wichtiges Detail dabei ist, dass Hacktron einen Bug außerhalb der Änderungen des PR gefunden hat. Der Grund dafür ist, dass die Reviews von Hacktron nicht eng auf den Diff des PR beschränkt sind. Hacktron verfolgt Abhängigkeiten und Auswirkungen über die gesamte Codebasis, um Schwachstellen zweiter Ordnung zu finden.

Hoch

Kontoübernahme über nicht verifizierte E-Mail-Adresse beim Apple-OAuth-Login

apps/meteor/app/apple/server/loginHandler.ts:32-35

Der Apple-OAuth-Login-Handler in loginHandler.ts enthält eine Schwachstelle, durch die er einer vom Client übermittelten E-Mail-Adresse vertraut, wenn das Apple Identity Token keine enthält. Da das vom Client übermittelte Feld email im loginRequest nicht kryptografisch verifiziert wird, kann ein Angreifer eine beliebige E-Mail-Adresse angeben (z. B. die E-Mail-Adresse eines Opfers). Der Hook accounts_meld.js sucht dann mit dieser nicht verifizierten E-Mail-Adresse nach einem bestehenden Benutzer und verknüpft die Apple-Service-ID des Angreifers mit dem Konto des Opfers. So kann sich der Angreifer mit seiner eigenen Apple-ID beim Konto des Opfers anmelden, was zu einer vollständigen Kontoübernahme führt.

Schritte zur Reproduktion

Der Angreifer startet einen Apple-Login mit seiner eigenen Apple-ID und sorgt dafür, dass das identityToken von Apple keinen Claim email enthält (z. B. mit einer Apple-ID, die ihre E-Mail-Adresse nicht freigegeben hat, oder bei einem späteren Login, bei dem Apple die E-Mail-Adresse weglässt).
Der Angreifer fängt die an den Rocket.Chat-Server gesendete Login-Anfrage ab (z. B. den Aufruf der DDP-Methode login).
Der Angreifer ändert die Payload loginRequest so, dass das Feld email die E-Mail-Adresse des Opfers enthält: {"identityToken": "<attacker_token>", "email": "victim@example.com", "fullName": {...}}.
Der Server verarbeitet die Anfrage. In loginHandler.ts ist serviceData.email leer, daher setzt er serviceData.email = email (die E-Mail-Adresse des Opfers).
Der Hook accounts_meld.js sucht den Benutzer anhand der E-Mail-Adresse des Opfers, findet dessen Konto und verknüpft die Apple-ID des Angreifers damit (Users.setServiceId(user._id, serviceName, serviceData.id)).
Der Angreifer ist nun im Konto des Opfers angemeldet und kann jederzeit mit seiner Apple-ID darauf zugreifen.

In apps/meteor/app/apple/server/loginHandler.ts griff der Ablauf für Sign in with Apple auf eine vom Client übermittelte E-Mail-Adresse zurück, wenn das Apple-JWT keine enthielt:

32
const serviceData = await handleIdentityToken(identityToken);
33
if (!serviceData.email && email) {
34
    serviceData.email = email;   // attacker-controlled fallback
35
}

Ein Angreifer konnte ein Apple-JWT ohne E-Mail-Claim fälschen und im Request eine beliebige email angeben, um sich so als beliebiger Benutzer zu authentifizieren. Rocket.Chat veröffentlichte dies als Sicherheitshinweis mit dem Schweregrad Kritisch (GHSA-wx3c-76rf-wpwf, CVE-2026-55666), da die Schwachstelle in bereits bestehendem Code steckte.

Die Anmeldung mit Apple überspringt die Validierung der JWT-Claims

Im selben Handler steckte ein weiterer Bug: Er verifizierte die Signatur des JWT, übersprang aber die Validierung der Claims. Er nutzte JWS.verify (nur Signatur) statt JWS.verifyJWT und prüfte nie aud, exp oder nbf. Jedes von Apple signierte Token mit nicht leerem iss wurde akzeptiert, sodass ein geleaktes oder für eine andere Audience ausgestelltes Token wiederverwendet werden konnte, um sich als das Opfer anzumelden, ohne dass das Zeitfenster für diese Wiederverwendung je ablief. Rocket.Chat veröffentlichte dies als Sicherheitshinweis mit dem Schweregrad Hoch (GHSA-c75c-5hc7-j4vp, CVE-2026-55759).

Kritisch

Fehlende Validierung der JWT-Audience (aud) im Handler für Apple Identity Tokens führt zur Kontoübernahme

Die Funktion handlePassportIdentityToken in apps/meteor/app/apple/lib/handlePassportIdentityToken.ts parst und validiert Apple Identity Tokens im Passport.js-basierten Ablauf für Sign in with Apple (apps/meteor/app/apple/server/applePassportOAuth.ts). Sie validiert zwar korrekt die kryptografische Signatur, den Aussteller (iss) und den Ablaufzeitpunkt (exp) des Tokens, aber nicht den Claim Audience (aud).

In JWT-basierten Authentifizierungsabläufen wie OpenID Connect gibt der Claim aud den vorgesehenen Empfänger des Tokens an (die Client-ID). Ohne zu prüfen, ob aud mit der konfigurierten Apple-Client-ID der Rocket.Chat-Instanz übereinstimmt, akzeptiert die Anwendung jedes gültige Apple Identity Token.

Ein Angreifer kann dies ausnutzen, indem er eine eigene Anwendung mit aktiviertem „Sign in with Apple“ erstellt. Meldet sich ein Opfer bei der Anwendung des Angreifers an, erhält der Angreifer ein gültiges Apple Identity Token für dieses Opfer. Dieses Token kann der Angreifer dann an den Callback-Endpunkt für Apple OAuth des Rocket.Chat-Servers senden. Da das Token tatsächlich von Apple signiert ist, einen gültigen Aussteller hat und nicht abgelaufen ist, gibt handlePassportIdentityToken die Daten des Opfers zurück. Die übergeordnete Passport-Strategie (AppleStrategy in applePassportOAuth.ts) meldet den Angreifer mit diesen Daten dann als das Opfer an, was zur vollständigen Kontoübernahme führt.

Eine andere Funktion, handleIdentityToken in apps/meteor/app/apple/lib/handleIdentityToken.ts, implementiert die Audience-Validierung korrekt, handlePassportIdentityToken lässt sie dagegen vollständig aus.

Jeder Benutzer konnte den Datenexport eines anderen Benutzers herunterladen

Im Download-Pfad für DSGVO-Datenexporte wurde die Zugriffsprüfung ohne das Dateiobjekt aufgerufen. Dadurch ließ sie alles durch und autorisierte jeden angemeldeten Benutzer. Mit einer gültigen Datei-ID eines Exports konnte ein Angreifer den vollständigen Datenexport eines anderen Benutzers abrufen: private Nachrichten, Profil und Raumdaten. Gefunden in PR #40889 und vor dem Merge behoben.

Kritisch

Fehlerhafte Autorisierung auf Objektebene (BOLA) in UserDataFiles erlaubt jedem authentifizierten Benutzer, DSGVO-Datenexporte herunterzuladen

apps/meteor/app/file-upload/server/lib/FileUpload.ts:472

Im Mechanismus zur Zugriffskontrolle für Datei-Uploads von Rocket.Chat besteht eine Schwachstelle, mit der sich die Autorisierung umgehen lässt. Fordert ein Benutzer den Download einer Datei aus der Collection UserDataFiles an (die hochsensible DSGVO-Datenexporte von Benutzern enthält, darunter private Nachrichten, Direktnachrichten und personenbezogene Daten), prüft der Server nicht, ob der anfragende Benutzer der Eigentümer des Datenexports ist.

Das Ergebnis: eine stärkere Sicherheitslage und weniger Zeit für die Triage von Nicht-Problemen

Für Rocket.Chat liegt der größte Gewinn in der Hebelwirkung. Hacktron gibt dem Sicherheitsteam die Möglichkeit, Reviews auf Expertenniveau konsistent im gesamten Entwicklungsablauf anzuwenden, ohne Sicherheit zum Hemmschuh für das Entwicklungstempo zu machen.

Das Ergebnis ist eine engere Feedbackschleife zwischen Entwicklung und Sicherheit: Schwachstellen werden früher erkannt, Entwickler erhalten klarere Hinweise direkt bei der Änderung, und das Sicherheitsteam verbringt weniger Zeit damit, Rauschen zu sortieren, und mehr Zeit mit den Problemen, die wirklich zählen.