CVE-2026-14281: Unauthenticated Admin Takeover in WAWP WooCommerce Plugin

Overview

A critical privilege escalation vulnerability, tracked as CVE-2026-14281, has been disclosed in Automation Web Platform – Notifications and OTP for WooCommerce, Advanced Country Code (commonly branded WAWP), a WordPress plugin from vendor 101gen that adds order notifications, OTP-based verification, country-code selection, and a chat widget to WooCommerce stores. The flaw affects all versions up to and including 4.8.6 and was published to the National Vulnerability Database (NVD) on September 25, 2026 with a maximum-severity CVSS 3.1 score of 9.8.

The root cause is missing permission enforcement on the publicly accessible REST route POST /wp-json/wawp/v1/signup/signup, combined with the absence of a key allowlist in the plugin's finish_registration_logic function. Any unauthenticated visitor can submit a wawp_custom_fields parameter that gets copied directly into update_user_meta(), including sensitive WordPress meta keys such as wp_capabilities and wp_user_level. An attacker can use this to register a brand-new account and hand it the administrator role in a single request — no credentials, no social engineering, and no user interaction required. A public Python proof-of-concept exploit is already circulating, and the plugin's own advisory catalog lists a patched release at version 4.8.7.

Technical Details

How It Works

The vulnerable signup path. WAWP registers its own REST namespace for account signup, verification, and magic-link handling. The POST /wp-json/wawp/v1/signup/signup route is intentionally public — new customers need to be able to hit it while logged out — but the plugin's public_permissions_check never restricts what data the caller can send, only that the request is well-formed.

Custom fields without an allowlist. The signup handler accepts a wawp_custom_fields parameter, which the plugin maps internally to custom_fields_data. After the new account is created with wp_insert_user(), WAWP's finish_registration_logic function loops over that caller-supplied data and writes each key/value pair straight into the new user's metadata with update_user_meta() — with no filter on which meta keys are allowed. WordPress uses two of those meta keys, wp_capabilities and wp_user_level, to determine a user's role and privilege level. Because the plugin never blocks those keys from being set by the request itself, an attacker can include them in wawp_custom_fields and the plugin will faithfully write administrator-level capabilities onto the account it just created.

The result: instant admin, zero authentication. The vulnerable code paths live in includes/api/class-wawp-rest-settings-api.php (route registration), includes/auth-services/class-wawp-otp-service.php (the wawp_custom_fields → custom_fields_data mapping), and includes/auth-services/class-wawp-signup.php (finish_registration_logic). Chained together, a single unauthenticated POST request creates a fully privileged WordPress administrator account on the target site.

A compounding weakness: OTP is trivially bypassable. Sites that enable OTP verification at signup are not meaningfully protected. The OTP session token (otp_transient) is returned in plaintext in the HTTP response body to the signup request itself, and the plugin's handle_magic_link_request() handler marks that token as verified on any unauthenticated GET request that includes it — without ever checking whether the submitted OTP code is correct. An attacker who receives the plaintext token from the signup response can immediately replay it to the magic-link handler and complete "verification" without ever seeing an SMS or email. This flaw has been tracked separately by researchers (disclosed 2026-08-20) but directly removes OTP as a mitigating control for CVE-2026-14281.

Impact Assessment

Why This Is Rated Critical

The CVSS vector (AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H) reflects the worst-case combination for a web application flaw: exploitable remotely over the network, low attack complexity, no privileges required, no user interaction required, and complete impact to confidentiality, integrity, and availability once the attacker holds an administrator account. There is no meaningful barrier between "anonymous visitor" and "site owner" in the vulnerable code path.

Mitigation

Immediate Actions

1. Update WAWP to version 4.8.7 or later immediately. This is the single most effective remediation — the patched release enforces permission checks on the signup route and adds a key allowlist to finish_registration_logic.
2. If you cannot patch immediately, disable the plugin or block public access to /wp-json/wawp/v1/signup/* at the web server or WAF layer until the update is applied.
3. Audit all WordPress administrator accounts on any site running WAWP ≤ 4.8.6, especially prior to confirming the patch was applied. Look for accounts you don't recognize, unusual creation timestamps, or accounts with generic/randomized usernames.
4. Rotate credentials and API keys for any integrations (payment gateways, SMTP relays, third-party plugins) if an unauthorized administrator account is found — assume full compromise, not partial.
5. Check for persistence mechanisms — new plugins/themes installed, modified theme/functions.php files, unexpected scheduled tasks (WP-Cron), or web shells dropped via the plugin/theme editor.

Detection Opportunities

• Web server / WAF logs: Search for POST requests to /wp-json/wawp/v1/signup/signup containing a wawp_custom_fields parameter that references wp_capabilities or wp_user_level — this is a near-certain indicator of exploitation attempts.
• WordPress user audit log: Flag any new user creation events where the resulting role is administrator and the account was not created through the standard wp-admin "Add New User" screen.
• Magic-link / OTP abuse: Review requests to the magic-link handler occurring within seconds of a signup request from the same IP — a signature of the OTP-bypass chain being used alongside the privilege escalation.
• Outbound traffic anomalies: Newly created administrator accounts that immediately install plugins, edit theme files, or trigger outbound connections shortly after creation warrant immediate investigation.

Recommendations for Site Administrators Generally

• Minimize public REST surface on WooCommerce and third-party plugins — REST routes intended for logged-out use should still validate and constrain what fields a caller can influence, particularly any field that maps to WordPress core meta keys.
• Monitor plugin advisories continuously. Low-install-count plugins like WAWP (~400 sites) rarely make mainstream news but are exactly the kind of target mass-scanning bots pick up within hours of a public PoC.
• Apply the principle of least trust to third-party plugin code touching update_user_meta(), wp_insert_user(), or capability assignment — these are the highest-value functions for an attacker to reach.

Why This Keeps Happening

CVE-2026-14281 follows a pattern seen repeatedly in the WordPress plugin ecosystem: a public-by-design REST endpoint (signup has to be reachable while logged out) paired with insufficient allowlisting of the data that endpoint is permitted to write. Developers correctly reason that some fields need to flow from an untrusted request into user meta — custom registration fields, marketing preferences, phone numbers for OTP — but fail to explicitly block the small set of WordPress-reserved keys (wp_capabilities, wp_user_level, and similar) that directly control privilege. Combined with the plugin's own OTP verification step being bypassable by design (a plaintext token that's "verified" without checking the actual code), this incident is a reminder that a security feature — OTP — is only as strong as the server-side validation behind it, not the presence of the feature itself. Any plugin that writes attacker-controlled data into update_user_meta() without an explicit allowlist is one missed key away from the same outcome.

References

• NVD — CVE-2026-14281
• Wordfence Intelligence — Wawp OTP Verification, Order Notifications, and Country Code Selector for WooCommerce
• WPScan — Automation Web Platform Plugin Vulnerabilities
• GitHub — murrez/CVE-2026-14281 PoC