MalCare 6.65: a guessable connection key gave admin on 200,000 sites

What the release fixes

Version 6.65 replaces the way three plugins generate the secret that binds a WordPress site to their vendor’s remote management service. BlogVault Backup and Staging, MalCare and WP Remote share that connection code, so all three ship the same fix at the same version number.

Before 6.65, the connection key came out of a weak pseudo-random number generator. Values from that class of generator are reproducible: given enough observed output, or the seed, the next value stops being a secret. The same code path also handed out data derived from the key to callers who had not authenticated. Put those two facts together and an attacker on the open internet could reconstruct the key.

The key is what proves to the vendor’s console that a request comes from the site’s owner. Holding it means administrator access to the site through the console. That is why an eight-point-one on a plugin most people install in order to be safer is worth reading about at all.

6.65 rebuilds the secret with random_int, the cryptographically secure generator PHP has shipped since 7.0, and reworks key generation around it. The same release also adds file-editing hardening controls, which its changelog mentions and which are unrelated to this bug.

How the bug works

Two weaknesses have to line up, and in this code they did.

The first is the generator. A key built from a predictable source has less real entropy than its length suggests. It looks like a long random string and it is not one. Nothing in the site’s own behaviour reveals this, which is what makes the class of bug survive so long in production code.

The second is the disclosure. An unauthenticated request could obtain values derived from the key. On its own that is an information leak of the kind that usually scores low and gets fixed quietly. Against a weak generator it is the other half of the attack: the leaked material narrows the search space that the generator already made small.

From there the path is short. Recover the key, present it to the vendor’s remote management service as the site’s own agent, and act with the authority the service grants that agent. The service is designed to let an owner manage the site remotely, so administrator-level actions on the site follow from holding the key, without ever needing a WordPress password.

Segurium Research reports what the released code changed. We did not touch a live site running the affected version, and this teardown carries no working exploit.

Who is exposed

Any site running BlogVault Backup and Staging, MalCare or WP Remote below 6.65. The malcare-security slug alone reports around 200,000 active installs on wordpress.org, and the other two carry their own install bases on top of that.

The exposure does not depend on a setting. A site that connected to the vendor console at any point holds a key that was generated by the old code, and updating the plugin does not by itself replace a key that already exists. That distinction matters more than usual here: for most vulnerabilities the update ends the story, and for this one the update stops new keys being weak while the old key stays exactly as guessable as it was.

Sites that installed the plugin and never connected it to the service have nothing to rotate.

What to do

Update to 6.65 or later. The malcare-security slug is on 6.69 in the directory as of 25 August 2026, so nobody has to install the fix release specifically.

Then rotate the key, which the update does not do for you. Disconnect the site from the vendor’s dashboard and reconnect it. That mints a new key with the new generator and retires the one an attacker could have derived.

Finally, read your administrator list. This bug ends in administrator access, and the cheapest evidence that somebody used it is an account you do not recognise, or a familiar account whose email address has changed. Check the dates on your existing administrators against when you actually created them.

If you find an account you cannot account for, treat the site as compromised rather than as needing one deletion. An attacker with administrator access has had the opportunity to write files, and the account is the part they expect you to find.