CVE-2026-94541: Critical WordPress WPMobile.App Auth Bypass (CVSS 9.8) — Detection and Remediation Guide

NVD has published CVE-2026-94541, a critical CVSS 9.8, network-exploitable vulnerability in the WPMobile.App – Android and iOS App Builder plugin for WordPress. Every version up to and including 11.82 is affected. The plugin fails to properly verify that a user is authorized to perform a sensitive action — a classic broken-access-control / missing-capability-check flaw — and the result is devastating: an unauthenticated remote attacker can exfiltrate password-reset URLs for arbitrary users, including administrators, and use those URLs to take over the targeted accounts.

The exploitation chain depends on one precondition: the plugin's mail-to-push feature must be enabled (wpmobile_auto_mail=1). When enabled, the plugin mirrors outbound mail — including password-reset emails — into its push notification queue. That queue is then reachable through an unauthenticated, authorization-free code path, handing attackers a ready-made credential-theft mechanism with no phishing required.

If you operate WordPress sites — directly or on behalf of clients — this is a patch-now, verify-now event. A CVSS 9.8 unauthenticated account-takeover path against a CMS that powers a massive share of the public web is precisely the class of bug that gets weaponized within days of disclosure. This post covers the attack chain, how to find vulnerable and compromised sites, and exactly what to do about it.

Technical Analysis

Affected Product and Versions

How the Attack Works

This is an authorization bypass (CWE-862 class — Missing Authorization). The mechanics, from a defender's perspective:

1. Feature precondition. A site administrator has enabled the plugin's mail-to-push bridge (wpmobile_auto_mail=1). This feature is designed to convert outbound WordPress emails into mobile push notifications.
2. Sensitive data mirrored into the push queue. When WordPress generates a password-reset email (e.g., via retrieve_password()), the plugin mirrors that message — including the one-time reset URL with its embedded key and user login — into the push queue.
3. Missing authorization check. The plugin exposes a code path (an AJAX/REST-style handler) that does not verify the requester is authenticated or authorized to read queued push content. No capability check, no nonce validation tied to a privileged session.
4. Exfiltration. The attacker triggers or waits for a password reset for a target account (an administrator login is trivially enumerable on most WordPress sites), then reads the reset URL out of the unauthenticated queue endpoint.
5. Account takeover. The attacker follows the reset URL before the legitimate user, sets a new password, and owns the account. An administrator account means full site compromise: webshell upload via theme/plugin editor, malicious plugin installation, content injection, and pivot into anything the site can reach.

The elegance — and danger — of this chain is that it requires no user interaction, no valid credentials, and no race conditions of consequence. The attacker controls the reset trigger; the plugin does the rest.

Exploitation Status

At time of writing, CVE-2026-94541 has been published by NVD with the technical details above. Defenders should assume rapid weaponization: WordPress plugin auth-bypass bugs with unauthenticated account-takeover impact historically see mass scanning and automated exploitation shortly after public disclosure. Treat this as effectively exploitable in the wild even before confirmed in-the-wild reporting — the bar to exploit is low (a single crafted HTTP request against a reachable endpoint), and vulnerable sites are enumerable via plugin fingerprinting. Check whether the CVE has been added to CISA's Known Exploited Vulnerabilities (KEV) catalog and your vendor feeds daily until you have patched or disabled the feature.

Who Is Actually Exposed

Not every site running WPMobile.App is exploitable — the mail-to-push feature must be enabled. However:

• Sites that enabled it to deliver transactional notifications to their mobile app users are fully exposed.
• Because the precondition is a single option value, your first triage action is inventory + configuration check, not just version checking. Version ≤11.82 and wpmobile_auto_mail=1 = critically exposed. Version ≤11.82 with the feature off = still patch, but the active attack path is closed.

Detection & Response

Defensive telemetry for this threat lives in three places: web access/WAF logs (the unauthenticated queue-read requests), the WordPress database (the wpmobile_auto_mail option), and post-exploitation artifacts (new admin users, password changes, plugin/theme modifications). The detections below target each.

Sigma Rules

---
title: WPMobile.App WordPress Plugin Unauthenticated Queue Access (CVE-2026-94541)
id: 8f2c4a17-6b3d-4e91-a5c2-7d8e9f0a1b2c
status: experimental
description: Detects HTTP requests targeting WPMobile.App plugin endpoints that may be used to exfiltrate password-reset URLs from the mail-to-push queue without authentication.
references:
  - https://nvd.nist.gov/vuln/detail/CVE-2026-94541
author: Security Arsenal
date: 2026/01/15
tags:
  - attack.initial_access
  - attack.t1190
logsource:
  category: webserver
detection:
  selection_uri:
    cs-uri|contains:
      - '/wp-content/plugins/wpmobile'
      - 'wpmobile'
      - 'wpmobile_auto_mail'
  selection_adminajax:
    cs-uri|contains:
      - '/wp-admin/admin-ajax.php'
    cs-uri-query|contains:
      - 'wpmobile'
  selection_wpjson:
    cs-uri|contains:
      - '/wp-json/'
    cs-uri-query|contains:
      - 'wpmobile'
  condition: selection_uri or selection_adminajax or selection_wpjson
falsepositives:
  - Legitimate mobile app traffic from the WPMobile.App companion apps
level: high
---
title: WordPress Password Reset Followed by Anomalous Password Change
id: 3b7e9d42-1c5f-4a68-b9d3-2e4f6a8c0d1e
status: experimental
description: Detects successful authentication or password-reset completion for a WordPress administrator account originating from an IP address with no prior session history, consistent with reset-URL theft via CVE-2026-94541.
references:
  - https://nvd.nist.gov/vuln/detail/CVE-2026-94541
author: Security Arsenal
date: 2026/01/15
tags:
  - attack.credential_access
  - attack.t1078
logsource:
  category: webserver
detection:
  selection_login:
    cs-uri|contains:
      - '/wp-login.php'
    cs-method: 'POST'
  selection_reset:
    cs-uri-query|contains:
      - 'action=rp'
      - 'action=resetpass'
      - 'key='
  condition: selection_login and selection_reset
falsepositives:
  - Legitimate user password resets from new devices or networks
level: medium

Analyst note: The first rule is intentionally scoped to plugin-specific URI patterns — it will be low-volume on sites that don't run the plugin and high-fidelity on sites that do, since unauthenticated hits against these handlers from datacenter/VPN exit IPs are almost never benign. Baseline against your legitimate mobile app user agents and geographies before tuning.

KQL — Microsoft Sentinel / Defender

This assumes your WordPress web logs (Apache/Nginx) or WAF logs reach Sentinel via Syslog/CEF ingestion.

// Hunt: Unauthenticated access to WPMobile.App plugin endpoints (CVE-2026-94541)
let lookback = 14d;
let wpmobile_requests = (
    CommonSecurityLog
    | where TimeGenerated > ago(lookback)
    | where RequestURL has_any ("wpmobile", "/wp-content/plugins/wpmobile")
       or (RequestURL has "/wp-admin/admin-ajax.php" and RequestURL has "wpmobile")
    | project TimeGenerated, SourceIP, RequestURL, RequestMethod, RequestClientApplication, DeviceAction, DestinationHostName
);
wpmobile_requests
| summarize RequestCount = count(),
            DistinctURLs = dcount(RequestURL),
            SampleURLs = make_set(RequestURL, 5),
            FirstSeen = min(TimeGenerated),
            LastSeen = max(TimeGenerated)
    by SourceIP, DestinationHostName
| where RequestCount > 20 or DistinctURLs > 3   // probing/exfil behavior, not single app sync
| order by RequestCount desc;

// Correlate: same source IPs hitting wp-login.php reset flow on the same hosts
CommonSecurityLog
| where TimeGenerated > ago(lookback)
| where RequestURL has "/wp-login.php" and RequestURL has_any ("action=rp", "action=resetpass", "key=")
| project TimeGenerated, SourceIP, DestinationHostName, RequestURL
| join kind=inner (wpmobile_requests | project SourceIP, DestinationHostName) on SourceIP, DestinationHostName
| order by TimeGenerated desc;

The correlation leg is the high-value part: a source IP that both touched WPMobile endpoints and completed a wp-login.php?action=rp flow on the same host within the hunt window is a strong account-takeover indicator and should trigger immediate IR.

Velociraptor VQL

Use this to inventory WordPress servers for vulnerable plugin versions and the dangerous feature flag — because exposure requires both.

-- Hunt: WPMobile.App plugin version and mail-to-push configuration (CVE-2026-94541)
-- Enumerates installed plugin version from readme/main plugin file and checks
-- WordPress options for wpmobile_auto_mail=1 across common web roots.

LET plugin_files = SELECT FullPath,
       read_file(filename=FullPath, length=4096) AS Header
FROM glob(globs=['/var/www/*/wp-content/plugins/wpmobile*/wpmobile*.php',
                 '/var/www/html/wp-content/plugins/wpmobile*/wpmobile*.php',
                 '/srv/www/*/wp-content/plugins/wpmobile*/wpmobile*.php',
                 '/home/*/public_html/wp-content/plugins/wpmobile*/wpmobile*.php'])
WHERE NOT IsDir

SELECT FullPath AS PluginFile,
       parse_regex(data=Header,
                   regex='Version:\\s*([0-9.]+)').g1 AS PluginVersion,
       -- Flag any WP database backup/dump containing the enabled option on disk
       (SELECT count() FROM glob(globs=[dirname(path=FullPath) + '/*'])
        WHERE True) AS DirFileCount,
       timestamp(epoch=now()) AS CollectionTime
FROM plugin_files
WHERE PluginVersion =~ '^([0-9]|10|11\\.[0-7][0-9]|11\\.8[0-2])($|\\.)'
   OR PluginVersion < '11.83'

For the option check, run a follow-up query on hosts with WordPress CLI available, or hunt the database directly. The fastest ground truth is WP-CLI (covered in the remediation script below), which Velociraptor can execute via the execve() function if your deployment permits it.

Remediation & Hardening Script

The following Bash script audits WordPress installations on a Linux host for (a) the vulnerable plugin version, (b) the dangerous wpmobile_auto_mail=1 setting, and (c) optionally disables the feature immediately as a stopgap. It uses WP-CLI where available.

#!/usr/bin/env bash
# CVE-2026-94541 triage & stopgap — WPMobile.App authorization bypass
# Run as root or a user with read access to web roots and WP-CLI configured.

set -u
WEB_ROOTS=(/var/www /srv/www /home)
FOUND=0

echo "=== CVE-2026-94541 WPMobile.App exposure audit ==="

find "${WEB_ROOTS[@]}" -maxdepth 6 -type d -path '*wp-content/plugins/wpmobile*' 2>/dev/null | while read -r plugdir; do
    FOUND=1
    wp_root="${plugdir%%/wp-content/*}"
    main_php=$(grep -rls 'Version:' "$plugdir" --include='*.php' -m1 2>/dev/null | head -1)
    ver=$(grep -m1 -oE 'Version:[[:space:]]*[0-9.]+' "$main_php" 2>/dev/null | grep -oE '[0-9.]+')
    echo "[+] Plugin found: $plugdir (Version: ${ver:-unknown})"

    # Compare version <= 11.82
    if [ -n "${ver:-}" ]; then
        if [ "$(printf '%s\n' "11.82" "$ver" | sort -V | tail -1)" = "11.82" ]; then
            echo "    [!] VULNERABLE VERSION (<= 11.82)"
        else
            echo "    [ok] Version appears patched (> 11.82)"
        fi
    fi

    # Check the mail-to-push flag via WP-CLI
    if command -v wp >/dev/null 2>&1; then
        flag=$(wp --path="$wp_root" --allow-root option get wpmobile_auto_mail 2>/dev/null || echo "unknown")
        echo "    [i] wpmobile_auto_mail = ${flag}"
        if [ "$flag" = "1" ]; then
            echo "    [!!!] CRITICALLY EXPOSED: mail-to-push ENABLED with vulnerable version"
            echo "    Stopgap: run the line below to disable the feature immediately:"
            echo "      wp --path=$wp_root option update wpmobile_auto_mail 0"
        fi
    else
        echo "    [i] wp-cli not found; check DB manually:"
        echo "        SELECT option_value FROM wp_options WHERE option_name='wpmobile_auto_mail';"
    fi
done

# Post-exploitation sweep: admin users created or password-changed recently
if command -v wp >/dev/null 2>&1; then
    echo "=== Post-exploitation indicators (per site, run per WP root) ==="
    echo "Review administrators:   wp --path=<wp_root> user list --role=administrator --fields=ID,user_login,user_email,user_registered"
    echo "Review recent resets:    grep -i 'action=rp' /var/log/nginx/access.log | tail -50"
fi

echo "=== Audit complete. Patch to the latest plugin release or remove the plugin if unused. ==="

Incident Response Checklist (If You Find Evidence of Exploitation)

1. Isolate the site — take it offline or restrict access at the WAF while you investigate.
2. Assume admin credential compromise — force-reset all WordPress user passwords, invalidate all sessions (wp config shuffle-salts to rotate auth keys/salts and kill every logged-in session).
3. Audit for persistence — enumerate administrator accounts created around the suspicious window; diff plugin/theme directories against clean copies; look for webshells (find wp-content -name '*.php' -newer <baseline> and review), mu-plugins, and modified functions.php.
4. Check outbound mail settings — attackers who take admin often install SMTP mailers or SEO-spam tooling.
5. Rotate adjacent secrets — database credentials in wp-config.php, API keys stored in options, and any third-party integrations.
6. Preserve evidence — access logs, the wp_options row history if available, and filesystem timelines before remediation destroys them.

Remediation

1. Update the plugin immediately. All versions ≤ 11.82 are vulnerable. Update WPMobile.App to the latest release from the WordPress plugin repository (verify the release notes explicitly reference CVE-2026-94541 or the authorization fix before relying on a version bump). Reference: https://nvd.nist.gov/vuln/detail/CVE-2026-94541
2. Stopgap — disable mail-to-push now. If you cannot patch today, close the attack path by disabling the feature: set wpmobile_auto_mail to 0 (WP-CLI: wp option update wpmobile_auto_mail 0, or via the plugin settings UI). This removes the reset-URL mirroring that the exploit chain depends on. This is a mitigation, not a fix — the missing authorization check remains, so patching is still required.
3. If the plugin is unused, delete it. Deactivating is not sufficient against unauthenticated endpoints in every case — remove the plugin directory entirely.
4. Verify exposure, not just version. Exploitability requires the feature flag. Inventory every WordPress property you manage (including staging and forgotten microsites — attackers scan those too) and check both version and wpmobile_auto_mail.
5. Block at the edge as a compensating control. Add WAF rules blocking unauthenticated requests containing wpmobile action parameters to /wp-admin/admin-ajax.php and suspicious hits to the plugin's REST routes until patching is confirmed. Rate-limit wp-login.php reset actions (action=rp, action=lostpassword) to slow reset-URL theft attempts.
6. Hunt backward. Because this is unauthenticated and leaves a clean log signature, review 30–90 days of access logs for the patterns above — exploitation may have preceded your patching. Any hit combined with a subsequent password-reset completion warrants the full IR checklist.
7. Monitor CISA KEV and vendor channels. If this CVE lands in the Known Exploited Vulnerabilities catalog, federal deadlines (typically 3 weeks for BOD 22-01-bound agencies) apply, and it is a reliable signal that mass exploitation is underway — accelerate accordingly.

The Bigger Lesson

WordPress plugin vulnerabilities of this class share a pattern: a convenience feature (email-to-push bridging) quietly handles high-value secrets (password-reset tokens) without the access controls those secrets demand. Two durable practices blunt this entire category: treat any plugin feature that touches authentication or mail flows as high-risk and review it before enabling, and maintain a real inventory of plugins and their configuration flags — not just their versions — so that when a CVE like this drops, your first question ("are we exposed?") takes minutes to answer, not days.

Related Resources

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