A deposit address displayed on a website—and the address copied from that same page—can agree and still both be wrong. In an analysis published on October 27, 2026, at 17:51 (UTC+8), SlowMist described malicious JavaScript that could alter both while also collecting browser-accessible session data and sensitive form submissions.
The report concerns two analyzed files associated with a poisoned Udesk customer-service script. It does not establish that every Udesk deployment was affected, and it provides no confirmed loss total.
How the malicious code entered the page
SlowMist said its threat-intelligence monitoring identified the activity and obtained two samples: udeskApi.2026-10-16.cached.js and deeps.js.
The first file contained ordinary customer-service functions, including a chat iframe and visitor tracking. After the main code, however, an additional function decoded hexadecimal strings and inserted an asynchronous script into the document’s head. That script loaded a remote payload from:
https[:]//udeskqlobal[.]com/deeps.js
The domain uses a lowercase “q” in qlobal, not a “g”. That spelling matters when searching logs or investigating exposure. Because the loader encoded the URL, searches limited to plaintext domains could miss it.
The important trust boundary was the page executing the script. A third-party classic script runs in the context of the document embedding it; a customer-service chat window’s iframe does not automatically isolate a script loaded into the host page.
Session-data collection extended beyond the deposit targets
The payload configured address-replacement rules for three hostname patterns: mgbx[.]com, bikingex[.] and bitxex[.]io. But SlowMist found that the data-collection routines ran before the code exited on pages that did not match those rules.
That means the three patterns were not a complete boundary for investigating data exposure. Other pages executing the payload could also enter its collection routines and receive its hooks.
At startup, the script attempted to collect:
- Cookies accessible through
document.cookie. - The contents of
localStorageandsessionStorage. - The top-level page URL and the current document’s origin.
HttpOnly cookies were outside the reach of document.cookie. Where readable storage contained valid, reusable login tokens, however, their disclosure could allow an attacker to impersonate a user’s session. A failed cross-origin attempt to read the top-level URL did not stop other collection; the script substituted x for that field.
The payload also intercepted later submissions. It copied nonempty values from form inputs, selectors and text areas while allowing the original submission to continue. Depending on what users entered, this could include account names, passwords or verification codes.
For interface-based submissions, it wrapped fetch and XMLHttpRequest. Requests with bodies and URLs matching terms such as login, signin, auth, register, signup or password could trigger copying. Coverage was not universal: the fetch branch required a string URL and a body in the request options, and direct JSON serialization of objects such as FormData could miss their actual fields.
Data could leave through two request paths
The collection destination was:
https[:]//udeskqlobal[.]com/c.php
The primary method was an asynchronous POST using application/x-www-form-urlencoded. If the request encountered an error, or sending raised a synchronous exception, the code attempted an image GET request carrying the data in the URL. That fallback URL was truncated to the first 8,000 JavaScript characters, so longer content could be incomplete.
SlowMist emphasized that sending a cross-origin request and reading its response are separate questions. A qualifying simple POST can be sent even when the browser prevents the script from reading the response. Consequently, a CORS error is not proof that no data left the page.
Investigators therefore need to examine both POST bodies and GET parameters. Relevant content-security-policy checks include connect-src for connection requests and img-src for the image fallback. Navigation following a form submission could also affect whether an asynchronous request completed.
How deposit addresses and copying were altered
On matching sites, the address module checked page URLs for terms including deposit, recharge and assets. Query strings and fragments could contribute to those matches. The hostname expressions were not anchored, so they matched more broadly than exact domain comparisons.
When the page, elements and address format matched, the script scanned every 200 milliseconds and replaced recognized deposit addresses with configured values. The six configured categories were BTC, EVM, TRON, Solana, LTC and DOGE.
Recognition relied on character patterns and matching order—not the user’s selected network or address checksums. SlowMist noted that ordinary business identifiers could also be misidentified.
The payload interfered with copying in three ways:
- Clipboard API wrapping: It modified text passed to
navigator.clipboard.writeText. This path required a matching hostname configuration but did not repeat the deposit-page check or require a successful DOM replacement. - Copy-button replacement: It cloned matching buttons and installed handlers that attempted to copy the last address actually replaced.
- Copy-event interception: Under its page conditions, it replaced copied text with that stored address without checking whether the user had selected an address.
These overlapping paths explain why comparing an on-page address with the clipboard result was not an independent verification: both could be manipulated.
There were implementation limitations. The stored address could be overwritten when several addresses appeared, potentially making multiple buttons copy the same value. A separate attempt to hook textContent used the wrong prototype and would throw under standard prototype relationships. That exception was caught, however; the polling and other copying hooks were not thereby disabled.
Source-supported recovery and investigation steps
For operators whose pages loaded the payload, SlowMist recommended preserving the actual script response, request chain, cache details and collection time, then stopping distribution of the contaminated resource. Restoration should use an independently verified trusted version, with checks of hosting, CDN, build and tag-management configurations.
For affected account holders and response teams, the practical distinction is between removing the file and ending its effects:
- Fully close affected pages or WebView documents. Removing a script element does not undo hooks or timers already installed, and reopening must not reload the old resource.
- Address exposed credentials from a clean environment. Revoke sessions and rotate tokens or passwords according to the actual exposure.
- Verify deposit destinations independently. Use trusted back-end information and transaction records to compare the intended address with the actual transfer destination. Do not rely solely on two views controlled by the affected page.
- Assess impact from records. Address replacement creates a potential diversion path if a user completes a valid transfer to the substituted address; the sample’s behavior alone does not establish that a loss occurred.
Indicators reported by SlowMist
Malicious domain: udeskqlobal[.]com
Paths: /deeps.js and /c.php
Sample SHA-256 hashes:
udeskApi.2026-10-16.cached.js:45b4e8f160d8d5177819f6c1dc67acc7abbdc65eeaffc909e668799dc778bcf6deeps.js:57c1441c4f5bb3260981a2df64f9ff35f117abde0d8667c8c66a047880074c59
Configured replacement addresses:
- BTC:
bc1qhzppfj69ywp22swj50jwcfxdamg3ym245srng9 - EVM:
0x9B6EcD0023a28E1391c5124eCe578A9751A337b2 - TRON:
TH4L5YAhhxtC8qALbZKbPZZgausbGi25nF - Solana:
AFmCUe3nNbjTaC585CcdA3vvC9iWVR8YunooFKpaQx2Z - LTC:
ltc1qwz0zp39ywl34kahvn9lyk7j5x63wsy9tcxhm3w - DOGE:
DAoy2w8uvFtZ92q87s9qKEoHbWgV7mVThj
Source: SlowMist’s original analysis, published October 27, 2026, at 17:51 (UTC+8).