Mentioned in This Article
1. What did SlowMist find in the Udesk chat script?
Blockchain security firm SlowMist said on Tuesday, October 27, that a JavaScript file belonging to the Udesk customer-service chat widget contained hidden code that collected login information from visitors and replaced cryptocurrency deposit addresses on at least three trading platforms. The analysis describes a two-stage attack in which a short, concealed loader pulled in a much larger malicious script from an outside domain.
Udesk is the kind of product many websites embed so that visitors can message a support team. Because such a widget runs as a script inside the host page, anything it contains is executed with the same trust as the website's own code. That is the property the attacker appears to have exploited: the chat feature was legitimate, but the file delivering it had been altered.
SlowMist said its team came across the code while carrying out routine threat-intelligence work, and that its MistEye monitoring service sent alerts to customers once the analysis was complete. The firm published its technical findings the same day. No funds figure accompanied the report, and the company did not state how many websites had loaded the compromised file.
2. How did the hidden loader work?
The tampered file is named udeskApi.2026-10-16.cached.js. According to SlowMist, the attackers placed a brief loader after the widget's ordinary code, so a casual reader scrolling through the top of the file would see nothing unusual. The address of the next stage was stored in hexadecimal form rather than as readable text, which means a defender searching logs or source files for the plain-text domain name could miss it entirely.
Once decoded, the loader retrieves a second script called deeps.js from a domain written as udeskqlobal[.]com. The spelling is deliberate and worth noting: the name uses the letter q where a reader might expect a g, imitating the real vendor's branding. SlowMist advised security teams to keep that exact spelling in mind when they search network records, since a search for the correct spelling would return nothing.
This layered design is a common way to hide malicious behavior. The file that sits on a trusted server stays small and easy to overlook, while the bulky and more revealing logic lives elsewhere and can be changed or removed at will. It also lets the operator alter the payload without touching the original file again.
3. What login data did the payload collect?
The second script went well beyond the crypto-specific targets. SlowMist reported that it read browser cookies and local storage, copied the contents of form fields, and captured request data on any address that included terms such as login, signup or password. All of this was transmitted to a server on the same lookalike domain.
The firm warned that this combination of session cookies and credential fields could allow an attacker to impersonate a user or take over an account outright. Cookies and stored tokens are especially sensitive because they can sometimes grant access without a password at all, while captured form entries expose the credentials themselves.
Importantly, the data collection was not confined to the three exchanges named in the report. SlowMist said the script entered its collection routine and installed its hooks even when the hostname of the page matched none of the site-specific rules. In practical terms, any website that loaded the compromised file could have had visitor logins read, not only the trading platforms that were singled out for address replacement.
The analysts also made a point about chat design. Many support widgets display their window inside an iframe, and some assume that this isolates the widget from the page around it. SlowMist said that an iframe-based chat window does not automatically separate a script from the host page, because the script that creates the frame is itself running in the page's context.
4. How were crypto deposit addresses swapped?
The second module activated only on three trading sites: MGBX, Biking Exchange and BitxEX. On their deposit pages, SlowMist said, the code checked the page every 200 milliseconds and replaced any displayed deposit address with one of six substitute wallets controlled by the attacker. The substitutes covered Bitcoin (BTC), EVM-compatible networks, Tron, Solana (SOL), Litecoin (LTC) and Dogecoin (DOGE), so the scheme was not limited to a single asset.
A deposit address is the string a user copies and pastes into a wallet to send funds to an exchange. If that string is silently altered, the transfer goes to whoever owns the replacement, and blockchain transactions are generally irreversible once confirmed. The attack therefore does not need to break into the exchange or the user's wallet; it only needs to change what the user sees and copies.
SlowMist also found that the module tampered with copied text through three separate routes. That matters because careful users often paste an address and compare it against the original. If the pasted value and the displayed value have both been altered to match, the comparison appears to succeed and the manual safeguard offers no protection.
The 200-millisecond polling interval means the swap would reappear almost immediately if a page refreshed its content, keeping the fraudulent address in place throughout a visit.
5. What is still unknown about the Udesk incident?
SlowMist's report leaves several central questions unanswered. It did not say how the malicious code reached the Udesk script in the first place, whether through a compromised build process, a hijacked server or another route. It did not state how many websites loaded the altered file during the period it was in circulation.
The firm also did not say whether any funds were actually sent to the six substitute addresses. Without that information, the financial damage cannot be estimated, and it is unclear whether users of the three named exchanges lost money or whether the replacement was caught before transfers were made.
The cache-style file name carries a date of October 16, which suggests the altered version had been available for roughly eleven days before the analysis was published, although the report does not describe the period of exposure in those terms. Readers should treat the file date as a label rather than as a confirmed start of the attack.
Reconstructing an incident like this usually takes time, because the evidence sits with several parties. The vendor holds server logs showing when the file changed, the exchanges hold records of deposits and page loads, and security firms hold copies of the script itself. Until those pieces are compared, the extent of any theft remains an open question.
6. What should affected businesses do now?
SlowMist's guidance was directed at companies that still load Udesk scripts. It told them to stop distributing the affected files, to deal with any exposed credentials, and to verify deposit destinations against trusted backend systems and transaction records rather than relying on what appears on a web page.
The firm stressed that removing the script tag is not a complete fix. Hooks and timers that the malicious code already installed in an open browser session continue to run until the page is closed. SlowMist therefore advised closing affected pages and rotating passwords and tokens from a clean environment, meaning a device and browser session that has not loaded the compromised script.
For exchange operators, the episode is a reminder to treat third-party widgets as part of the security perimeter. A chat tool, analytics tag or advertising snippet can read what is typed into a page, so many security teams limit such scripts on the pages that handle logins and deposits, or serve them from a controlled location with integrity checks that detect unexpected changes.
Ordinary users have fewer options, but one habit helps: before confirming a large transfer, check the first and last characters of the destination address against a source that does not depend on the same web page, such as a verified record inside the user's account dashboard on a separate device.
7. Why do third-party script attacks keep working?
The Udesk case follows a pattern the crypto industry has seen before. In December 2023, a tampered version of Ledger's Connect Kit library was served to applications that relied on it, and the altered code drained roughly $500,000 from users of decentralized application front ends including SushiSwap and Zapper. In that incident, as in this one, the victims interacted with a familiar website that was behaving as designed except for one trusted component.
The underlying weakness is structural. Modern websites assemble themselves from many externally hosted pieces, and a single compromised piece inherits the permissions of the whole page. Defenders must trust every vendor in the chain, and an attacker only needs to alter one file to reach every site that loads it.
SlowMist's report is a technical write-up rather than a loss tally, so the scale of the damage will depend on disclosures from Udesk, the three named exchanges and any other sites that embedded the file. Until those emerge, the practical message for exchanges and their customers is to assume any page that loaded the script may have exposed credentials and to confirm every deposit address independently.
Security teams commonly respond to this class of risk with controls such as subresource integrity, which lets a page refuse a script whose contents no longer match a known fingerprint, and content security policies, which restrict the domains a page may contact. Neither is a complete defense, but a restriction on outbound connections would have made it harder for a script to send stolen data to an unfamiliar domain.