Table of contents
17
By Salman Khan, OSCP+, Founder of XHack, SRT (Synack Red Team member)
Read this in 30 seconds: CVE-2026-27540 is an unauthenticated file-upload bug in the WooCommerce Wholesale Lead Capture plugin, and Wordfence has blocked over 100,000 exploitation attempts against it since June, months after the patch shipped.
- The registration form is the entry point, not an admin screen. An unauthenticated AJAX action meant to accept a lead’s document upload has no login check at all, and its file-type allowlist is read from a parameter the visitor controls.
- This plugin has two unauthenticated bugs, not one, patched together. CVE-2026-27542, a straight privilege-escalation flaw in the same registration flow, lets an attacker self-register as a full WordPress administrator with no file upload and no guessing required.
- NVD scores the file-upload bug 9.0, not the 9.8 you’ll see repeated elsewhere. The reason is specific: exploiting it means guessing a folder name PHP generates from the current time, which knocks the attack complexity from Low to High. The companion privilege-escalation bug has no such barrier and is the more dangerous of the two.
- The patch has existed since February 20, and attackers are still finding unpatched sites in bulk. 100,000-plus blocked attempts since June, with fresh attempts logged in the 24 hours before this was written.
- The dropped webshell isn’t the end of the visit. It reports host details back and offers a browser-based form for uploading more files, built for a second trip.
A plugin built to capture wholesale leads is instead capturing WordPress installs.
WooCommerce Wholesale Lead Capture, a premium plugin from Rymera Web Co with roughly 6,000 active installs, shipped a fix for two unauthenticated, unrelated-looking bugs back on February 20, 2026. Seven months later, Wordfence is still counting exploitation attempts in the tens of thousands, and a public proof-of-concept tool now automates both attack paths end to end.
Here’s how the file-upload bug actually works, why its companion privilege-escalation bug is arguably worse, and what to check if you run this plugin.
WooCommerce Wholesale Lead Capture is a premium add-on for WooCommerce stores that run a wholesale sales channel alongside a normal retail one. Its core job is a public registration form: a prospective wholesale buyer fills it in, optionally attaches a document like a resale certificate, and the store owner approves or rejects the application before granting wholesale pricing access.
That form is unauthenticated by design, because the whole point is to let a stranger apply. Both bugs in this article, CVE-2026-27540 chief among them, live inside the code that handles what an unauthenticated stranger is allowed to submit through it.
Here’s NVD’s description:
“Unrestricted Upload of File with Dangerous Type vulnerability in Rymera Web Co Pty Ltd. Woocommerce Wholesale Lead Capture woocommerce-wholesale-lead-capture allows Using Malicious Files. This issue affects Woocommerce Wholesale Lead Capture: from n/a through <= 2.0.3.1.”
AV:N/AC:H/PR:N/UI:N/S:C/C:H/I:H/A:H, scored by Patchstack as the CVE Numbering Authority. Note the AC:H (attack complexity: high), the reason this scores lower than the “9.8” figure that circulates in a lot of secondary coverage. More on why below.WordPress plugin vulnerability write-ups for a CVE-2026-27540-style bug usually get to point to a public commit diff. This one can’t: WooCommerce Wholesale Lead Capture is a paid plugin distributed directly by Rymera Web Co, not through the public wordpress.org repository, so there’s no public source or patch diff to link. What follows is reconstructed from Wordfence’s and Patchstack’s published descriptions and a public proof-of-concept tool, not from reading the plugin’s own source, and it’s labeled that way throughout.
The CVE-2026-27540 vulnerable code path is an AJAX action called wwlc_file_upload_handler, registered so that it’s reachable by anyone, logged in or not, the same way the registration form itself has to be. The handler is meant to accept a resale certificate or similar document and check its file type before saving it. According to Wordfence’s and Patchstack’s descriptions, that check reads its allowed-extensions list from a request parameter named file_settings, one the visitor supplies, rather than from a fixed, server-side list. In effect, the illustrative shape of the flaw looks like this:
// Illustrative reconstruction, not the plugin's actual source.
// Based on published researcher descriptions of the vulnerable behavior.
function wwlc_file_upload_handler() {
$settings = json_decode( stripslashes( $_POST['file_settings'] ), true );
$allowed_extensions = $settings['allowed_types']; // attacker-controlled
$filename = $_FILES['file']['name'];
$ext = strtolower( pathinfo( $filename, PATHINFO_EXTENSION ) );
if ( in_array( $ext, $allowed_extensions ) ) {
// saved with no further type or content check
move_uploaded_file( $_FILES['file']['tmp_name'], $upload_dir . '/' . $filename );
}
}If that’s an accurate read of the behavior, an attacker just needs to submit a file_settings value that includes php in its own allowlist, alongside a file named something like shell.php, and the handler saves it. A public PoC tool does exactly this: it POSTs a multipart request to /wp-admin/admin-ajax.php with a forged file_settings parameter and a PHP payload.
The file lands in wp-content/uploads/, inside a subdirectory the plugin names dynamically using PHP’s uniqid('wwlc-temp-'). That’s the source of the AC:H in the CVE-2026-27540 CVSS score. uniqid() without its extra-entropy flag is derived from the server’s current microtime, which is predictable, not random, but it isn’t handed back to the attacker in the response either. The published PoC tool’s answer is brute force: it tries directory listing first, then pattern-based guesses, then a time-seeded hex search keyed to the observed request timestamp, then random hex, logging up to 100,000 guesses per target. That’s real work compared to a shell that lands at a URL the server just tells you, which is exactly why this bug is scored a full 0.8 points lower than its companion.
Patched in the same 2.0.3.2 release, reported by the same researcher (Teemu Saarentaus, per Patchstack’s advisory), is CVE-2026-27542, an unauthenticated privilege escalation, CVSS 3.1 9.8, AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H. No AC:H here.
The vulnerable code is a second AJAX handler, wwlc_create_user, the one behind the same public registration form. Per the same PoC tool’s documentation, the handler processes registration submissions without adequately validating role-related fields, so a crafted POST that injects wp_capabilities[administrator] directly into the new account’s user metadata is accepted at account-creation time. No brute-forcing, no waiting, no second request: submit the registration form with that field forged in, and the account WordPress creates for you is already a full administrator.
That makes CVE-2026-27542 the more practically dangerous of the pair, even though CVE-2026-27540 is the one that made headlines this week. A skilled attacker with both bugs in hand would almost certainly reach for this one first.
Wordfence’s own count: over 100,000 blocked exploitation attempts against CVE-2026-27540 since June 2026, four months after the February patch, with fresh attempts still logged as recently as the 24 hours before this article was researched. That gap, patch available for months, mass exploitation happening anyway, is the same pattern that’s shown up repeatedly in WordPress plugin CVEs this year: a fix exists, but a large share of installs never apply it. Reporting from The Hacker News covers the same exploitation wave, and our own wp2shell writeup and WordPress core template writeup cover two other 2026 WordPress bugs that followed the identical fixed-but-still-exploited shape.
The dropped payload isn’t a one-shot shell. Reporting on the observed attacks describes the uploaded shell.php as reporting host details back to the attacker and providing a browser-based upload form for planting further files, built for repeat visits rather than a single smash-and-grab.
Wordfence’s published indicators include a set of attacker source IPs actively used against this vulnerability: 92.241.13.213, 31.59.129.150, 2a0f:85c1:840:5389::1, 92.241.13.140, 23.137.105.214, 23.180.120.140, 104.194.9.138, 187.75.114.36, 114.10.43.203, and 37.114.144.209.
You’re exposed to CVE-2026-27540 if both of these are true:
If you’re running 2.0.3.2 or later, both CVE-2026-27540 and CVE-2026-27542 are patched. If you don’t recognize the plugin name but run WooCommerce, check your plugin list rather than assuming, wholesale add-ons are common enough on B2B storefronts to be easy to forget about.
# Look for uploaded PHP inside the plugin's temp-upload pattern
find /path/to/wordpress/wp-content/uploads -type d -iname 'wwlc-temp-*'
find /path/to/wordpress/wp-content/uploads -type f -iname '*.php' -newer /path/to/wordpress/wp-content/plugins/woocommerce-wholesale-lead-captureWhat to check for CVE-2026-27540 specifically:
wwlc-temp-* directory under wp-content/uploads/ containing a .php file. None should exist; the plugin’s normal file attachments are documents and images, not executable code./wp-admin/admin-ajax.php with action=wwlc_file_upload_handler or action=wwlc_create_user in access logs, particularly any carrying a file_settings parameter or a wp_capabilities field, which a legitimate wholesale application would never include.
The interesting CVE-2026-27540 lesson here isn’t the file upload, it’s the pattern behind both bugs: a form built to accept input from an unauthenticated stranger, where a security-relevant decision, which file types are allowed, or which role a new account gets, was driven by data that same stranger controls. That’s exactly the class of bug a web application penetration test is built to find, and it rarely shows up in an automated scan, because the endpoint looks legitimate and the parameters look like normal form fields.
We’d test a form like this by systematically trying to influence every parameter that looks like it configures behavior rather than carries content, file type allowlists, role fields, redirect targets, not just the ones an attacker is obviously meant to fill in. That’s slower than a scanner and it’s exactly why a scanner missed this class of bug on thousands of sites for months.
Our ultimate penetration testing checklist covers how that kind of engagement is scoped for a WordPress or WooCommerce storefront specifically.
CVE-2026-27540 is an unauthenticated arbitrary file-upload vulnerability in the WooCommerce Wholesale Lead Capture plugin, CVSS 9.0. An unauthenticated attacker can submit a file with a forged file_settings parameter to the plugin’s wwlc_file_upload_handler AJAX action, bypassing its file-type allowlist to upload a PHP web shell.
Yes. Wordfence has blocked over 100,000 exploitation attempts against it since June 2026, four months after the February 20 patch, with attempts continuing as of this writing.
NVD and Patchstack score it 9.0 because the uploaded file lands in an unpredictable, dynamically named folder, raising attack complexity to High. The 9.8 figure that circulates in some coverage more likely reflects the companion bug, CVE-2026-27542, which has no such barrier and is scored 9.8.
CVE-2026-27542 is an unauthenticated privilege-escalation vulnerability in the same plugin’s registration handler (wwlc_create_user), patched in the same 2.0.3.2 release. It lets an attacker self-register as a full WordPress administrator by injecting a forged capability field into the registration request, with no file upload and no guessing required.
Update WooCommerce Wholesale Lead Capture to version 2.0.3.2 or later. This also fixes CVE-2026-27542. Treat it as an emergency update given the scale of ongoing exploitation, and check for unauthorized PHP files and unrecognized admin accounts afterward.
Any WordPress site running WooCommerce Wholesale Lead Capture 2.0.3.1 or earlier with its registration form reachable from the internet, which is the plugin’s normal, intended configuration.
CVE-2026-27540 and its companion, CVE-2026-27542, both trace back to the same mistake: a public registration form that let the visitor configure security-relevant behavior instead of just submitting an application. One bug needs a lucky folder guess to pay off; the other doesn’t need luck at all.
The patch has existed since February. If you run this plugin and haven’t checked your version since then, do that first, then check your uploads folder and your user list for anything that shouldn’t be there before you assume the update alone cleaned things up.
Categories
Related articles
