CVE-2024-5503: WP Blog Post Layouts RCE Vulnerability

CVE-2024-5503 Overview

CVE-2024-5503 is a Local File Inclusion (LFI) vulnerability in the WP Blog Post Layouts plugin for WordPress, developed by Codevibrant. The flaw affects all versions up to and including 1.1.3. Authenticated attackers with Contributor-level access or higher can include and execute arbitrary PHP files on the server. This enables execution of any PHP code contained in those files. Attackers can leverage the flaw to bypass access controls, read sensitive data, or achieve code execution when "safe" file types such as images can be uploaded and included. The weakness is tracked under CWE-98: Improper Control of Filename for Include/Require Statement in PHP Program.

Critical Impact
A Contributor-level user can escalate to full PHP code execution on the WordPress host, compromising site integrity, confidentiality, and availability.

Affected Products

Codevibrant WP Blog Post Layouts plugin for WordPress, all versions ≤ 1.1.3
WordPress sites permitting Contributor-level (or higher) account registration
Sites allowing image or other "safe" file uploads that can be referenced by the plugin

Discovery Timeline

2024-06-21 - CVE-2024-5503 published to NVD
2026-06-17 - Last updated in NVD database

Technical Details for CVE-2024-5503

Vulnerability Analysis

The WP Blog Post Layouts plugin exposes PHP include/require operations in which the target file path is derived from user-controlled input without adequate validation. Because the plugin ships multiple layout renderers (grid, list, masonry) and Gutenberg block handlers that reach the same code path, several entry points share the same weakness. An authenticated Contributor can craft plugin block parameters that direct the renderer to load an arbitrary local file. Once included, PHP interprets the referenced file, executing any code it contains. Contributor is a low-privilege WordPress role, which significantly widens the pool of viable attackers on multi-author blogs and community sites.

Root Cause

The plugin passes attacker-influenced values into PHP file-inclusion functions inside includes/gutenberg.php (around lines 883, 900, and 917) and in the element renderers at includes/src/grid/element.php (line 1146), includes/src/list/element.php (line 1136), and includes/src/masonry/element.php (line 1134). These call sites lack a strict allow-list of template paths and do not confine resolution to the plugin's template directory. Any string a Contributor can inject through block attributes reaches the include statement, satisfying the classic CWE-98 pattern.

Attack Vector

The attack is network-reachable through the standard WordPress editor and REST endpoints used by Gutenberg blocks. An attacker first obtains or compromises a Contributor account. They then submit a post or block payload whose layout parameter references a local file path chosen by the attacker, for example a previously uploaded image containing embedded PHP or a sensitive configuration file. When the block is rendered, PHP includes and executes the referenced file, yielding arbitrary code execution in the context of the web server user. See the Wordfence Vulnerability Report and the WordPress Plugin Changeset for the corrected source paths.

No verified public exploit code is available. Refer to the vendor changeset and Wordfence advisory linked above for source-level details.

Detection Methods for CVE-2024-5503

Indicators of Compromise

Unexpected PHP execution originating from wp-content/uploads/ or other user-writable directories.
WordPress posts or blocks authored by Contributor accounts referencing absolute filesystem paths in layout parameters.
New or modified files in the WordPress webroot shortly after a Contributor-level login.
Outbound network connections from the php process to unfamiliar hosts following block rendering.

Detection Strategies

Inspect HTTP request bodies to admin-ajax.php and the REST API for block attributes containing ../, absolute paths, or file extensions such as .php, .phtml, or .jpg.
Alert on file include/require events in PHP where the resolved path is outside the plugin directory wp-content/plugins/wp-blog-post-layouts/.
Correlate Contributor-role authentication events with post-save actions that reference uploaded media as a template.

Monitoring Recommendations

Ingest WordPress access, error, and audit logs into a centralized log platform for retention and query.
Monitor plugin inventory to identify hosts still running WP Blog Post Layouts 1.1.3 or earlier.
Track process lineage under the web server user for unexpected shell, wget, or curl invocations.

How to Mitigate CVE-2024-5503

Immediate Actions Required

Update WP Blog Post Layouts to a version later than 1.1.3 on every affected WordPress site.
Audit Contributor and Author accounts for unfamiliar users and rotate credentials where suspicious activity is found.
Review recently modified PHP files under wp-content/ and remove any unauthorized web shells or backdoors.
Restrict new user registration to trusted personnel until patching is complete.

Patch Information

The vendor addressed the flaw in a plugin update published to the WordPress plugin repository. Refer to the WordPress Plugin Changeset for the specific code changes that constrain file-inclusion paths. Site administrators should apply the update through the WordPress admin dashboard or via WP-CLI.

Workarounds

Disable and remove the WP Blog Post Layouts plugin until it can be updated.
Enforce PHP open_basedir restrictions to constrain file inclusion to the WordPress installation directory.
Configure the web server to deny PHP execution inside wp-content/uploads/.
Deploy a Web Application Firewall rule that blocks block attributes containing suspicious path traversal or absolute file paths.

bash

# Update the plugin via WP-CLI
wp plugin update wp-blog-post-layouts

# Or deactivate and delete if no patched version is deployed yet
wp plugin deactivate wp-blog-post-layouts
wp plugin delete wp-blog-post-layouts

# Deny PHP execution inside uploads (Apache example)
cat <<'EOF' > wp-content/uploads/.htaccess
<FilesMatch "\.(php|phtml|phar)$">
    Require all denied
</FilesMatch>
EOF