CVE-2026-112327: Patch the Amelia SQL Injection (2026)

CVE-2026-112327 is a critical unauthenticated SQL injection in the Amelia booking plugin for WordPress. If your site runs Amelia 2.4.11 or older, anyone on the internet can read, modify, or delete your site’s database — including your customers’ names, phone numbers, and booking details — with no login required. The fix is already out, but the vendor patched the hole silently, so the changelog gives you no reason to hurry. You should update tonight anyway. Here is how to check if you are affected, patch it, and tell whether someone got to you first.

This post was written and verified on 23 October 2026.

Table of Contents

The flaw, in one table

Item	Detail
CVE ID	CVE-2026-112327
Vulnerability type	Improper Neutralization of Special Elements used in an SQL Command — CWE-89 (SQL injection)
Product	Amelia – Booking For Appointments And Events Calendar (TMS; wp.org slug `ameliabooking`)
Affected versions	All versions up to and including 2.4.11
Fixed in	2.4.12 (silent patch); 2.4.13 is the current release
Severity	CVSS 3.1: 9.3 Critical — `AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:N/A:L`
Reported by	SVO via the Patchstack Bug Bounty program (18 October 2026)
Disclosed	Patchstack advisory 20 October 2026; CVE published 22 October 2026
Exploitation in the wild	Not known to be exploited as of 23 October 2026

Why CVE-2026-112327 is worse than a typical plugin flaw

Most WordPress plugin SQL injections need the attacker to be logged in — a subscriber account, at minimum. This one does not. Look at the CVSS vector: PR:N (no privileges required) and UI:N (no user interaction). A complete stranger can fire crafted requests at your site and pull data straight out of the database.

And S:C — scope changed — means the attacker breaks out of the vulnerable component’s boundaries. That is what drives the score to 9.3.

Then there is what the database actually holds. Amelia is a booking plugin: it stores customer PII — names, phone numbers, email addresses, appointment histories. A SQL injection here does not just deface your homepage; it leaks your clients’ contact data. If you run a salon, clinic, consultancy, or anything else that takes appointments online, the blast radius is your customers’ privacy, and possibly your legal exposure.

Scale matters too. The free version of Amelia has 90,000 active installs on wordpress.org (current figure, October 2026). Patchstack rates this class of flaw as “highly dangerous and expected to become exploited — vulnerabilities like this are used in mass-exploit campaigns.” That is not marketing language: unauthenticated, critical-severity plugin flaws get swept up by automated scanners within days of disclosure, and bots do not care how small your site is.

Do not confuse it with the older Amelia flaws

Amelia has a history of security issues, and the search results are a minefield of old CVEs. If you have ever looked into an Amelia vulnerability before, make sure you are patching this one, not congratulating yourself for a fix you applied months ago:

CVE	What it was	Affected	Status
CVE-2026-4668	Authenticated SQL injection via the `sort` parameter	≤ 2.1.2	Old — different flaw
CVE-2026-2931	IDOR allowing arbitrary password changes	≤ 9.1.2 (premium line)	Old — fixed in 9.1.3 (Feb 2026)
CVE-2026-112327	Unauthenticated SQL injection	≤ 2.4.11	This one — patch now

The confusion hazard is real enough that it deserves a warning of its own: if your site was fully patched against the February 2026 IDOR (9.1.3) and you stopped paying attention, you are still exposed to CVE-2026-112327. Different flaw, different line, different patch.

Check if you are affected tonight

You need about two minutes. Pick whichever method fits your access:

Method 1: The wp-admin Plugins page

Log in to wp-admin → Plugins → Installed Plugins, find “Amelia – Booking For Appointments And Events Calendar”, and read the version number in the plugin row.

2.4.11 or lower: vulnerable. Patch tonight.
2.4.12: the SQLi is patched (Patchstack verified the fix independently). But update to 2.4.13 anyway — it is the current release and its changelog cites further security fixes.
2.4.13: you are on the fixed version. Still read the “were you hit?” section below if your site was on an older version this week.

Method 2: WP-CLI (one command)

If you have shell access, this is faster:

wp plugin list --fields=name,version,status | grep ameliabooking

You will get something like ameliabooking 2.4.11 active. If the version is 2.4.11 or below, you are exposed.

Method 3: No wp-admin access? Check via your host

If you only have file or database access (a common situation for agency-managed client sites), look at the plugin’s readme header:

grep -i "^Stable tag" wp-content/plugins/ameliabooking/readme.txt

Same verdict: 2.4.11 or lower means vulnerable.

Patch it: update to 2.4.13

The vendor fixed the SQL injection in 2.4.12, but you should go straight to 2.4.13 — it was released on 22 October 2026 (one day after the CVE went public) with a changelog that reads “This update includes important security fixes. We strongly recommend updating to this version immediately.”

The dashboard way

Back up the site first — database plus wp-content at minimum. A one-click backup plugin or your host’s snapshot both work.
wp-admin → Plugins → Installed Plugins → click Update now under Amelia.
Confirm the version reads 2.4.13 after the update.

The WP-CLI way

# Back up the database first
wp db export ~/ameliadb-$(date +%F).sql

# Then update
wp plugin update ameliabooking

# Confirm
wp plugin get ameliabooking --field=version

Expect the last command to print 2.4.13.

Turn on auto-updates while you are there

On the Plugins page, click “Enable auto-updates” next to Amelia. Plugin auto-updates are the single cheapest defense against this entire class of disclosure — this CVE would have been a non-event for anyone with auto-updates on, since the fix shipped before the CVE went public.

The uncomfortable part: 2.4.12’s changelog says nothing

Here is a detail worth sitting with. The vendor’s changelog for 2.4.12 — the release that actually fixed a 9.3 unauthenticated SQL injection — mentions only Outlook Calendar integration fixes and “minor bug fixes and stability improvements.” No security note at all. Patchstack had to verify the fix independently.

This is more common than it should be, and it is why “I only update when the changelog mentions security” is a broken policy. If you run booking, ecommerce, or membership plugins on client sites, treat every plugin update as potentially security-relevant. Auto-updates exist precisely because changelog reading does not scale.

Were you already hit? How to check

As of 23 October 2026 there are no public reports of in-the-wild exploitation of CVE-2026-112327. But the CVE went public on 22 October, scanners move fast, and this flaw needs no credentials — so if your site was on 2.4.11 or older during the disclosure window, spend ten minutes checking:

Look for new admin users. SQLi with C:H (high confidentiality impact) is typically used to read the database — and the classic follow-up is creating a rogue admin. In wp-admin → Users, sort by registration date and look for anything you did not create. Or via WP-CLI: wp user list --role=administrator --fields=user_login,email,registered
Scan for tampered bookings. Open a few recent appointments in the Amelia dashboard and sanity-check the customer details. Look for test or gibberish entries an attacker may have inserted.
Check your access logs for probing. Before mass exploitation starts, scanners leave distinctive fingerprints. Grep your web server logs for requests touching Amelia endpoints over the last few days: grep -iE "amelia" /var/log/nginx/access.log | tail -100. On shared hosting, ask your host for the raw access logs — most cPanel/Plesk hosts keep a few days of them.
If you find anything: assume the database was fully read. Rotate your WordPress salts in wp-config.php, force a logout of all sessions (changing salts does this), reset admin passwords, and — critically — notify affected customers if their PII was stored. A booking database is customer data, not just site content.

Make this the last time

Five habits, in order of impact:

Enable plugin auto-updates for every plugin that handles customer data — Amelia, ecommerce, forms, memberships.
Subscribe to disclosure feeds for your stack: Patchstack’s database, the Wordfence Intelligence vulnerability list, or cvefeed.io. A two-minute daily scan beats discovering a CVE on social media.
Keep a staging site. The reason people leave auto-updates off is fear of breakage. A staging copy lets you test updates in minutes instead of leaving the door open for weeks.
Least-privilege database user. WordPress only needs SELECT, INSERT, UPDATE, DELETE, CREATE, ALTER on its own database in normal operation. A DB user that cannot DROP tables or read information_schema freely limits what any SQLi can do. (Test this on staging first — some plugins misbehave.)
A WAF with virtual patching. Patchstack, Wordfence, and Cloudflare’s WAF all shipped or ship mitigation rules for flaws like this within hours of disclosure — a useful safety net for the window between disclosure and your update.

CVE-2026-112327: The Amelia Booking Plugin SQL Injection — Update Tonight (2026)