CVE-2026-77705

Executive Summary

CVE-2026-77705 is an authorization flaw in the "Booking for Appointments and Events Calendar" (Amelia) WordPress plugin affecting all versions before 2.4.10. The plugin fails to verify that an authenticated user editing a customer or employee record is entitled to modify the WordPress user account linked to that record. A low-privileged actor holding Amelia's customer or employee management permissions can therefore overwrite the password and email address of arbitrary WordPress accounts that are linked to Amelia records, resulting in full account takeover. This vulnerability is unpatched according to all tracked sources and no public proof-of-concept, exploit code, or Nuclei template currently exists.

Technical Analysis

Vulnerability Class

This is a horizontal privilege escalation / authorization bypass issue rooted in improper access control (CWE-639 / CWE-269). The core defect is a missing or insufficient ownership/entitlement check in the plugin's record-editing workflow.

In WordPress multiuser deployments, the plugin associates customer and employee records with underlying WP_User objects. This linkage allows the plugin to synchronize profile data — notably the user's email address and password — between the Amelia record and the WordPress account. The NVD description explicitly identifies that the plugin "does not verify that the user editing a customer or employee record is entitled to modify the WordPress account linked to it."

Attack Surface

• Entry point: The plugin's customer or employee management interface, reachable by any authenticated user who holds Amelia's customer-management or employee-management capabilities.
• Preconditions: The attacker must (1) be authenticated to WordPress, and (2) hold the plugin's customer or employee management permission. Both are routine for staff-level roles in many WordPress booking/CRM deployments (receptionists, appointment coordinators, support staff).
• Target of manipulation: The WordPress account linked to the edited customer or employee record — specifically its email address and password.

Mechanism

The flaw is a failure to enforce object-level authorization across the boundary between the plugin's own record model and the linked WP_User object. When a user with Amelia management permissions edits a record, the plugin propagates the supplied email and password to the linked WordPress account without confirming that the editor has authority over that WordPress account. Because the WordPress account is a distinct security principal with higher or broader privileges than the Amelia record editor, this creates a privilege boundary crossing.

The result is a password and email overwrite primitive: the attacker sets a known password on the victim's WordPress account and can also reroute the account's email address, potentially capturing password-reset flows and obscuring recovery. The victim account need not be owned or managed by the attacker in any legitimate sense — only linked to a customer or employee record the attacker is permitted to edit.

Why CVSS Is Unscored

No CVSS vector is published in the intelligence feed, and FIRST.org has not produced an EPSS score. The vector shown in METADATA is an analyst estimate and must be labeled as such in any downstream use. It assumes network attack vector, low complexity, low privileges required, no user interaction, and high confidentiality/integrity/availability impact — consistent with full account takeover of an arbitrary linked WordPress user.

Patch Status

The description references version 2.4.10 as the fixed baseline, yet the tracked patch sources are empty and patch confidence is 0/4. There is no confirmed vendor advisory, changelog entry, or code commit available in the provided data. Administrators should not assume 2.4.10 exists or is deployed; they must independently verify the patched release with the vendor before relying on it.

Exploitation Scenarios

No public PoC, exploit code, or Nuclei template is available. The attack chain below is inferred from the vulnerability class and the NVD description; it deliberately avoids inventing function names, API parameters, endpoints, or file paths that do not appear in the source data.

Step 1 — Reconnaissance and Target Identification

The attacker authenticates with any WordPress account that holds Amelia's customer or employee management permission. They enumerate customer or employee records through the plugin's administrative interface, identifying records linked to higher-value WordPress accounts (administrators, editors, shop managers, or other privileged users).

Step 2 — Triggering the Flaw

The attacker opens a customer or employee record that is linked to a victim WordPress account. Because the plugin does not verify entitlement to modify the linked WordPress account, the record-editing workflow accepts changes to the account's email address and password fields.

Step 3 — Payload / Record Manipulation (Vulnerability-Class Level)

The attacker submits modified values for the victim account's email address and password through the record-editing interface. The plugin propagates these values to the linked WP_User object. No special tooling is required beyond the plugin's own legitimate UI — the vulnerability is a logic/authorization flaw, not a memory-safety or injection flaw, so no crafted payload or encoding tricks are necessary.

Step 4 — Post-Exploitation Impact

With the password overwritten, the attacker authenticates directly as the victim WordPress user. If the victim held elevated roles, this yields full control of the WordPress site — content manipulation, plugin/theme installation, arbitrary user creation, and potential remote code execution through the plugin/theme editor or uploaded components. Optionally, the attacker changes the account email to intercept reset links and slow incident response. Restoring the original account owner then requires out-of-band administrative recovery.

Impact Assessment

Business impact: Full account takeover of arbitrary linked WordPress users from a low-privileged plugin role. In booking/CRM deployments — where staff routinely hold customer and employee management permissions — this represents a systemic escalation path from "appointment coordinator" to "site administrator."

Affected systems: Any WordPress installation running Amelia (Booking for Appointments and Events Calendar) before 2.4.10 in which customer or employee records are linked to WordPress accounts. Installations using Amelia solely as a standalone booking tool with no WordPress account linkage may be less exposed, but this cannot be assumed without source review.

Blast radius: The set of WordPress accounts linked to Amelia customer or employee records. Because the plugin commonly links accounts for staff and repeat customers, the potentially exposed account population can be large. Compromise of a single site administrator linked to an Amelia record yields compromise of the entire WordPress site.

CVSS subscores (estimated — not authoritative):

• Confidentiality: High — attacker gains the victim's full account access and associated data.
• Integrity: High — password and email of the victim account are attacker-controlled.
• Availability: High — the legitimate owner is locked out until administrative recovery.
• Privileges Required: Low — requires only the plugin's customer/employee management permission.
• User Interaction: None — no victim action is required.

CISA KEV: Not listed. EPSS: Not scored (do not fabricate). Exploit availability: None public.

Detection Guidance

Because this is an authorization logic flaw, network-only signatures are weak. The rule set below detects the consequences — anomalous password/email changes on linked accounts, and suspicious access to the plugin's management surfaces — rather than the flaw itself. Rules must be tuned to each environment's baseline; the thresholds shown are illustrative.

Sigma Rule

title: Amelia Plugin Linked WordPress Account Email or Password Modification
id: 8f2c1a44-7770-5cve-9b01-amelia0001
status: experimental
description: Detects modification of a WordPress user account's email or password in proximity to Amelia customer/employee record edits, consistent with CVE-2026-77705 account takeover via missing entitlement check.
references:
  - https://nvd.nist.gov/vuln/detail/CVE-2026-77705
author: valtersit.com
date: 2026/01/01
logsource:
  product: wordpress
  service: audit
detection:
  selection_email:
    event_type: 'user_updated'
    field_changed: 'user_email'
  selection_pass:
    event_type: 'user_updated'
    field_changed: 'user_pass'
  selection_actor:
    actor_capability|contains:
      - 'amelia'
      - 'manage_customers'
      - 'manage_employees'
  condition: (selection_email or selection_pass) and selection_actor
falsepositives:
  - Legitimate self-service profile changes by the account owner
  - Administrative bulk user maintenance
level: high
tags:
  - attack.t1098
  - attack.t1078.004

YARA Rule

rule CVE_2026_77705_Amelia_Account_Takeover
{
    meta:
        author = "valtersit.com"
        description = "Flags Amelia plugin files referencing the fixed 2.4.10 baseline and account-link editing logic for CVE-2026-77705 triage"
        reference = "https://nvd.nist.gov/vuln/detail/CVE-2026-77705"
        date = "2026-01-01"
        severity = "high"

    strings:
        $plugin = "ameliabooking" ascii nocase
        $cal    = "Booking for Appointments and Events Calendar" ascii nocase
        $link1  = "wp_user" ascii nocase
        $link2  = "user_pass" ascii nocase
        $link3  = "user_email" ascii nocase
        $ver    = /Version:\s*2\.[0-4]\.[0-9]/ ascii

    condition:
        $plugin and $cal and $ver and 2 of ($link*)
}

Note: this rule is a file-inventory aid for identifying vulnerable Amelia installs. Because the vulnerability is a server-side logic flaw, YARA cannot reliably detect exploitation itself.

Suricata IDS Rule

alert http any any -> any any (msg:"CVE-2026-77705 Amelia Plugin Linked WordPress Account Password/Email Modification"; flow:established,to_server; http.method; content:"POST"; http.uri; content:"amelia"; nocase; http.uri; content:"/wp-admin/admin-ajax.php"; nocase; http.request_body; content:"user_pass"; nocase; http.request_body; content:"user_email"; nocase; threshold:type both, track by_src, count 5, seconds 60; classtype:attempted-user; sid:7770501; rev:1;)

This signature targets POSTs to the plugin's admin-ajax surface carrying both user_pass and user_email in the body. It will generate false positives on legitimate profile updates and must be tuned to the environment; the URI substrings are provided as illustrative anchors, not confirmed plugin endpoints from the source data.

Elastic Detection

sequence by user.name with maxspan=60s
  [ any where event.action == "user_updated" and
      event.category == "iam" and
      process.name : "*wp*" and
      /* actor holds Amelia management capability */
      user.roles : ("amelia_manager", "amelia_customer_manager", "amelia_employee_manager") ]
  [ any where event.action == "user_password_reset" or
      (event.action == "user_updated" and
        (event.category == "iam" and
         (user.changes.email != null or user.changes.password != null))) ]

EQL sequence correlates an Amelia-management session with a subsequent target-account password reset or email change within a 60-second window. Field names reflect ECS conventions and must be mapped to the actual audit pipeline.

Splunk SPL Query

index=wordpress sourcetype=wp_audit OR sourcetype=wordpress_audit
(event_type=user_updated OR action=update_user)
(field_changed=user_pass OR field_changed=user_email OR message=*user_pass* OR message=*user_email*)
| eval actor_caps=lower(coalesce(user_capabilities, capabilities, ""))
| where match(actor_caps, "amelia|manage_customers|manage_employees")
| stats count min(_time) as first_seen max(_time) as last_seen
        values(field_changed) as fields_changed
        values(target_user) as targets
        by src_ip, actor, user
| where count >= 1
| convert ctime(first_seen) ctime(last_seen)
| sort - count

Wazuh OSSEC Rule

<group name="wordpress,web,">
  <rule id="777050" level="12">
    <decoded_as>json</decoded_as>
    <field name="event_type">^user_updated$</field>
    <field name="field_changed">^user_(pass|email)$</field>
    <field name="actor_capability">amelia|manage_customers|manage_employees</field>
    <description>CVE-2026-77705: WordPress user email/password changed by Amelia customer/employee manager (potential account takeover).</description>
    <mitre>
      <id>T1098</id>
      <id>T1078.004</id>
    </mitre>
    <options>no_full_log</options>
  </rule>
</group>

Mitigation & Patch Guidance

Patch confidence: 0/4 (UNPATCHED — no patch evidence from any tracked source). The NVD description references 2.4.10 as the fixed baseline, but no vendor advisory, changelog, or commit has been confirmed. Verify independently before treating 2.4.10 as patched.

1) Immediate Mitigations

• Restrict Amelia management capabilities. Audit which roles hold the plugin's customer and employee management permissions. Remove these capabilities from any role that does not strictly require them. This directly closes the access path described in the CVE.
• Separate plugin roles from WordPress accounts. Where the plugin allows standalone records (no linked WP_User), avoid linking customer/employee records to privileged WordPress accounts (administrators, editors, shop managers).
• Harden administrator accounts. Ensure site administrators are not linked to Amelia customer or employee records that lower-privileged staff can edit.
• Monitor and alert on account changes. Enable audit logging for WordPress user email/password changes and alert on any change performed by a user holding Amelia management permissions (see Detection Guidance).
• Virtual patching. Where available from a WAF or WordPress security plugin vendor, deploy rules that block or flag POST requests to the plugin's admin-ajax surface that carry both user_pass and user_email parameters.
• Force session review. If compromise is suspected, invalidate all active WordPress sessions and rotate credentials for potentially linked accounts.

2) Patch / Upgrade Steps

1. Confirm the current Amelia plugin version via the WordPress admin Plugins list or read the plugin header directly.
2. Contact the vendor (Amelia) or check the plugin's official changelog to confirm that 2.4.10 exists and is the security release addressing CVE-2026-77705.
3. Take a full site backup (files and database) before upgrading.
4. Upgrade to 2.4.10 or later using the WordPress plugin updater, or manually via a trusted, checksum-verified package.
5. After upgrading, rotate passwords for any WordPress accounts linked to Amelia customer or employee records, and review account email addresses for unauthorized changes.
6. Re-verify that the fixed release is actually deployed — do not rely on the version string alone if the vendor advisory cannot be obtained.

3) Long-Term Hardening

• Least privilege. Operate a strict RBAC model: never grant plugin management capabilities to roles that also hold, or can reach, administrative WordPress accounts.
• Account-link hygiene. Treat any plugin-to-WordPress account linkage as a security-relevant trust relationship; document it and restrict who can edit it.
• Continuous audit logging. Ship WordPress user-object changes to a central SIEM and alert on cross-boundary modifications.
• Routine patch cadence and SBOM. Track third-party WordPress plugins in an inventory with version pinning and prompt patching.
• Defense in depth. Deploy a WAF, enable WordPress two-factor authentication for all privileged accounts, and limit admin-ajax exposure where feasible.

References

• NVD — CVE-2026-77705: https://nvd.nist.gov/vuln/detail/CVE-2026-77705
• FIRST.org EPSS: No score yet — https://api.first.org/data/v1/epss?cve=CVE-2026-77705
• CISA Known Exploited Vulnerabilities catalog: Not listed — https://www.cisa.gov/known-exploited-vulnerabilities-catalog
• Vendor (Amelia / Booking for Appointments and Events Calendar): No advisory confirmed in tracked sources. Administrators should check the official plugin page and changelog directly.
• MITRE ATT&CK — T1098 (Account Manipulation): https://attack.mitre.org/techniques/T1098/
• MITRE ATT&CK — T1078.004 (Valid Accounts: Cloud Accounts): https://attack.mitre.org/techniques/T1078/004/
• CWE-639 (Authorization Bypass Through User-Controlled Key): https://cwe.mitre.org/data/definitions/639.html

Threat actor / exploit-in-the-wild evidence: None available. No public PoC, exploit code, or Nuclei template exists, and the CVE is not in the CISA KEV catalog. All exploitability assessment in this report is derived from the vulnerability class and the NVD description only.