The importer never asked who was promoting whom.

WordPress does not treat "create a user" and "promote a user to administrator" as the same permission. Core maps them to distinct capabilities — create_users, promote_users, edit_users — and adds a hard rule that a non-administrator can never edit or elevate an administrator. A bulk-import feature is only safe if it re-checks those same capabilities for the person clicking Import.

A user who holds only the user-creation capability must not be able to assign the administrator role, nor edit an account that already holds it.

The bug was not that the plugin could import users. The bug was that the import path trusted the CSV's role, user_pass and target-identity columns as data, while WordPress core treats acting on those same fields as privileged operations gated by the current user's capabilities.

The import handler confirmed the actor could reach the import screen and create users, then looped over rows and called WordPress's user APIs with the CSV's own field values. What it never did was re-map the role change or the edit of an existing account against the acting user — the check core performs on every admin-screen equivalent.

import screen:
  require current_user_can('create_users')   // gate present

per row:
  role      = row['role']            // taken verbatim
  target    = existing user? update : insert
  wp_insert_user([... 'role' => role])       // no promote_users check
  wp_update_user([... 'user_pass' => row['user_pass'],
                      'user_email' => row['user_email']])
                                             // no edit_user(target) check

// missing: current_user_can('promote_users')
// missing: current_user_can('edit_user', target_admin_id)

Core's own map_meta_cap() would have refused both operations for a lesser role: promoting to administrator requires promote_users, and editing an existing administrator is denied outright to anyone who is not one. By calling the low-level functions directly, the importer skipped the layer that enforces those rules.

The finding was promoted only after the vulnerable path, the negative control and the fixed control were retained together against the same actor and site.

A capability check that guards the screen is not the same as a capability check that guards the operation. The import screen asked "can this user create accounts?" and then performed operations — promotion, and editing an administrator — that demand far stronger permissions.

The durable engineering rule is that bulk and API paths must re-map every privileged field against the acting user with the same current_user_can() checks the interactive path uses. A CSV column is attacker-controlled input, not an authorization decision.

WPScan scores CVE-2026-16534 at 7.2 High on CVSS 3.1. The PR:H term reflects that the attacker must already hold a privileged role — one with import access and user creation — not that the impact is limited. Once that foothold exists, confidentiality, integrity and availability are all fully compromised at the administrator level.

CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:U/C:H/I:H/A:H

The realistic actor is an inside role or a lower-tier account on a multi-author, membership, e-commerce or LMS site — exactly the deployments that hand out custom roles with user-management slices. Any such role that can reach this import screen becomes an administrator on demand.

Marketed as Import and Export Users and Customers. Sites that never delegate user management to a non-administrator role are not directly exploitable, but should still upgrade.

The fix is not "block the administrator string in CSV." The durable rule is that the import must authorize each privileged field against the acting user exactly as the interactive path does.

1. Upgrade to Import and Export Users and Customers 2.4.2 or later.
2. Enforce current_user_can('promote_users') before honoring any role in a row, and reject or downgrade rows that request roles the actor cannot grant.
3. Enforce a per-target edit check (current_user_can('edit_user', $id)) before updating an existing account, so administrators cannot be edited by lesser roles.
4. Until patched, restrict the import screen to full administrators and audit custom roles that carry create_users or list-user capabilities.
5. Review recently created administrators and any unexpected email/password changes on existing admin accounts.

The bug lived between two ideas of "who can do this." WordPress core said a lesser role may not promote users or touch an administrator. The plugin said, in effect, "if you reached the import screen, your rows are trusted." A CSV column carried the privileged instruction across that gap.

The CVE is the identifier. The admin-screen negative control is what proved the role boundary was real before the import erased it.

1. WPScan / WPVDB record for CVE-2026-16534
2. NVD record for CVE-2026-16534
3. Import and Export Users and Customers plugin page
4. WordPress map_meta_cap() — promote_users / edit_users mapping
5. WordPress wp_insert_user() reference

Credit: Discovered and reported by Charles Vosburgh. Research was AI-assisted through source mapping, hypothesis generation, runtime construction and skeptical validation; final review and disclosure ownership remained human.