CVE-2025-6784: Authenticated RCE in WordPress Code Engine Plugin
TL;DR - CVE-2025-6784 is a high-severity authenticated RCE in the WordPress Code Engine plugin through version 0.3.5. - Attackers need Contributor-level access or higher and can abuse the
code-engineshortcode. - Upgrade beyond 0.3.5 immediately or disable the plugin if no fixed version is available in your environment.
Vulnerability at a Glance
| Field | Value |
|---|---|
| CVE ID | CVE-2025-6784 |
| CVSS | 8.8 (High) |
| Attack vector | Authenticated attack via WordPress shortcode functionality |
| Privileges required | Contributor-level access or higher |
| Patch available | Yes, upstream fix reference exists; update to a version later than 0.3.5 |
CVE-2025-6784 affects the Code Engine plugin in the WordPress ecosystem. According to the NVD description, the vulnerability is a remote code execution issue caused by insufficient restriction around the plugin’s code injection capability exposed through the code-engine shortcode. The impact is severe because an attacker who can create or edit content at the Contributor role or above may be able to execute code on the server.
From a defender’s perspective, this is not an unauthenticated internet-wide wormable issue, but it is still operationally significant. Many WordPress sites allow multiple contributors, guest authors, marketers, contractors, or compromised low-privilege accounts. In those environments, a contributor-to-server-compromise path can turn a limited CMS foothold into full application or host-level impact.
What Is This Vulnerability?
The root cause, based on the NVD description, is that the plugin does not properly restrict access to code-injection functionality available through the code-engine shortcode. In practical terms, shortcode processing in WordPress can expose powerful server-side behavior if plugin authors permit user-supplied content to reach dangerous execution paths. Here, the plugin appears to allow authenticated users with Contributor-level permissions to reach functionality that should have been tightly limited or disabled for untrusted roles.
That matters because Contributors in WordPress typically have fewer permissions than Editors or Administrators, but they may still be allowed to submit or manage their own posts depending on site configuration. If a plugin ties executable behavior to post content via a shortcode and fails to enforce capability checks, an attacker can weaponize ordinary content submission into server-side code execution. This is especially risky on multi-author sites, membership sites, managed blogging platforms, and any environment where lower-privileged accounts are easier to obtain than admin access.
Technical Notes
Because the upstream patch diff was not retrievable in the available research session, the exact implementation details of the vulnerable function path are unknown from the source set provided. Defenders should avoid assuming the issue is limited to one rendering path. If the plugin processes the code-engine shortcode during preview, save, publish, AJAX, REST, or front-end rendering, any of those paths could be relevant to exploit attempts.
A practical assumption is that exploitation will involve creating or modifying content that includes the shortcode. Review plugin behavior in a staging environment before concluding that only published posts are at risk.
Who Is Affected?
The affected product is the Code Engine plugin for WordPress. The available source-backed version range is explicit: all versions up to and including 0.3.5 are vulnerable. The product listing is in the official WordPress plugin ecosystem, and the NVD description directly attributes the issue to this plugin.
The fixed version could not be directly confirmed from the upstream changeset because the referenced changeset URL returned 403 Forbidden during retrieval. However, the evidence does support one clear remediation boundary: versions later than 0.3.5 are expected to contain the fix. If your site is running 0.3.5 or earlier, you should treat it as vulnerable unless you have independently validated a backported patch from a trusted maintainer or hosting provider.
This issue is most relevant to WordPress installations where the plugin is active and where users with Contributor-level access or higher can author or edit content that reaches shortcode processing. Sites with tightly restricted user creation and no contributor accounts still need patching, but their immediate exposure is lower than sites with many semi-trusted users.
If you do not know whether the plugin is installed, inventory your environment rather than assuming it is absent. WordPress plugins are often left enabled but unused, or present across staging clones, customer microsites, and older content properties.
Technical Notes
To check whether the plugin exists on disk:
ls -ld /var/www/html/wp-content/plugins/code-engine
To inspect the installed version from the plugin header:
grep -E "^[[:space:]]*\*?[[:space:]]*Version:" /var/www/html/wp-content/plugins/code-engine/*.php
To identify sites running the plugin across multiple vhosts:
find /var/www -path "*/wp-content/plugins/code-engine/*.php" -exec grep -H "Version:" {} \;
CVSS Score Breakdown
The published base score is 8.8 (High). The full CVSS vector string was not available in the returned NVD tool output, so any component-level discussion must be framed carefully. Still, the known facts support why the score is high: the vulnerability leads to remote code execution, which usually implies severe confidentiality, integrity, and availability impact if exploitation succeeds.
The required privileges reduce the score relative to a fully unauthenticated RCE, but not by much in many real-world WordPress deployments. Contributor access is a meaningful barrier on paper, yet in practice it may be obtainable via credential stuffing, phishing, reused passwords, weak account lifecycle controls, or compromise of a lower-tier content author. Once that role is obtained, code execution on the server can lead to web shell deployment, database theft, plugin tampering, redirect injection, or broader host compromise depending on server hardening.
Because the vector string was not available, defenders should avoid overfitting response decisions to guessed subcomponents such as user interaction or scope. The safe operational takeaway is simpler: a high-severity authenticated path to server-side code execution exists, and that is enough to justify urgent remediation.
A useful way to prioritize this issue is to pair the score with your user model. If you have open registration, many content contributors, external agencies, or history of account abuse, your practical risk may be closer to the upper end of “High” even without confirmed in-the-wild exploitation.
Exploitation Status
At the time of writing, there is no CISA KEV-backed confirmation that CVE-2025-6784 is being actively exploited in the wild. The CVE is not currently listed in CISA’s Known Exploited Vulnerabilities catalog. That does not prove the vulnerability is not being exploited; it means there is no confirmed KEV evidence in the dataset provided.
There is also no confirmed public proof-of-concept in the research note. The NVD references did not include a confirmed exploit repository in the material provided, and additional verification in the note did not confirm a PoC. In other words, the current source set supports this statement: public PoC not confirmed, active exploitation not confirmed.
Defenders should not confuse “no confirmed PoC” with low risk. Authenticated shortcode abuse in WordPress plugins is often straightforward for an attacker to reproduce once they understand the vulnerable feature. If your site has many lower-privilege accounts, assume exploit development effort is modest and prioritize patching accordingly.
Since active exploitation is unconfirmed, incident responders should calibrate urgency based on exposure rather than headlines. Focus on whether the plugin is present, whether vulnerable versions are active, and whether contributor-level accounts exist or have shown suspicious behavior.
How to Detect It
Detection should start with three questions: is the plugin installed, is a vulnerable version present, and are there suspicious uses of the code-engine shortcode? Because the root cause involves shortcode-based access to code injection functionality, content and request telemetry are more useful than generic vulnerability scanner output alone.
You should review recent content creation and modification activity by Contributor, Author, Editor, and Administrator accounts. In WordPress, shortcode abuse can show up in post bodies, revisions, autosaves, previews, and AJAX-driven editor workflows. If server-side execution occurred, there may also be downstream indicators such as new PHP files in writable directories, unusual outbound connections from the web server, unexpected scheduled tasks, or modified plugin/theme files.
Technical Notes
Search the database for posts containing the shortcode:
SELECT ID, post_author, post_date, post_status, post_title
FROM wp_posts
WHERE post_content LIKE '%[code-engine%';
If you use WP-CLI, run:
wp db query "SELECT ID, post_author, post_date, post_status, post_title FROM wp_posts WHERE post_content LIKE '%[code-engine%';"
Review WordPress and web server logs for content edits and shortcode-related requests. Example patterns to hunt:
POST /wp-admin/post.php
POST /wp-admin/post-new.php
POST /wp-admin/admin-ajax.php
GET /?p=<post_id>
Example grep for suspicious shortcode usage in exported logs or content snapshots:
grep -Rni "\[code-engine" /var/www/html/wp-content /var/log
Basic Apache/Nginx log triage focused on lower-privilege users and post editing windows:
grep -E "POST /wp-admin/(post\.php|post-new\.php|admin-ajax\.php)" /var/log/nginx/access.log
Example Sigma-style idea for log enrichment pipelines where request bodies or parameters are captured:
title: WordPress Code Engine Shortcode Abuse Attempt
logsource:
product: webserver
detection:
selection:
cs-uri-stem:
- "/wp-admin/post.php"
- "/wp-admin/post-new.php"
- "/wp-admin/admin-ajax.php"
request_body|contains: "[code-engine"
condition: selection
level: high
If you do not log request bodies, correlate post modification timestamps with suspicious child processes from the web server user, such as php-fpm, apache2, or nginx spawning shell utilities unexpectedly.
Mitigation and Patching
The strongest remediation supported by the available evidence is to upgrade the Code Engine plugin to a version later than 0.3.5. Because the exact fixed version number could not be directly retrieved from the upstream changeset in this research session, defenders should verify the currently published plugin version in the WordPress repository or from a trusted maintainer source before rollout. If your environment is on 0.3.5 or earlier, treat it as vulnerable.
If an updated version is not yet available in your internal mirrors or you cannot immediately validate the fixed release, disable the plugin until you can patch. Given the impact is server-side code execution, temporary business disruption from disabling the plugin is usually preferable to leaving the feature exposed. As a compensating control, reduce or remove Contributor access where possible and closely monitor any user who can create or edit posts.
For organizations that cannot remove the plugin immediately, limit risk by restricting content-authoring accounts, enforcing MFA, rotating passwords for all non-admin users, and reviewing any recent contributor-created content. Those are not substitutes for patching, but they reduce the likelihood of successful exploitation while maintenance windows are scheduled.
Technical Notes
Update via WP-CLI after confirming a safe fixed release is available upstream:
wp plugin update code-engine
Verify the installed version after update:
wp plugin get code-engine --fields=name,version,status
If you need an emergency containment step, deactivate the plugin:
wp plugin deactivate code-engine
For a stronger stop-gap, remove the plugin after backing up the site:
wp plugin uninstall code-engine
If immediate plugin removal is impossible, restrict lower-privilege authoring temporarily. For example, review and suspend Contributor accounts that do not need current access, and require administrators to publish content on their behalf until patching is complete.
After patching or disabling, re-scan content for the shortcode and review file integrity in common writeable locations:
find /var/www/html -type f \( -name "*.php" -o -name "*.phtml" \) -mtime -14
find /var/www/html/wp-content/uploads -type f \( -name "*.php" -o -name "*.phtml" \)
References
The primary reference for CVE-2025-6784 is the NVD record, which provides the vulnerability description, severity, and reference links. Based on the available data, NVD describes the issue as an authenticated RCE in the Code Engine WordPress plugin affecting all versions through 0.3.5 via the code-engine shortcode.
The other important references are the official WordPress plugin listing, the upstream WordPress plugin changeset associated with the fix, and the Wordfence advisory referenced by NVD. In this research session, the changeset was not retrievable due to 403 Forbidden, and the Wordfence page did not yield usable content through the tool. Because of that, some implementation details and the exact fixed version number were not independently confirmed here. In the absence of that detail, defenders should assume all versions up to and including 0.3.5 are vulnerable and upgrade beyond 0.3.5 as soon as a trusted fixed release is available.
- NVD CVE record: https://nvd.nist.gov/vuln/detail/CVE-2025-6784
- CISA Known Exploited Vulnerabilities Catalog: https://www.cisa.gov/known-exploited-vulnerabilities-catalog
- WordPress plugin page for Code Engine: https://wordpress.org/plugins/code-engine
- WordPress plugin changeset reference: https://plugins.trac.wordpress.org/changeset/3345666
- Wordfence advisory reference: https://www.wordfence.com/threat-intel/vulnerabilities/id/1a5f970a-e6a0-4dc7-8e99-342a32f5fd49?source=cve
For further reading on software vulnerabilities, check our glossary on what is software composition analysis and explore best practices in vulnerability management.
This article may contain affiliate links. We earn a commission on qualifying purchases at no extra cost to you.