CVE-2024-6823: Media Library Assistant RCE Vulnerability

CVE-2024-6823 Overview

The Media Library Assistant plugin for WordPress contains an arbitrary file upload vulnerability affecting all versions up to and including 3.18. The flaw resides in the mla-inline-edit-upload-scripts AJAX action, which fails to validate uploaded file types. Authenticated attackers with Author-level access or higher can upload arbitrary files to the server. Successful exploitation can lead to remote code execution on the affected WordPress site. The vulnerability is tracked under [CWE-434] Unrestricted Upload of File with Dangerous Type.

Critical Impact
Author-level users can upload executable files such as PHP scripts through the vulnerable AJAX handler, enabling remote code execution and full site compromise.

Affected Products

Davidlingren Media Library Assistant plugin for WordPress, versions ≤ 3.18
WordPress sites permitting Author-level user registration or with compromised Author accounts
Any deployment using the mla-inline-edit-upload-scripts AJAX handler

Discovery Timeline

2024-08-13 - CVE-2024-6823 published to NVD
2026-06-17 - Last updated in NVD database

Technical Details for CVE-2024-6823

Vulnerability Analysis

The Media Library Assistant plugin exposes an AJAX endpoint named mla-inline-edit-upload-scripts that processes file uploads without enforcing file type restrictions. WordPress plugins typically validate MIME types and extensions before persisting uploaded content. The vulnerable handler skips this validation entirely, allowing any file extension to be written to the server.

An authenticated attacker with the edit_posts capability, granted to the Author role by default, can invoke the AJAX action. The endpoint accepts the uploaded content and stores it within a location reachable via HTTP. When the uploaded file is a PHP script or another server-executable format, the attacker can trigger execution by requesting the file directly.

The root vulnerability class is Unrestricted File Upload [CWE-434]. Refer to the Wordfence Vulnerability Analysis and the WordPress Plugin Code Reference for handler-level details.

Root Cause

The mla-inline-edit-upload-scripts AJAX handler in class-mla-settings.php does not call WordPress file-type validation functions such as wp_check_filetype_and_ext() before writing uploads to disk. The absence of an allow-list for extensions and MIME types converts a plugin administration feature into an arbitrary write primitive.

Attack Vector

Exploitation is remote and requires authenticated Author-level access. The attacker sends a POST request to the WordPress admin-ajax.php endpoint with action=mla-inline-edit-upload-scripts and a multipart file payload containing an executable script. The plugin writes the file to a web-accessible directory. The attacker then requests the resulting URL to execute the payload in the PHP context of the web server.

The vulnerability manifests entirely within the plugin's AJAX handler; no user interaction is required beyond the authenticated request. See the WordPress Plugin Changeset Log for the patched code path.

Detection Methods for CVE-2024-6823

Indicators of Compromise

Requests to /wp-admin/admin-ajax.php containing action=mla-inline-edit-upload-scripts originating from Author-level accounts
New .php, .phtml, .phar, or other executable files appearing under plugin or upload directories with recent modification timestamps
Outbound network connections initiated by the web server process shortly after upload activity
Unexpected creation of scheduled tasks, cron entries, or new WordPress administrator accounts following an upload event

Detection Strategies

Inspect web server access logs for POST requests to admin-ajax.php referencing the vulnerable AJAX action and correlate with the requesting user ID
Baseline the wp-content/uploads and plugin directories and alert on the introduction of files with server-executable extensions
Deploy a Web Application Firewall (WAF) rule that blocks uploads containing PHP signatures on the vulnerable action parameter
Review WordPress audit logs for uploads performed by Author accounts that deviate from historical behavior

Monitoring Recommendations

Enable file integrity monitoring across the WordPress webroot to detect writes of executable content
Forward web server, PHP-FPM, and WordPress audit logs to a centralized platform for cross-correlation
Alert on PHP interpreter invocations that spawn shells, network utilities, or package managers under the web server user
Monitor the creation of new privileged WordPress users following any upload event by non-administrator accounts

How to Mitigate CVE-2024-6823

Immediate Actions Required

Update the Media Library Assistant plugin to version 3.19 or later, which addresses the missing file type validation
Audit all Author-level and higher accounts and rotate credentials that show unexpected activity
Inspect wp-content for unauthorized .php or other executable files created since the plugin was installed
Restrict access to wp-admin/admin-ajax.php at the WAF layer for actions that are not required in production

Patch Information

The vendor addressed the vulnerability in the plugin update referenced by the WordPress Plugin Changeset Log. The fix introduces file type validation on the mla-inline-edit-upload-scripts AJAX handler. Administrators should apply the update through the WordPress plugin manager and verify the installed version is greater than 3.18.

Workarounds

Temporarily deactivate the Media Library Assistant plugin until the patched version can be deployed
Restrict Author role assignments and disable open user registration on affected sites
Configure the web server to deny PHP execution within wp-content/uploads and other user-writable directories
Deploy WAF signatures that block multipart uploads containing PHP tags to the mla-inline-edit-upload-scripts action

bash

# Deny PHP execution within WordPress uploads (Apache .htaccess example)
<FilesMatch "\.(php|phtml|phar|php3|php4|php5|php7|phps)$">
    Require all denied
</FilesMatch>

# Nginx equivalent snippet for the uploads location
location ~* /wp-content/uploads/.*\.(php|phtml|phar)$ {
    deny all;
    return 403;
}