What happened

• CVE-2026-81648 (CVSS 10.0) is an unauthenticated authorization bypass in the CryptoPayment Gateway WordPress plugin, versions 1.2.1 through 1.2.2 [S1].
• It lets unauthenticated users invoke administrative AJAX operations, including arbitrary file deletion and recovery of stored wallet credentials in cleartext [S1].
• No fix is available [S1].
• Defused Cyber observed exploitation attempts from infrastructure marketed as 'Anonymous KYC-Free VPS Hosting'; the report states attempts, not confirmed compromises [S1].
• The plugin is reported as delisted and its installed base is unclear [S1].

Timeline

Detect

Plugin footprint and probing · Web server access logs

index=* uri_path="*/wp-content/plugins/*crypto*pay*" | stats count min(_time) as first max(_time) as last values(status) as status by host, src, uri_path | sort - count

FROM logs-* | WHERE url.path LIKE "*/wp-content/plugins/*crypto*pay*" | STATS count = COUNT(*), first = MIN(@timestamp), last = MAX(@timestamp), status = VALUES(http.response.status_code) BY host.name, source.ip, url.path | SORT count DESC

A hit means: Requests to the plugin's directory. A 200 response suggests the plugin is present on that site; many requests from one src suggest scanning. The plugin slug is not published in the sources, so confirm the actual directory name.

Unauthenticated admin-ajax calls to plugin actions · Web server access logs

index=* uri_path="*/wp-admin/admin-ajax.php" (uri_query="*crypto*" OR uri_query="*cpg*") | stats count values(http_method) as method values(status) as status values(uri_query) as query by host, src | sort - count

FROM logs-* | WHERE url.path LIKE "*/wp-admin/admin-ajax.php" AND (url.query LIKE "*crypto*" OR url.query LIKE "*cpg*") | STATS count = COUNT(*), method = VALUES(http.request.method), status = VALUES(http.response.status_code), query = VALUES(url.query) BY host.name, source.ip | SORT count DESC

A hit means: admin-ajax requests that may target the plugin's actions. The action names are not published, and POST bodies are often not logged. A hit from an unknown or VPS-hosted src that has no session is a candidate exploitation attempt.

Verify

• Confirm the plugin and its version (1.2.1–1.2.2) are installed on the targeted host [S1].
• Match the admin-ajax action name in the request to an administrative function of the plugin, once its code or a vendor advisory identifies them.
• Check whether the source IP had an authenticated WordPress session; legitimate admin use carries a logged-in cookie.
• Look for missing files or changed gateway settings that follow the request in time [S1].
• Benign look-alikes: administrators using the plugin settings, other plugins with 'crypto' in their action names, and vulnerability scanners.

Scope

Affected

• CryptoPayment Gateway WordPress plugin versions 1.2.1 through 1.2.2

Only if

• Plugin installed on the WordPress site

Not affected if

• Plugin not installed

Enumerate

• All WordPress sites, including marketing, campaign and third-party-hosted sites, and their installed plugins and versions
• Wallets and API credentials configured in the plugin
• Web access logs for admin-ajax and plugin-path requests since installation
• Files deleted or changed on affected hosts

Contain

• Preserve evidence first: snapshot the host, copy the plugin directory, the gateway configuration and the web logs.
• Deactivate and remove the plugin, because no fix exists [S1]. If removal is not possible at once, block unauthenticated requests to admin-ajax.php for the plugin at the WAF.
• Rotate the wallet credentials and API keys stored in the plugin, and move funds if those credentials could have been read [S1]. Exposure of the old credentials cannot be undone; on-chain transfers cannot be reversed.
• Consider blocking the source infrastructure seen in your logs. The sources publish no IoCs.

Eradicate

• Remove the vulnerable plugin; it is the root cause [S1].
• The sources describe no persistence mechanism. Review the host for web shells or new admin users as a precaution.

Recover

• Restore deleted files from known-good backups and confirm site integrity [S1].
• Re-enable payments only through a supported gateway, with new credentials.
• Monitor wallet activity and admin-ajax traffic for further attempts.

Re-enter the loop when

• A fix or vendor advisory is published, or the advisory changes the affected version range.
• Defused Cyber or others publish IoCs, action names or exploit details.
• Confirmed compromises or wallet thefts are reported.
• Exploitation is seen chained to code execution or persistence.

Debrief

• Record whether the plugin was present, on which sites, and since when.
• Record whether any attempt reached an affected site and what it did.
• Record why a delisted plugin was still deployed, if it was.
• Gaps: no primary advisory, no IoCs, no AJAX action names, no installed-base figures.

Detection coverage — checked automatically

Checked automatically 2026-11-10 15:11Z from public sources: 6 published, 21 nothing found, 0 not machine-checkable, 0 failed. "Nothing found" means the public source answered and had nothing, as of that moment; a feed covers only its newest posts. Re-checked daily.

Exposure queries — generated automatically

Where each CVE comes from: CVE-2026-81648 — Attackers attempt to exploit unpatched CryptoPayment Gateway WordPress plugin flaw CVE-2026-81648 (no confirmed compromi. A product row answers "is the software from that story reachable from the internet", not "is this card about that software".

vuln:CVE-2026-81648

http.html:"cryptopayment-gateway"

Internet-wide count, trend

Shodan's count of matching services on the whole internet, one point a day; the scope (your ranges) is never part of it. A count moves with Shodan's crawl as much as with patching, so read the direction, not the digit.

NVD has not published CPE configurations for these CVEs yet, so only the CVE query is exact; the product queries use the name the campaign gives (CryptoPayment Gateway) and are replaced by NVD's spelling at the daily re-check once it names the software.

Also tried under the name the card uses, nothing matched on Shodan: product:"CryptoPayment Gateway", http.component:"CryptoPayment Gateway", host.services: (software.product = "CryptoPayment Gateway").

Banner spellings: a model read 1 from the NVD names and this card's text (former and marketing names, console titles); 1 matched something on Shodan and is shown above, the rest were dropped.

Scope every query in your own tool, never in a shared document: Shodan `net:<your_ranges>`, `org:"<your_org>"` or `hostname:<your_domain>` (or a Shodan Monitor network alert, which applies the scope for you); Censys `host.ip: <your_ranges>` or `host.dns.names: <your_domain>`. Then compare the banner version with the affected range. Generated automatically 2026-11-10 15:11Z from the CVE ids and NVD's CPE configurations, each Shodan query counted against Shodan itself; re-built daily with the coverage check.

Open questions

• What are the plugin's slug and its vulnerable AJAX action names?
• Is there a primary Defused Cyber or vendor advisory, and an NVD entry?
• Are versions before 1.2.1 affected?
• How large is the installed base, given the plugin is reported delisted?
• Have any attempts succeeded?

Sources

• [S1] https://thehackernews.com/2026/11/attackers-target-unpatched.html · The Hacker News

Public OSINT only. AI-generated by the pipeline; structure follows the DAIR model from Dynamic Incident Response (Joshua Wright). Published automatically; a dismissed draft unpublishes it.