Booking for Appointments and Events Calendar – Amelia <= 2.4.3 - Authenticated (Custom+) SQL Injection via Customer Import
The Booking for Appointments and Events Calendar – Amelia plugin for WordPress is vulnerable to SQL Injection via the Customer Import in all versions up to, and including, 2.4.3 due to insufficient escaping on the user supplied parameter and lack of sufficient preparation on the existing SQL query. This makes it possible for authenticated attackers, with wpamelia-manager role, to append additional SQL queries into already existing queries that can be used to extract sensitive information from the database.
Browse WordPress security risksQuick answer
Booking for Appointments and Events Calendar – Amelia should be reviewed and updated if it matches the affected versions. The recommended fix is to apply the vendor-supported patched version or the mitigation steps below, then retest the public website with Fixnx.
Who is affected
Affected versions
- up to and including 2.4.3
Fixed versions
- 2.4.4
How to fix it
Booking for Appointments and Events Calendar – Amelia is affected by CVE-2026-14782, an authenticated SQL injection flaw in the Amelia customer import. A compromised or malicious wpamelia-manager account can query the database and expose private data. Update Booking for Appointments and Events Calendar – Amelia to 2.4.4 or a newer vendor-supported patched release. Prioritize exposed production systems and accounts that can reach the affected feature.
- Inventory every Booking for Appointments and Events Calendar – Amelia deployment, version, exposed endpoint, environment, and owner.
- Confirm the installed release is not an affected version up to and including 2.4.3.
- Update Booking for Appointments and Events Calendar – Amelia to 2.4.4 or a newer vendor-supported patched release.
- Until the update is complete, disable Customer Import and suspend or tightly restrict wpamelia-manager accounts.
- Review customer imports, unusual manager activity, SQL-like input, database errors, and timing anomalies.
- Revoke abused accounts, assess customer-data exposure, and rotate database or integration credentials if compromise is suspected.
- Clear WordPress, object, page, CDN, and browser caches, then update the asset inventory and close any temporary controls only after validation.
Scan now. Google sign-in is only needed to unlock fix guidance.
Verify the fix
- Confirm Booking for Appointments and Events Calendar – Amelia is on the patched version or mitigation stated above and record the exact deployed version.
- Confirm the customer import uses the patched code and a safe test cannot add SQL syntax to the query.
- Confirm the affected WordPress REST, AJAX, form, shortcode, upload, export, or admin feature is available only to the roles and requests that need it.
- Review logs after remediation for continued exploit attempts or signs that the issue was used before the fix.
- Rerun the relevant dependency, platform, vendor, or Fixnx security check and document the result, affected assets, change record, and cleanup evidence for CVE-2026-14782.
Related categories
Related security risks
More published guidance from the same primary category.
Participants Database <= 2.7.8.3 - Missing Authorization to Unauthenticated Arbitrary Record Update / Sensitive Information Exposure via 'id' Parameter
Updated July 24, 2026
mediumKirki <= 6.0.14 - Insecure Direct Object Reference to Unauthenticated Sensitive Information Disclosure via 'context' Parameter
Updated July 24, 2026
mediumCVE-2026-12877 Project Management, Bug and Issue Tracking Plugin vulnerability
Updated July 24, 2026
Trusted references
FAQ
What is affected by CVE-2026-14782?
Booking for Appointments and Events Calendar – Amelia versions listed as affected should be reviewed: up to and including 2.4.3.
What should I fix first?
Start with internet-facing sites, admin panels, login flows, plugins, themes, modules, packages, and systems that process user-controlled input or sensitive data.
How do I confirm the fix worked?
Apply the patched version or mitigation, clear caches where relevant, retest the affected workflow, and run a new Fixnx scan to verify public website exposure signals.
How are Fixnx security risk categories chosen?
Fixnx keeps one canonical risk page and assigns only broad, relevant categories such as ecosystem, technology area, or vulnerability class.