MCP is how AI agents plug into external tools and services, and it is spreading fast into exactly the kind of automation that runs on servers and in build pipelines. If any of your systems act as an MCP client and connect to servers you do not fully control, this is a credential-theft problem you need to close now, and patching alone does not finish the job.

What the flaw actually was

When an MCP client authenticates with OAuth, it is supposed to send its credentials to a known, trusted authorization server. The vulnerable SDK skipped the step of validating that authorization server’s identity before handing over the credentials. That single omission is the whole vulnerability.

Because of it, a malicious MCP server could redirect a connecting client to an attacker-controlled endpoint and intercept:

• Client secrets. These are long-lived credentials. Unlike a session token that expires, a stolen client secret keeps working until someone rotates it.
• Authorization codes.
• PKCE proof keys. PKCE exists specifically to stop an intercepted authorization code from being reused. Capturing the proof key defeats that single-use protection, so PKCE, the control you would expect to save you here, does not.

With those in hand, an attacker obtains valid access tokens carrying the full application permissions of the victim client. This is not a crash or a data-read bug. It is credential theft that hands over the identity your client uses to reach everything it is authorized to reach.

Who is affected, and who is not

The flaw is in the client-side OAuth providers of the SDK. Affected providers include OAuthClientProvider, ClientCredentialsOAuthProvider, PrivateKeyJWTOAuthProvider, and the deprecated 1.x RFC7523OAuthClientProvider.

Notably not affected: MCP servers themselves, stdio clients, and applications that attach tokens with their own custom logic. So the risk sits specifically with applications acting as OAuth MCP clients that connect out to MCP servers. If that describes any automation you run, you are in scope.

Severity is rated CVSS 7.5 (high) for non-interactive providers and 6.5 for the interactive provider. The higher score for non-interactive providers makes sense: unattended, server-to-server automation is exactly where a stolen long-lived client secret does the most damage, because there is no human in the loop to notice anything odd.

Affected and fixed versions

One detail worth flagging: the fix first shipped on September 7 listed as a behavior change, not a security fix, with the formal advisory only following on September 28. If you update dependencies by scanning changelogs for the word “security,” you would have missed this for three weeks. That is a recurring trap with SDK-level fixes, and a reason to treat behavior-change notes in a security-sensitive dependency as worth a second look.

What to do, and why patching is only step one

Upgrading closes the hole going forward. It does not undo credentials that may already have been exposed if your client ever connected to a server you did not fully trust. Work through all of these:

• Upgrade the SDK to 1.30.0 or 2.2.0, whichever matches your line.
• Two providers need an extra step after upgrading. ClientCredentialsOAuthProvider and PrivateKeyJWTOAuthProvider require you to pass the issuer= parameter post-upgrade. Without it, you have installed the fix but not fully engaged it.
• Clear stored OAuth client registrations. Old registrations can carry the unsafe state forward.
• If your client ever connected to an untrusted or third-party MCP server, assume the credentials are burned. Rotate client secrets and revoke tokens at the login service. Because the stolen client secret is long-lived, rotation is the only thing that actually stops a quiet attacker who already grabbed it. Revocation without rotation is not enough. If you are not sure whether an affected server was ever compromised in the process, that assessment is exactly what our emergency incident response team handles.

Also note a Python-specific gotcha: version 1.30.0’s deprecation warnings are hidden by default in Python, so you may not see prompts telling you that a provider now needs the issuer= parameter. Do not rely on the warnings to remind you. Make the config change deliberately.

The takeaway

There are no known attacks using this yet, which makes now the good time to act rather than the reason to wait. The lesson underneath is one that keeps repeating as agents and MCP wire more systems together: connecting to an MCP server is a trust decision, and a client that hands over credentials without verifying who is on the other end turns every untrusted server into a credential-theft opportunity. The bug is a classic missing-validation flaw wearing new MCP clothes, and the credentials at stake are long-lived client secrets with full application permissions. Upgrade to 1.30.0 or 2.2.0, set the issuer= parameter where required, clear old registrations, and rotate anything that ever touched a server you did not control. If you want an outside check on where your automation’s OAuth credentials and long-lived secrets are actually exposed, that is what our penetration testing and managed security hardening services are for.

How this unfolded

On September 26, the firm watchTowr reported that during forensic investigations it had found two unpatched RCE vulnerabilities in NetScaler, both already being exploited in the wild, both with no patch at the time. That is the classic zero-day pattern: the hole is in use before a fix exists.

A day later it closed out officially. CISA confirmed that threat actors are actively exploiting these vulnerabilities globally, assigned CVE numbers, and on September 27 added both to its Known Exploited Vulnerabilities catalog. US federal civilian agencies were ordered to apply the fixes by September 30. CISA sets a deadline like that only for things being hit right now.

The two flaws

Both are rated CVSS 9.5, the top of the scale:

• CVE-2026-88771 (9.5): improper input validation, lets an unauthenticated attacker execute arbitrary commands. Affects all NetScaler ADC and NetScaler Gateway deployments.
• CVE-2026-88772 (9.5): improper memory buffer restriction, leads to remote code execution or denial of service. Requires DTLS configuration enabled, which is the default on VPN virtual servers.

Note the word “unauthenticated” in the first one. The attacker needs no account, no session, no prior access. Network reachability of the device is enough. The second hits exactly the configuration most deployments run by default when NetScaler is used as a VPN gateway, and that is how it is used almost everywhere.

Fixed versions

Update to at least these builds on the line you run:

• NetScaler ADC/Gateway 14.1-73.37 and later
• NetScaler ADC/Gateway 13.1-64.23 and later
• NetScaler ADC 14.1-FIPS 14.1-73.37 FIPS and later
• NetScaler ADC 13.1-FIPS and 13.1-NDcPP 13.1.37.279 and later

A separate note on 13.1: it reached End of Maintenance on September 15, just a couple of weeks before all this. If you are on 13.1, confirm you are pulling the fixed build specifically, and keep in mind that this line will not get updates going forward. That is a reason to plan a migration, not just a one-off patch. If your infrastructure is managed by someone else, this is exactly the kind of detail server management done properly is supposed to catch before it becomes a deadline.

Why the patch is only half the job

This is the part that matters most on NetScaler-class devices. Installing the patch closes the hole going forward, but it does not answer whether someone already got in. If an attacker gained access before you updated, they could have persisted in a way the patch does not evict: stolen keys, added accounts, a web shell on the appliance itself. Both flaws were exploited before the fix shipped, and the first wave was found during forensic investigations in the first place. That means for some devices the patch arrives after the compromise.

So on any NetScaler that sat exposed on a vulnerable version, it is reasonable to assume possible compromise and work through the steps Citrix itself recommends:

• Preserve evidence before you touch anything: VPX snapshots, logs, technical support bundles, core dumps. Without them there is nothing to investigate later.
• Isolate the device from the network while you check it.
• Change service account passwords, revoke and reissue certificates and keys, replace SSL certificates. If the device was reachable, treat everything on it as compromised.
• Check the systems NetScaler had access to, not just the gateway itself. A perimeter foothold is rarely the final target.
• Rebuild the device on updated firmware rather than trying to clean it in place if there are any signs of access. If you need that confirmed rather than assumed, that’s exactly what our emergency compromise response team checks for.
• The NetScaler management interface should never face the public internet. If it was exposed, that is the first thing to close.

The takeaway

In a single day these two flaws went from an anonymous post on X to a CISA catalog entry with a federal deadline, and that pace is one to get used to: the gap from disclosure to confirmed mass exploitation is now hours, not weeks. NetScaler is a high-value target precisely because it sits at the boundary and holds the way into the internal network, and both flaws give unauthenticated RCE at that boundary. Update to a fixed build immediately, and on any device that was exposed on a vulnerable version, do not stop at the patch: check whether someone already got in. If you would rather have an outside team confirm your perimeter appliances are actually patched and clean, that is what our penetration testing and managed security hardening services are for.

We clean up compromised hosting environments for a living, and webmail is one of the most reliably neglected surfaces on any server. It gets installed once, exposed to the internet permanently, and then nobody touches it until something goes wrong. That is the population getting hit right now.

The flaw

The vulnerability lives in Roundcube’s virtuser_query plugin, rated CVSS 8.1. The root cause is a preg_replace() backslash-escape bypass: input that should have been neutralized slips through the escaping and reaches the SQL query intact. Because the affected path is reachable before authentication, an attacker needs no account and no credentials. Per SentinelOne’s analysis, an unauthenticated attacker can inject SQL into Roundcube’s database backend through that plugin, potentially exposing mail account credentials and stored messages.

Sit with what that exposes. Roundcube’s database holds the keys to the mailboxes it serves: account credentials and the stored contents of people’s email. On a shared hosting box, one webmail install often fronts mail for many customers, so a single successful injection is not one mailbox, it is potentially every account on that instance. Email is also the reset vector for everything else, so mailbox access is rarely the end of the story.

Affected and fixed versions

The vulnerable and patched builds are narrow, so check your version precisely:

Update to at least 1.6.16 or 1.7.1 on the branch you run. If your webmail came bundled with a hosting control panel, the panel vendor may package Roundcube separately from its own updates, so confirm the actual Roundcube version rather than assuming the panel’s latest build carries it. If you’re not sure your hosting stack is tracking these versions correctly, that’s exactly the kind of gap server management done right is supposed to catch.

Why “patched in May” does not mean you are safe

This is the part that matters. The fix has existed for months, which means the exploitation you are seeing now is entirely against installs that never applied it. The timeline is instructive:

• May 2026: Roundcube released the patches.
• July 2026: a China-aligned threat actor tracked as UNK_MassTraction was already exploiting known Roundcube vulnerabilities.
• September 2026: the Canadian Centre for Cyber Security confirmed active exploitation of this flaw in the wild, citing open-source reporting.

The scale of the exposed surface is the reason this stays profitable for attackers. Shadowserver data from September 23 counted more than 523,000 Roundcube instances reachable from the internet. That is an enormous field of targets, and webmail is precisely the kind of software that gets stood up and forgotten. State-aligned actors have specifically favored Roundcube flaws because the install base is huge, internet-facing by design, and patched slowly.

What to do

• Update now to 1.6.16 or 1.7.1, whichever matches your branch. There is no substitute for the patch.
• Check the real version. Do not trust the control panel’s version label. Confirm the Roundcube build itself, and if you manage mail for clients, check every instance, because the one forgotten install is the one that gets hit.
• Assume pre-patch compromise on any instance that sat exposed on a vulnerable version between May and now. Because the payoff is credentials and message contents, treat exposure as potential data access, not just a patching to-do. If you need that confirmed rather than assumed, that’s what our hacked website and hosting cleanup team checks for.
• Rotate mail credentials on any instance you cannot rule out. If the database was reachable, assume the account passwords and stored messages in it are burned.
• Review database and access logs for anomalous queries against the Roundcube backend and for unusual authentication activity on the mail accounts it serves.

The takeaway

CVE-2026-48842 is not a novel or exotic bug. It is a plain pre-auth SQL injection with a fix that has been available since May, being exploited in September against the half-million-plus installs that never updated. That is the whole lesson: on internet-facing infrastructure, a patch you have not applied is identical to no patch at all, and webmail is the surface most likely to be running on last year’s version. Update to 1.6.16 or 1.7.1, verify the real version, and treat any instance that was exposed as a mailbox breach until you can prove otherwise. If you’d rather have someone independently confirm your mail and hosting stack is actually patched and clean, that’s exactly what our penetration testing and secure hosting services are for.

We spend a lot of time on the seam between deployment tooling and live infrastructure, and this is exactly the seam attackers are now probing. A malicious npm package infects a developer laptop. A malicious Terraform provider runs inside the process that provisions your cloud. Those are not the same blast radius.

What was published

Per Aikido, which disclosed the activity, the malicious packages were:

• Terraform providers: gocommunity-io/dockerd (222 downloads) and kreuzwenker/docker (1,449 downloads).
• Go modules: gocommunity.io/orderedbtree and gogets.dev/btreex.

Notice the naming. dockerd and docker are typosquat-adjacent names built to look like legitimate container tooling, which is exactly what an engineer wiring up container infrastructure might grab without a second look. Both share infrastructure with a parallel wave of malicious npm packages flagged this week by Checkmarx, JFrog, and SafeDep, including indexed-btree, mathsbase, mathmain, math-universe, modern-events, quick-events, crypto-hasher, events-router, sort-btree, graphcore-js, and graphlib-js. If any of those names are in your dependency tree, treat it as a hit and read the response section below.

Why a Terraform provider is a worse place to hide malware than an npm package

This is the point worth sitting with. Aikido called the Terraform vector novel but unsurprising, and the reasoning is blunt: a provider gives a more direct pathway to critical production credentials. Think about where Terraform code actually runs. It runs in your CI/CD pipeline or on an operator’s machine, holding exactly the credentials needed to create and destroy real infrastructure: cloud API keys, cloud provider tokens, secrets for whatever it provisions. A provider is code that Terraform executes with all of that in reach. Malware that lands there does not need to escalate or move laterally to get to the good stuff. The good stuff is already in the environment it starts in.

This is also not a one-off experiment. Just last week, SentinelOne detailed a separate North Korea-linked cluster, TraderTraitor, using weaponized Terraform lock files to deliver Rust backdoors from attacker-controlled provider registries. Two DPRK-linked campaigns reaching for Terraform in the same window is the kind of pattern that stops being coincidence. As Socket’s researcher put it, these actors have a history of taking a technique that works and applying it across campaigns, and Terraform registries may be the next distribution channel they scale up.

How the implant talks home: two C2 channels, both hard to kill

The Go implant delivered through the Terraform and Go paths is a port that shares blockchain and Slack infrastructure with the npm version, and it runs dual command-and-control. This design is what marks it as a targeted, well-resourced operation rather than commodity crimeware.

On execution it fingerprints the host, collecting hardware attributes, OS, hostname, and whether Node.js is present, then sends that check-in to an attacker Slack channel over the API. From there:

• Slack channel: the implant polls the conversations.history endpoint every 10 seconds and reassembles file transfers from a sequence of start, chunk, and end packets. A Slack bot token as C2 blends into normal corporate traffic, because outbound HTTPS to Slack is not something most egress rules flag.
• Blockchain dead drop: the Go port pulls encrypted commands from an Ethereum smart contract on the Arbitrum Sepolia testnet, using a hard-coded contract address and polling every 3 seconds. Retrieved commands run as Go or JavaScript. There is no takedown for a smart contract, so this channel cannot simply be seized the way a domain can.

The operators layered real cryptographic discipline on top. The implant generates an ephemeral key pair and derives shared keys by combining it with two threat-actor public keys, so infected hosts can share channels without exposing C2 traffic or leaking one victim’s messages to another. Every client consumes every message and silently no-ops on anything it cannot decrypt. Researchers recovered the implant but not the later code delivered through these channels, which means the full set of actions run on victims is still unknown. Read that as a warning, not an all-clear: “we could not recover the second-stage payload” is not “there was no second stage.”

How victims get hit in the first place

The delivery relies on social engineering as much as on the registry. The Graphalgo playbook approaches developers through LinkedIn, Facebook, and job-board postings, posing as Web3 companies that do not exist, then asks the target to complete a coding task built around a benign-looking GitHub repo that pulls in the malicious dependency. In several packages the payload only decrypts when the victim performs a specific cryptographic operation, solving a linear system with one particular matrix, which both narrows execution to intended targets and frustrates researchers who find the backend without the matching front end.

This same fake-interview pattern is spreading. The Rust project warned this month about an ongoing campaign targeting rust-lang members and popular crate owners, where a video call for a supposed job or contract is used to get the target to install something (a fake “missing audio codec”) or paste a command from the clipboard. The Rust warning overlaps with the Contagious Interview campaign, also tied to North Korea. The common thread across all of it: the initial access is a person being convinced to run code, and the package registry is just the delivery mechanism.

What to do

There is no single patch here, because the exposure is a class of dependency, not a versioned bug. Concrete steps:

• Audit your Terraform providers and modules against the named list. If gocommunity-io/dockerd, kreuzwenker/docker, gocommunity.io/orderedbtree, or gogets.dev/btreex appear anywhere in your IaC, treat the environment that ran them as compromised.
• Check your npm tree for the flagged packages listed above, since they share the same operator infrastructure.
• Rotate every credential the affected pipeline or machine could reach. For Terraform that means cloud API keys, provider tokens, and any secret the plan had access to. Given the whole point of the Terraform vector is proximity to production credentials, assume those are the first thing that was taken.
• Watch egress for the C2 patterns. Unexpected outbound calls to Slack API endpoints from a build agent, or any traffic to Arbitrum Sepolia testnet RPC endpoints from infrastructure that has no business touching a blockchain, are strong signals. Normal build servers do not poll conversations.history every 10 seconds. If you are not sure your team would catch that pattern, an outside penetration test of the pipeline is a faster way to find out than waiting for an incident.
• Pin and vet infrastructure dependencies like production code. Providers and modules from unfamiliar namespaces deserve the same scrutiny as any third-party package, and low download counts on a provider with a name that mimics popular tooling is a red flag, not a reassurance.
• Treat unsolicited job interviews that involve running code as hostile. If a “hiring task” or a call asks a developer to clone and run a repo, install a codec, or paste a command, that is the initial access vector in this entire campaign family. Enforce MFA and review accounts for unexpected logins. If you suspect a machine already ran one of these payloads, that is exactly the scenario our emergency malware removal team is built for.

The takeaway

The supply chain conversation has mostly centered on npm and PyPI, because that is where the volume has been. This moves the frontier. Terraform providers put attacker code inside the process that holds your infrastructure credentials, which is a shorter path to real damage than a poisoned application dependency, and a capable, state-linked actor has now used that path twice in two weeks. The download numbers are small today. The technique is the part that scales. Audit your infrastructure dependencies with the same seriousness you give your application ones, rotate anything the affected pipelines could reach, and treat the too-good-to-be-true coding interview as the attack it usually is. If you want that discipline applied on an ongoing basis instead of after the fact, that is what our managed security hardening service and secure hosting environment are built around.

We see MikroTik gear constantly on the perimeter of hosting setups and server infrastructure we manage, and the reason this attack matters is that the router is the one device that sees all your traffic and holds the keys to your network layout. Here is how the chain works, how to tell if you were hit, and what to do about it.

The chain: two flaws that are weak alone and devastating together

MikroTrick combines two separate RouterOS SSH vulnerabilities. Neither one is game over by itself. Stacked, they hand over the whole device.

Step one: skipping authentication (CVE-2026-67279)

Normal SSH runs in a strict order. It sets up an encrypted connection, authenticates the user, and only then lets the client open a session and run commands. The server sends a specific confirmation message once authentication passes, and nothing should proceed without it.

CVE-2026-67279 breaks that order. If the client kicks off an SSH key renegotiation during the authentication step, vulnerable RouterOS jumps straight to the command phase once the renegotiation finishes, without ever confirming who the user is. On its own this does not create an authenticated session or grant privileges. What it does is let an unauthenticated stranger reach a stage that is supposed to be locked behind a completed login. That is the door being propped open.

Step two: becoming admin through the login program (CVE-2026-86060)

This is the clever part, and it is a textbook argument-injection bug. When a session comes in, RouterOS runs a login program at /nova/bin/login, and the SSH daemon passes it the username and a privilege level as command-line arguments. The problem: it does not validate the username first. A value that starts with a hyphen gets treated as a program option, not as a name.

So the attacker sends -2 as the username. The login program reads that as an instruction to pull its identity and privilege level from file descriptor 2, which happens to point at the terminal the SSH session created. And through the SSH channel the attacker has already written their chosen username and a full-admin privilege value into that very terminal. The login program dutifully reads both and opens a fully privileged console. No credential ever changed hands.

That is the whole trick: one bug gets you to the login stage without authenticating, the second bug tells the login program to trust input the attacker controls.

This was exploited before the patch existed

This is not a theoretical chain. CERT Polska found attack logs dating to at least September 2, one day before MikroTik released fixes on September 3. CISA independently confirmed active exploitation by adding CVE-2026-86060 to its Known Exploited Vulnerabilities catalog on September 10.

The attack leaves a very recognizable footprint. On one device documented on the MikroTik forum, the sequence was: a rejected login for user -2, a forced renegotiation, a jump to the channel phase, and an exec request trying to create a user called ops with full privileges. On that particular device the SSH process crashed before the command finished, but other reports confirmed the ops account was successfully created elsewhere. In some incidents CERT Polska saw diagnostic files being generated and then data transferred out to an attacker IP, which strongly suggests router configuration was copied off to attacker infrastructure. Your config is your network map, your firewall rules, your VPN secrets. That is exactly what you do not want in someone else’s hands, and it is exactly the gap a properly configured perimeter firewall in front of admin-facing services is meant to close.

Fixed versions, and who is actually at risk

MikroTik patched the chain in RouterOS 6.49.21, 7.23.4, and 7.24.2. Update to at least these builds on the release line you run.

The precondition for attack is that SSH is reachable by the attacker. MikroTik says its default home configuration does not expose SSH to the Internet, so out-of-the-box home units are largely out of scope. The higher-risk group is everyone who changed their firewall rules or manages devices over SSH from untrusted networks, which describes a lot of real-world hosting and business deployments. If you administer your MikroTik remotely over SSH, assume you are in the target set.

One point of clarity, because some outlets got it wrong: MikroTrick is specifically CVE-2026-67279 plus CVE-2026-86060. A third flaw, CVE-2026-67276, has been incorrectly lumped in. CERT Polska says that one is a separate SSH bug that lets an attacker forge an RSA key to log in as an existing user, but it requires knowing the account name and its public key and only gives access to that one account. Different bug, different severity. Patch for all of them, but do not confuse the two stories.

How to check whether you were compromised

Patching stops the attack going forward. It does not undo anything an attacker already did before you updated. This distinction is critical: a patched router is not automatically a clean router. After updating, check the device Flagged status with:

/system/device-mode/print

But do not lean on Flagged as proof of safety. Both CERT Polska and MikroTik are explicit that the Flagged mechanism only detects selected traces of compromise, and its absence does not prove the device is clean.

CERT Polska published these concrete indicators from observed attacks. Check for all of them:

• Username -2 appearing in SSH login logs.
• An account named ops in the full-privilege group.
• Attacker IP 82.192.72.4, seen in successful attacks.
• Attacker IP 103.102.31.18, used in exploitation attempts.

Beyond those, go hunting for anything you cannot explain: unknown users, unfamiliar scripts, scheduler entries, tunnels, proxies, unexpected .rif diagnostic files, or fetch activity you did not initiate. Those are the kinds of persistence and exfiltration artifacts this attack leaves behind.

If you find any of it: assume full compromise

If any indicator is present, treat the device as fully owned and do not try to clean it in place. CERT Polska’s guidance, which matches what we tell clients after any confirmed router compromise, is direct:

• Isolate the device from the network.
• Preserve its logs and configuration for investigation before you wipe anything.
• Factory reset it and rebuild from a configuration you trust, not from a backup taken off the compromised device. A backup from a compromised router can carry the attacker’s changes straight back in.
• Change every password, key, and credential the router touched. If the config was exfiltrated, assume everything in it is burned, including VPN secrets and any shared credentials.

If you are not confident you can do that isolate-and-rebuild sequence cleanly under pressure, that exact process is what our emergency incident response team handles for compromised infrastructure, not just compromised websites.

The takeaway

MikroTrick is a clean example of why chained vulnerabilities beat isolated ones, and why the network edge deserves the same patch urgency as your servers. An authentication-skip bug that grants nothing on its own, plus a sloppy argument-handling bug in a login helper, combine into unauthenticated full admin on a device that sees all your traffic. It was exploited before the fix was even out. If you run MikroTik with SSH reachable, update to 6.49.21, 7.23.4, or 7.24.2 now, then work through the indicators above, because the patch closes the door but does not evict anyone already inside. If you would rather have someone else confirm your edge devices are actually closed off, that is what our penetration testing and managed security hardening services are for.

We deal with the fallout of compromised developer machines and deployment pipelines regularly, and this one is worth understanding in detail because the delivery method, stealing a project’s own publishing tokens, is becoming the standard playbook. If your site’s build or deploy touches npm or PyPI, read the indicators below and check yourself today.

What got compromised

Two real MemTensor libraries were poisoned across both ecosystems. The specific versions matter, because not every release is malicious:

• npm: @memtensor/memos-cloud-openclaw-plugin versions 0.1.21, 0.1.23, and 0.1.25 are malicious. Versions 0.1.22 and 0.1.24 are clean. Note the pattern: the attacker interleaved bad and clean releases, which is a deliberate way to slip past anyone who assumes “the latest version is fine.”
• PyPI: MemoryOS version 2.0.34. The project is currently quarantined on PyPI.

The npm package is a MemOS Cloud plugin that connects the OpenClaw agent runtime to a memory service, and it declares integration points for the Clawdbot and Moltbot runtimes too. On npm, the hidden Go payload fires when the agent gateway starts and again every time the plugin handles a memory-recall event. Worse, the launcher passes the host process environment and, during recall, the user’s actual prompt text straight to the malicious binary. On the PyPI side it is even more direct: the statically linked Go binary launches the moment the memos module is imported into an application. No special trigger, just import and you are running it.

What sckit steals

Once running, sckit is a cross-platform credential harvester built for Windows, Linux, and macOS. It goes after exactly the things a developer or a CI job tends to have lying around, and ships them to an external server at skyleen[.]fr. Per the researchers who analyzed it, the targets include:

• Credential files: .npmrc, .vault-token, id_ecdsa, credentials.db, access_tokens.json, and stored_tokens.
• Environment variables that signal secrets: anything pointing to tokens, passwords, API keys, private keys, session cookies, and database or message-broker connection strings, including NPM_TOKEN and PYPI_API_TOKEN.
• Named credentials: AWS access keys, GitHub and GitLab tokens, npm and PyPI tokens, plus Hugging Face, HashiCorp Vault, Slack, Stripe, and SendGrid keys, and JWTs.

Read that list as a whole and the intent is obvious. This is not opportunistic browser-cookie theft. It is a targeted sweep of the exact keys that let you publish packages, push code, and reach cloud infrastructure. Those are the keys that turn one infected laptop into a breach of everything that laptop can deploy to.

How the attacker got in: the project’s own release pipeline

This is the detail every team should sit with. The attacker did not phish a maintainer’s password. According to the supply chain analysis, they obtained MemTensor’s publish tokens straight from the project’s own GitHub Actions release pipelines, by pushing commits that caused the workflow to hand over the npm or PyPI token.

In other words, the CI/CD automation that exists to make releases safe and repeatable became the thing that leaked the keys to the kingdom. A release workflow with a publish token in its environment is a high-value target, and if an attacker can influence what that workflow runs, they can make it cough up the token. This is the same class of weakness that keeps showing up in supply chain incidents: over-privileged automation holding long-lived publishing credentials.

The worm behavior is why this cannot be shrugged off

sckit is not a passive stealer that sits and exfiltrates once. Analysis shows it can self-proliferate through GitHub and by directly publishing to npm and PyPI. It collects credentials from developer machines and from CI jobs, it receives signed tasks from a command-and-control server, and it carries templates to install itself into npm packages, Python packages, and GitHub Actions workflows.

Put those pieces together and you get the mechanism: infect a developer or a CI runner, steal their publishing tokens, then use those tokens to poison the next set of packages, which infects the next set of victims. As of now it is unclear whether packages beyond MemTensor were caught in the spread, and that uncertainty is exactly the problem with a worm. “We only know about MemTensor so far” is not the same as “it stopped at MemTensor.”

What to do right now

The malicious npm versions were still downloadable at the time of reporting, so this is not a “wait for it to clear” situation. Concrete steps:

• Pin to a known-safe baseline. For the npm package, pin to 0.1.20. For the PyPI package, pin to 2.0.33. Do not just grab “latest,” given how the attacker interleaved clean and malicious releases.
• Rotate every exposed secret. If any affected version touched a machine or a CI job, assume everything reachable from that environment is burned. Rotate npm and PyPI tokens, AWS keys, GitHub and GitLab tokens, Vault tokens, SSH keys, and any of the third-party keys listed above. Rotation, not just revocation, because you do not know what was already used.
• Kill any running sckit process on affected hosts. If you are not confident you found everything by hand, that is exactly the kind of sweep our emergency malware removal team runs on a compromised environment.
• Block skyleen[.]fr and all its subdomains at your DNS and egress firewall, so any implant you have not found yet cannot phone home.
• Audit your CI/CD publish tokens. This is the real lesson. Check whether your release workflows hold long-lived npm or PyPI tokens, whether those tokens are scoped as tightly as possible, and whether an untrusted commit or pull request can influence what a workflow with those tokens runs. Move to short-lived or OIDC-based publishing where you can. It’s exactly the kind of gap a penetration test of your release pipeline is built to catch before an attacker finds it first.

The takeaway

The MemTensor compromise is a clean illustration of where the risk has moved. The vulnerable surface is no longer just your production server, it is the entire path a piece of code travels before it gets there: the packages you pull, the machine you build on, and the automation that publishes on your behalf. A single poisoned dependency, installed once, can drain the credentials that reach your cloud, your repos, and your deploy pipeline in one motion, and this one tries to reproduce through those same credentials. Pin your versions, rotate anything that was exposed, block the exfiltration domain, and treat your CI publishing tokens as the crown jewels they actually are. If you want an outside team keeping watch on that whole chain instead of catching it after the fact, that ongoing coverage is what our managed security hardening and server management services are for.

We’ve spent years cleaning up compromised hosting environments, and this is the exact class of bug that turns a single throwaway account into a full server breach. Below is what actually matters, why it’s dangerous in practice, and what to do today.

The short version

cPanel’s CalDAV and CardDAV service, the piece that stores each account’s calendars and contacts, contains a privilege escalation flaw. cPanel’s own advisory puts it plainly: successful exploitation leads to code execution as root, giving an attacker full control of the server. The only precondition is having a cPanel account. No admin access, no special role, no chained zero-day. Just an account.

Two more flaws landed in the same batch:

• CVE-2026-87900, a bug in WP Toolkit’s database-creation logic that lets one logged-in cPanel user modify databases belonging to other accounts on the same server.
• CVE-2026-68490, a lower-severity issue in the same CalDAV/CardDAV service where a local user can read other accounts’ calendar events and contacts (read-only, no root).

All three were reported by researcher Ali Mustafa, who goes by rz1027, the same handle credited on a string of recent cPanel and Plesk findings.

Why the root flaw is the one that keeps us up at night

Here’s the thing people underestimate about shared hosting: the whole business model assumes tenant isolation actually holds. A hundred customers, a hundred cPanel accounts, one kernel underneath. The security boundary between “some customer’s website” and “the box that runs everyone’s websites” is supposed to be solid.

CVE-2026-87899 erases that boundary. Think through who has “a cPanel account” on a typical provider:

• Every paying customer, including the one who signed up 20 minutes ago with a stolen card.
• Anyone who phished, credential-stuffed, or otherwise got hold of a single customer’s login.
• Any low-value site on the server that’s already been compromised through an unrelated bug, a stale WordPress plugin, a weak password, whatever.

Any one of those becomes root. And root on a shared server means every site on that machine: database dumps across all tenants, planted webshells, mass defacement, credential harvesting from config files, or a quiet foothold for later. In our hacked website cleanup work, the pattern is almost always the same: the initial break-in happens on the least important account on the box, and the privilege escalation is what makes it a disaster instead of an annoyance.

The advisory doesn’t publish exploit mechanics, and that’s appropriate this early. But CalDAV/CardDAV handling code that touches per-account file permissions is a classic escalation surface, the service runs with elevated privileges to manage every account’s calendar store, so a flaw in how it processes an authenticated user’s request is a direct line from “unprivileged account” to “root context.” cPanel even notes that the update repairs calendar and contact permissions on existing accounts, which tells you permissions were part of the story.

Affected and fixed versions

The CalDAV/CardDAV flaws (both -87899 and -68490) affect cPanel & WHM v120 and later. Patched builds are:

The WP Toolkit flaw (CVE-2026-87900) is separate. It affects WP Toolkit 6.11.2-10794 and older, and is fixed in 6.11.3 or later. Worth flagging: WP Toolkit is a distinct package (wp-toolkit-cpanel) with its own update path, updating cPanel & WHM does not update it. We’ve seen plenty of servers where the panel is current but a bundled add-on is months behind, so don’t assume one update covers both.

What to do right now

1. Patch cPanel & WHM

In WHM, go to Home » cPanel » Upgrade to Latest Version, or run this as root:

/usr/local/cpanel/scripts/upcp --force

The upgrade also fixes the calendar/contact permission state for accounts that already exist on the server.

2. Update WP Toolkit separately

If you have WP Toolkit installed, pull 6.11.3 explicitly:

bash <(curl https://wp-toolkit.plesk.com/cPanel/installer.sh || wget -O - https://wp-toolkit.plesk.com/cPanel/installer.sh) --version 6.11.3

cPanel hasn’t confirmed whether auto-updates will roll 6.11.3 out on their own, so treat this as a manual job until you’ve verified the version. If your sites run on WordPress specifically, this is also a good moment to review your broader WordPress security posture rather than just the toolkit version number.

3. If you can’t patch immediately

There’s no official workaround for the root flaw, the fix is the update, full stop. That makes it a scheduling problem, not an optional one. On any server you can’t touch tonight, our practical advice from cleanup work:

• Treat the window between now and patch as active exposure. Assume the flaw is reachable by anyone with an account.
• Watch for new account signups and sudden activity from dormant accounts, that’s how opportunistic abuse tends to start on shared boxes.
• Review who currently holds accounts and kill any you don’t recognize.
• A web application firewall in front of your hosting panel and customer-facing services won’t patch this bug, but it does cut down the number of accounts an opportunistic attacker can reach in the first place while you get the update scheduled.

Is it being exploited?

As of September 23, none of the three advisories mention in-the-wild exploitation, and none of the CVEs were listed in CISA’s Known Exploited Vulnerabilities catalog. That’s genuinely good news, but it’s a snapshot, not a guarantee. Root RCE on cPanel is high-value, the panel runs on a huge slice of the shared-hosting market, and a bug this clean tends to attract attention fast once details circulate. The absence of detection guidance in the advisories also cuts the other way: cPanel doesn’t provide a way to check whether a given server was hit before it was updated, so “we saw nothing” is not the same as “nothing happened.” If you’re patching a box that sat exposed, err toward a post-update integrity review rather than assuming you’re clean. That’s exactly the kind of check our hacked website repair team does after a patch like this: confirm nothing was already planted before you close the door.

The bigger pattern

This isn’t an isolated slip. The same researcher has been credited with at least seven cPanel and Plesk flaws since late August, several of them privilege-escalation issues that end in root or full server takeover, including a WP Toolkit-adjacent EmailTrack RCE earlier in September and two Plesk Backup Manager bugs. Both products come from the same vendor, WebPros, and share components; cPanel hasn’t said whether the Plesk build of WP Toolkit carries the -87900 flaw, which is a question Plesk operators should be asking their vendor directly.

The takeaway for anyone managing hosting infrastructure: the control panel is your attack surface, not just the sites on top of it. Patch cadence on cPanel/WHM and its add-ons deserves the same discipline you’d give a public-facing application, because on a shared server one unpatched escalation bug hands over everyone at once. If you’re evaluating hosting providers precisely because of stories like this one, that discipline is the whole reason we run secure web hosting the way we do, and if you manage your own servers and want an outside check on how they’d actually hold up, that’s what our penetration testing service and server management team are for.

We monitor and clean WordPress sites at scale, and this is a textbook example of the pattern we see over and over: a core disclosure, a public advisory that hands attackers the recipe, and automated mass-probing before most admins have finished their morning coffee. AgentOffense flagged exactly this compressed timeline as an industry-wide trend in their research on disclosure-to-breach reaction windows, and CVE-2026-87902 is that trend playing out in real time, down to the hour. Here is what the flaw actually does, the classic trick that turns it into code execution, and exactly what to check.

The vulnerability: a file-inclusion bug in template resolution

The flaw lives in how WordPress resolves page templates. Per the WordPress advisory, an unauthenticated attacker can make get_page_template() include a chosen, readable local .php file from outside the active theme directories. In plain terms: a function meant to load a theme’s own template files can be steered into loading an arbitrary PHP file already sitting on the server. That is a local file inclusion (LFI) at the core level, reachable with no login.

What makes CVE-2026-87902 less catastrophic than the CVSS number alone suggests is that it needs two preconditions to line up. Both have to be true:

• Theme condition: the active child or parent theme must contain a top-level directory whose name starts with page-, for example page-templates. This is common but not universal, which is what gates the bug.
• Server condition: a chosen local .php file must exist on the server and be readable by the web server account. The attacker’s file of choice is almost always pearcmd.php.

An LFI that can only include files already on the server is limited on its own. You cannot upload your own code through it directly. The escalation comes entirely from what you point it at, and that is where pearcmd.php enters.

The pearcmd.php trick: turning file inclusion into code execution

This is the part the news coverage glosses over, and it is the whole game. pearcmd.php is a command-line helper that ships with PEAR, the old PHP package manager, and it lives at a predictable path on many servers: /usr/local/lib/php/pearcmd.php. On a lot of PHP installations it is present by default and readable by the web server, which is exactly the “chosen local .php target” the second precondition calls for.

The reason attackers love pearcmd.php is a long-standing quirk. When a PHP file is included via a web request and the PHP setting register_argc_argv is enabled, the query string gets parsed into argv, as if it were command-line arguments. pearcmd.php reads those arguments and acts on them, including a config-write operation that lets an attacker write attacker-controlled content to an attacker-chosen path. So the chain is: use the WordPress LFI to include pearcmd.php, feed it a query string that behaves like PEAR command-line flags, and have it write a PHP file of your choosing to a writable directory like /tmp or /var/tmp. That written file is a web shell. LFI plus pearcmd.php equals arbitrary file write equals RCE. This is the same gadget that has been abused against countless other LFI bugs for years, which is precisely why exploitation showed up within hours: the second half of the chain was already sitting in every attacker’s toolkit.

The observed attacks match this exactly. Requests include /usr/local/lib/php/pearcmd.php, write a file to /tmp/, and in one variant pull a PHP upload script hosted on GitHub (raw.githubusercontent[.]com/MrG3P5/web-shell/refs/heads/main/uploader.php) to get a full file-upload capability onto the box.

Active exploitation: who and how much

This is not theoretical or slow-moving. Multiple security firms are seeing it live:

• Previdian recorded 68 exploitation attempts against its honeypot network starting September 23, with malicious requests coming from an IP in New Jersey (104.194.9[.]227) and others from an Indonesia-based address.
• Patchstack corroborated the escalation, noting the traffic moved from harmless reconnaissance against core files to active exploitation that includes pearcmd.php and writes PHP files to disk.

Previdian’s founder Ryan Dewhurst made a point worth repeating, because it is the silver lining: because WordPress has auto-updates enabled by default, the likely outcome is lots of mass-exploitation attempts but relatively few actual compromises. The sites that get hit are the ones that disabled auto-updates, run outdated versions, or have the specific theme structure the bug requires. That is the population to worry about.

Fix now: the patched versions

WordPress released fixes across every supported branch. Update to at least the patched build on your line:

• 7.1.2 (current branch)
• 7.0.6
• 6.9.9
• 6.8.10

If auto-updates are on and were not disabled, you are most likely already patched, but verify your version rather than assume. If you manage sites for others, check every one of them, because the single site running a pinned old version is exactly the one that gets shelled.

How to check whether you were hit

Patching stops future attempts. It does not remove a web shell an attacker dropped before you updated. Given how fast exploitation started, any site that was on a vulnerable version during September 22 to 24 deserves a look. Hunt for these specific artifacts:

Suspicious PHP files

Check /tmp, /var/tmp, and your web root for attacker-written PHP. Observed file names from the campaign include:

• wp-pear-rce-flag.php
• poc87902.php
• luci_<random>.php
• zeta_<random>.php

Any unexplained .php file in a temp directory is a strong signal, since legitimate applications rarely drop executable PHP into /tmp.

Attacker IP addresses

Grep your access logs for these source IPs tied to the malicious activity:

• 104.194.9[.]227 (New Jersey, US)
• 43.250.53[.]42
• 180.251.159[.]243
• 195.178.110[.]247
• 107.189.14[.]87
• 45.61.184[.]170
• 92.246.130[.]76

Request patterns in logs

Look for requests referencing pearcmd.php, requests containing /usr/local/lib/php/, or any request to the site that carries PEAR-style arguments in the query string against a page-template path. Outbound fetches to raw.githubusercontent[.]com/MrG3P5/ are also an indicator of the upload-script stage.

If you find any of this, treat the site as compromised: take it offline or isolate it, preserve logs, remove the dropped files, hunt for persistence (unexpected admin users, modified core files, cron entries, injected code in wp-config.php or theme files), rotate all credentials and salts, and rebuild from a known-clean backup taken before the compromise window if you have one. If you’d rather not run that process solo under time pressure, that exact triage is what our emergency malware removal team handles.

Hardening beyond the patch

Two server-level changes blunt this entire class of attack, not just this CVE:

• Disable register_argc_argv for your PHP web SAPI unless you have a specific reason to keep it. With it off, the pearcmd.php trick loses the mechanism it depends on to parse the query string into arguments.
• Remove or restrict pearcmd.php if PEAR is not in use. If /usr/local/lib/php/pearcmd.php is not needed, deleting it or making it unreadable to the web server account removes the gadget the second precondition relies on.

Neither replaces patching, but both are cheap defense-in-depth that would have neutralized the RCE half of this chain regardless of the WordPress bug.

The takeaway

CVE-2026-87902 is a clean illustration of how modern WordPress attacks unfold: a core file-inclusion bug, harmless-looking on its own, gets welded to a decade-old PHP gadget that every attacker already carries, and the result is unauthenticated RCE being sprayed at the internet within hours of the patch. Default auto-updates will save most sites. The ones that lose are the unpatched, the pinned, and the unmonitored. Update to 7.1.2, 7.0.6, 6.9.9, or 6.8.10 now, check your temp directories and logs against the indicators above, and if PEAR is dead weight on your server, take pearcmd.php off the board for good. If you want an outside check that your WordPress installs are actually clean and hardened rather than just patched, that is what our penetration testing and website security assessment services are for.

What the group says happened

According to ShinyHunters, they found a zero-day in Oracle PeopleSoft, the system the FBI uses to run HR administration and process job applications, and used it to reach servers sitting in AWS GovCloud, the cloud environment US government agencies use specifically because it carries tighter controls for sensitive data. From there, the claim is straightforward: they pulled everything, somewhere between 2 and 3 terabytes of files covering current employees, former employees, and special agent applicants.

The data types listed are names, home addresses, phone numbers, spouse information, and dates of birth. That’s not the combination you need for financial fraud. It’s the combination you need to find someone’s house and know who lives there with them.

What journalists could actually verify

The group sent a 5,000-record sample to reporters. Some of the phone numbers in it were run through OSINT Industries, an open-source intelligence tool, and they matched the names attached to them, so the sample didn’t look randomly generated. Separately, a tool called Darkside tied a portion of those numbers to personnel at the US Department of Justice, the parent agency the FBI sits under. None of that confirms the full 2-to-3-terabyte claim. It does mean at least part of the sample is real data belonging to real people, not a fabricated attention grab.

“This is not financially motivated”

One quote from the group is worth pulling out on its own, because it breaks from the usual script: a representative said the attack “is not financially motivated,” and that whatever comes next “is not something I’d call extortion, maybe coercion.” ShinyHunters’ normal pattern is the standard one, break in, then threaten to publish unless paid. Walking away from that framing upfront leaves a much worse read available: contact information, home addresses, and family details for FBI personnel aren’t obviously useful for a payday. They’re useful for finding someone.

Our take

Two separate questions are getting collapsed into one headline here, and they shouldn’t be: did someone breach the FBI, and did real data on real people leak. Based on what’s public, the second looks more likely than the first is confirmed. ShinyHunters didn’t necessarily punch through the bureau’s core defenses in the classic sense, they may have reached a supporting HR system that could sit in a contractor’s cloud environment and be logically distant from the FBI’s operational infrastructure. For the person whose phone number just leaked, that distinction means nothing. For sizing up the actual incident, it means a lot.

The vector itself is the part every business, not just a federal agency, should sit with: a vulnerability in Oracle PeopleSoft, an old but still widely deployed HR and ERP product. Systems like this rarely get the same security attention as a public-facing website or a customer login page, and what they hold is precisely the personal and employment data that makes an attack like this worth running in the first place. The more “background” a system is treated as, the less scrutiny it gets, and the more attractive it quietly becomes.

What to actually do about it

• If your organization runs an HR system, an applicant portal, or any similar “internal” web application, don’t assume it’s out of scope just because customers never see it. These systems fall out of the regular security review cycle constantly, precisely because they’re treated as background infrastructure.
• Get a real penetration test that covers your HR, employee, and applicant-facing systems specifically, not just the public website customers interact with every day.
• If the system in question is a customer- or employee-facing web application built on any modern framework, web application penetration testing that goes past the login page is what actually finds this class of issue before someone else does.
• For the wider infrastructure and network perimeter around any system holding employee personal data, website penetration testing services cover exactly the kind of exposure that turns a background system into a headline.
• If you already suspect something similar may have happened to your organization, don’t wait for confirmation before acting. Get it checked, understand the real scope first, and decide what to communicate second.

How a comment turns into a shell

The bug doesn’t live in the comment form’s input filtering, it lives one step later, in how WordPress reformats a comment for display. An attacker submits a comment containing a line break placed inside an HTML tag attribute, something the initial sanitization pass doesn’t catch because at submission time the payload still looks harmless. The problem shows up when WordPress reformats that comment for the page: the line break splits the tag structure apart and effectively repositions the attacker’s text into what the browser now reads as an event handler.

The result is a script that fires automatically the moment the page loads, running with whatever access level belongs to the person viewing it. For a regular visitor, that’s nothing interesting. For a logged-in site administrator who happens to open the page the comment lives on, most commonly a moderation screen or the post itself, the script executes in their authenticated session. From there it can install a plugin carrying a web shell, and a web shell on a WordPress site means arbitrary command execution on the server underneath it.

Why “just enable comment moderation” doesn’t save you here

The instinctive fix most site owners reach for is comment moderation: hold every comment for approval before it goes live. It helps, but researchers are explicit that moderation is not a security control in this case, and the reasoning is straightforward. WordPress ships with moderation off by default, so a large share of sites never turn it on in the first place. And even where it is enabled, the payload only needs to render once in front of a logged-in administrator, and the moderation queue itself is a page an administrator looks at, logged in, specifically to review pending comments. The exact workflow meant to catch spam is also the exact workflow that puts the payload in front of the one account that matters.

The flaw isn’t specific to one theme or plugin either. Researchers found it triggers on both block themes and classic themes that use comparable comment-formatting logic, which is most of them, since that formatting logic lives in WordPress core rather than in individual themes.

What’s patched and what isn’t

WordPress fixed the issue across every actively maintained branch on September 17, 2026: version 7.1.1 for the current release line, plus backported fixes at 7.0.5, 6.9.8, and 4.7.36 covering older branches still receiving security updates. Researcher Rafie Muhammad is credited with the discovery. As of publication there’s no evidence of active exploitation in the wild, and it isn’t on any government actively-exploited-vulnerabilities list, which is the good news. The less good news is that a CVSS 7.1 unauthenticated bug affecting core versions going back to 4.7 is now public knowledge, and every unpatched WordPress install on the internet is a matching target.

Our take

This is the third time in recent memory that a formatting or sanitization edge case in WordPress core, not a plugin, has turned into a real path to remote code execution, and it follows a pattern we keep seeing across the ecosystem: the actual danger in WordPress security rarely sits in the obvious places. Nobody audits the comment reformatting pipeline expecting to find an RCE chain there, because on paper it’s just text display logic. That’s exactly why it’s worth auditing. The plugins ecosystem gets the bulk of security attention because plugins get exploited constantly and at scale, and rightly so, but core itself is not immune, and a bug at this layer touches every single WordPress site regardless of which plugins it runs or which theme it uses.

The other thing worth sitting with is how little privilege the attack actually requires to start. No account, no login, just a comment field working exactly the way it’s supposed to. The distance between “anonymous visitor” and “administrator session” here is one page load by the wrong person, and that’s a distance most site owners assume doesn’t exist.

This isn’t the first core-adjacent shell we’ve covered

WordPress’s scale means a single core-level bug reaches an enormous number of sites at once, and we’ve tracked this pattern before. Earlier this year we broke down how a W3 Total Cache flaw exposed more than a million WordPress sites to unauthenticated remote code execution, and separately how a vulnerability in the Elementor plugin enabled complete site takeover. Different components, same underlying lesson: on WordPress, the path from a low-privilege input field to full server control is usually shorter than site owners assume.

What to do right now

• Update to WordPress 7.1.1, or the matching patched release for your branch (7.0.5, 6.9.8, 4.7.36), immediately. This is not a “schedule it for next maintenance window” patch given the CVSS score and the lack of authentication required.
• Don’t treat comment moderation as your security boundary here. It reduces exposure, it doesn’t close it, since the moderation screen itself is exactly where an administrator views pending, unpatched comments while logged in.
• If your site runs an older, unsupported WordPress branch that didn’t get a backported fix, that’s now a genuinely urgent upgrade, not a someday item.
• Get a real WordPress security review rather than relying on the plugin list alone, since this bug lived in core the whole time, untouched by any plugin decision you made.
• Pair patching with two-factor authentication on admin accounts, so that even if a session gets hijacked through a flaw like this one, a stolen cookie alone isn’t enough to act as that administrator going forward.
• A web application firewall in front of WordPress catches a meaningful share of exploitation attempts against bugs like this before they ever reach the comment-rendering code, which matters most in the window between disclosure and when every site actually gets patched.
• If you suspect a site was already hit before you patched, don’t just update and move on. Get a proper hacked website cleanup to confirm no plugin or shell was already dropped through an admin session.
• If you want to know what an attacker could actually reach on your specific WordPress setup, not just in theory, a scoped penetration test will tell you before someone less friendly does.