SConnect ist im Chrome Web Store mit mehr als einer Million Nutzern gelistet, hinzu kommen weitere Installationen aus anderen App-Stores. Eingesetzt wird die Software unter anderem beim katarischen nationalen Identitätsdienst Tawtheeq und bei der schwedischen Steuerbehörde Skatteverket.
Die Schwachstelle wurde von Bay Area Labs beschrieben, einem auf Browser-Erweiterungen spezialisierten Forschungsteam. Nach deren Darstellung lässt sich der Angriff als Drive-by-Attacke binnen weniger Sekunden durchführen – im Test gelang die komplette Kette von Ende zu Ende in sechs bis zehn Sekunden.
Technisch kombiniert SConnect – wie vergleichbare Authentifizierungs-Middleware – eine schlanke Browser-Erweiterung mit einem nativen Desktop-Programm. Nutzer rufen eine in SConnect eingebundene Website auf, stecken ihren Hardware-Token in den Rechner oder einen angeschlossenen Kartenleser, und Erweiterung und Native Host vermitteln die Kommunikation zwischen beiden Seiten. Im Erfolgsfall bestätigt die Software, dass sowohl die Website als auch der Hardware-Token vertrauenswürdige, autorisierte Instanzen sind.
Das erste Problem: Die Erweiterung nahm Nachrichten von jeder beliebigen Webseite oder eingebetteten iframe entgegen – gleich ob vom SWIFT-Bankensystem oder von einer beliebigen Angreiferdomain. Damit konnte sich grundsätzlich jeder Angreifer in einen SConnect-Authentifizierungsablauf einklinken, sofern er ein Opfer auf die passende Seite lockte.
SConnect prüfte anschließend zwar, ob die Seite autorisiert war, indem es eine gültige digitale RSA-Signatur des Herstellers Thales verifizierte. Für das Ergebnis der RSA-Berechnung reservierte die Software einen Puffer. Diese Prüfung hatten die Entwickler laut Bay Area Labs selbst implementiert – und dabei den Fall einer ungültigen, überlangen Signatur nicht abgesichert. In diesem Fall schlug die Berechnung fehl, ohne etwas in den reservierten Speicherbereich zu schreiben. SConnect prüfte nicht, ob die Berechnung überhaupt erfolgreich war, las aber dennoch den veralteten Pufferinhalt aus. Wer diesen Speicher zuvor per Heap-Spraying mit sorgfältig konstruierten Byte-Mustern füllte, die ein gültiges Signaturergebnis vortäuschen sollten, konnte die Software dazu bringen, die untergeschobene Ersatzsignatur als gültig zu akzeptieren.
In den Versuchen von Bay Area Labs gelang das unter Einsatz von KI-Agenten in rund 18 Prozent der Fälle. Fehlgeschlagene Versuche erzeugten keine sichtbare Fehlermeldung, die Nutzer auf einen laufenden Angriff hätte aufmerksam machen können.
“Letztlich haben sie eine kryptografische Prüfung implementiert, und sie haben sie selbst gebaut”, erklärt James Arnott, Gründer von Bay Area Labs. “Sie haben keine Bibliothek verwendet, und sie haben es vermasselt.”
Im Ergebnis konnten bösartige Websites die Sicherheitsprüfung von SConnect passieren und über den Native Host eine schädliche DLL laden – mit uneingeschränkter Codeausführung als Folge. “Man besucht eine Seite mit einem bösartigen iframe, und schon ist man infiziert. Ehrlich gesagt kann man von da an so ziemlich alles machen”, sagt Arnott.
Eine trivial ausnutzbare Lücke sei das nicht, räumt er ein – erst KI-gestützte Werkzeuge hätten den Exploit in Reichweite gebracht: “Früher hätte das den Aufwand eines Nationalstaats erfordert. Aber als ich diesen Exploit entwickelt habe, lief das ganz überwiegend agentengesteuert. Die Agenten hatten Ghidra, um den Native Host zu dekompilieren, und dann Frida, um im Speicher nachzusehen, was beim Heap-Spraying funktionieren würde und was nicht.”
Thales hat SConnect im August im Apple App Store und im Chrome Web Store gepatcht und die Anwendung im September vollständig aus Microsoft Edge entfernt. Die CVE-Veröffentlichung erfolgte am 1. Oktober. Anwender sollten ihre Installationen so rasch wie möglich aktualisieren. Auf eine Bitte um Stellungnahme hat Thales bislang nicht reagiert.
Für den Zugang zum SWIFT-System benötigen Nutzer einen sogenannten 3SKey – einen USB-Sicherheitstoken, der an Partnerunternehmen für deren besonders weitreichend berechtigte Mitarbeiter ausgegeben wird. Jahrelang war SConnect das Standardprogramm, das 3SKeys mit dem dahinterliegenden System verband. Im September 2025 führte die SWIFT-Genossenschaft mit “Web Connect” einen Nachfolger ein und bemüht sich seither, Firmenkunden von SConnect auf die neue Lösung umzustellen. SConnect hat seit dem vergangenen Monat den End-of-Life-Status erreicht – was nicht bedeutet, dass alle Anwender den Wechsel bereits vollzogen haben.
“Ich vermute, die meisten werden es noch installiert haben, wenn sie SWIFT nutzen, weil SConnect der Rückfallweg ist, falls Web Connect noch nicht eingerichtet ist”, sagt Arnott. Wie groß der Wirkungsradius des Problems tatsächlich ist, lasse sich allerdings nur schwer abschätzen, da die Bankenbranche Details ihrer Sicherheitspraxis für sich behalte.
Die Tests von Bay Area Labs waren dadurch begrenzt, dass das Team weder einen 3SKey noch Token für andere Systeme wie das katarische nationale Identitätsportal beschaffen konnte. Arnott hält über die Codeausführung auf einzelnen Rechnern hinausgehende Angriffsszenarien für denkbar. Er spekuliert, es könnte “eine ähnliche Exploit-Kette wie bei Connective” geben: um Challenges weiterzuleiten, die Identitätskarte des Nutzers Dokumente signieren zu lassen und anschließend dessen Sitzung zu stehlen und sich als dieser anzumelden. Ebenso gelte: “Sobald man Codeausführung in einem Bankensystem hat, könnte es recht einfach sein, sich umzusehen, herauszufinden, auf wessen Rechner man sitzt, und zu versuchen, Geld zu überweisen. Ich kann es nur nicht beweisen, weil mir wenig überraschend niemand einen 3SKey schickt.”