CVE-2026-57702: Amelia Booking Plugin SQL Injection — Patch Now

If you or a client runs the Amelia booking plugin, stop and check the version number before you read the rest of this. CVE-2026-57702 is an unauthenticated blind SQL injection, CVSS 9.3, disclosed two days ago on July 13. No login, no user interaction, no social engineering — a single crafted request against a vulnerable endpoint can pull data straight out of your database.

I run Amelia on two client sites (a physiotherapy clinic and a car detailing shop, both booking-heavy). Both got patched within the hour of this landing in my WP Umbrella alerts. This is the kind of CVE where "I'll get to it this week" is the wrong answer.

TL;DR

• What: Unauthenticated blind SQL injection (CWE-89) in the ameliabooking plugin.
• CVE / score: CVE-2026-57702, CVSS 3.1 = 9.3 (AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:N/A:L).
• Affected: All versions up to and including 2.4.2.
• Patched: 2.4.3. Current release on WordPress.org is 2.4.4.
• Install base: 90,000+ active sites per the WordPress.org plugin page — likely higher counting the CodeCanyon-distributed Pro builds, which don't report through the .org API.
• Exploitation status: IONIX's research team says it is tracking ongoing exploitation attempts against unpatched sites.
• Do today: Update to 2.4.4. If you manage this on a client's behalf and can't push an update immediately, deactivate the plugin until you can.

What CVE-2026-57702 actually is

Amelia is a calendar/appointment booking plugin — used heavily by clinics, salons, consultants, and service businesses, which is exactly the client profile a lot of WordPress agencies manage. The vulnerability sits in how the plugin builds SQL queries for its booking and search functionality: attacker-controlled input isn't sufficiently sanitized or parameterized before it's dropped into a backend database query.

Because it's a blind injection, there's no direct output to confirm success — the attacker infers data by observing response timing or boolean differences (true/false query outcomes), one bit at a time. Slower to exploit than a classic error-based injection, but just as complete: with enough requests, an attacker can extract the entire database — customer names, emails, phone numbers, booking history, and if you're not hashing them properly anywhere else on the stack, credentials.

The CVSS vector tells the same story in shorthand: AV:N (network-reachable), AC:L (low complexity — no special conditions needed), PR:N (no privileges), UI:N (no user interaction), C:H (high confidentiality impact — full data read). That combination is why it lands at 9.3.

Who's exposed

Anyone running Amelia 2.4.2 or earlier, on either the free WordPress.org build or the Pro version sold through CodeCanyon and wpamelia.com — the vulnerable code lives in the shared plugin core, not a paid-only module. WordPress.org lists 90,000+ active installs for the free tier alone; the real number including Pro licenses is almost certainly higher, and .org's counter doesn't capture those.

If you manage multiple client sites, the highest-value five minutes you can spend today is grepping your fleet for this plugin rather than checking one site and assuming the rest are fine.

# From an SSH session with WP-CLI, check one site
wp plugin get ameliabooking --field=version

# Across every site in a common webroot layout (adjust the glob to your setup)
for d in /var/www/*/public_html; do
  echo "$d:"
  wp --path="$d" plugin get ameliabooking --field=version 2>/dev/null
done

Anything reporting 2.4.2 or lower needs action now.

Patch immediately

wp plugin update ameliabooking
wp plugin get ameliabooking --field=version   # confirm 2.4.3 or newer

No WP-CLI access? Log in to /wp-admin/plugins.php, find "Booking for Appointments and Events Calendar — Amelia," and click Update. If you're on the Pro build, update through the plugin's own license dashboard or download the latest build from your account at wpamelia.com — CodeCanyon-distributed Pro plugins don't always show up in the standard WordPress update queue.

If for any reason you can't apply the update right now — a client site frozen for a launch, a heavily customized build you need to test first — deactivate the plugin entirely until you can. A booking form that's temporarily down is a much smaller problem than an exposed database.

If you can't update or deactivate immediately

Two stopgaps, neither a substitute for the real fix:

• Web application firewall rule. If you're running Wordfence, Cloudflare WAF, or a host-level WAF (Kinsta, Cloudways, and most managed hosts run one), confirm SQL injection rule sets are active and up to date. IONIX and most major WAF vendors typically ship virtual-patch signatures for high-profile CVEs like this within a day or two of disclosure — check your vendor's advisory feed.
• Block the plugin's public-facing AJAX/REST endpoints at the edge if the booking functionality isn't currently in active use (e.g., an off-season business) — this narrows the attack surface without fully removing the plugin, but it's a worse option than actually patching.

Checking whether you've already been hit

Blind SQLi doesn't deface a site or throw an obvious error — the visible frontend keeps working normally while data walks out the back door. A few things worth checking on any site that was running 2.4.2 or older before today:

• Database error logs for repeated malformed queries hitting Amelia's booking, search, or availability-check endpoints — a pattern of near-identical requests with slightly varied payloads is the signature of an automated blind-injection scan.
• wp_users for administrator accounts you don't recognize.
• wp_options for unfamiliar API keys, redirect settings, or injected siteurl/home values.
• Amelia's own customer records for entries that look synthetic or test-like — sometimes attackers probe with throwaway bookings before running the real extraction.

If the site handles customer PII or payment details through Amelia's booking forms, and you find any of the above, treat it as a data-exposure incident rather than a routine cleanup. Our hacked WordPress cleanup guide covers the remediation steps; if customer data may have left the building, that also means notification obligations depending on your jurisdiction — worth a conversation with the client, not just a quiet patch-and-move-on.

The pattern: booking and calendar plugins keep getting hit

This isn't Amelia's first SQLi disclosure in 2026, and it won't be the last for this category of plugin. Booking plugins are an attractive target because they're inherently unauthenticated-facing — anyone needs to be able to submit a booking request without an account — which means their input-handling code is exposed to the entire internet by design, not just to logged-in users. LatePoint, BookIt, and other calendar/appointment plugins have had comparable findings.

The operational lesson for agencies isn't "stop using booking plugins" — it's "monitor plugin versions across your whole client fleet the same way you'd monitor server patches." A CVE with active exploitation and a 90,000-install footprint moves fast; the agencies that get burned are the ones checking sites one at a time after a client calls, not the ones running fleet-wide version monitoring. WP Umbrella or a comparable tool that flags outdated plugins the moment a CVE is disclosed is the difference between patching in an hour and patching after an incident.

Our WordPress security hardening checklist and security plugin comparison cover the layered defenses — WAF rules, database user permissions, monitoring — that reduce blast radius the next time a plugin you run turns out to have a critical flaw like this one.

Update Amelia to 2.4.4 today. If you manage this for clients, don't wait for them to ask — patch it, then send a one-line email saying you already handled it. That's the entire pitch for paying an agency instead of self-managing WordPress.