The code on your website you did not write

· · Security Infrastructure

Open your own website and count the companies whose code runs on it. Not the code your developer or agency wrote: the other stuff. Analytics. Advertising and conversion tracking. The chat widget. The cookie banner. Maybe a font, a map, a review badge, a payment form. Most business websites load between five and 20 of these, and each one is a live connection to somebody else's server that fetches fresh code every time a visitor lands on your page.

That code runs with the same privileges as your own. It can read what your visitors type. And you do not control when it changes.

On 27 July, one of them changed.

What happened

Attackers modified a JavaScript file served by Adform, an advertising technology company. The compromised file, trackpoint-async.js, is a tracking script that Adform's own documentation says can be deployed across an entire website. Every site loading that file served the attackers' code to its visitors.

The code watched for cryptocurrency wallet addresses and swapped them. It read the clipboard every four seconds, rewrote addresses in form fields as they were typed, and hooked the browser's copy, cut, paste, and input events. The independent researcher Kevin Beaumont, who disclosed the compromise, noted the practical effect: "Even if you notice the address is wrong and recopy the wallet, it keeps replacing it."

Adform detected it on 27 July, removed the malicious code, notified clients, and reported it to the authorities. The company says the code was not designed to install software or persist on a machine, and that it found no evidence visitor IP addresses were transmitted, while adding in its incident notice that "technical analysis indicates that such transmission may have been possible".

Two details matter more than the incident itself. At the time Beaumont found it, the file and its associated domains and addresses returned no detections on VirusTotal, the service that aggregates around 70 antivirus engines. And because browsers cache files like this, the altered version stayed live in visitors' browsers after the fix, which is why Adform told people to clear their cache.

Why this is not a cryptocurrency story

It is tempting to file this under "crypto problem" and move on. Very few UK SMEs take payment in Bitcoin.

That misreads it. The wallet swapping is what these particular attackers chose to do with the access. The access itself was the ability to run arbitrary code in the browser of every visitor to every site carrying that script. The same position could read anything typed into a form on your site: card details, login credentials, the contents of an enquiry form, a customer's address and phone number.

Think about what your website asks people to type. Then think about who else's code is on the page while they type it.

This is a supply-chain compromise, the same shape as the poisoned VS Code extension that emptied 3,800 GitHub repositories. Nobody breached the downstream sites. They breached one shared thing that all of those sites had chosen to trust, and the trust did the rest.

What honest scope looks like

Adform's 2025 annual report describes roughly 1,800 customers and 1.5 billion ads displayed daily. Those numbers describe the platform, not this incident, and it would be easy to imply otherwise.

The genuinely useful figure, how many page loads actually received the altered file, has not been published. Neither has the route the attackers took into Adform's deployment path, nor whether any money was diverted. Adform's notice identifies 27 July as the affected date, while Beaumont reported seeing malicious activity over a longer period, and the two accounts have not been reconciled. Adform's public notice lists no indicators of compromise.

So the honest position is that the exposure window is unresolved and the blast radius is unknown. That is worth stating plainly, because "we do not know yet" is the accurate answer and a supplier who says it is being more useful than one who guesses.

What to do this quarter

Find out what your site actually loads. Open your website, press F12, and look at the Network tab, or use a free external checker. You are looking for requests going to domains that are not yours. Most people are surprised by the length of the list, particularly by tags added years ago for a campaign that ended.

Delete what you are not using. This is the highest-value step and it costs nothing. Old analytics, a retired chat widget, a tracking pixel from an agency you no longer work with: every one is a live route into your visitors' browsers, kept open for no benefit. If nobody can name what a script is for, remove it.

Ask who can change each remaining one. For every script you keep, somebody at that supplier can push new code to your visitors tonight. That is the actual relationship. It is a reasonable thing to raise at renewal: what controls do they have on their own deployment pipeline, and how would they tell you if it were compromised?

Keep third-party code off your most sensitive pages. Checkout, login, and any form collecting personal or payment data should carry the bare minimum. Marketing tags do not need to be on your payment page, and the PCI DSS rules for card payments now expect you to manage exactly this.

Ask your developer about Content Security Policy and Subresource Integrity. These are the two technical controls that help. A Content Security Policy tells the browser which domains are allowed to run code on your site, so an unexpected one is blocked. Subresource Integrity pins a specific version of a file by its cryptographic fingerprint, so an altered version simply will not run. Subresource Integrity does not suit scripts designed to change often, which is most advertising and analytics tags, and that limitation is precisely why deleting unused ones matters more.

If you take one thing from this: the security of your website is not only about your website. It is about every company whose code you have agreed to run, and the list is almost always longer than anybody remembers.

How Steelwise can help

Working out what your site loads, who controls it, and what should be stripped off your sensitive pages is a short, defined piece of work with a clear answer at the end. Get in touch if you would like a second opinion on yours.

Further reading

← All filings

We use cookies to understand how visitors use this site. More information.