CVE-2026-6933: Remote Code Execution in Premmerce Dev Tools
High CVSS (8.8) vulnerability; prioritize internet-facing assets.
| Field | Value |
|---|---|
| CVE ID | CVE-2026-6933 |
| CVSS score | 8.8 |
| Attack vector | Authenticated remote code execution |
| Auth required | Yes, Subscriber-level access or above |
| Patch status | No verified fixed version confirmed from retrieved sources |
TL;DR - Premmerce Dev Tools for WordPress is vulnerable to authenticated RCE in versions
<= 2.0. - Any authenticated user with Subscriber-level access may be able to write executable PHP intowp-content/plugins/. - No verified patch is publicly confirmed in the retrieved sources, so disable or remove the plugin now if present.
What Happened and Why It Matters
CVE-2026-6933 is a high-severity authenticated remote code execution flaw in the Premmerce Dev Tools plugin for WordPress. According to the NVD description, the issue exists because the generatePluginHandler function lacks an authorization check and the createFromStub function performs unsafe string substitution using user-controlled POST data. In practical terms, this means an authenticated low-privilege user can supply crafted input that is written into a generated PHP plugin file.
The impact is severe because the malicious file is written into the WordPress plugins directory, specifically under wp-content/plugins/, and the code can then execute when the generated plugin file is accessed over HTTP. That changes this from a simple logic bug into a direct route to server-side code execution. Once an attacker can run arbitrary PHP in the web application context, defenders should assume full site compromise is possible, including webshell deployment, database access, credential theft, and persistence through rogue plugin code.
This is not an unauthenticated internet-wide bug, but it is still operationally important for sites that allow self-registration, membership accounts, customer accounts mapped to WordPress users, or any workflow where Subscriber-level access exists outside a tightly controlled administrative team. On those sites, the privilege threshold is low enough that account compromise, credential stuffing, or abuse of abandoned low-privilege accounts becomes a realistic attack path.
The vulnerability is also notable because the WordPress plugin page showed the plugin as closed as of June 10, 2026 with the note “temporary, pending a full review.” That is not a patch notice and should not be treated as remediation, but it does reinforce that defenders should verify whether the plugin is installed and active rather than waiting for more public reporting.
Affected Versions and Fixed Version Status
The affected product is the Premmerce Dev Tools plugin for WordPress. Based on the NVD record, the GitHub Advisory entry, and the WordPress plugin page metadata cited in the research note, the affected version range is up to and including 2.0. The most defensible version statement from the retrieved sources is:
- Affected versions:
<= 2.0 - Fixed version: unknown / not publicly confirmed from retrieved sources
That distinction matters. You should not assume a fix exists unless you can verify a new release from a trusted source such as the WordPress plugin directory, vendor advisory, or source repository changelog. In this case, the available research material did not confirm a patched release number, and the plugin page still listed version 2.0 while the plugin was closed.
For practitioners, the absence of a verified fix changes the response plan. This is not a routine “schedule the update for the next maintenance window” issue. If you have premmerce-dev-tools deployed and the installed version is 2.0 or earlier, the prudent stance is to treat it as vulnerable until a fixed version is explicitly published and validated. If the plugin is not strictly required in production, removal is safer than disablement alone because the vulnerability involves generating plugin files in a sensitive directory.
Because no verified fixed version was available in the retrieved sources, defenders should also be careful with third-party blog posts or mirrors that may speculate about a future patch. In the absence of confirmed vendor data, assume no patch is available yet and plan compensating controls accordingly.
Exploitation Status and Threat Assessment
At the time of writing, exploitation in the wild is not confirmed in the retrieved primary sources. The CVE is not listed in CISA’s Known Exploited Vulnerabilities catalog, which means there is no current KEV evidence tying it to confirmed active exploitation. That said, absence from KEV is not proof of safety; it only means there is no public CISA listing at this time.
Likewise, a public proof of concept is not confirmed from the retrieved sources. The research note specifically states that no concrete GitHub PoC repository was confirmed during the source review. That is the most accurate public statement available from the evidence provided: no known in-the-wild exploitation confirmed, and no public PoC confirmed.
Defenders should still treat this as high risk because the exploit path described by NVD is straightforward. The vulnerability combines two well-understood failure modes: missing authorization and unsafe code generation. An authenticated attacker with Subscriber-level access can potentially submit crafted POST data, inject PHP via the premmerce_plugin_namespace parameter, write attacker-controlled code into a generated plugin, and then trigger execution. Even without a public PoC, this kind of flaw is typically reproducible by a capable attacker with access to the plugin and a test WordPress instance.
A realistic threat model here includes insider misuse, compromised low-privilege accounts, abused customer or membership accounts, and opportunistic attackers who gain Subscriber access through weak credentials. If your WordPress deployment exposes registration, account creation, or low-privilege user roles to the public, urgency should be higher than the “authenticated” label may initially suggest.
How the Vulnerability Works
According to the NVD description, the issue centers on two application behaviors. First, generatePluginHandler lacks proper authorization checks before handling POST data. Second, createFromStub performs unsanitized string substitution with the premmerce_plugin_namespace value, writing the result into PHP stub files. That creates a route for attacker-controlled input to become executable PHP on disk.
The dangerous part is not merely that user input is stored. The dangerous part is that the plugin appears to generate PHP plugin files directly inside wp-content/plugins/, which is an executable path for WordPress. If an attacker can break out of an expected namespace value by injecting a semicolon and arbitrary PHP, they can transform what should be metadata-like input into live code. Once that file is reachable over HTTP, the web server and PHP runtime do the rest.
This turns the plugin generator feature itself into the exploitation primitive. Rather than uploading a standalone shell through a classic file upload bug, the attacker abuses the plugin’s own file generation logic to create malicious PHP in a location WordPress expects to contain trusted code. That can make incident response harder because the resulting artifact may look like a generated plugin rather than a dropped payload.
Technical Notes
The NVD-linked references identify the vulnerable code areas as:
src/Admin/Admin.phparound thegeneratePluginHandlerlogicsrc/PluginGenerator/PluginData.phparound the plugin generation and substitution logic
The WordPress Trac reference URLs were cited by NVD, but the research environment could not retrieve their contents due to 403 Forbidden. Because of that, defenders should rely on the NVD description for the root-cause summary rather than assuming line-level source details beyond what is explicitly confirmed.
Conceptually, the flow looks like this:
Authenticated user
-> submits crafted POST request
-> generatePluginHandler processes request without adequate authorization
-> createFromStub injects unsanitized premmerce_plugin_namespace into PHP stub
-> generated file written under wp-content/plugins/
-> attacker requests generated plugin path over HTTP
-> arbitrary PHP executes on server
If you maintain a test copy of the plugin for internal validation, treat any generated plugin artifacts as potentially dangerous and isolate the test host. Do not attempt reproduction on production infrastructure.
What Defenders Should Do Next
First, inventory WordPress sites for the Premmerce Dev Tools plugin and identify any instance running version 2.0 or earlier. Because the affected range is stated as up to and including 2.0, any known deployment in that range should be treated as vulnerable. If you cannot quickly verify versioning from your asset data, assume exposure until proven otherwise.
Second, remove or disable the plugin and begin a brief compromise assessment focused on wp-content/plugins/, user accounts, and unusual PHP execution paths. If you find unknown generated plugin directories, unauthorized user activity, or direct web requests to new plugin PHP files, escalate to incident response. Server-side code execution on WordPress should be treated as potentially full compromise of the site and application secrets.
Third, monitor vendor and trusted advisory sources for a verified fixed version. Since the retrieved sources did not confirm one, update your internal ticketing and risk register to reflect that remediation currently depends on plugin removal or isolation rather than patch deployment. When a vendor or WordPress.org fix is published, verify the release notes and test in a non-production environment before reintroduction.
For more information on when to report a cyberattack, check our FAQ on reporting cyberattacks. To understand more about red teaming, visit our glossary on red teams.
This article may contain affiliate links. We earn a commission on qualifying purchases at no extra cost to you.
Detection and Hunting Guidance
Detection should focus on two areas: abuse of low-privilege accounts and unexpected file creation in the plugins directory. Because the described exploitation path relies on an authenticated request followed by execution of a generated plugin file, defenders should look for suspicious admin-ajax or plugin-specific POST activity, followed by requests to new or unusual paths beneath wp-content/plugins/.
Start with file integrity and timeline analysis. On a WordPress host, inspect wp-content/plugins/ for directories or files created recently that do not match your deployment process. Pay special attention to plugin names, namespaces, headers, or file contents that look generated but include unexpected PHP statements. If you do not normally generate plugins in production, any recent writes in that location deserve immediate review.
Also review WordPress users with the subscriber role and above. Because the vulnerability requires authentication, authentication logs, account creation events, password reset activity, and role changes are part of the hunt. If your site allows public registration, assume Subscriber accounts are part of the attack surface. If your environment maps e-commerce or membership users into WordPress roles, include those pathways in scoping.
Technical Notes
Example filesystem and content checks on Linux hosts:
find /var/www/html/wp-content/plugins -type f -mtime -14 \( -name "*.php" -o -name "*.inc" \) -ls
grep -RIn --color -E "premmerce_plugin_namespace|eval\s*\(|base64_decode\s*\(|system\s*\(|shell_exec\s*\(" /var/www/html/wp-content/plugins
Example web log hunt for direct access to plugin PHP files:
grep -E 'POST .*wp-admin|/wp-content/plugins/.+\.php' /var/log/nginx/access.log
grep -E 'POST .*wp-admin|/wp-content/plugins/.+\.php' /var/log/apache2/access.log
A concrete suspicious access-log pattern to review:
POST /wp-admin/... HTTP/1.1
...
GET /wp-content/plugins/<unexpected-plugin>/<unexpected-file>.php HTTP/1.1
Example Splunk query for suspicious plugin execution after admin POSTs:
index=web_logs (uri_path="/wp-content/plugins/*.php" OR http_method=POST)
| stats count min(_time) as firstTime max(_time) as lastTime by src_ip, http_method, uri_path, user, status
| sort - lastTime
Example Sigma-style idea for web logs:
title: Suspicious Direct Execution of PHP Under WordPress Plugins
logsource:
category: webserver
detection:
selection:
cs_uri_stem|contains: '/wp-content/plugins/'
cs_uri_stem|endswith: '.php'
condition: selection
level: medium
These are detection ideas, not guaranteed exploit signatures. Because no public PoC was confirmed in the retrieved sources, defenders should assume indicators may vary and focus on the invariant behaviors: authenticated setup activity, file creation in wp-content/plugins/, and subsequent HTTP execution of newly created PHP files.
Mitigation and Remediation
Because the affected range is <= 2.0 and no verified fixed version is confirmed from the retrieved sources, the safest mitigation is to disable and remove Premmerce Dev Tools from production WordPress instances until a trusted fixed release is available. If the plugin is only used for development or debugging, it should not remain installed on internet-facing production systems anyway.
If business requirements prevent immediate removal, the next best step is to disable the plugin, restrict access to the WordPress admin area, review and reduce low-privilege accounts, and continuously monitor wp-content/plugins/ for new file creation. These are temporary risk-reduction measures, not a substitute for patching or removal. Given the nature of the bug, simply relying on WAF rules is not enough because the exploit is authenticated and may look like legitimate plugin-generation traffic.
You should also assume that any site with the vulnerable plugin active and low-privilege user access may already be at risk of compromise. That means remediation should include compromise assessment, not just software changes. Review recently created plugin files, admin accounts, scheduled tasks, .htaccess changes, database options, and outbound connections from the web host.
Technical Notes
Check whether the plugin is present via WP-CLI:
wp plugin list | grep premmerce-dev-tools
Disable the plugin:
wp plugin deactivate premmerce-dev-tools
Remove the plugin entirely:
wp plugin uninstall premmerce-dev-tools
If WP-CLI is unavailable, you can manually remove it after deactivation:
rm -rf /var/www/html/wp-content/plugins/premmerce-dev-tools
Temporary workaround if immediate removal is not possible: restrict access to WordPress admin and account registration paths at the reverse proxy or web server. Example Nginx control to limit admin access to trusted IPs:
location ~* ^/wp-admin/ {
allow 203.0.113.10;
deny all;
}
If your site requires public logins, also review whether Subscriber registration can be disabled:
wp option get users_can_register
wp option update users_can_register 0
Only apply that last change if it does not break a required business workflow. For e-commerce, membership, or community sites, you may need compensating controls instead, such as IP restrictions for admin functions, MFA for all authenticated users, and aggressive monitoring.