senn-tech15,579 infected websites: what Report URI reports and what our three sites have against it
Scott Helme, founder of Report URI, wrote on 6 November 2026 that his service has found 15,579 websites currently serving malicious JavaScript. Together they receive, by a conservative estimate, more than 135 million visits a month. The problem is not finding them but notifying the owners: most emails go unanswered.
A site with malicious JavaScript loads code its owner never approved. The code skims card data on payment pages (Magecart), shows fake "prove you are human" prompts that install malware (ClickFix), exploits specific iOS versions or redirects visitors. The browser runs it with the page's privileges. Countermeasures are a Content Security Policy, Subresource Integrity and an inventory of every loaded script.
What Report URI describes
Report URI names four ways the script gets onto a page:
- Direct compromise, usually through a WordPress flaw or similar, where the site's own JS files are modified.
- Supply chain: a third-party file gets infected and is then loaded by every page that includes it.
- XSS in the page itself.
- "DeadTag": a group buys expired domains that sites still load scripts from and serves malware there. Report URI describes the group in its own post on DeadTag.
According to Helme, many findings come from regionally strong sites under .de, .fr and .es. He deliberately did not publish the list. His reasons are protecting the victims, the difficulty of getting off blocklists again, and the risk of handing attackers a target list. It also means that 15,579 is a vendor statement nobody outside Report URI can recompute.
The vendor sells monitoring of this kind. Helme's post carries a "Sponsored by Report URI" label at the top and offers access to the threat intelligence data at the end. That is no reason to doubt the findings. It is a reason to treat them as a vendor claim.
What we measured on our sites
On 9 November 2026 at about 10:36 UTC we fetched the home pages of senn-tech.com, senn-gruppe.com and senn-logistik.com once each from the office network and evaluated the response headers and the HTML. Counted are script tags with an absolute address.
| Site | Scripts with absolute address | Host | integrity attributes | script-src in CSP header |
|---|---|---|---|---|
| senn-tech.com | 13 | senntechassets-22949.kxcdn.com (our KeyCDN zone) | 0 | self, own CDN zone, ip.senn-tech.com, 'unsafe-inline' |
| senn-gruppe.com | 4 | gruppe-22949.kxcdn.com (our KeyCDN zone) | 0 | not set (header names only object-src, base-uri, frame-ancestors) |
| senn-logistik.com | 9 | slgassets-22949.kxcdn.com (our KeyCDN zone) | 0 | self, CDN zone, Snipcart, Stripe, PayPal, 'unsafe-inline' |
Source: curl with a browser user agent, home page of each domain, 9 Nov 2026. Scripts loaded only at runtime are not in the count. On senn-tech.com and senn-logistik.com the CSP header arrived twice in the response, on senn-gruppe.com once; we have not established which layer sets it. This is a single measurement, so the values are preliminary.
Two results hold for the statically embedded script tags of the home pages. First, these scripts come from addresses that belong to us; DeadTag mostly hits pages with scripts from foreign, abandoned domains. Second, none of these tags carries an integrity attribute. For scripts from the own CDN zone a hash adds protection if the zone or the origin is altered. On senn-gruppe.com the policy does not limit script sources at all, and on the other two sites 'unsafe-inline' allows injected inline code. According to MDN on Content Security Policy, developers should avoid 'unsafe-inline' because it defeats much of the purpose of a CSP: inline JavaScript is one of the most common XSS vectors.
These are open items, not incidents. Whether and when we close them is undecided. For the Next.js sites a move to nonces is an option; we have not yet measured the effect on our analytics and the shop.
What an operator can do right away
Inventory the scripts and check that every host still belongs to the expected provider. Use own copies instead of foreign sources where possible. Our recommendation: run the policy in report-only mode first and read the reports for a few weeks before it blocks (MDN describes the mode, the duration is our judgement). Where a foreign script has to stay, pin its hash with the integrity attribute as described by MDN on Subresource Integrity.
If you want this reviewed for a shop or website, see Services. How a supply chain actually breaks is shown in npm supply chain and the GitLab regex; more posts are in the hub Security and data protection.
Further reading
- Scott Helme, 6 Nov 2026: We Know 15,579 Websites Are Infected. How Do We Tell Them?
- Report URI on DeadTag: blog.report-uri.com
- MDN, Content Security Policy: developer.mozilla.org
- MDN, Subresource Integrity: developer.mozilla.org
How many sites does Report URI say are infected?+
Report URI names 15,579 websites currently running malicious JavaScript, with an estimated more than 135 million visits a month. Both figures come from the vendor itself. The list is not public, so the number cannot be checked from outside.
Does Subresource Integrity help against a compromised script?+
Only if the script is loaded from a host other than the page itself, including your own CDN zone, and must not change from the recorded checksum. The browser rejects a file whose hash does not match the attribute. It does not help against code written straight into your own page or into your own script files.
Is a Content Security Policy enough to stop Magecart?+
Not automatically. If 'unsafe-inline' is in script-src, injected inline code still runs. A policy helps when it limits script sources to your own hosts and reports violations.