CVE-2024-3564 Overview
The Content Blocks (Custom Post Widget) plugin for WordPress contains a Local File Inclusion (LFI) vulnerability in all versions up to and including 3.3.0. The flaw exists in the plugin's content_block shortcode, which fails to properly validate file paths before inclusion. Authenticated attackers with contributor-level access or above can include and execute arbitrary files on the server. This allows execution of any PHP code contained in those files, including malicious code smuggled inside uploaded images or other file types considered safe. The issue is tracked under CWE-98 (Improper Control of Filename for Include/Require Statement) and CWE-552 (Files or Directories Accessible to External Parties).
Critical Impact
Contributor-level accounts can escalate to full remote code execution on the WordPress host, enabling access control bypass, sensitive data theft, and persistent compromise of the site.
Affected Products
- Vanderwijk Content Blocks (Custom Post Widget) WordPress plugin, all versions up to and including 3.3.0
- WordPress installations exposing the content_block shortcode to contributor-or-higher accounts
- Sites permitting image or media uploads that can be referenced by the vulnerable shortcode
Discovery Timeline
- 2024-06-01 - CVE-2024-3564 published to the National Vulnerability Database (NVD)
- 2026-06-17 - Last updated in NVD database
Technical Details for CVE-2024-3564
Vulnerability Analysis
The Content Blocks plugin registers a content_block shortcode that accepts user-supplied parameters and passes them into a PHP include or require statement. The plugin does not restrict the resolved path to a trusted directory, nor does it enforce a file-extension allowlist before inclusion. Any authenticated user with the edit_posts capability (contributor or higher) can insert the shortcode into a post or page and reference arbitrary local files. When WordPress renders the content, the included file is parsed as PHP, giving the attacker code execution in the context of the web server user.
Because the inclusion happens through PHP's include/require semantics, any file readable by the web server that contains valid PHP tags is executed. Attackers frequently combine LFI with uploaded images that carry embedded PHP payloads in EXIF metadata or file comments, converting a benign upload primitive into full remote code execution.
Root Cause
The root cause is missing input validation and path sanitization on shortcode attributes passed to a file inclusion sink. The plugin trusts author-controlled data and constructs a file path without normalizing traversal sequences or constraining the target to the plugin's own content directory. This maps directly to CWE-98, improper control of a filename used in a PHP include statement.
Attack Vector
An authenticated contributor authors a post that embeds the content_block shortcode with a manipulated attribute pointing to an attacker-controlled or otherwise sensitive file on disk. When the post is previewed or published, WordPress expands the shortcode, and the plugin includes the referenced file. If the file contains PHP, it executes with the privileges of the web server. See the Wordfence Vulnerability Report for additional technical context.
No verified proof-of-concept code is publicly indexed. The exploitation pattern follows the standard WordPress LFI-via-shortcode chain: obtain contributor access, upload or locate a PHP-bearing file, reference it through the vulnerable shortcode, and trigger rendering.
Detection Methods for CVE-2024-3564
Indicators of Compromise
- Post or page content containing the [content_block] shortcode with unusual id, slug, or path-like attributes referencing traversal sequences such as ../ or absolute filesystem paths.
- Recently created contributor or author accounts followed by uploads of image files that contain PHP tags (<?php) in their binary content.
- Web server access logs showing draft-preview or post-render requests immediately followed by outbound connections from the PHP worker process.
- Unexpected PHP files, webshells, or cron entries appearing under wp-content/uploads/ after contributor activity.
Detection Strategies
- Scan the wp_posts table for shortcode invocations that include suspicious path characters or reference files outside the plugin's expected content scope.
- Inspect uploaded media in wp-content/uploads/ for embedded PHP markers using tools such as grep -r '<?php' wp-content/uploads/.
- Correlate low-privilege user authentication events with post creation, media uploads, and subsequent PHP process spawns to surface the LFI chain.
Monitoring Recommendations
- Enable WordPress activity logging to capture post edits, shortcode changes, and role assignments for contributor-tier accounts.
- Monitor the web server process tree for unexpected child processes spawned by php-fpm or the Apache worker when rendering posts.
- Alert on file writes to wp-content/plugins/, wp-content/mu-plugins/, and wp-content/uploads/ outside of scheduled update windows.
How to Mitigate CVE-2024-3564
Immediate Actions Required
- Update the Content Blocks (Custom Post Widget) plugin to a version later than 3.3.0 that includes the vendor fix referenced in the WordPress Plugin Changelog.
- Audit all contributor, author, and editor accounts and remove or reset any that are unused, stale, or unrecognized.
- Review wp-content/uploads/ for PHP-bearing files and remove any that were not placed by legitimate administrators.
- Rotate WordPress secret keys in wp-config.php and force a password reset for privileged users if compromise is suspected.
Patch Information
The vendor addressed the shortcode file inclusion path in the plugin changeset published at the WordPress Plugin Changelog. Site operators should install the latest release from the WordPress plugin directory and verify the installed version is greater than 3.3.0.
Workarounds
- Temporarily deactivate the Content Blocks (Custom Post Widget) plugin until the patched version is deployed.
- Restrict the edit_posts capability so that untrusted contributors cannot create or edit content containing shortcodes.
- Configure PHP to disable execution inside the uploads directory using web server rules that deny .php handling under wp-content/uploads/.
- Enable a web application firewall rule that blocks requests carrying path traversal sequences targeting the content_block shortcode.
# Apache: deny PHP execution inside wp-content/uploads
<Directory "/var/www/html/wp-content/uploads">
<FilesMatch "\.(php|phar|phtml)$">
Require all denied
</FilesMatch>
</Directory>
# Nginx equivalent
location ~* /wp-content/uploads/.*\.(php|phar|phtml)$ {
deny all;
return 403;
}
Disclaimer: This content was generated using AI. While we strive for accuracy, please verify critical information with official sources.

