Writing · November 2026

The plugin was already closed.

A WordPress crypto-payment plugin was pulled from the directory in August. It has no known fix, a maximum severity score, and attackers are now reported probing it. The detail that matters is where it kept the wallet credentials.

On November 3, The Hacker News reported that attackers are trying to exploit a flaw in CryptoPayment Gateway, a WordPress plugin for taking crypto payments. The finding came from Defused Cyber, which posted it on X. I'm going to stick to what I could read myself and mark where the record is thin.

What the sources agree on

The flaw is tracked as CVE-2026-81648 and scored 10.0, the maximum, per OpenCVE. The record says the plugin "does not apply an authorization check on one of its AJAX endpoints." In plain terms, a stranger on the internet can ask the plugin to do administrator work without logging in.

OpenCVE and The Hacker News list the same three consequences: deleting arbitrary files on the server, overwriting the payment gateway configuration, and recovering stored wallet credentials in cleartext. Versions 1.2.1 through 1.2.2 are affected. 1.2.2 is the latest.

There is no known fix. WPScan lists the entry as "No known fix," and the plugin's WordPress.org page says it "has been closed as of August 28, 2026 and is not available for download," citing a security issue.

The timeline is the story

The plugin was closed August 28. WPScan lists its advisory as published September 10. The CVE record shows a publication date of September 13, per OpenCVE. The exploitation report came November 3. So the plugin was pulled, the flaw was written up, and the CVE was public for about seven weeks before anyone reported attackers using it.

The Hacker News says the attacks came from infrastructure that markets itself as "Anonymous KYC-Free VPS Hosting." It also reports the plugin had 1,845 total downloads, 20 of them in the last seven days. That last number is worth sitting with. I can't explain downloads that late, and I won't guess. I can't tell you how many sites run it today. WordPress.org shows no install count, and WPScan shows zero active installs. Neither is a census of copies that were installed before the closure.

What nobody has said

Whether any money has been taken. None of what I read reports a loss, an amount or a victim. Exploitation attempts are not thefts, and I won't write them as thefts.

Why the credentials were stored in recoverable form. The CVE says they can be recovered in cleartext. It doesn't say why they were kept that way, and I won't guess at intent.

The sources don't conflict on the facts above, but their dates differ: closure August 28, WPScan September 10, CVE September 13. I've kept each source's own date.

The part that isn't news

I wrote about BTCPay hot wallets earlier this week. This is the same lesson wearing a cheaper suit. A web server that can pay out must hold something that authorizes the payout. Any bug that lets a stranger read that something turns a website flaw into a wallet flaw.

I lost 9 BTC to security mistakes, and the lesson I teach from it is that the dangerous part is rarely the exploit. It's what was sitting within reach when the exploit landed.

A closed plugin is a bad sign for another reason. Nothing about "closed" removes the files from your server. The code stays where you installed it, listening, long after the people who maintain the directory have stopped vouching for it.

What I'd do

1. Check every plugin against its directory page. Open each plugin's page on WordPress.org. A banner reading "closed" means the maintainers pulled it. If it handles payments, treat it as an incident.

2. If you ever ran CryptoPayment Gateway, remove it. That is the advice in The Hacker News report. Then rotate the keys. Rotating means moving the funds to a new wallet whose seed was never on that server, not changing a setting. Whatever was stored there should be assumed readable.

3. Look for signs of tampering. The report also says to audit for suspicious changes. The bug allows file deletion and settings overwrites, so check the payment settings for addresses you don't recognise.

4. Don't keep spending keys on a web server. Use a setup where the site only sees receiving addresses, for example one built from an extended public key, and sweep funds to a device that never touches the site. A stolen login or a plugin bug then reveals addresses, not spending power.

5. Keep a float, not a treasury. If a key must live on a server, hold only what you could lose tonight.

The boring conclusion

Software dies and your server doesn't notice. The plugin was closed in August, and everything it put on a website's disk stayed there. The question to ask about any tool that touches money is simple: if this fails, what does the attacker walk away with, and how would I find out it was abandoned?

This one is still developing. If a patch or a confirmed loss turns up, I'll update it.

Verify everything, especially the plugin that holds your keys.

— Jon Tetreault, November 2026. The habits, tools, and checks behind this piece are what I teach in Crypto Security Mastery.