On publication of CVE-2026-126173 to the National Vulnerability Database, a critical authorization bypass was disclosed in the AutomatorWP Pro Webhooks addon for WordPress, affecting all versions up to and including 1.4.4. Rated CVSS 9.8 (Critical) with a network-exploitable attack vector requiring no authentication, this vulnerability allows a remote attacker to reset the password of any WordPress account on the site — including administrator accounts — resulting in complete account takeover and full site compromise.
WordPress powers a significant portion of the public web, and AutomatorWP is a popular automation plugin used to connect WordPress events to internal and external workflows. Organizations running AutomatorWP Pro with the Webhooks addon — particularly those that have configured inbound webhook automations that update user records — are at immediate risk. If your WordPress instance is internet-facing and running this plugin configuration, treat this as an emergency change window event.
Technical Analysis
Affected Product and Versions
- Product: AutomatorWP Pro — Webhooks Addon (WordPress plugin)
- Affected Versions: All versions up to and including 1.4.4
- Vulnerability Type: Authorization Bypass / Missing Authorization (CWE-862)
- CVE: CVE-2026-126173
- CVSS v3.x Score: 9.8 (Critical) — Vector: Network / Low Complexity / No Privileges / No User Interaction
- Exploitation Prerequisites: An administrator must have configured an automation pairing a Receive Webhook trigger (with an 'Is the user ID' field) to an Update-User action where the User ID field is left blank
How the Vulnerability Works
The root cause is a missing authorization check in the webhook handler of the AutomatorWP Pro Webhooks addon. When an administrator creates an automation that listens for inbound webhooks (the Receive Webhook trigger) and chains it to an Update-User action with the User ID field left blank, the plugin fails to verify that the caller is authorized to perform the user update operation.
An unauthenticated remote attacker can craft a webhook request to the exposed endpoint that triggers the automation. Because the User ID field is blank in the Update-User action configuration, the plugin does not constrain which user account gets modified. The attacker can effectively instruct the automation to reset the password of any WordPress account — including accounts with the administrator role — by supplying the target user identifier or letting the blank field default in an attacker-controlled manner.
The attack chain from a defensive perspective:
- Attacker identifies a WordPress site running AutomatorWP Pro Webhooks addon ≤ 1.4.4
- Attacker locates the webhook receiver endpoint (predictable URL pattern based on automation configuration)
- Attacker sends an unauthenticated HTTP POST to the webhook endpoint with parameters targeting the Update-User action
- The automation executes, resetting the target user's password to an attacker-controlled or attacker-known value
- Attacker authenticates as the compromised user (e.g., admin) and achieves full site control
Why This Is So Dangerous
- No authentication required — the attacker never needs valid credentials to trigger the exploit
- Low attack complexity — the webhook endpoint is a standard HTTP listener; no special tooling needed
- No user interaction — exploitation is fully automated and does not require tricking an administrator
- Complete impact — admin password reset yields full WordPress control: content manipulation, plugin/theme uploads (leading to webshells and RCE), database access, lateral movement into connected systems
- Configuration-dependent but plausibly common — the Update-User action with a blank User ID is a pattern administrators might use for "self-service" profile update workflows, making this misconfiguration more prevalent than it might initially appear
Exploitation Status
At the time of this writing, CVE-2026-126173 has been published to NVD with a CVSS score of 9.8. Given the trivial exploitation path (a single crafted HTTP request to a known endpoint), defenders should assume active scanning and exploitation attempts are imminent or already underway. WordPress plugin vulnerabilities with unauthenticated paths to admin takeover historically see weaponization within hours to days of public disclosure. Check the CISA Known Exploited Vulnerabilities catalog for updates on confirmed in-the-wild exploitation.
Detection & Response
Detecting exploitation of CVE-2026-126173 requires visibility into web server access logs, WordPress application-layer events, and downstream indicators of account compromise. The following detections are designed to be high-fidelity and actionable.
Sigma Rules
The following Sigma rules target observable behaviors associated with this vulnerability: suspicious webhook endpoint access patterns and post-exploitation indicators such as password reset activity on privileged accounts.
---
title: AutomatorWP Webhook Endpoint Suspicious Access
description: Detects inbound HTTP requests to AutomatorWP webhook receiver endpoints with characteristics consistent with CVE-2026-126173 exploitation — specifically POST requests to the webhook automation URL pattern that could trigger unauthorized user update actions.
author: Security Arsenal
date: 2026/04/06
status: experimental
references:
- https://nvd.nist.gov/vuln/detail/CVE-2026-126173
logsource:
category: webserver
product: apache
detection:
selection_uri:
cs-uri-stem|contains:
- '/wp-admin/admin-ajax.php'
- '/wp-json/automatorwp/'
- '/automatorwp-webhook'
selection_method:
cs-method: 'POST'
selection_no_auth:
sc-status: 200
condition: selection_uri and selection_method and selection_no_auth
falsepositives:
- Legitimate webhook deliveries from configured external services
- WordPress AJAX calls from authenticated sessions
level: high
---
title: WordPress Admin Password Reset Followed by Login
description: Detects a password change event on a WordPress administrator account followed by a successful login from an external IP address within a short window — indicative of account takeover via CVE-2026-126173.
author: Security Arsenal
date: 2026/04/06
status: experimental
references:
- https://nvd.nist.gov/vuln/detail/CVE-2026-126173
logsource:
category: application
product: wordpress
detection:
selection_event:
EventType:
- 'password_reset'
- 'user_updated'
selection_role:
UserRole|contains:
- 'administrator'
condition: selection_event and selection_role
falsepositives:
- Legitimate admin-initiated password resets
- Automated provisioning workflows
level: critical
---
title: New Plugin or Theme Installation on WordPress
description: Detects installation of new plugins or themes on a WordPress site, which is a common post-exploitation action following administrator account compromise via vulnerabilities like CVE-2026-126173. Attackers frequently upload webshells or malicious plugins after gaining admin access.
author: Security Arsenal
date: 2026/04/06
status: experimental
references:
- https://nvd.nist.gov/vuln/detail/CVE-2026-126173
- https://attack.mitre.org/techniques/T1505/003/
logsource:
category: file_event
product: linux
detection:
selection_paths:
TargetFilename|contains:
- '/wp-content/plugins/'
- '/wp-content/themes/'
- '/wp-content/uploads/'
selection_write:
TargetFilename|endswith:
- '.php'
- '.zip'
condition: selection_paths and selection_write
falsepositives:
- Legitimate plugin/theme installations by site administrators
- Automated WordPress update processes
level: medium
KQL Hunt Queries (Microsoft Sentinel / Defender)
The following KQL queries are designed for Microsoft Sentinel environments ingesting web server logs (via CEF/Syslog) or WordPress application logs. The first query hunts for webhook endpoint access patterns consistent with exploitation. The second identifies rapid password-change-to-login sequences indicative of account takeover.
// Hunt 1: Suspicious POST requests to AutomatorWP webhook endpoints
// Looks for unauthenticated POST requests matching webhook receiver patterns
CommonSecurityLog
| where TimeGenerated > ago(7d)
| where RequestMethod == "POST"
| where RequestURL has_any (
"automatorwp",
"admin-ajax.php"
)
| where RequestURL has_any (
"webhook",
"automatorwp-webhook",
"action=automatorwp"
)
| extend SourceIP = SourceIP, DestinationHost = DestinationHostName
| summarize RequestCount = count(), DistinctURLs = dcount(RequestURL), URLs = make_set(RequestURL, 10) by SourceIP, DestinationHost, bin(TimeGenerated, 1h)
| where RequestCount > 5
| sort by RequestCount desc
// Hunt 2: Password reset followed by successful login (account takeover pattern)
// Requires WordPress security plugin logs (e.g., Wordfence, iThemes) ingested via Syslog
Syslog
| where TimeGenerated > ago(7d)
| where SyslogMessage has_any ("password", "reset", "user_updated")
| where SyslogMessage has "admin"
| extend EventTime = TimeGenerated, Message = SyslogMessage
| summarize ResetEvents = count() by Computer, bin(TimeGenerated, 15m)
| where ResetEvents >= 1
| join kind=inner (
Syslog
| where TimeGenerated > ago(7d)
| where SyslogMessage has_any ("login", "authenticated", "session")
| where SyslogMessage has "success"
) on Computer
| where TimeGenerated1 between (TimeGenerated .. TimeGenerated + 15m)
| project TimeGenerated, Computer, ResetEvents, LoginMessage = SyslogMessage1
// Hunt 3: New PHP files written to WordPress content directories (webshell staging)
// Requires File Integrity Monitoring or Sysmon data ingested into Sentinel
DeviceFileEvents
| where TimeGenerated > ago(7d)
| where FolderPath has_any (
"wp-content/plugins",
"wp-content/themes",
"wp-content/uploads"
)
| where FileName endswith ".php"
| where ActionType == "FileCreated"
| project TimeGenerated, DeviceName, FolderPath, FileName, InitiatingProcessFileName, InitiatingProcessAccountName
| sort by TimeGenerated desc
Velociraptor VQL Hunt
For organizations with Velociraptor deployed on WordPress hosting servers, the following VQL artifact hunts for recently created or modified PHP files in WordPress content directories — a strong post-exploitation indicator following admin account takeover.
-- Hunt for recently modified PHP files in WordPress content directories
-- Indicative of webshell deployment or malicious plugin/theme installation
-- following CVE-2026-126173 admin account takeover
SELECT
FullPath,
Size,
Mtime AS ModifiedTime,
Ctime AS CreatedTime,
Btime AS BirthTime
FROM glob(globs=[
'/var/www/*/wp-content/plugins/**/*.php',
'/var/www/*/wp-content/themes/**/*.php',
'/var/www/*/wp-content/uploads/**/*.php',
'/home/*/public_html/wp-content/plugins/**/*.php',
'/home/*/public_html/wp-content/themes/**/*.php',
'/home/*/public_html/wp-content/uploads/**/*.php'
])
WHERE Mtime > now() - 604800
ORDER BY Mtime DESC
Remediation and Verification Script
The following Bash script helps WordPress administrators identify whether the vulnerable plugin is installed, check the version, and verify whether any webhook automations with the exploitable configuration exist. It is intended to be run on the WordPress hosting server with appropriate filesystem permissions.
#!/bin/bash
# CVE-2026-126173 — AutomatorWP Pro Webhooks Addon Vulnerability Checker
# Run on WordPress hosting server. Requires read access to wp-content and WP-CLI.
# Usage: bash check-cve-2026-126173.sh [wordpress_root_path]
WP_ROOT="${1:-/var/www/html}"
PLUGIN_DIR="$WP_ROOT/wp-content/plugins/automatorwp-pro-webhooks"
PLUGIN_MAIN="$PLUGIN_DIR/automatorwp-pro-webhooks.php"
RED='\033[0;31m'
GREEN='\033[0;32m'
YELLOW='\033[1;33m'
NC='\033[0m'
echo "==================================================="
echo " CVE-2026-126173 — AutomatorWP Pro Webhooks Checker"
echo "==================================================="
echo ""
echo "[*] WordPress root: $WP_ROOT"
echo ""
# Check 1: Is the plugin directory present?
echo "[CHECK 1] Checking for AutomatorWP Pro Webhooks plugin directory..."
if [ -d "$PLUGIN_DIR" ]; then
echo -e " ${YELLOW}[FOUND]${NC} Plugin directory exists: $PLUGIN_DIR"
# Check 2: What version is installed?
echo ""
echo "[CHECK 2] Checking plugin version..."
if [ -f "$PLUGIN_MAIN" ]; then
VERSION=$(grep -i "Version:" "$PLUGIN_MAIN" | head -1 | awk '{print $NF}')
echo " Installed version: $VERSION"
if [ -n "$VERSION" ]; then
# Compare version against 1.4.4
if [ "$(printf '%s\n' "1.4.4" "$VERSION" | sort -V | head -1)" = "$VERSION" ] && [ "$VERSION" != "1.4.5" ]; then
echo -e " ${RED}[VULNERABLE]${NC} Version $VERSION is <= 1.4.4 — IMMEDIATE ACTION REQUIRED"
else
echo -e " ${GREEN}[PATCHED]${NC} Version $VERSION appears to be newer than 1.4.4"
fi
fi
else
echo -e " ${YELLOW}[WARN]${NC} Main plugin file not found — check directory contents manually"
ls -la "$PLUGIN_DIR"
fi
# Check 3: Look for webhook automations in the database via WP-CLI
echo ""
echo "[CHECK 3] Checking for webhook automations with exploitable configuration..."
if command -v wp &> /dev/null; then
echo " Querying AutomatorWP automations with Receive Webhook triggers..."
wp --path="$WP_ROOT" db query \
"SELECT p.ID, p.post_title, pm.meta_value
FROM wp_posts p
JOIN wp_postmeta pm ON p.ID = pm.post_id
WHERE p.post_type LIKE 'automator%'
AND pm.meta_value LIKE '%webhook%'" 2>/dev/null
if [ $? -eq 0 ]; then
echo -e " ${YELLOW}[REVIEW]${NC} Examine the above automations for Receive Webhook triggers paired with Update-User actions"
echo " Look for Update-User actions where the User ID field is blank"
else
echo -e " ${YELLOW}[WARN]${NC} WP-CLI query failed — check database access or table prefix"
fi
else
echo -e " ${YELLOW}[SKIP]${NC} WP-CLI not found. Install WP-CLI or check automations manually in WordPress admin."
fi
# Check 4: Recent webhook-related entries in web server access logs
echo ""
echo "[CHECK 4] Checking access logs for suspicious webhook requests (last 24h)..."
for LOGFILE in /var/log/apache2/access.log /var/log/nginx/access.log /var/log/httpd/access_log; do
if [ -f "$LOGFILE" ]; then
HITS=$(grep -i "automatorwp\|webhook" "$LOGFILE" | grep "POST" | grep "$(date -d '24 hours ago' '+%d/%b/%Y' 2>/dev/null || date '+%d/%b/%Y')" | wc -l)
if [ "$HITS" -gt 0 ]; then
echo -e " ${RED}[ALERT]${NC} Found $HITS POST request(s) to webhook endpoints in $LOGFILE (last 24h)"
grep -i "automatorwp\|webhook" "$LOGFILE" | grep "POST" | tail -20
else
echo -e " ${GREEN}[CLEAN]${NC} No recent POST requests to webhook endpoints found in $LOGFILE"
fi
fi
done
else
echo -e " ${GREEN}[NOT FOUND]${NC} AutomatorWP Pro Webhooks plugin directory not present — likely not affected"
fi
# Check 5: Recent PHP file modifications in wp-content (post-exploitation indicator)
echo ""
echo "[CHECK 5] Checking for recently modified PHP files in wp-content (last 48h)..."
RECENT_PHP=$(find "$WP_ROOT/wp-content" -name "*.php" -mmin -2880 -type f 2>/dev/null | head -20)
if [ -n "$RECENT_PHP" ]; then
echo -e " ${YELLOW}[REVIEW]${NC} Recently modified PHP files found (verify these are legitimate):"
echo "$RECENT_PHP"
else
echo -e " ${GREEN}[CLEAN]${NC} No PHP files modified in wp-content within the last 48 hours"
fi
echo ""
echo "==================================================="
echo " RECOMMENDED ACTIONS"
echo "==================================================="
echo "1. UPDATE AutomatorWP Pro Webhooks addon to the latest patched version immediately"
echo "2. If no patch is available, DEACTIVATE the Webhooks addon until patched"
echo "3. REVIEW all automations using Receive Webhook + Update-User actions"
echo "4. Ensure the User ID field in Update-User actions is explicitly set"
echo "5. FORCE PASSWORD RESET for all administrator accounts as a precaution"
echo "6. REVIEW WordPress user list for unauthorized accounts"
echo "7. AUDIT installed plugins/themes for unauthorized additions"
echo "==================================================="
Remediation
Immediate Actions (Within 24 Hours)
-
Update AutomatorWP Pro Webhooks addon to the latest available patched version beyond 1.4.4. Check the plugin vendor's changelog and update via the WordPress admin dashboard or WP-CLI. If the vendor has not yet released a patch, proceed to step 2 immediately.
-
If no patch is available, deactivate the Webhooks addon. This eliminates the attack surface entirely while preserving other AutomatorWP functionality. Navigate to Plugins > Installed Plugins in WordPress admin and deactivate the AutomatorWP Pro Webhooks addon.
-
Audit all existing automations. Review every automation that uses the Receive Webhook trigger. Specifically look for any automation that pairs a Receive Webhook trigger (with an 'Is the user ID' field) to an Update-User action where the User ID field is blank. This is the exact vulnerable configuration. Either populate the User ID field with a specific, intended user or delete the automation.
-
Force password resets for all privileged accounts. As a precaution against prior exploitation, force a password reset for all WordPress accounts with
administrator,editor, orshop_managerroles. Consider using a security plugin or WP-CLI to invalidate all existing sessions. -
Review WordPress user accounts. Check for unauthorized user accounts, particularly any recently created accounts with elevated privileges. Attackers who gain admin access frequently create backdoor accounts.
Short-Term Hardening (Within 1 Week)
-
Restrict webhook endpoint access. If webhook functionality is required, implement IP allowlisting at the web server or WAF level to restrict inbound webhook requests to known, trusted source IPs (e.g., your integration platforms like Zapier, Make, or internal services).
-
Enable comprehensive WordPress logging. Deploy a security logging plugin (e.g., WP Activity Log, Wordfence) to capture user modification events, password changes, login attempts, and plugin/theme installations. Forward these logs to your SIEM.
-
Implement a Web Application Firewall (WAF) rule. If using Cloudflare, Sucuri, AWS WAF, or similar, create a rule to inspect POST requests to AutomatorWP webhook endpoints and block requests that do not originate from expected sources or that contain user-modification parameters.
-
Enable two-factor authentication (2FA) on all WordPress accounts with elevated privileges. This provides a critical second layer of defense even if a password is reset by an attacker.
Ongoing Practices
-
Establish a WordPress plugin vulnerability management cadence. WordPress plugins are among the most frequently exploited components on the internet. Subscribe to vulnerability feeds from Wordfence, Patchstack, WPScan, and NVD. Test and deploy plugin updates within defined SLAs — critical (CVSS 9.0+) within 24 hours, high within 72 hours.
-
Minimize plugin footprint. Every installed plugin expands your attack surface. Regularly audit installed plugins and remove those that are not actively maintained or no longer needed.
-
Apply the principle of least privilege to WordPress user roles. Limit the number of administrator accounts and ensure automation workflows do not inadvertently grant excessive capabilities.
Vendor Advisory
- NVD Entry: https://nvd.nist.gov/vuln/detail/CVE-2026-126173
- Monitor the AutomatorWP vendor site and WordPress plugin repository for patched version releases and official advisory details.
- Check the CISA KEV catalog for updates on confirmed exploitation status and any associated remediation deadlines.
Key Takeaways
CVE-2026-126173 is a textbook example of how a missing authorization check in a widely deployed WordPress plugin can provide a direct, unauthenticated path to full site compromise. The exploitation barrier is extremely low — a single crafted HTTP request. The impact is absolute — administrator account takeover means the attacker owns the site, its content, its user database, and potentially the underlying server.
The configuration-dependent nature of this vulnerability (requiring a specific webhook-to-Update-User automation pairing with a blank User ID) does not diminish the urgency. Administrators frequently build "self-service" or integration-driven user update workflows that match this exact pattern. If you are running AutomatorWP Pro with the Webhooks addon, assume you are exposed until you have verified otherwise.
Patch or deactivate now. Hunt for indicators of prior exploitation. Harden your WordPress environment against the next plugin vulnerability — because there will be a next one.
Related Resources
Security Arsenal Penetration Testing Services AlertMonitor Platform Book a SOC Assessment vulnerability-management Intel Hub
Is your security operations ready?
Get a free SOC assessment or see how AlertMonitor cuts through alert noise with automated triage.