SURIQ
The advertising and analytics tags most websites paste into their pages are the least-verified code they run. Each one loads from a vendor's servers, changes whenever the vendor ships an update, and executes with full access to the page. When one of those vendors is compromised, every site carrying the tag serves the attacker's code without anyone touching its own infrastructure. That is what happened with Adform, and it is a category of risk that host-based defenses cannot see.
Around July 26 and 27, 2026, Adform's shared tracking script was altered to hijack cryptocurrency payments in the browsers of people visiting sites across its network. Researcher Kevin Beaumont disclosed the compromise, and Adform confirmed it removed the code. The theft technique is old. The delivery is the part worth studying.
What the tampered script did
The attackers scrambled two blocks of code with a six-byte XOR key and bolted them onto trackpoint-async.js, the tracking file Adform serves from s2.adform.net. One block listened for copy actions and polled the clipboard every few seconds, substituting any Bitcoin, Ethereum, or Tron address it saw for one the attacker owned. The second scanned the page's visible text and replaced addresses inside form fields and editable regions, moving the cursor back afterward so the edit was easy to miss. It also overrode the value setters on those fields, so even an address written by the site's own script got swapped, according to The Hacker News.
A separate request reached out to 84.32.102.230 on port 7744, carrying which page and path the visitor was on. Adform said its analysis indicated that kind of transmission may have been possible. When Beaumont looked, the file along with its domains and IP addresses was still showing clean on VirusTotal. Per BleepingComputer, the earliest captured copy dates to late on July 26, and Adform spotted the activity and pulled the code on July 27.
Scope is the open question. Adform reported roughly 1,800 customers and about 1.5 billion ad displays a day in 2025, but has not said how many of those loads were served the tampered file, how the attackers got into its deployment path, or whether any money moved. Read the reach figure as the size of the network, not the count of people hit.
Why can't subresource integrity stop this?
Subresource integrity works by pinning a script to a known hash, so the browser refuses to run a file that has changed. Ad and analytics tags are built to change on the vendor's schedule, so you cannot pin them. The one control teams reach for on third-party scripts does not apply to the highest-reach third-party code on the web.
That leaves the controls that do not depend on the file staying constant. A content security policy with a strict connect-src allowlist would not have stopped the address swap, but it would have blocked or reported the callback to 84.32.102.230, because that host was never on the list of places the page is allowed to talk to. A report-uri or report-to endpoint turns that block into a log line you can alert on. Trusted Types and sandboxing third-party tags behind a tag manager or an isolated frame shrink what a rogue script can reach in the first place.
Detection lives in the browser, not the host
Nothing in this campaign touched the customer sites' back ends. No file changed on their servers, no process spawned, no login happened. Server logs, a web application firewall, and host monitoring on the origin all saw a normal day, because the malicious logic ran in the visitor's browser against addresses the visitor copied. The detection surface is the client.
Three signals are worth wiring up. Content security policy violation reports catch a script reaching an origin it should not. Real-user or synthetic monitoring that fetches your third-party scripts on a schedule and compares them against the last known good copy catches a silent change like this one, which no scanner flagged. And a current inventory of every third-party tag on your pages is what makes the other two possible, since you cannot watch a script you forgot you embedded.
The tag you paste is a trust boundary you inherit
Embedding a vendor's tag is a decision to run whatever that vendor's deploy pipeline produces, on your users, indefinitely. The blast radius is inverted from a normal breach: the attacker did not need to compromise 1,800 sites, only one file with the reach of the whole network, and the reputational damage lands on the sites that embedded it, not on Adform alone. We watched the same shape in a compromised web front end that redirected funds and in clipboard-swapping malware that rewrites crypto addresses. The clipboard clipper is a decade-old trick; delivering it through a legitimate ad content delivery network with zero antivirus detections is the new part.
It rhymes with the package-manager incidents we keep covering, from a poisoned npm package to code that runs the moment you open a project. The pattern repeats: the code you did not write, loaded from infrastructure you do not control, is where the modern web breaks.
Audit your third-party tags before one turns on you
Start with the inventory. List every external script your pages load, who owns it, and why it is there, then drop the tags nobody can justify. For the ones that stay, put a content security policy in front of them with a connect-src allowlist and a reporting endpoint, so an unexpected outbound call becomes an alert instead of a quiet theft. Add out-of-band monitoring that re-fetches those scripts and diffs them against a known-good copy. And on the user side, the durable habit against address-swapping is to check the first and last characters of any crypto address in the destination wallet before sending, because the value shown in the browser is exactly what this attack rewrites.