HIGH 8.8

CVE-2026-6933: Premmerce Dev Tools WordPress RCE Vulnerability (CVSS 8.8)

The Premmerce Dev Tools plugin for WordPress contains a critical authorization flaw that allows low-privileged attackers to execute arbitrary code on the server. An attacker with even a Subscriber account can exploit a missing permission check in the plugin's code generation function to inject malicious PHP code into newly created plugin files. When those files are accessed, the injected code runs with full server privileges, giving the attacker complete control over the WordPress installation.

Source data · NVD / CISA · public domain

CVSS
3.1 · 8.8 HIGH · CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
Weaknesses (CWE)
CWE-434
Affected products
0 configuration(s)
Published / Modified
2026-06-16 / 2026-06-17

NVD description (verbatim)

The Premmerce Dev Tools plugin for WordPress is vulnerable to Remote Code Execution via missing authorization in versions up to and including 2.0. This is due to the 'generatePluginHandler' function lacking any authorization check before processing user-supplied POST data, combined with the 'createFromStub' function performing unsanitized string substitution of the 'premmerce_plugin_namespace' parameter directly into PHP stub files written to the wp-content/plugins/ directory. An attacker can inject a semicolon followed by arbitrary PHP code into the namespace parameter, causing the generated plugin file to contain and execute that code when accessed via HTTP. This makes it possible for authenticated attackers with Subscriber-level access and above to create arbitrary PHP files on the server and achieve remote code execution.

7 reference(s) · View on NVD →

SEC.co analysis · AI-assisted, reviewed against source

Technical summary

CVE-2026-6933 is a Remote Code Execution vulnerability stemming from two compounded weaknesses in the Premmerce Dev Tools plugin (versions ≤2.0). The 'generatePluginHandler' function fails to validate user authorization before processing POST requests. The 'createFromStub' function then performs unsafe string substitution of the 'premmerce_plugin_namespace' POST parameter directly into PHP template files, which are written to wp-content/plugins/. An attacker can inject a semicolon and arbitrary PHP into this namespace parameter, resulting in executable code embedded in the generated plugin file. When the plugin file is accessed via HTTP request, PHP executes the injected payload. The vulnerability is classified under CWE-434 (Unrestricted Upload of File with Dangerous Type).

Business impact

Compromise of a WordPress site running Premmerce Dev Tools exposes all business-critical data hosted on that platform. An attacker can steal customer information, payment data, and proprietary content; modify site functionality to redirect users or inject malware; or leverage the server for lateral attacks into connected infrastructure. The low barrier to entry (Subscriber-level access) makes this particularly dangerous for organizations with loose user provisioning controls or shared WordPress environments. Ransomware deployment, data exfiltration, and site defacement are direct consequences.

Affected systems

The vulnerability affects Premmerce Dev Tools plugin for WordPress in all versions up to and including 2.0. Any WordPress installation with this plugin active and accessible to users with Subscriber-level privileges or higher is at risk. The plugin must be active and the vulnerable functions must be callable; however, there is no evidence the vulnerability requires any specific WordPress configuration beyond standard installation.

Exploitability

The vulnerability is highly exploitable. No complex technical steps are required: an attacker need only craft a POST request to the vulnerable handler with a malicious 'premmerce_plugin_namespace' parameter containing PHP code preceded by a semicolon. The attack requires authentication (Subscriber level or above), but does not require user interaction, administrative approval, or social engineering. Network accessibility is direct over HTTP/HTTPS. The barrier to weaponization is minimal, making this vulnerability attractive to threat actors with even basic WordPress knowledge.

Remediation

Update the Premmerce Dev Tools plugin immediately to a patched version released after 2.0. Verify the updated version against the official Premmerce plugin repository or vendor advisory for confirmation of the fix. As an interim control pending patching, disable or remove the Premmerce Dev Tools plugin entirely if not actively in use. Audit user roles and capabilities to ensure Subscriber-level accounts are restricted to trusted users only. Consider implementing a Web Application Firewall (WAF) rule to block requests to the vulnerable handler endpoint. Review access logs for evidence of exploitation.

Patch guidance

Check the official WordPress plugin repository and Premmerce's vendor advisory for the earliest available patch version after 2.0. Apply the patch through the WordPress admin dashboard (Plugins > Updates) or via direct download and installation. Verify the plugin version reflects the patched release before considering remediation complete. Test the patched version in a non-production environment first to ensure compatibility with other installed plugins and themes.

Detection guidance

Monitor HTTP POST requests to the Premmerce Dev Tools plugin handler, particularly those containing the 'premmerce_plugin_namespace' parameter with unusual or PHP-like content (semicolons, 'eval', 'system', 'exec', etc.). Inspect newly created files in wp-content/plugins/ for unexpected plugin directories or suspicious PHP code. Review WordPress user activity logs for Subscriber-level account logins and administrative actions, especially plugin file creation. Search web server and PHP error logs for execution errors or exceptions originating from auto-generated plugin files. Compare active plugins in wp-content/plugins/ against documented whitelist.

Why prioritize this

With a CVSS score of 8.8 (HIGH) and direct RCE capability requiring only low-level authentication, this vulnerability should receive immediate priority. The ease of exploitation, absence of any user interaction requirement, and the complete control granted to an attacker make this a critical business risk. The plugin is targeted at developers, meaning organizations using it may have broader security implications. Remediation is straightforward (update or remove), justifying rapid action.

Risk score, explained

The CVSS 3.1 vector (AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H) reflects a severity of 8.8 (HIGH). The vulnerability scores highly because: (1) Attack Vector is Network (AV:N), meaning no physical access is required; (2) Attack Complexity is Low (AC:L), requiring no special conditions; (3) Privileges Required are Low (PR:L), needing only Subscriber-level access; (4) User Interaction is None (UI:N), the attacker needs no victim action; (5) Scope is Unchanged (S:U), impact is limited to the vulnerable component; (6) Confidentiality, Integrity, and Availability are all High (C:H/I:H/A:H), granting complete compromise of the server. The score reflects near-maximum impact with moderate barriers to entry.

Frequently asked questions

Do we need an active Premmerce Dev Tools license to be vulnerable?

No. The vulnerability exists in the plugin code itself regardless of licensing status. If the plugin is installed and activated on your WordPress site, you are at risk. Licensing is a separate commercial arrangement with Premmerce and does not mitigate this security flaw.

What is the difference between this and a standard WordPress plugin upload vulnerability?

Standard plugin upload vulnerabilities typically require administrative privileges to upload files intentionally. This vulnerability bypasses authorization entirely, allowing a Subscriber-level user to trigger automatic plugin file generation and code execution without ever visiting the admin dashboard. It is more dangerous because it exploits a legitimate plugin function, not user intent.

Can we safely run the plugin in a limited development environment?

Running the plugin in any environment accessible to untrusted users (or even trusted users with Subscriber accounts) carries risk. If you must test it, isolate the environment completely from production and external networks. However, given the easy availability of patches, upgrading is the safer path.

How do we know if we have been exploited?

Check wp-content/plugins/ for unexpected subdirectories created after the plugin was installed. Look for suspicious files or those with recent modification timestamps. Review web server access logs for POST requests to the vulnerable endpoint. Scan the server with security tools like Wordfence or Sucuri. If compromise is suspected, engage incident response and review all system access logs and database activity.

This intelligence is provided as-is and based on publicly disclosed vulnerability information available as of the publication date. SEC.co makes no representations regarding patch availability, vendor timelines, or comprehensive coverage of all affected deployments. Verify all technical details, patch versions, and remediation steps against official vendor advisories before implementation. Organizations should conduct their own risk assessment and testing before applying patches to production systems. No warranty is provided regarding the accuracy or completeness of derived threat intelligence. Source: NVD (public-domain), retrieved 2026-07-24. Analysis generated by SEC.co (claude-haiku-4-5).