Thales SConnect Flaw Opened Drive-By Code Execution on PCs Used for SWIFT 3SKey Sign-In

LONDON - A piece of browser middleware that banks and corporate treasuries have long used to sign in to SWIFT with hardware tokens could be turned into a drive-by code execution channel by an ordinary web page, according to research published on October 2, 2026, by Bay Area Labs on its Am I Being Pwned? blog. Thales, which owns the product through its acquisition of Gemalto, published the flaw as CVE-2026-18397 on October 1 with a critical CVSS 4.0 score of 9.4. The fixes shipped in August. For security operations teams, the more urgent question is an inventory one: where the vulnerable software still sits on machines that touch payment and signing systems.

SConnect pairs a browser extension with a desktop program, called a native host, so that approved websites can talk to smart cards and USB tokens. Dark Reading reported that the extension has more than 1 million users on the Chrome Web Store and is used for national services such as Qatar's Tawtheeq identity provider and the Swedish Tax Agency, as well as banking and insurance portals. It has also been one of the primary ways to use SWIFT's 3SKey, a USB security token that Dark Reading describes as issued to partner corporations for their most highly permissioned employees. SWIFT introduced a replacement called Web Connect in September 2025, and SConnect reached end of life in September 2026. James Arnott, the Bay Area Labs founder credited in the CVE record, told Dark Reading he suspects most SWIFT users still have SConnect installed because it is the fallback when Web Connect is not set up.

The weakness sat in the gate meant to keep unauthorized sites out. The extension accepted messages from any web page or embedded frame and passed them to the native host, which was supposed to reject sites that could not present an RSA-2048 token signed by Thales and bound to their origin. Bay Area Labs found that Thales had written that signature check itself rather than relying on a cryptographic library. When the researchers supplied an oversized signature, 257 bytes of 0xFF in their test, the math step failed and wrote nothing, but the verifier ignored the failure and read a 256-byte buffer that had never been cleared. By spraying the host process's memory with crafted blocks, a page could make that stale data look like a valid Thales signature. Because the extension kept one long-lived connection to the host, the spray accumulated across messages, and each failed attempt came back as a quiet error with nothing shown to the user.

The same broken routine guarded SConnect's add-on mechanism. With two more forged signatures, the researchers got the host to unpack their package to disk and call LoadLibrary on an unsigned DLL, so their code ran inside the Authenticode-signed Thales host process. They said the full chain took about six to 10 seconds, was invisible to the user, and could run from any iframe because the extension injected its content script into every frame. Using AI agents, they raised the heap spray's success rate to about 18 percent per attempt without debugging tools on the target. "Visit a page with a malicious iframe, then you have been infected," Arnott told Dark Reading. "To be honest, from there, you can do pretty much whatever you want."

The research has limits that defenders should keep in view. Bay Area Labs said it proved code execution but did not test commands against real 3SKeys or national identity cards because it does not own any. Arnott speculated to Dark Reading that an attacker could relay signing challenges or try to move money from a compromised banking workstation, while saying he could not prove it. The CVE record does not describe exploitation in the wild, and CVE-2026-18397 was not in CISA's Known Exploited Vulnerabilities catalog when SOCtember checked on Monday. Thales had not responded to Dark Reading's request for comment at publication of that report.

The disclosure timeline explains why many fleets may already be partly covered. Bay Area Labs reported the flaw to Thales PSIRT on June 29, Thales confirmed it on July 3, and patched versions reached the Apple App Store and Chrome Web Store on August 7. The Edge listing was removed on September 13, when it had about 89,000 users, and the researchers said they could not confirm those installations were removed automatically. A SWIFT notice reproduced in the research names the fixed builds as SConnect Host 2.16.1.0 and SConnect extension 2.16.1.1, says Chrome and Edge users receive the extension automatically through the Chrome store while Firefox users must install it manually, and says SConnect is disabled until an unsupported host is upgraded. The CVE record lists versions before 2.16.1.0 as affected.

For detection teams, the chain Bay Area Labs documented leaves evidence on the endpoint even when the browser shows nothing. The practical starting points are an inventory of SConnect native host versions below 2.16.1.0 and of any Edge installations that predate the store removal; outbound requests from the SConnect host for its validation token to origins that are not known partner sites; add-on packages written to disk outside a normal update; and unsigned DLLs loaded into the Thales-signed host process, followed by child processes or new network connections. Workstations used for SWIFT 3SKey or national eID signing belong on the high-value asset list, and the cleaner fix is the one SWIFT has been pushing: move to Web Connect and remove the legacy host where it is no longer needed.

Bay Area Labs argues the deeper problem is architectural, with any site able to reach an extension that in turn reaches privileged native code. It says it has more digital signing extensions with similar flaws than it can report, and previewed upcoming research on signing extensions in Brazil and South America that it says affect about 10 million endpoints. Arnott told Dark Reading the SConnect exploit "would have previously required nation-state effort," but that his development work was largely agent-driven.