Adform Attack: Manipulated Tracking Script Steals Crypto Wallets

Published on 2 August 2026

Anyone who visited one of the estimated 1,800 websites that embed the tracking script of European ad-tech giant Adform over the past few days may have unwittingly become part of a crypto theft. Between 20 and 27 July 2026, that very script – trackpoint-async.js – was manipulated to monitor visitors' clipboards and secretly swap out copied cryptocurrency addresses for the attackers' addresses. Anyone who copied a Bitcoin, Ethereum or TRON address to send money during this period may have transferred it straight to criminals.

What makes it so insidious: it wasn't just the operators of the websites who were affected, but their visitors – and the attack ran centrally through a single compromised script embedded on hundreds of pages simultaneously. A classic supply-chain attack: the website itself wasn't hacked, but rather a service provider whose code runs on many pages at the same time.

What exactly happened?

Adform is one of the largest ad-tech companies in Europe – a provider of advertising technology whose tracking and ad scripts are embedded on numerous commercial websites. On 27 July 2026, well-known security researcher Kevin Beaumont discovered that the file trackpoint-async.js, delivered by Adform via the company's own content delivery network (CDN, a network for the fast delivery of files such as scripts), had been tampered with.

The injected malicious code had two jobs:

• Clipboard hijacking: The script monitored the browser's "copy" event and read the clipboard every four seconds. If it detected a Bitcoin, Ethereum or TRON wallet address, it swapped it for one of the attackers' addresses. The unsuspecting user then pasted the wrong address when paying – and the money ended up with the attacker.
• Direct manipulation in the form: Additionally, the code searched through the page's text elements and overwrote wallet addresses directly in input fields (input, textarea and contenteditable elements).

Beyond that, the malicious code communicated with an external command-and-control server (a control server operated by attackers) at the IP address 84.32.102.230:7744. Among other things, the hostname and path of the visited page as well as visitors' IP addresses were transmitted to this server.

Kevin Beaumont sums up the danger on his blog DoublePulsar as follows:

„This allows end-user devices of downstream websites to be compromised with crypto-stealing malware. Meaning if you visit example.com and they use Adform, example.com will compromise your device."

In other words: visitors to any website using Adform could be exposed to the crypto-stealing malware simply by visiting the page.

Why did this go undetected for so long?

The malicious code was obfuscated with a 6-byte XOR key – a simple encryption technique that makes the malicious code hard for automated scanners to read. The result: no common antivirus program on the analysis platform VirusTotal flagged it. According to Beaumont, the manipulation had been active for at least a week before it was noticed. The oldest verifiable snapshot of the manipulated script on Archive.org dates from 26 July 2026, 23:29 GMT.

Who is affected?

In principle, all websites that embed the Adform script trackpoint-async.js via the domain adform.net (specifically s2.adform.net) are affected – an estimated 1,800 or so customers use the Adform platform. It's important to understand: the servers or databases of these website operators were not hacked. The risk primarily affected the visitors of these pages, especially those who dealt with cryptocurrencies during their visit.

For website operators, this nonetheless represents a significant liability and reputational risk – and, as explained further below, possibly a notification obligation under the GDPR.

How to check whether you are affected

If you operate a website, work through the following steps:

1. Check embeds: Search your website's source code, your tag manager configurations (tools such as Google Tag Manager through which scripts are embedded) as well as your CSP reports for embeds of adform.net or trackpoint-async.js.
2. Analyse server logs: Review your web server logs (e.g. the access.log) for the period from 20 to 27 July 2026. Check whether the affected script was loaded during this time.
3. Investigate transactions: If you process cryptocurrency payments, check your transaction logs for suspicious wallet addresses that don't belong to your registered payout addresses – especially in the case of failed payments or customer complaints about transfers that never arrived.

What you need to do right now

According to its own statement, Adform removed the malicious code server-side back on 27 July 2026. An official statement reads:

„On 27 July 2026, Adform detected suspicious activity and immediately launched an investigation… we contained the incident, removed the malicious code, and took further measures to protect website visitors."

But that doesn't fully solve the problem: the manipulated script may still reside in your visitors' browser caches. So proceed as follows:

Immediate measures

1. Ask visitors to clear their cache: Advise your users – for instance via a notice on your website – to clear their browser cache so that the cleaned version of the script is loaded.
2. Warn affected customers: If crypto payments are possible via your site, actively inform your customers about the incident and ask them to verify that recent transfers went to the correct destination address.

Lasting protective measures

So that such an incident doesn't catch you unprepared in future, you should put the following technical precautions in place:

1. Use Subresource Integrity (SRI): SRI is a browser security mechanism that checks whether an externally loaded file is unaltered. To do this, add the integrity attribute with the hash (a kind of digital fingerprint) of the original file to your <script> tags. If the file is manipulated, the browser refuses to execute it. This is precisely the protection that was missing in the Adform case.
2. Configure a strict Content Security Policy (CSP): A CSP is a set of rules that tells the browser which sources scripts may be loaded from. A strict CSP can block both the loading of unwanted scripts and the transmission of data to external servers (such as the C2 server in the Adform case).
3. Conduct regular audits: Review all embedded third-party scripts at fixed intervals and remove those you don't strictly need. Every tracker you don't load is one less potential attack surface.

GDPR: Take the notification obligation seriously

The incident has a clear data protection dimension. Since the manipulated script transmitted IP addresses and visited URLs – both personal data – to an external server controlled by attackers, in all likelihood a data breach within the meaning of Art. 33 GDPR has occurred.

As a website operator, you are the "controller" under data protection law – even if the fault lay with a service provider. You must therefore assess:

• Notification obligation to the supervisory authority: A data breach must in principle be reported to the competent supervisory authority within 72 hours of becoming aware of it.
• Notifying data subjects (Art. 34 GDPR): If there is a high risk to the rights and freedoms of users – and an impending financial loss through stolen cryptocurrency is exactly such a risk – the affected individuals must also be informed.

Failures can result in hefty fines. Therefore, document your assessment and your decisions carefully, even if you conclude that there is no notification obligation. That such incidents are no longer a fringe phenomenon is shown by the DLA Piper GDPR Report 2026: reported data breaches in Europe rose by 22% to an average of 443 notifications per day.

Context: Why this case is so dangerous

The severity of the incident is to be classed as high. The reason lies less in the technical sophistication than in the reach: a single compromised script was enough to turn hundreds of websites into a danger to their visitors simultaneously. The affected operators had done nothing wrong as far as their own systems were concerned – and yet were part of the attack chain.

This is precisely the key lesson of this case: every external script you embed in your website is only as trustworthy as its provider – and their security. Without integrity checking via SRI, you blindly accept whatever code the service provider delivers, including manipulated code. The attack also went undetected for a week and was missed by all antivirus engines, which shows that you cannot rely on traditional protection software alone.

Conclusion

The Adform incident is a case study in the risks of the digital supply chain. Website operators using Adform should now do three things: check whether and when the compromised script was loaded, inform their customers and visitors, and carefully weigh up the GDPR notification obligation. In the medium term, there's no getting around Subresource Integrity and a strict Content Security Policy.

The good news: Adform has removed the malicious code, and with the right technical precautions, a comparable attack will be significantly harder to carry out in future. The uncomfortable truth behind it: anyone who runs third-party code on their website shares responsibility for its security – and should not rely on the service provider having everything under control.