Analysis Report · Folder Analysis cache/acf-extended_0.9.2.1 → cache/acf-extended_0.9.2.2 — CVE-2025-14533

# Security Analysis: ACF Extended Form User Module

## Vulnerability 1

**Vulnerability Existed:** yes
TRUE POSITIVE

**Privilege Escalation / Insecure Direct Object References - CWE-269 - includes/modules/form/module-form-action-user.php Lines 356-377**

**Old Code:**
```php
// apply tags
$action = $this->setup_action($action, $form);

// switch type
switch($action['type']){
```

**Fixed Code:**
```php
// apply tags
$action = $this->setup_action($action, $form);

// security measure
// check 'promote_users' capability for insert/update administrator role
if($action['type'] === 'insert_user' || $action['type'] === 'update_user'){
    
    // get role as array
    $role = acf_get_array($action['save']['role']);
    
    // check capability
    if((in_array('administrator', $role, true) || in_array('super_admin', $role, true)) && !current_user_can('promote_users')){
        
        // filters
        $validate = true;
        $validate = apply_filters("acfe/form/validate_user_admin_role",                          $validate, $form, $action);
        $validate = apply_filters("acfe/form/validate_user_admin_role/form={$form['name']}",     $validate, $form, $action);
        $validate = apply_filters("acfe/form/validate_user_admin_role/action={$action['name']}", $validate, $form, $action);
        
        // should validate
        if($validate){
            return acfe_add_validation_error('', $errors['generic']);
        }
        
    }
    
}

// switch type
switch($action['type']){
```

**Explanation:**
The original code allowed users to create or update WordPress user accounts with administrator or super_admin roles without checking the `promote_users` capability. This is a privilege escalation vulnerability—an authenticated user without proper permissions could elevate their own account or create new admin accounts. The fix adds a capability check using `current_user_can('promote_users')` before allowing administrator role assignment, with filter hooks for extensibility. This prevents unauthorized privilege escalation while maintaining backward compatibility through filters.

---

## Vulnerability 2

**Vulnerability Existed:** yes
TRUE POSITIVE

**Information Disclosure / User Enumeration - CWE-200 - includes/modules/form/module-form-action-user.php Lines 334-335**

**Old Code:**
```php
$errors = array(
    'empty_user_pass'           => __('An error has occured. Please try again', 'acfe'),
```

**Fixed Code:**
```php
$errors = array(
    'generic'                   => __('An error has occured. Please try again', 'acfe'),
    'empty_user_pass'           => __('Invalid username or password', 'acfe'),
```

**Explanation:**
The original error message was overly generic for all validation failures. The fix introduces a `generic` error message and updates `empty_user_pass` to be more specific ("Invalid username or password"). This prevents user enumeration attacks where attackers could determine valid usernames by observing different error messages for "user not found" vs "wrong password" scenarios. The generic fallback message combined with specific but non-distinguishing messages reduces information leakage while the addition of the dedicated `generic` key suggests error handling now intentionally obscures which validation specifically failed.

---

## Vulnerability 3

**Vulnerability Existed:** not sure

**Insufficient Input Validation - CWE-20 - includes/modules/form/module-form-action-user.php Line 1272**

**Old Code:**
```php
'default_value' => 0,
```

**Fixed Code:**
```php
'default_value' => 1,
```

**Explanation:**
The default value for the validation field changed from disabled (0) to enabled (1). While this appears to be a configuration change to enable validation by default, it's uncertain whether this addresses a security vulnerability or simply changes default behavior. If the previous default of disabled validation allowed unvalidated malicious input to reach user creation functions, enabling validation by default would mitigate that. However, without evidence that the disabled state created actual exploitable conditions, this is classified as uncertain. The accompanying instruction text change ("Automatically validate fields" → "Validate username and email fields") suggests this is primarily a UX/clarity improvement rather than a security fix.