Plerdy SEO Tracker Hack: What Site Owners Should Check

The Plerdy SEO tracker hack turned a script that ordinary websites embed into a delivery route for a Safari and Chrome exploit chain that steals browser cookies. CISA has now flagged the Apple bug at its center, CVE-2024-27834, as actively exploited. If your site loaded that tag, or your admins log in from older Apple devices, you have work to do.

What happened in the Plerdy SEO tracker hack?

Attackers used the Plerdy SEO Tracker, a third-party script that site owners add for SEO and visitor analytics, as one of three routes for delivering a browser exploit chain that steals cookies. Security firm Sekoia documented the campaign. The U.S. Cybersecurity and Infrastructure Security Agency (CISA) then added an Apple WebKit flaw, CVE-2024-27834, to its Known Exploited Vulnerabilities (KEV) catalog.

The Hacker News article, dated November 5, 2026, says the addition happened “on Wednesday.” November 5 was a Thursday, so the KEV entry landed on November 4 or 5.

According to Sekoia, visitors reached the malicious code in three ways:

• Compromised legitimate websites, where attackers injected script into pages people already trust.
• Fake sites built to look like popular websites.
• A supply chain compromise of the Plerdy SEO Tracker, which put attacker code on sites that had simply embedded the tag.

Every route ends the same way. JavaScript on the page profiles the visitor’s device and browser first. Only when the target looks suitable does it trigger the exploit and drop a payload that collects browser cookies plus browser and device data.

For a site owner, the supply chain compromise is the uncomfortable route. You did not need to be hacked in the usual sense to take part. If your pages loaded a script someone else controlled, and that someone else got compromised, your visitors received whatever that script served.

Why does an old Safari bug matter to your website?

CVE-2024-27834 is one link in a chain that turns a page view into a stolen login session. Plenty of devices that log into websites still run software from before the fix. On its own the flaw is modest: an improper authentication bug in Apple WebKit, rated CVSS 5.5, that lets an attacker who already has arbitrary memory read and write bypass Pointer Authentication.

Pointer Authentication Codes (PAC) are a hardware protection on Apple chips. They cryptographically sign pointers, so an attacker who corrupts memory cannot simply redirect execution wherever they like. A PAC bypass grants no access on its own; it removes a barrier that matters only after another bug has already given the attacker read and write access. That dependency explains the medium score. Attackers care that the bypass makes the chain work.

The flaw was demonstrated as a zero-day at Pwn2Own Vancouver in March 2024. Apple shipped fixes in May 2024, describing them as “improved checks” in its release notes. About two and a half years later, it was used in this campaign against devices that never took the update.

As reported, the chain pairs a WebKit remote code execution bug with the PAC bypass to run a JavaScript payload that steals cookies. The source calls it zero-click, meaning the exploit fires on page load with no further interaction from the victim.

Verification note: The report lists CVE-2025-43529 for both the WebKit RCE and the PAC bypass, apparently an editing error in the source. Given CISA’s listing, CVE-2024-27834 is the most plausible PAC bypass, but treat any second identifier as unconfirmed until Sekoia or Apple clarifies.

Chrome users were hit too, through already patched (n-day) vulnerabilities the report does not name. The source describes no sandbox escape and no persistence. The goal is narrow and practical: cookies and device data. A valid session cookie lets an attacker act as you on the site the cookie belongs to, until it expires, often without your password or two-factor code.

Could your site be handing the script to visitors?

Yes, if your pages load third-party JavaScript you don’t control, and this campaign shows exactly how. A watering hole attack poisons a site the intended victims already visit. The site owner usually has no idea, because nothing changes in the admin panel.

Your site could end up in that role two ways. In the first, attackers compromise the site itself and inject script through a vulnerable plugin, stolen FTP or admin credentials, or a writable theme file. In the second, they never touch your server. They compromise a vendor whose tag you embedded, like the Plerdy SEO Tracker, and every page carrying that tag serves their code. In Sekoia’s account, site owners who used Plerdy were unwitting distribution points.

The fingerprinting step makes this hard to spot. The script checks the visitor’s device before doing anything. View your own site from an updated MacBook or current Chrome and it has no reason to fire, so you see a normal page. An old iPad on a visitor’s kitchen counter gets a different experience.

The look-alike sites are a separate problem. They copy popular brands without needing the real brand’s CMS to be hacked. If someone clones your design on a lookalike domain, your server stays clean while your name takes the damage.

Shared scripts have failed this way before. The DebugBear RUM script hijack on Polymarket and the Convertr checkout skimmer hidden in a shared Plausible tracker both turned a trusted tag into the attack surface. The Plerdy case adds a browser exploit chain at the end.

What should you check on the site today?

Start with an inventory of every third-party script your pages load, then work back to the CMS itself. This is the order we use.

Clean up the tags

1. List every external script. Check the theme header and footer, any header/footer injection plugin, your tag manager container, and SEO or analytics plugins. Open your homepage with browser developer tools and review the Network tab for script domains you can’t explain.
2. Look for Plerdy specifically. If you embedded the Plerdy SEO Tracker, note when you added it and whether you still need it. If you can’t verify it serves clean code today, remove it until Plerdy publishes an explanation.
3. Remove or replace anything unaccounted for. Old marketing trials and abandoned testing tools are the usual leftovers.
4. Purge every cache. Page, plugin and CDN caches can keep serving a deleted tag for days.

Rule out your own compromise

1. Check whether the site itself was the watering hole. Review recently added admin users, plugins you don’t recognize, and changes to theme files and the mu-plugins folder. Compare file modification dates with your last legitimate update.
2. Keep Google warnings separate. A Search Console security issue or hacked content notice is its own problem. Clean the site completely before requesting a review.

Practitioner’s note: In the site audits we run, the third-party script list is almost always longer than the owner thinks. We regularly find a heatmap tool from a two-year-old trial, a chat widget nobody uses, and a tag manager container a former agency still controls. Each one is a vendor you are trusting with your visitors’ browsers. If no one on the team can name a tag’s purpose, it goes.

For indicators of compromise, go to Sekoia’s report; we don’t reproduce them here. Server-side scanning such as SiteGuarding Antivirus helps with the compromise check by flagging injected code and modified files, but no server scan can tell you whether a remote vendor script is clean. That’s why the inventory comes first.

Are the devices you use to log in still unpatched?

Patching login devices closes the second risk. If you or a contractor logged into wp-admin, Joomla administrator, cPanel or your registrar from an outdated iPhone, iPad or Mac, those session cookies are exactly what this payload collects.

Apple’s May 2024 fixes for CVE-2024-27834 shipped in these versions:

Most current devices updated long ago. The realistic exposure is older, unmanaged hardware: a spare iPad used to moderate comments, a family Mac that stopped nagging about updates, an iPhone stuck on the 16.x branch. For Chrome, update to the current release. The source names no Chrome CVEs or versions, so “latest” is the only safe answer.

U.S. Federal Civilian Executive Branch agencies must patch by November 18, 2026 under CISA’s KEV rules. Everyone else has no deadline, which is not the same as having time.

If an admin device was out of date and may have visited a compromised or look-alike site:

• Click “Log Out Everywhere Else” in your WordPress profile and end other sessions in your hosting panel.
• Rotate admin, hosting and email passwords from a patched device.
• Regenerate the WordPress salts in wp-config.php, which invalidates every existing login cookie at once.
• Review the user list and recent logins for activity you don’t recognize.

Who is blamed, and what is still unconfirmed?

Sekoia attributes the campaign to APT29, also known as Cozy Bear and Midnight Blizzard, a group linked to Russia’s Foreign Intelligence Service (SVR), with “moderate to high confidence.” The Hacker News headline framing is more cautious, saying only that the actors are possibly linked to Russia. Attribution is an assessment, not a verdict, so read it that way.

What we still don’t know:

• The correct CVE identifiers for the full chain.
• Which Chrome bugs were used, and on which platforms.
• How and when Plerdy was compromised, which customer sites served the malicious script, and whether Plerdy has fixed it or commented. Nothing in the reporting says every Plerdy customer was affected.
• Who was targeted, how many victims there are, and whether the campaign is still running.
• Whether the payload has a name or gains any persistence.

None of these gaps changes the defensive plan: know every script you load, keep admin devices current, and treat a compromised vendor tag as an incident on your own site.

FAQ

What is the Plerdy SEO tracker hack?

According to Sekoia, attackers compromised the Plerdy SEO Tracker and used it, along with hacked and fake websites, to push JavaScript that fingerprinted visitors and then ran a cookie-stealing exploit chain against vulnerable Safari and Chrome browsers.

Do I need to remove Plerdy from my website?

If you can't confirm the tag currently serves clean code, take it off your pages until Plerdy explains what happened, then clear page, plugin and CDN caches. The reporting does not say every Plerdy customer was affected.

What is CVE-2024-27834?

A medium-severity (CVSS 5.5) improper authentication flaw in Apple WebKit. An attacker who already has memory read and write access can use it to defeat Pointer Authentication. It debuted as a zero-day at Pwn2Own Vancouver in March 2024 and Apple patched it two months later.

Which Apple and Safari versions fix CVE-2024-27834?

iOS and iPadOS 16.7.8 or 17.5, macOS Sonoma 14.5, Safari 17.5, tvOS 17.5 and watchOS 10.5, or any later versions.

Could stolen browser cookies give someone access to my WordPress admin?

Yes, until the cookie expires or is invalidated. If an admin device may have been exposed, end all other sessions, change passwords from a patched device and regenerate the salts in wp-config.php.

Found a script you can’t explain or code you didn’t add? A SiteGuarding website protection package covers malware removal, a website firewall and ongoing monitoring so a poisoned tag doesn’t sit on your pages unnoticed.