Brief Summary: CVE-2026-3243 Arbitrary File Deletion in Advanced Members for ACF WordPress Plugin

Introduction

A path traversal flaw in the Advanced Members for ACF WordPress plugin lets any authenticated user with Subscriber privileges delete arbitrary files on the server. That includes critical configuration files, and deleting them can lead to full site takeover. The vulnerability is tracked as CVE-2026-3243 with a CVSS score of 8.8, and it shows how a single unsanitized input in a file-handling function can undermine an entire WordPress installation.

Advanced Members for ACF is a lightweight membership plugin from danbilabs, built for sites that use Advanced Custom Fields (ACF). It has a small footprint, with approximately 30 active installations. Its integration with ACF still places it in the wider WordPress ecosystem, where even niche plugins can introduce significant risk if they handle file operations insecurely.

Technical Information

Root Cause: Unsanitized File Paths in create_crop

The vulnerability is in the create_crop function in class-avatar.php. The cause is simple. User-supplied file paths from the $image_data['file'] parameter were concatenated directly into a filesystem path with zero sanitization.

In the vulnerable version (1.2.4), the code looked like this:

// VULNERABLE (v1.2.4, line 641)
$file = amem()->files->upload_temp . DIRECTORY_SEPARATOR . $image_data['file'];

An attacker could supply a value like ../../wp-config.php as the file parameter. The plugin would resolve this to a path outside the intended avatar upload directory and then delete the targeted file. This is a textbook CWE-22 (Path Traversal) vulnerability.

Compounding Factor: Open REST API Endpoints

The REST API permission model made the problem worse. In the vulnerable version, all three REST API routes (/upload, /crop, /cancelCrop) used a completely open permission callback:

function(){ return true; }

Any caller could reach these endpoints, including unauthenticated visitors. Combined with the path traversal in create_crop, that left a remarkably low barrier to exploitation.

Attack Flow

1. The attacker registers or compromises a WordPress account with at least Subscriber-level access. Because the REST API permission callbacks were open, even unauthenticated access may have been possible in some configurations.

2. The attacker sends a request to the crop or cancel crop REST API endpoint, with a path traversal payload in the file parameter (e.g., ../../wp-config.php).

3. The plugin concatenates the unsanitized input with the upload temp directory path, which resolves to the target file. It then deletes that file as part of its normal avatar processing workflow.

4. With wp-config.php deleted, WordPress enters its installation setup state. The attacker can then reconfigure the site with their own database credentials and gain full administrative control, which effectively amounts to remote code execution.

The attack vector is network-based (AV:N) and needs no user interaction (UI:N), so the flaw suits automated exploitation once the attacker has a valid session.

Additional Vulnerable Patterns

The same unsanitized path concatenation existed in the rest_api_cancel_crop_callback() method, which used the $params['file'] parameter to build a file path for deletion without any validation. The $image_data['id'] value, used to generate output filenames, was not sanitized either.

Researcher Muhammad Yudha (DJ) discovered the vulnerability.

Patch Information

The vulnerability was fully patched in version 1.2.6, released through the WordPress plugin repository (changeset 3492372). Version 1.2.5 attempted a partial fix (changeset 3479725), but it was incomplete. Comparing the vulnerable source (tag 1.2.4) with the patched source (tag 1.2.6) shows five distinct fixes.

1. Path Traversal Sanitization on File Inputs

The patch applies wp_basename() to strip all directory components, then uses a regex to remove any remaining slash characters:

// PATCHED (v1.2.6)
$safe_file = wp_basename( $image_data['file'] );
$safe_file = preg_replace('/[\/\\\\]/', '', $safe_file);
$file = amem()->files->upload_temp . DIRECTORY_SEPARATOR . $safe_file;

The same two-step sanitization was also applied to the $image_data['id'] value and to the $params['file'] parameter inside rest_api_cancel_crop_callback().

2. realpath() Containment Check

As a defense-in-depth measure, the patch adds a realpath() check that confirms the resolved destination file path stays inside the expected avatar upload directory:

// PATCHED (v1.2.6) — added after new_file is constructed
$avatar_base = realpath($this->get_avatar_dir());
if ( $avatar_base ) {
    $real_dir_path = realpath(dirname($new_file));
    if ( $real_dir_path ) {
        $real_path = $real_dir_path . DIRECTORY_SEPARATOR . wp_basename($new_file);
        if ( strpos($real_path, $avatar_base) !== 0 ) {
            wp_send_json(__('Invalid file path', 'advanced-members'), 400);
        }
    }
}

If the resolved path does not start with the avatar base directory, the plugin rejects the request with a 400 error.

3. REST API Permission Callback Hardened

The open function(){ return true; } callbacks were replaced with a dedicated rest_api_permission_check() method that verifies a WordPress nonce:

// PATCHED (v1.2.6)
'permission_callback' => [$this, 'rest_api_permission_check'],

// New method:
public function rest_api_permission_check(\WP_REST_Request $request) {
    $nonce = $request->get_header('X-AMem-Avatar-Nonce');
    if ( empty($nonce) ) {
        return false;
    }
    return (bool) wp_verify_nonce($nonce, 'amem-avatar');
}

4. User Ownership Validation

The vulnerable code trusted the user-supplied uid parameter and never checked that the requesting user was working on their own avatar. The patch adds explicit ownership checks. Default avatar operations are restricted to administrators, logged-in users can only modify their own avatar (unless they are admins), and unauthenticated callers can no longer specify numeric user IDs.

5. SSRF Mitigation

When the source image file was not found locally, create_crop() fell back to fetching it from a user-supplied URL with wp_remote_get(). The patch switches this to wp_safe_remote_get(), which applies WordPress's built-in protections against Server-Side Request Forgery. The JSON response also used to leak the absolute server filesystem path, and it now returns a relative path instead.

Users should update to at least version 1.2.6, or preferably the latest available version (currently 1.2.7).

Affected Systems and Versions

Do not treat version 1.2.5 as a safe place to stop, because the patch in that release was incomplete. Only version 1.2.6 and later contain the full set of fixes.

Vendor Security History

Before CVE-2026-3243, the Advanced Members for ACF plugin had no documented history of security vulnerabilities. The scope of the fixes in version 1.2.6 (open REST API callbacks, no nonce verification, missing ownership validation, SSRF exposure, and server path leakage) suggests that security was not a primary design consideration in earlier versions. The vendor responded proactively to the disclosure. Version 1.2.6 shipped with comprehensive hardening, and danbilabs followed it with version 1.2.7 to address additional Plugin Check Program coding standards.

References

• NVD: CVE-2026-3243
• Wordfence Threat Intel: Advanced Members for ACF Arbitrary File Deletion
• Advanced Members for ACF on WordPress.org
• Vulnerable Source: class-avatar.php (tag 1.2.4)
• Patched Source: class-avatar.php (tag 1.2.6)
• Vulnerable Source: class-avatar.php Line 266
• Vulnerable Source: class-avatar.php Line 57
• Patched Source: class-avatar.php (trunk) Line 710
• Changeset 3479725 (Partial Fix, v1.2.5)
• Changeset 3492372 (Full Fix, v1.2.6)