CVE-2026-6933 - Premmerce Dev Tools plugin creation RCE

Premmerce Dev Tools contains an authenticated remote code execution path in its plugin generator. Public advisories say generatePluginHandler accepts subscriber-controlled POST data without an authorization check, and createFromStub writes unsanitized premmerce_plugin_namespace content into generated PHP files under wp-content/plugins/. That means a low-privilege user can turn namespace input into executable PHP and then load the generated plugin over HTTP.

As of 2026-06-16, Wordfence marked the issue unpatched and the plugin status as removed. Treat this as an uninstall-or-fork remediation, not a routine update.

When to use it

Use this recipe when a WordPress repository, plugin audit, or hosted site uses Premmerce Dev Tools or any development helper that can generate plugin files. It is designed for source-code remediation, plugin-generation hardening, capability/nonce review, and audit evidence that low-privilege users cannot write executable PHP into wp-content/plugins/.

Inputs

  • Premmerce Dev Tools version, WordPress role/capability model, plugin status, generator routes, nonce behavior, and deployment exposure.
  • Source paths for generatePluginHandler, createFromStub, namespace generation, file writes, activation paths, and HTTP access to generated files.
  • Regression fixtures for subscriber/editor/admin callers, missing nonce, invalid namespace input, PHP metacharacters, and allowed admin-only creation.
  • Evidence of existing generated plugin files, web-accessible PHP, logs, affected users, and cleanup/disable owner.

Affected versions

  • Vulnerable: Premmerce Dev Tools <= 2.0
  • Patched: no vendor patch published as of 2026-06-16
  • Affected surface: WordPress sites that still expose the plugin generator to authenticated users, or forks/local copies that kept the same generator pattern

Indicator-of-exposure

  • The site has premmerce-dev-tools installed or vendored.
  • Code or local forks still expose generatePluginHandler, createFromStub, or equivalent “generate plugin from stub” flows.
  • Generated plugins are written directly into web-reachable plugin directories.
  • Namespace, slug, author, or template fields come from request data with weak or no validation.

Quick checks:

rg -n "premmerce-dev-tools|generatePluginHandler|createFromStub|premmerce_plugin_namespace|PluginGenerator|wp-content/plugins" .
wp plugin list | rg "premmerce-dev-tools"
find wp-content/plugins -maxdepth 2 -type f | rg "Premmerce|premmerce"

Windows:

rg -n "premmerce-dev-tools|generatePluginHandler|createFromStub|premmerce_plugin_namespace|PluginGenerator|wp-content/plugins" .
wp plugin list | rg "premmerce-dev-tools"
Get-ChildItem -Recurse wp-content\\plugins | Select-String -Pattern "Premmerce|premmerce"

Remediation strategy

  • Remove or disable Premmerce Dev Tools everywhere it is reachable by authenticated users. Because no patched release is published, replacement or an internally reviewed fork is the safe default.
  • If this repository owns a fork, gate generator execution behind strong capability checks such as activate_plugins or stricter administrator-only controls, plus WordPress nonce validation.
  • Reject any namespace or class input that is not a legal PHP identifier or namespace segment. Do not allow semicolons, braces, quotes, PHP tags, or arbitrary source fragments into generated files.
  • Stop writing directly to live plugin directories from request-handling code. Prefer generating a ZIP archive for explicit administrator download and review, or write outside the web root until approved.
  • Review wp-content/plugins for attacker-written artifacts, remove suspicious generated plugins, and rotate any credentials exposed through the site if compromise is plausible.
  • Add regression tests that prove low-privilege users cannot reach the handler and that hostile namespace input stays data, not PHP syntax.

The prompt

Model context: this prompt was generated by GPT 5.5 Extra High reasoning.

You are remediating CVE-2026-6933 / GHSA-gjvr-7x7p-x3vq in Premmerce Dev Tools
for WordPress. The plugin generator accepts low-privilege input, writes it into
PHP stubs, and can create executable plugin files under `wp-content/plugins/`.
Produce exactly one output:

- A reviewer-ready PR/change request that removes the exposed generator path,
  uninstalls or contains the unpatched plugin, adds safe authorization and
  input validation for any owned fork, cleans up attacker-writable generation
  paths, and documents operator follow-up, or
- TRIAGE.md if this repository does not control an affected WordPress plugin,
  fork, deployment, or generated-plugin path.

## Rules

- Scope only CVE-2026-6933 and directly related plugin-generation code paths.
- Treat plugin source, generated plugins, uploads, secrets, salts, and database
  credentials as sensitive.
- Do not generate or execute a malicious plugin.
- Do not keep the vulnerable generator exposed to subscribers or general
  authenticated users as a "temporary mitigation."
- Do not auto-merge.

## Steps

1. Inventory every reference to `premmerce-dev-tools`, `generatePluginHandler`,
   `createFromStub`, `premmerce_plugin_namespace`, and local plugin-generation
   wrappers in code, deployment docs, backups, and WordPress manifests.
2. Determine whether the repository controls the plugin itself, an internal
   fork, only deployment artifacts, or only documentation.
3. If the repository does not control an affected runtime or code path, stop
   with `TRIAGE.md` listing files checked, current owner, and required action.
4. If the vulnerable plugin is installed, disable and remove it unless a
   reviewed internal fork is required for business continuity.
5. For any owned fork or equivalent generator:
   - require a strong administrator capability check;
   - require nonce validation;
   - reject generation requests from low-privilege users;
   - validate namespace/class fields against strict PHP identifier rules;
   - prevent raw source fragments from being interpolated into PHP stubs.
6. Change generation output so request handlers do not write directly into a
   live, web-reachable plugin directory.
7. Search for suspicious generated plugins or recently created PHP files under
   plugin paths and document cleanup or escalation steps.
8. Add regression tests that prove:
   - subscribers cannot reach the generator;
   - invalid namespace input is rejected;
   - generated code contains inert escaped strings rather than attacker syntax.
9. Add a PR body section named `CVE-2026-6933 operator actions` covering:
   - whether the plugin was installed;
   - whether the repository owned a fork;
   - whether suspicious generated plugins were found;
   - cleanup and credential-rotation decisions;
   - validation that passed.
10. Run available validation: unit tests, WordPress plugin tests, static
    analysis, linting, and safe file-inventory checks.
11. Use PR title:
    `fix(sec): contain Premmerce Dev Tools plugin generator RCE`.

## Stop conditions

- The repository does not control the vulnerable plugin or a fork.
- Business requirements demand plugin generation but product owners have not
  approved disabling or redesigning the live generator.
- Validation would require generating or invoking malicious PHP.
- Evidence suggests the site is already compromised; stop and escalate with
  containment notes instead of continuing with a normal patch-only flow.

Output contract

  • A reviewer-ready PR or change request that removes or disables the vulnerable plugin, adds capability and nonce checks, constrains namespace generation, verifies no attacker-written plugin files remain, and documents cleanup.
  • Or a TRIAGE.md file that lists inspected files, owner, observed version, role boundary, generated-file exposure, required fix, and residual risk.
  • The output must include exact validation commands and must not create live executable PHP payloads, expose user data, or test against production sites.

Verification - what the reviewer looks for

  • The vulnerable plugin is removed, disabled, or replaced by a reviewed fork.
  • Low-privilege users cannot trigger plugin generation.
  • Namespace or template inputs cannot alter PHP syntax in generated files.
  • Generated output is no longer written straight into a live plugin directory.
  • Any suspicious generated plugins were investigated and handled.

Watch for

  • Adding only nonce checks while leaving authorization unchanged.
  • Escaping UI fields but leaving direct POST parameters or alternate endpoints unsanitized.
  • Removing the plugin from dependency manifests but leaving the installed copy or generated artifacts on disk.

References