CVE-2026-18467: Critical Paytium WordPress Plugin Privilege Escalation — Detection and Remediation Guide

A CVSS 9.8, network-exploitable privilege escalation vulnerability has been published in the Paytium: Mollie payment forms & donations plugin for WordPress. If you operate a WordPress site that accepts payments or donations through Mollie using this plugin, treat this as an emergency patch event: all versions up to and including 5.0.3 are vulnerable, and the flaw is exploitable by an unauthenticated remote attacker with no user interaction.

What makes this vulnerability particularly instructive — and dangerous — is that it is a patch bypass. The vendor already attempted to fix the unauthorized privilege-gain pathway in 5.0.3 by adding a wp_hash()/hash_equals() signature gate on the pt-paytium-user-data field. That fix was incomplete. A second code path, the pt_cf_checkout_meta() filter registered on the pt_meta_values hook, continues to copy attacker-controlled POST data verbatim into the payment meta array — including a pt-user-role value that overwrites the output of the now-signed code path. In plain terms: the front door was locked, but the side window was left wide open, and both lead to the same room.

WordPress plugin privilege escalations of this class are reliably weaponized within days of disclosure. Attackers use them to create administrator accounts, which then become the beachhead for webshell deployment, SEO spam injection, payment skimmer installation (especially damaging on a payments plugin), and full site compromise. Defenders need to patch, hunt for prior exploitation, and audit user accounts now.

Technical Analysis

Affected Products and Versions

How the Vulnerability Works — Defender's View

The exploit chain is a textbook incomplete-fix / dual-path authorization bypass:

1. The intended (signed) path. The plugin builds a pt-paytium-user-data payload that can influence user attributes. In version 5.0.3, the vendor gated this path with a wp_hash()-generated signature validated via hash_equals() — a correct constant-time comparison pattern that prevents an attacker from forging the payload.

2. The forgotten filter. After the signed builder runs, the plugin applies the pt_meta_values hook, on which pt_cf_checkout_meta() is registered. This filter iterates over every key in $_POST['pt_form_field'][*] and copies the values verbatim into the payment meta array — with no signature verification.

3. The overwrite. Because this filter executes after the signed builder, an attacker who submits a crafted pt_form_field[pt-user-role] value in the POST body causes that unsanitized value to overwrite the signed path's output. The result: the attacker-controlled role assignment wins, yielding unauthorized privilege gain — up to administrator-level access depending on the role value accepted downstream.

Key exploitation characteristics:

• No authentication required. The vulnerable code path is reachable through the plugin's public-facing payment form submission flow.
• No special conditions. Standard plugin configuration with published payment/donation forms exposes the pt_meta_values filter chain.
• Observable indicator. The exploit request must carry pt_form_field[pt-user-role] (or an equivalent pt-user-role key) in the POST body — a highly distinctive, low-noise hunting indicator.

Exploitation Status

At the time of writing, CVE-2026-18467 has been published to NVD with a CVSS 9.8 rating. The vulnerability pathway is network-exploitable and unauthenticated, which historically correlates with rapid PoC development and mass scanning against WordPress plugin CVEs. Defenders should operate under the assumption of imminent or active in-the-wild exploitation until proven otherwise, and should check the CISA Known Exploited Vulnerabilities catalog for updates. Even absent confirmed exploitation, the preconditions for automated mass exploitation — a popular CMS, a trivially scriptable POST body, and an admin-account payoff — are all present.

Detection & Response

The single most reliable detection indicator is the presence of pt-user-role (particularly nested under pt_form_field) in HTTP requests targeting WordPress endpoints that process Paytium form submissions (typically /wp-admin/admin-ajax.php or REST/form POST handlers). Legitimate Paytium checkouts should never submit a role assignment from the client — this field appearing in a request is inherently suspicious.

Sigma Rules

---
title: Paytium CVE-2026-18467 Exploitation Attempt — pt-user-role in POST Body
id: 3f8c1a92-7d4e-4b5a-9c61-2e8f4a6b0d17
status: experimental
description: Detects HTTP requests containing the pt-user-role or pt_form_field parameters indicative of CVE-2026-18467 privilege escalation attempts against the Paytium WordPress plugin. Best deployed against WAF, reverse proxy, or ModSecurity audit logs that capture request bodies.
references:
  - https://nvd.nist.gov/vuln/detail/CVE-2026-18467
author: Security Arsenal
date: 2026/04/06
tags:
  - attack.privilege_escalation
  - attack.t1068
  - attack.initial_access
  - attack.t1190
logsource:
  category: webserver
detection:
  selection_params:
    cs-uri-query|contains:
      - 'pt-user-role'
      - 'pt_form_field'
      - 'pt-paytium-user-data'
  selection_body:
    request_body|contains:
      - 'pt-user-role'
      - 'pt_form_field%5Bpt-user-role'
      - 'pt_form_field[pt-user-role]'
  condition: 1 of selection_*
falsepositives:
  - Extremely rare; legitimate Paytium checkouts do not submit pt-user-role from the client
level: critical
---
title: Paytium Form Endpoint POST Flood — Potential Mass Exploitation Scanning
id: 91b4e7d3-2c6a-4f18-b5d9-8a3c7e1f5b42
status: experimental
description: Detects elevated volumes of POST requests to WordPress admin-ajax.php or Paytium-related endpoints from single sources, consistent with automated exploitation scanning for CVE-2026-18467.
references:
  - https://nvd.nist.gov/vuln/detail/CVE-2026-18467
author: Security Arsenal
date: 2026/04/06
tags:
  - attack.initial_access
  - attack.t1190
  - attack.reconnaissance
  - attack.t1595
logsource:
  category: webserver
detection:
  selection:
    cs-method: 'POST'
    cs-uri-stem|contains:
      - '/wp-admin/admin-ajax.php'
      - 'paytium'
  condition: selection
falsepositives:
  - Legitimate Paytium payment form submissions — baseline normal volume per source before tuning
level: medium
---
title: Suspicious WordPress Administrator Account Creation Following Web Exploitation
id: c47d2f81-5e9b-4a36-8d14-6f2a9c3b7e58
status: experimental
description: Detects execution of WP-CLI or direct user-creation commands from web server process context, a common post-exploitation action after WordPress privilege escalation such as CVE-2026-18467.
references:
  - https://nvd.nist.gov/vuln/detail/CVE-2026-18467
author: Security Arsenal
date: 2026/04/06
tags:
  - attack.persistence
  - attack.t1136
  - attack.t1136.001
logsource:
  category: process_creation
  product: linux
detection:
  selection_parent:
    ParentImage|endswith:
      - '/php-fpm'
      - '/php'
      - '/apache2'
      - '/httpd'
      - '/nginx'
  selection_cmd:
    CommandLine|contains:
      - 'wp user create'
      - 'wp user update'
      - 'set-role'
      - 'administrator'
  condition: all of selection_*
falsepositives:
  - Legitimate WP-CLI administration from interactive shells (parent will typically be bash/sshd, not php-fpm)
level: high

KQL — Microsoft Sentinel / Defender

This query hunts web request logs (ingested via WAF, IIS, Apache/Nginx via CEF/Syslog, or Azure Front Door/Application Gateway) for the distinctive Paytium exploitation parameters, and separately surfaces anomalous POST volume against the plugin's form-handling endpoints.

// Hunt 1: Requests carrying CVE-2026-18467 exploitation parameters
let suspiciousParams = dynamic(["pt-user-role", "pt_form_field", "pt-paytium-user-data"]);
union isfuzzy=true
    (CommonSecurityLog
     | where RequestURL has_any (suspiciousParams)
        or RequestURL has "paytium"
     | project TimeGenerated, SourceIP, DestinationHostName, RequestURL, RequestMethod, DeviceVendor, DeviceProduct),
    (Syslog
     | where SyslogMessage has_any (suspiciousParams)
        and SyslogMessage has "POST"
     | project TimeGenerated, HostIP, Computer, SyslogMessage)
| extend ExploitIndicator = iff(RequestURL has "pt-user-role" or SyslogMessage has "pt-user-role", "pt-user-role present (HIGH CONFIDENCE)", "Paytium parameter present (INVESTIGATE)")
| sort by TimeGenerated desc;

// Hunt 2: Abnormal POST volume to Paytium/WordPress AJAX endpoints per source IP (1-hour bins)
CommonSecurityLog
| where RequestMethod =~ "POST"
| where RequestURL has "/wp-admin/admin-ajax.php" or RequestURL has "paytium"
| summarize PostCount = count(), DistinctURIs = dcount(RequestURL) by SourceIP, bin(TimeGenerated, 1h)
| where PostCount > 50
| sort by PostCount desc;

// Hunt 3: Correlate web exploitation window with local account creation on web hosts
let exploitWindow =
    CommonSecurityLog
    | where RequestURL has "pt-user-role"
    | summarize FirstSeen = min(TimeGenerated), LastSeen = max(TimeGenerated) by DestinationHostName;
exploitWindow
| join kind=inner (
    SecurityEvent
    | where EventID == 4720  // user account created (Windows-hosted WP)
    | project AccountCreatedTime = TimeGenerated, TargetUserName, Computer, SubjectUserName
) on $left.DestinationHostName == $right.Computer
| where AccountCreatedTime between (FirstSeen .. datetime_add("minute", 30, LastSeen))
| project DestinationHostName, TargetUserName, AccountCreatedTime, SubjectUserName, FirstSeen, LastSeen;

Velociraptor VQL

Use this artifact to sweep web server access logs across your WordPress fleet for exploitation indicators. Note that standard access logs do not capture POST bodies — if your exploitation indicator (pt-user-role) appears in query strings (common in some exploit variants or error logs) or if you log request bodies via ModSecurity, this will surface it. Pair this with a user-table audit for post-exploitation persistence.

-- CVE-2026-18467: Hunt web server logs for Paytium privilege escalation attempts
-- Scopes common Apache/Nginx access log locations; extend glob for your layout.
LET log_files = SELECT FullPath
FROM glob(globs=['/var/log/apache2/access*.log*', '/var/log/nginx/access*.log*', '/var/log/httpd/access_log*', '/var/log/nginx/*access*.log'])
WHERE FullPath !~ '\\.gz$';

SELECT FullPath,
       Line,
       split(string=Line, sep=' ')[0] AS SourceIP,
       timestamp(string=split(string=Line, sep='[')[1][:20]) AS RequestTime
FROM foreach(row=log_files,
             query={
               SELECT FullPath, Line
               FROM parse_lines(filename=FullPath)
               WHERE Line =~ 'pt-user-role|pt_form_field|pt-paytium-user-data'
                  OR (Line =~ 'POST' AND Line =~ 'paytium')
             })
ORDER BY RequestTime DESC;

-- Post-exploitation check: recent files written to WordPress directories by the web user
-- Webshells and modified plugin files often follow privilege escalation.
SELECT FullPath,
       Mtime,
       Size,
       Mode AS Permissions
FROM glob(globs=['/var/www/*/wp-content/uploads/**/*.php', '/var/www/*/wp-content/plugins/paytium*/**', '/var/www/html/wp-content/uploads/**/*.php'])
WHERE Mtime > now() - 604800   -- last 7 days, in seconds
ORDER BY Mtime DESC;

Remediation & Verification Script

Run the following on each WordPress host (adjust WP_PATH and the web user as appropriate). It verifies the installed Paytium version, updates the plugin, audits for rogue administrator accounts created recently, and greps logs for exploitation indicators.

#!/usr/bin/env bash
# CVE-2026-18467 — Paytium plugin verification, patch, and exploitation sweep
set -euo pipefail

WP_PATH="/var/www/html"          # adjust to your WordPress root
WP_USER="www-data"               # adjust to your web server user
LOG_DIRS="/var/log/apache2 /var/log/nginx /var/log/httpd"

echo "=== [1] Installed Paytium version ==="
sudo -u "$WP_USER" wp --path="$WP_PATH" plugin list \
  --fields=name,status,version | grep -i paytium || echo "Paytium not installed at $WP_PATH"

echo "=== [2] Updating Paytium to latest release (must be > 5.0.3) ==="
sudo -u "$WP_USER" wp --path="$WP_PATH" plugin update --all --exclude=none paytium 2>/dev/null \
  || sudo -u "$WP_USER" wp --path="$WP_PATH" plugin update paytium
sudo -u "$WP_USER" wp --path="$WP_PATH" plugin list --fields=name,status,version | grep -i paytium

echo "=== [3] Audit: administrator accounts created in the last 14 days ==="
sudo -u "$WP_USER" wp --path="$WP_PATH" user list --role=administrator \
  --fields=ID,user_login,user_email,user_registered --format=table

echo "=== [4] Audit: any user with unexpected capabilities (recent registrations) ==="
sudo -u "$WP_USER" wp --path="$WP_PATH" user list \
  --fields=ID,user_login,user_email,user_registered,roles --format=table

echo "=== [5] Log sweep: exploitation indicators (pt-user-role / pt_form_field) ==="
for d in $LOG_DIRS; do
  [ -d "$d" ] || continue
  echo "--- $d ---"
  zgrep -hE 'pt-user-role|pt_form_field|pt-paytium-user-data' "$d"/access*log* 2>/dev/null \
    | awk '{print $1, $4, $6, $7}' | sort | uniq -c | sort -rn | head -25 \
    || echo "No indicators found in $d"
done

echo "=== [6] Webshell sweep: PHP files modified in uploads in the last 7 days ==="
find "$WP_PATH/wp-content/uploads" -name '*.php' -mtime -7 -ls 2>/dev/null || true

echo "=== Done. Review section 3 for unknown admins and section 5 for exploit hits. ==="

If step 3 reveals administrator accounts you do not recognize, assume full compromise: take the site offline or into maintenance mode, force-reset all admin credentials and WordPress salts/keys (wp-config.php — attackers with DB access often harvest these), rotate Mollie API keys, and begin a forensic review before restoring service.

Remediation

Immediate (within 24 hours):

1. Update the Paytium plugin to the latest available release — any version above 5.0.3. All versions up to and including 5.0.3 are vulnerable, including 5.0.3 itself, because its signature gate does not cover the pt_cf_checkout_meta() filter path. Verify the update actually applied: WordPress auto-updates for plugins are frequently disabled in production, and a queued update is not a patched site.
2. Audit all user accounts, with priority on administrator and editor roles. Look for accounts created around or after the disclosure window, accounts with unfamiliar email domains, and role changes on existing low-privilege accounts.
3. Review web server and WAF logs for pt-user-role, pt_form_field, and pt-paytium-user-data in requests. Positive hits on pt-user-role specifically should be treated as confirmed exploitation attempts and trigger your IR process.

Short-term (within 7 days):

4. If you cannot patch immediately, disable and deactivate the Paytium plugin entirely — there is no configuration workaround that neutralizes the unsanitized $_POST['pt_form_field'] copy while the vulnerable code is loaded. Payment forms will be unavailable; that is an acceptable trade against unauthenticated privilege escalation. As a compensating control, a WAF rule blocking any request whose body or query string contains pt-user-role can provide temporary coverage, but understand its limits: WAF rules are bypassable, and this must not substitute for patching.
5. Rotate Mollie API keys and WordPress secrets on any host where exploitation indicators or unexplained accounts are found.
6. Scan for webshells in wp-content/uploads and plugin directories; privilege escalation to admin is almost always followed by file-upload persistence via the theme/plugin editor or media upload.

Strategic:

7. Enforce WordPress plugin inventory and auto-update policy. This vulnerability is a patch bypass — meaning organizations that patched promptly to 5.0.3 were still vulnerable. Track your plugin fleet centrally (WP-CLI reporting into your asset inventory, or an MDM/WordPress management platform) and alert on any plugin more than 7 days behind latest.
8. Deploy a WAF or virtual patching layer (ModSecurity with OWASP CRS plus custom rules like the Sigma logic above) in front of WordPress properties. For a CMS ecosystem with this cadence of critical plugin CVEs, virtual patching is the difference between a 24-hour emergency and a 2-hour containment.
9. Restrict WordPress admin surface: disallow file editing (DISALLOW_FILE_EDIT), limit admin-ajax.php abuse where feasible, and enforce MFA on all administrator accounts so that a created or escalated account cannot be trivially leveraged.

Monitor the NVD entry for CVE-2026-18467, the plugin's WordPress.org changelog, and the CISA KEV catalog for confirmed-exploitation status and any vendor advisory updates.

The Bottom Line

CVE-2026-18467 is a reminder of two hard truths in vulnerability management. First, a patch is only as good as its completeness — the 5.0.3 fix hardened one data path while leaving a filter hook that overwrote it, and organizations that did everything right by patching to 5.0.3 remained exposed. Second, WordPress plugin CVEs with unauthenticated privilege gain are among the fastest-weaponized vulnerability classes in existence. Patch above 5.0.3 today, hunt for pt-user-role in your logs going back at least to disclosure, and audit your admin accounts. If you find evidence of exploitation, you are no longer doing vulnerability management — you are doing incident response, and the clock on credential rotation and webshell hunting has already started.

Related Resources

Security Arsenal Penetration Testing Services AlertMonitor Platform Book a SOC Assessment vulnerability-management Intel Hub