Third-party code on your site

On an average website a whole lot of code runs that does not come from there. An analytics script, a map display, a chat window, a font library, a review widget, a booking system.

Each of these is loaded from a third-party server when the page is opened and runs in your visitors' browsers — with the same rights as your own code. It can read what is on the page, it can change the page, it can read along with form entries.

On top of that comes the layer below: plugins and themes are updated from sources that do not belong to you. That is third-party code too, only with even more far-reaching rights — directly on the server, with access to the database.

The order of magnitude

The numbers make clear where the risk sits.

In 2025, 11,334 new vulnerabilities became known in the WordPress ecosystem — 42 percent more than the year before.

Their distribution is remarkable:

• 91 percent in plugins
• 9 percent in themes
• Six in WordPress itself, none of them high-risk

So the risk lies almost entirely in what you install on top, not in the software itself.

The speed is the real problem. The median until the first mass exploitation is five hours. And 46 percent of the published holes had no fix at all at the time of publication.

(Atlas, security/wordpress-attack-surface-2025-2026.md; threat-intel/patchstack-2026-state-of-wp-security.md)

The supply chain is now the main route

Attacking a single website does not pay. Attacking something installed on a hundred thousand websites pays very well.

Two cases from April 2026 show what that looks like in practice:

Case one: a provider had bought up 31 plugins. In August 2025 a backdoor was built in. It slept for eight months. At the beginning of April 2026 it was activated for just under seven hours. More than 20,000 websites were affected.

Case two: at the same time the update server of a widespread slider plugin was compromised. The malicious code came through the legitimate update channel — that is, exactly through the route considered safe. More than 800,000 installations.

The lesson from this is uncomfortable and simple: when a plugin changes owner, that is an event in the supply chain.

The trust placed in a plugin applies to the developer who built it, their care and their reputation. After a sale, none of that automatically carries over.

In practice that means: after a change of ownership, it is reassessed — just like the first time. Who is the new provider? What else do they do? Why did they buy?

Such takeovers are usually announced in a post hardly anyone reads. For plugins that run on many maintained websites, it is worth watching for such announcements.

(Atlas, security/wordpress-supply-chain-attacks-2024-2026.md)

Can you tell when a script changes?

For files embedded from third-party servers there is a method for this: a cryptographic checksum in the HTML. The browser loads the file, recalculates the checksum and only runs it if it matches.

<script src="https://cdn.example.com/bibliothek-3.2.1.js"
        integrity="sha384-…"
        crossorigin="anonymous"></script>

What it detects: a file swapped under the same address — whether through a compromised delivery network or a redirected request.

What it works for: files with a fixed address and a fixed version. A library pinned to version 3.2.1 delivers the same bytes on every fetch.

What it fundamentally does not work for — and this is the important part:

• Tag management systems. They assemble their file from the current configuration on every request. The bytes are different on every request. There cannot be a fixed checksum.
• Addresses that always deliver the latest version. They change as soon as the provider publishes.

Why this distinction matters: such sources are a deliberately accepted risk, not a fixable defect. Reporting both the same would be dishonest — and harmful in practice, because a permanently red row leads people to skip the whole category at some point.

The right question for such sources is not “how do I secure them”, but “do I need them”.

(Atlas, security/subresource-integrity.md)

The small thing with new windows

A link that opens in a new window gives the target page a reference to the window it was opened from. Through this reference the target page can redirect the original page — the visitor only notices when they switch back and find something else there.

The safeguard is an attribute:

<a href="https://example.com" target="_blank" rel="noopener">Zur Quelle</a>

For context: modern browsers now apply this behaviour by themselves. Stating it explicitly does no harm, records the intent in the code and covers the cases where the default does not apply.

A variant, rel="noreferrer", additionally prevents the originating address from being passed on.

(Atlas, security/subresource-integrity.md)

The one real emergency

There is exactly one finding on a website that has to be dealt with not “this month” but today: an entry on the blocklist the major browsers share.

Then visitors see a full-page red warning instead of your website. No visitor, no enquiry, no revenue — and considerable damage to trust with everyone who sees it.

How to deal with it:

This is an incident, not an optimisation point. The order:

1. Change all credentials — WordPress, database, FTP, host.
2. Check the files, especially the directories where malicious code likes to nest.
3. Restore from a backup known to be clean. This is where long retention pays off: if the backdoor has been there for six weeks, yesterday's backup is affected too.
4. Find the cause.
5. Only then request a review.

Just having the warning cleared without finding the cause regularly leads to a second entry — and that one is treated worse than the first.

And the other way round, an assessment that protects against false security: a clean answer is no free pass. Such lists report what has already been found. A freshly compromised website is not on them yet.

How to check it yourself

The list of third parties. Developer tools (F12), Network tab, reload the page, sort by domain. Everything that is not your own address is a third party. Write the list down — there are usually more than you expect.

Then three questions for every entry:

• Do I know what this is?
• Do I still need it?
• Is it in my privacy policy?

The third question connects this topic with data protection: the same list answers both questions — which third-party code runs, and which recipients the privacy policy has to name. Two duties, one list.

The blocklist status. Google Search Console has a “Security issues” section. If nothing is there, everything is fine at this point.

The plugin layer. In the backend under Plugins: when was it last updated? Is it still maintained? A plugin that has not had an update for two years is an open bill.

And search the source once for target="_blank" — and see whether rel is there too.

What to do

1. Reducing comes before securing. Every script you remove you no longer have to secure. That is the most effective step in this whole field — and at the same time it makes the page faster and the privacy policy shorter.

On almost every grown website I find tracking pixels from campaigns that ran years ago and widgets from services long cancelled.

2. Switch on automatic updates where that is defensible. With five hours until mass exploitation, “I do the updates at the end of the month” is not a strategy. For critical building blocks where an automatic update could break something, the checked route through the staging environment remains — but then promptly.

3. Set checksums where possible: for pinned library versions from third-party servers.

4. For the others, ask whether they need to be there.

5. Keep the list of third parties and maintain it together with the privacy policy. Both go out of date if only one is maintained.

6. Reassess after changes of ownership.

7. And have a backup with long retention. In an emergency it is the difference between half a day and a week.

What I tell clients about this: the question is not whether you trust third-party code — a modern website cannot be built without it. The question is how many you trust. Five services you know and maintain are a manageable risk. Twenty, half of which nobody can place any more, are not.

Sources

• Atlas, security/wordpress-attack-surface-2025-2026.md — 11,334 new vulnerabilities in the WordPress ecosystem in 2025 with an increase of 42 percent, the distribution with 91 percent in plugins, 9 percent in themes and six in core with none of them high-risk, the median of five hours from publication to mass exploitation, the share of 46 percent without a fix at the time of publication, the supply chain as the primary attack route, and automatic updates as the consequence of the five-hour window.
• Atlas, security/wordpress-supply-chain-attacks-2024-2026.md — the April 2026 incident with 31 bought-up plugins, the backdoor built in in August 2025 and sleeping for eight months, its activation for 6 hours 44 minutes on 5 and 6 April 2026 and more than 20,000 affected websites; the simultaneous compromise of the update server of a widespread slider plugin, delivering the malicious code through the legitimate update route to more than 800,000 installations; the classification of a plugin takeover as a supply chain event requiring a renewed assessment of trust; and checksum protection of third-party embedded scripts as a defence.
• Atlas, security/subresource-integrity.md — the checksum attribute with algorithm prefix and digest, the need for the crossorigin declaration with third-party servers, blocking on mismatch, what the check achieves (pinned files, own resources, swapped files under the same address), the delivery patterns outside its reach (files assembled per request by tag management systems, addresses with a rolling version) and the resulting classification as a deliberately accepted risk rather than a fixable defect, with the reasoning about permanently red findings, as well as noopener and noreferrer with today's browser default and the reason to state the relationship anyway, and the inventory of third-party origins with its double function for the privacy policy.
• Atlas, threat-intel/patchstack-2026-state-of-wp-security.md — the 2025 annual figures and the recommendation of a backup retention of 30 days, so that a compromised website can be reset to a state before the compromise.
• Own checklist technisches-seo — no malware warnings in Search Console as a check, and regular security and plugin updates.
• Own audit practice — the five-step procedure for a blocklist incident with the note on the second entry, the classification of a clean blocklist answer as no free pass, the note on regularly found tracking pixels and widgets from ended campaigns, the double use of the service list for security and the privacy policy, and the closing classification by number rather than presence of third-party services.