On 27 July 2026, thousands of legitimate business websites started serving cryptocurrency-stealing malware to their visitors. Not one of them was hacked. Their servers were fine, their CMS was patched, their dependencies were current. The malicious code arrived through a script tag they had pasted into their template months or years earlier and never thought about again.
The compromised script belonged to Adform, one of the largest advertising technology platforms in Europe, serving roughly 1.5 billion ad impressions a day across around 1,800 customers. Its trackpoint-async.js file, hosted on Adform’s own CDN, was modified to hijack visitors’ clipboards. This is the part of the software supply chain that most development teams have no visibility into at all, and it deserves considerably more attention than it gets.
TL;DR
- Adform’s
trackpoint-async.jstracking script was trojanised in a supply chain attack detected on 27 July 2026, silently swapping Bitcoin, Ethereum and Tron wallet addresses in visitors’ clipboards, rewriting addresses in form fields and page content, and beaconing page data to an attacker-controlled server. - The affected websites were never breached. A single change at the vendor gave attackers execution rights on every site embedding the tag, which is the defining characteristic of client-side supply chain risk.
- Most teams now defend the build-time supply chain (npm, Composer, PyPI) but leave the runtime supply chain wide open. The average page pulls in over 70 third-party requests before main content renders.
- Defences exist and are underused: only 20.8% of the top million sites send a Content Security Policy, 46.8% of those still allow
unsafe-inline, and just 0.2% deploy Trusted Types. - If you take card payments, PCI DSS 4.0 requirements 6.4.3 and 11.6.1 have made script inventory, authorisation and change detection mandatory since 31 March 2025. Many organisations are quietly non-compliant.
What actually happened
Security researcher Kevin Beaumont disclosed the compromise publicly on 31 July, after a captured sample of the modified script was published on 27 July. The injected code did three things, all of them quietly.
First, it monitored clipboard activity and replaced cryptocurrency wallet addresses with attacker-controlled equivalents, refreshing every four seconds so that a user who copied an address, checked it, and pasted it would still be caught. Second, it rewrote values inside input fields, textareas and contenteditable elements, so addresses displayed on the page itself could be swapped. Third, it attempted HTTP requests to a hard-coded IP address on port 7744, carrying the hostname and path of the page the visitor was on.
Adform removed the code, notified customers, and advised users to clear their browser cache and verify wallet addresses before transacting. The company has not disclosed how its systems were initially compromised, how many sites carried the tampered file, or how many visitors were affected. That opacity is itself instructive: when a vendor’s script is compromised, the downstream businesses are entirely dependent on that vendor’s disclosure quality to understand their own exposure.
Two supply chains, one blind spot
The same week, the npm ecosystem was hit by another wave of the Shai-Hulud worm, compromising keyv (604 million monthly downloads), flat-cache and cacheable-request, then propagating to hundreds of further packages while harvesting CI/CD tokens and cloud credentials.
Those two incidents look similar and are not. The npm attack targets your build supply chain: it runs on developer machines and CI runners, and it is defended with lockfiles, provenance attestations, dependency scanning and scoped tokens. Most competent teams have at least started on that work.
The Adform attack targets your runtime supply chain: code that never touches your repository, never appears in your package.json, never passes through your CI pipeline, and executes with full DOM privileges in your users’ browsers under your domain’s trust context. Your SBOM does not list it. Your SCA tooling does not scan it. Your penetration test probably ignored it. And it is frequently added not by engineers but by the marketing team, through a tag manager, without a ticket.
That asymmetry is the point. The industry has spent five years hardening the pipeline while leaving a permanently open remote code execution channel in the page itself.
The scale of the exposure
The numbers are not encouraging. According to HTTP Archive data, the average page makes more than 70 third-party requests before main content renders, and each unsandboxed third-party script can read the DOM, intercept form input, access same-origin storage, and modify anything on the page.
The obvious mitigation, Content Security Policy, remains thinly and poorly deployed. Scott Helme’s June 2026 analysis of the top million sites found CSP on 170,057 sites, or 20.8% of those responding. Adoption has grown 114% since 2022, which sounds excellent until you look at policy quality: 46.8% of those policies still permit unsafe-inline, 41.9% permit unsafe-eval, only 24.7% use nonces, and Trusted Types appears on 318 sites in total. A policy that allows inline script is largely decorative.
Subresource Integrity, the other standard answer, does not help much here either. SRI validates a hash of a fetched file, which works beautifully for a pinned library on a public CDN and not at all for an advertising or analytics loader that is designed to change constantly and to inject further scripts at runtime. Adform’s script was async and dynamic by design. That is precisely why these vendors are attractive targets.
What to actually do about it
This is a solvable engineering problem, but it needs a deliberate programme rather than a header bolted on at the end of a project.
1. Build a real script inventory. You cannot defend what you cannot list. Enumerate every third-party origin loading on every template, including scripts injected by other scripts. Tag managers are the usual source of surprises: expect to find pixels for campaigns that ended in 2023 and A/B testing tools nobody has logged into for two years.
2. Justify each one, then delete aggressively. For every script, name an owner and a business reason. Anything without both comes out. This is the single highest-value hour in the whole exercise, and it improves Core Web Vitals as a side effect.
3. Move what you can server-side. Server-side tagging for analytics and conversion tracking removes an entire class of client-side script from the page, gives you control over what data leaves, and tends to improve measurement accuracy under modern browser privacy restrictions. It is more infrastructure to run, but for anything adjacent to payment data it is usually the right call.
4. Isolate what you cannot remove. Third-party widgets belong in sandboxed iframes on a separate origin wherever the vendor supports it. Never let a marketing or advertising script share an origin with a payment form, an authentication flow, or an admin interface. Origin separation is the difference between a bad week and a breach notification.
5. Deploy a CSP that does something. Start in Content-Security-Policy-Report-Only mode, collect violations for a fortnight, then move to a nonce-based policy with strict-dynamic. Add Trusted Types for DOM sink protection. Skip this step and you have a header that passes an audit while permitting exactly the behaviour you are worried about.
6. Monitor for change at runtime. Static configuration does not detect a compromised vendor. You need synthetic monitoring that loads your pages on a schedule, records the scripts that execute and the network destinations they contact, and alerts on anything new. CSP violation reporting gives you a second signal from real user sessions. In the Adform case, an alert on an unexpected outbound connection to a raw IP address on a non-standard port would have surfaced the problem in hours rather than days.
7. Write the vendor expectations down. Contracts should specify notification timelines, integrity controls and incident detail. Adform’s disclosure left customers unable to assess their own exposure, and that is a commercial conversation as much as a technical one.
The compliance angle nobody enjoys
If you process card payments, this is no longer optional. PCI DSS 4.0 requirements 6.4.3 and 11.6.1 have been mandatory since 31 March 2025. Together they require a maintained inventory of every script on payment pages, written justification and authorisation for each, assurance of script integrity, and continuous detection and alerting on unauthorised changes to scripts and security-relevant HTTP headers, evaluated at least weekly.
In practice, a great many organisations have signed a self-assessment questionnaire without implementing any of this. An incident like Adform’s is exactly what those requirements were written for, and exactly the scenario in which an acquirer will ask to see the evidence.
Where we land on it
The client-side supply chain deserves the same seriousness as the dependency tree, because functionally it is the same risk with worse visibility and faster propagation. It is also cheaper to fix than most people assume: a script audit, a tag cull, a properly constructed CSP and runtime change monitoring is typically a few days of focused work, not a quarter-long programme.
At REPTILEHAUS we handle this as part of security and DevOps engagements, whether that is auditing an existing estate, implementing server-side tagging, or building CSP and change detection into a CI/CD pipeline so that policy drift fails a build rather than surfacing in an incident. If you are not certain what runs on your checkout page right now, that uncertainty is the finding. Get in touch and we will help you answer it properly.
📷 Photo by Chris Ried on Unsplash
