CVE-2026-14311: Amelia WP Plugin: missing ownership check exposes customers
MEDIUMAmelia Premium for WordPress (up to 2.4.4) fails to verify ownership on its /users/customers/<id> endpoint, so any authenticated user with the wpamelia-provider (employee) role can read and modify arbitrary customer records, including triggering password resets. Because a reset can be chained into takeover of linked WordPress accounts up to Editor level, the practical impact goes beyond the booking data itself. Exposure is limited: it affects only the Premium edition with the Employee Panel, it requires a valid low-privilege account, and the CVSS is 5.4 (medium). EPSS is low in absolute terms (0.17%) although it sits in the 94th percentile, there is no public exploit or Nuclei template, it is not in CISA KEV, and the SSVC decision is TRACK. This is a general WordPress plugin with no meaningful AI/ML component, so treat it as a routine web-application patch rather than an AI-security priority. Upgrade to the fixed version above 2.4.4 per the vendor changeset, and review provider accounts and recent customer password resets.
What is the risk?
Medium. Exploitation is network-based and low complexity, but requires an authenticated wpamelia-provider account and only affects the Premium version with the Employee Panel. Confidentiality and integrity impacts are low (C:L/I:L), with no availability impact. No public exploit, no Nuclei template, not in KEV; SSVC says TRACK. The main escalation path is account takeover of WordPress users up to Editor who have made an Amelia booking. AI relevance is minimal (classified ml_ui, but the product is a booking calendar with no identified AI/ML function).
How does the attack unfold?
How severe is it?
What is the attack surface?
What should I do?
1 step1) Update Amelia Premium to the patched release above 2.4.4 (see the WordPress plugin changeset 3614392 and the Wordfence advisory). 2) Until patched, disable or restrict the Employee Panel and audit all accounts holding the wpamelia-provider role. 3) Review logs for requests to /users/customers/<id> by provider-role users and for unexpected customer password resets or email changes. 4) Force password resets for WordPress users with Editor or lower roles who have Amelia bookings if suspicious activity is found. 5) Enforce MFA on WordPress accounts and apply a WAF rule limiting access to the Amelia REST endpoints.
What does CISA's SSVC say?
Source: CISA Vulnrichment (SSVC v2.0). Decision based on the CISA Coordinator decision tree.
How is it classified?
Which compliance frameworks are affected?
This CVE is relevant to:
Frequently Asked Questions
What is CVE-2026-14311?
Amelia Premium for WordPress (up to 2.4.4) fails to verify ownership on its /users/customers/<id> endpoint, so any authenticated user with the wpamelia-provider (employee) role can read and modify arbitrary customer records, including triggering password resets. Because a reset can be chained into takeover of linked WordPress accounts up to Editor level, the practical impact goes beyond the booking data itself. Exposure is limited: it affects only the Premium edition with the Employee Panel, it requires a valid low-privilege account, and the CVSS is 5.4 (medium). EPSS is low in absolute terms (0.17%) although it sits in the 94th percentile, there is no public exploit or Nuclei template, it is not in CISA KEV, and the SSVC decision is TRACK. This is a general WordPress plugin with no meaningful AI/ML component, so treat it as a routine web-application patch rather than an AI-security priority. Upgrade to the fixed version above 2.4.4 per the vendor changeset, and review provider accounts and recent customer password resets.
Is CVE-2026-14311 actively exploited?
No confirmed active exploitation of CVE-2026-14311 has been reported, but organizations should still patch proactively.
How to fix CVE-2026-14311?
1) Update Amelia Premium to the patched release above 2.4.4 (see the WordPress plugin changeset 3614392 and the Wordfence advisory). 2) Until patched, disable or restrict the Employee Panel and audit all accounts holding the wpamelia-provider role. 3) Review logs for requests to /users/customers/<id> by provider-role users and for unexpected customer password resets or email changes. 4) Force password resets for WordPress users with Editor or lower roles who have Amelia bookings if suspicious activity is found. 5) Enforce MFA on WordPress accounts and apply a WAF rule limiting access to the Amelia REST endpoints.
What systems are affected by CVE-2026-14311?
This vulnerability affects the following AI/ML architecture patterns: WordPress booking plugins, Web application back-ends.
What is the CVSS score for CVE-2026-14311?
CVE-2026-14311 has a CVSS v3.1 base score of 5.4 (MEDIUM). The EPSS exploitation probability is 0.24%.
What is the AI security impact?
Affected AI Architectures
MITRE ATLAS Techniques
AML.T0012Valid AccountsCompliance Controls Affected
What are the technical details?
Original Advisory
The Booking for Appointments and Events Calendar – Amelia plugin for WordPress is vulnerable to unauthorized access and modification of data due to a missing ownership verification on /users/customers/<id> endpoint in all versions up to, and including, 2.4.4. This makes it possible for authenticated attackers, with wpamelia-provider role, to view and modify arbitrary customers, including password reset. Takeover of WordPress user accounts, with the roles up to Editor, is also possible if that user had made an Amelia booking. This vulnerability affects only the Premium version of the plugin, where the Employee Panel is present.
Exploitation Scenario
A malicious or compromised employee/provider account logs into the Amelia Employee Panel and sends requests to /users/customers/<id>, iterating over IDs because no ownership check is made. The attacker reads customer PII, then modifies a customer record tied to a WordPress Editor account and triggers a password reset. They take over that Editor account and use it to publish or alter site content, including any embedded AI chatbot or integration settings.
Weaknesses (CWE)
CWE-862 — Missing Authorization: The product does not perform an authorization check when an actor attempts to access a resource or perform an action.
- [Architecture and Design] Divide the product into anonymous, normal, privileged, and administrative areas. Reduce the attack surface by carefully mapping roles with data and functionality. Use role-based access control (RBAC) [REF-229] to enforce the roles at the appropriate boundaries. Note that this approach may not protect against horizontal authorization, i.e., it will not protect a user from attacking others with the same role.
- [Architecture and Design] Ensure that access control checks are performed related to the business logic. These checks may be different than the access control checks that are applied to more generic resources such as files, connections, processes, memory, and database records. For example, a database may restrict access for medical records to a specific database user, but each record might only be intended to be accessible to the patient and the patient's doctor [REF-7].
Source: MITRE CWE corpus.
CVSS Vector
CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:L/I:L/A:NReferences
Timeline
Related Vulnerabilities
CVE-2025-512010.0smolagents: sandbox escape enables unauthenticated RCE
Same attack type: Data LeakageCVE-2023-376510.0MLflow: path traversal allows arbitrary file read
Same attack type: Data LeakageCVE-2025-282810.0LangChain RequestsToolkit: SSRF exposes cloud metadata
Same attack type: Auth BypassCVE-2025-5376710.0Azure OpenAI: SSRF EoP, no auth required (CVSS 10)
Same attack type: Auth BypassCVE-2026-2185810.0n8n: Input Validation flaw enables exploitation
Same attack type: Auth Bypass