Amelia patches externalId IDOR enabling WordPress account takeover

TL;DR — A High-severity IDOR in the WordPress ameliabooking plugin lets low-privileged Provider (Employee) users take over arbitrary WordPress accounts by swapping the externalId user identifier during profile updates.

What happened

Amelia ("Booking for Appointments and Events Calendar – Amelia") is a WordPress scheduling/booking plugin used to manage appointments, staff (providers/employees), and customer bookings.

Wordfence reports that CVE-2026-5465 is an Insecure Direct Object Reference (IDOR) in Amelia’s provider profile update path: the UpdateProviderCommandHandler does not validate changes to the externalId field when a Provider (Employee) updates their own profile. Per the advisory, externalId maps to a WordPress user ID and is passed to wp_set_password() and wp_update_user() without authorization checks, enabling a Provider user to target other users’ accounts.

This is operationally high impact for platform teams because it turns a common “staff account” role into a site-wide credential reset primitive, and WordPress admin takeover is typically a direct pivot into persistent code execution (plugin/theme edits, webshell upload chains, or malicious admin creation).

Who is impacted

• WordPress sites running the Amelia plugin (ameliabooking) in versions <= 2.1.3.
• Sites where untrusted users can obtain or retain Provider/Employee accounts (e.g., large multi-staff scheduling deployments, outsourced staff onboarding, shared accounts, or compromised low-privilege credentials).
• Any deployment where a Provider account has network reach to the vulnerable profile update functionality (as implied by AV:N and PR:L in the CVSS vector).

What to do now

• Follow vendor remediation guidance and apply the latest patched release available at the time of writing.

  "Update to version 2.2, or a newer patched version"

• Inventory production sites for ameliabooking (plugin lists, Composer/SBOM if embedded into images, and WordPress fleet management tooling) and prioritize instances that expose staff/provider logins.
• Treat this as a potential account-compromise scenario:
  • review audit trails for unexpected password resets and profile updates by Provider/Employee users
  • look for anomalous changes to Provider profiles where externalId could have been manipulated
• Reduce blast radius while rolling out updates:
  • restrict who can be a Provider/Employee and remove stale accounts
  • enforce strong auth (unique accounts, MFA where supported) for staff roles that can access administrative plugin flows
• If compromise is suspected, rotate credentials reachable from the WordPress admin context (e.g., SMTP/API keys stored in WordPress, integration tokens, and database/admin credentials as applicable to your environment).