- What: Attackers appended two obfuscated malicious blocks to trackpoint-async.js, a legitimate Adform tracking library served from s2.adform[.]net to customer websites.
- Impact: Any visitor who copied or typed a Bitcoin, Ethereum, or Tron address on a page loading the script could have had it replaced with an attacker address at the moment of payment, across sites that were never themselves breached.
- Fix / mitigation: Adform removed the malicious code on July 27, 2026; there is no CVE or patched version, so remediation is clearing browser caches, forcing a fresh pull of the script, and verifying wallet addresses before every transfer.
- Who's at risk: Visitors and customers of the roughly 1,800 organizations running Adform tracking tags, particularly anyone handling crypto payments in a browser.
Attackers modified trackpoint-async.js, a JavaScript file that advertising technology company Adform serves from s2.adform[.]net, and turned it into a browser-side cryptocurrency address swapper. Anyone who visited a site carrying the affected script and copied or typed a Bitcoin, Ethereum, or Tron address may have ended up pasting an attacker-controlled address instead. Adform detected the incident on July 27, 2026, removed the code, notified affected clients, and reported it to authorities.
The mechanics matter less than the delivery path. Adform's own implementation documentation describes the tracking code as something that can run on a single page, on selected sections, or unconditionally across an entire website. Compromising that one shared resource gave the attackers execution on unrelated downstream sites without touching any of them. Adform's 2025 annual report puts the platform at roughly 1,800 customers, 1.5 billion ads displayed daily, and ad activity in more than 180 countries. Those numbers describe the platform, not this incident, but they frame the ceiling.
What the payload actually does
Max Maass published a captured copy of the script on July 27. The sample shows two malicious blocks appended to the end of the legitimate library, with replacement strings obfuscated behind a six-byte XOR key. The two blocks overlap in purpose but cover different input paths.
- Block one hooks the copy event and additionally polls the clipboard every four seconds, replacing any string matching a supported address pattern.
- Block one also fires an HTTP request to 84.32.102[.]230:7744 on page load, carrying the hostname and path of the page the visitor is on.
- Block two walks the document's text nodes and rewrites values in input, textarea, and contenteditable elements, restoring cursor position afterward so the edit is not visually obvious.
- Block two hooks the value setter on input and textarea elements, so programmatic writes get rewritten in transit, and intercepts copy, cut, paste, and input events.
- Both blocks carry hardcoded replacement addresses for Bitcoin, Ethereum, and Tron patterns. Kevin Beaumont, who disclosed the compromise, reported the addresses appeared to vary.
The practical consequence is that clipboard hygiene does not save you. Because the second block hooks the value setter and rewrites form fields directly, an address typed by hand or written by a page's own script gets swapped the same way. Beaumont's description is blunt: "Even if you notice the address is wrong and recopy the wallet, it keeps replacing it."
Adform removed the malicious file, but a browser that fetched the poisoned trackpoint-async.js may still be serving it from local cache. Until that cache entry is evicted or replaced, the swapping behavior continues on any page that loads the script. Adform is explicitly telling users to clear browser cache and to verify wallet addresses before sending funds.
Detection was effectively zero
Beaumont reported that at the time of disclosure, the file and its associated URLs, domains, and IP addresses returned no detections on VirusTotal. That is worth sitting with. The payload was appended to a file that is expected to be present, served from a hostname that is expected to be present, on sites where advertising and analytics JavaScript is background noise. There is no anomalous domain to flag and no new process to catch on the endpoint. Adform also says the code was not designed to install software or establish persistence and operated only while an affected page stayed open, which is precisely what keeps it out of the reach of endpoint tooling.
The timeline does not reconcile
Adform's notice identifies July 27, 2026 as the affected date. Beaumont says he observed malicious activity via Adform over the preceding week. Those two statements have not been reconciled publicly, and the gap is not academic. Exposure math depends entirely on duration, and no defensible estimate of impressions, sessions, or affected sites can be built until someone publishes the real window.
There is a similar hedge on exfiltration. Adform says it found no evidence that the code transmitted visitor IP addresses or information about the websites they visited, then adds in the same incident notice that "technical analysis indicates that such transmission may have been possible." The captured sample is unambiguous on intent: the first payload builds a request carrying page hostname and path to an external host. Whether it landed with the operator is not established by the sample alone.
What is still unknown
- How many websites actually carried the poisoned file, and how many page loads received it. Adform has not published this count, and it is the only number that measures the incident rather than the platform.
- How the attackers reached Adform's deployment path in the first place. No initial access vector has been disclosed.
- Whether any funds were successfully diverted, and to which addresses.
- Who did it. Adform has not publicly identified the attacker, and the incident notice lists no indicators of compromise.
What to do now
Treat this as a third-party script incident, not a malware incident, because there is nothing on disk to hunt for.
- Search web proxy, CDN, and DNS logs for requests to s2.adform[.]net and specifically for trackpoint-async.js, covering at minimum July 20 through July 28, 2026, to establish whether your properties or your users were in scope.
- Hunt egress logs for connections to 84.32.102[.]230, particularly on port 7744. This is the one hard network indicator in the public sample.
- Inventory every third-party tag on customer-facing and payment-adjacent pages. Ad tech, analytics, chat widgets, and A/B testing scripts all execute with full DOM access.
- Deploy Subresource Integrity where the vendor serves a versioned, static file, and a Content-Security-Policy that constrains which origins can execute script. SRI would have broken this file the moment its bytes changed.
- Force cache invalidation for affected assets and instruct users who transact in crypto to clear browser cache rather than assuming the vendor's fix propagated.
- Add a verification step to any workflow where a wallet address moves between a browser and a transaction: confirm the full string, not the first and last four characters.
Subresource Integrity pins a hash of the third-party file, so an appended payload causes the browser to refuse execution instead of running it. It is not universally deployable because many vendors update their scripts without versioning, but on any asset a vendor keeps static it converts a silent supply-chain compromise into a hard load failure you can alert on.
The broader takeaway is scope asymmetry. One JavaScript file on one CDN put wallet-rewriting code into the browsers of visitors to sites that were never themselves attacked, with zero detections at the time of disclosure. Every third-party tag on your pages is an unaudited code execution path in your users' browsers, and it stays that way until you either constrain it with policy or accept the vendor's security posture as your own.
Questions about your exposure?
RedEye Security provides assessments for organizations that need to understand their real risk.
Talk to us