The Events Calendar SQL Injection CVE-2026-49772: What to Do

If your site runs The Events Calendar, check its version today. A flaw tracked as CVE-2026-49772 affects versions 6.15.12 through 6.16.2, and it is fixed in 6.16.3. The official CVE record describes it as a blind SQL injection that needs no login and no user interaction, scored 9.3 out of 10 (CVE record, published 16 June 2026 by Patchstack, checked 27 Oct 2026).

The fix has been out since June, and the plugin has had many releases since, so most sites that update regularly are already safe. The ones at risk are the sites nobody has touched in a while: the club site a volunteer set up, the venue site whose developer moved on, the staging copy that somehow became the live site. Those are exactly the sites that rarely see an alert.

This post covers what to do in order. First the fix, then a check that nothing happened while the site was exposed, and only then the question some owners will now be asking, which is whether to stay with the plugin at all.

What the flaw is, in plain words

SQL injection means an attacker can slip their own database commands into a request the plugin makes. “Blind” means they do not see the results directly, but can work them out one piece at a time from how the site responds. “Unauthenticated” means they do not need an account.

Put together, someone who finds an affected site can read data from its database without logging in. The CVE record marks the impact on confidentiality as high. That database holds more than events: it is the whole WordPress site, including user accounts, their email addresses and password hashes, and anything else your plugins store there.

The record marks the impact on integrity as none, which means the flaw itself is about reading data, not changing it. That is good news, but it is not the end of the story. Stolen password hashes can be cracked offline, and a cracked administrator password lets someone log in normally and change whatever they like.

Step 1: Update now

1. Log in to your WordPress dashboard and open Plugins.
2. Find The Events Calendar and look at its version number.
3. If it is anywhere from 6.15.12 to 6.16.2, update it. The current release on wordpress.org is 6.18.2 (checked 27 Oct 2026). Anything at 6.16.3 or later has the fix.
4. If your site uses the paid add-ons, update those at the same time, so the versions stay compatible.

If you cannot update right away, for example because a developer locked the version, deactivate the plugin until someone can. A calendar that is missing for a day is a far smaller problem than an exposed database.

If you look after several sites, check all of them, including old ones. A forgotten site is still on the internet.

How do you check which version of a plugin you run?

You do not need any tools for this, and the same steps work for every plugin on every site you look after.

1. In your WordPress dashboard, open Plugins and then Installed Plugins.
2. Find the plugin in the list. Its version number is shown in the description line under the name, next to the author.
3. Open Dashboard and then Updates to see which plugins have a newer version waiting.
4. For a full list in one place, open Tools, then Site Health, then the Info tab, and expand Active Plugins. It lists every active plugin with its version, which is handy to paste into a note or send to a developer.

Compare what you see with the vendor’s own announcement. For this flaw, that means checking whether your number falls between 6.15.12 and 6.16.2, or is 6.16.3 or later. If a plugin is inactive and you have no use for it, delete it, so there is less to keep up to date.

How do you update a plugin safely?

An update is a small change, and most go through without any trouble. But a site that earns money or runs events deserves a short routine, so that a bad update never costs you more than a few minutes.

1. Take a backup first. Use your host’s backup or snapshot tool, or a backup plugin you already trust, and make sure it includes both the files and the database. Check that you know how to restore it before you need to.
2. Try it on a staging copy if you have one. Many hosts offer a one-click staging site. Update there, click through the pages that matter (the calendar, an event page, the registration or ticket flow, the contact form) and only then repeat on the live site.
3. Update on the live site at a quiet time. Not an hour before a ticket sale opens.
4. Read the changelog. The plugin’s page on wordpress.org lists what each release changed. If a release says it fixes a security issue, treat it as urgent.
5. Test again afterwards. Open the same pages you tried on staging and place a test registration if you sell or collect sign-ups.
6. Keep the backup for a few days. If something looks off later, you can compare or roll back.

If an update does break something, restore the backup, then find out why before trying again. If the update is a security fix and you cannot apply it quickly, the safer interim choice is to deactivate the plugin, as described above.

Can WordPress update plugins for you automatically?

Yes. WordPress core has had automatic plugin updates since version 5.5. On the Plugins screen, each plugin has an Enable auto-updates link in its row, and there is a bulk action for choosing several plugins at once. Once it is on, WordPress installs new releases for that plugin on its own schedule, and you can switch it off again from the same place.

Auto-updates are a trade, and it is fair to say so both ways:

• For: a fixed flaw reaches the site without waiting for someone to remember. For the forgotten club site, that is the difference between patched and exposed.
• Against: an update can change behaviour you depend on, and nobody is watching when it lands.

A sensible middle path is to turn auto-updates on for plugins where an unexpected change would be a minor nuisance, and to update the plugins that run your business (ticketing, payments, membership) by hand after a backup. Whatever you choose, still look at the Updates screen regularly. Your host may also manage updates for you, so ask them what they already do before you duplicate it.

Step 2: Check whether anything happened

Updating closes the hole. It does not tell you whether someone used it before you did. If the site ran an affected version for any length of time, do these checks.

Look at your user list. Open Users and sort by registration date. Look for administrator accounts you do not recognise, or recent accounts with odd names and email addresses. Remove anything you cannot explain, and check with your team before you delete a real colleague.

Reset the passwords that matter. Ask every administrator and editor to change their password. Because the flaw could expose password hashes, a strong old password is still worth changing. Turn on two-factor login for those accounts if you have not already.

Rotate the keys. WordPress uses secret keys and salts, stored in wp-config.php, to protect login cookies. Changing them logs everyone out, which ends any stolen sessions. Most hosts and security plugins can do this for you.

Check for changes you did not make. New plugins you did not install, unfamiliar files in the uploads folder, a changed site address, or pages with links you did not add are all signs worth investigating. A malware scan helps here, for example with WP Vanguard, or the scan your host or security plugin offers.

Keep a note. Write down which version the site ran, when you updated, and what you checked. If your site stores personal data about members or attendees, you may have obligations to assess the risk and, in some cases, to report it. Ask whoever handles privacy for your organisation.

If you find signs of a break-in, stop and get help from your host or a security professional before you try to clean it yourself. Cleaning only part of an infected site is how infections come back.

How can you tell whether your site was affected?

We want to be careful here. This section is general good practice for any site that ran a vulnerable plugin, not a list of signs specific to this flaw, and we are not describing how an attack on this vulnerability looks. A blind SQL injection is designed to leave little behind, so finding nothing does not prove nothing happened. What you can do is reduce the risk and look for the ordinary signs of a compromised site.

• Ask your host. Hosting providers can often see access logs, security scan results and file change reports that you cannot see from the dashboard. Ask whether they have logs for the period the site ran an affected version, and whether anything stands out.
• Look at your access logs if you can read them. Unusual spikes of requests, or one address making a great many requests in a short time, are worth a closer look. A log that is a mass of normal traffic will not show you much, and an empty result is not a clean bill of health.
• Check recent changes. Look at the date modified on files in your plugin and theme folders, new administrator accounts, new scheduled tasks and changed settings. Anything you cannot explain deserves a question.
• Run a scan. A malware scanner from your host, a security plugin, or an outside service can look for known bad files. It finds known patterns, so treat a clean result as one useful data point, not a guarantee.
• Review who can log in. Remove old accounts, and make sure everyone left has a strong, unique password and two-factor login.
• Keep the evidence. Before you change or delete things on a site you think was broken into, take a copy of the logs and a backup. A professional will want to see them.

If you decide the exposure was real, change the passwords and keys as described above and tell whoever needs to know. Your own privacy or data protection rules decide what that means for you.

Step 3: Decide calmly whether to move

A serious flaw is a fair moment to look at your plugins, but it is a poor reason on its own to switch. Every plugin with a large user base will have security issues at some point. The Events Calendar’s team disclosed this one through a bug bounty and shipped a fix, which is how the process is supposed to work. A plugin that has never had a CVE is not necessarily safer; it may have been looked at less.

The better questions are about fit:

• How much of it do you use? Many sites install a full events suite and use a calendar, a list and an RSVP button. Every feature you do not use is still code on your site that needs updating.
• How many add-ons does your setup depend on? Each one is another update to keep in step, and another place for a version mismatch.
• Who keeps it updated? If the honest answer is “nobody, really”, the plugin matters less than putting someone in charge of updates.
• What do you actually need next year? Paid tickets, recurring series, check-in at the door, member-only events. Choose for that, not for this week’s news.

If those answers point to staying, stay, update, and set a reminder to check plugin versions monthly. If they point to a change, the next section is for you.

If you do move: what comes across

Eventonomy is an events and RSVP plugin for WordPress, and it has a free importer for The Events Calendar. It reads the events straight from your site’s database, so there is no export file to make, and it never changes the original data. You can leave The Events Calendar installed while you test, or deactivate it first. Either works.

The importer runs in four steps:

1. Scan and preview. A full dry run that creates nothing. It reports how many events will be created, how many are duplicates it will skip, how many venues and organizers are new or matched to existing ones, how many cover images it will download and how many old addresses will get redirects.
2. Import. Up to 500 events import while you wait. Larger sets run in the background and keep going if you close the page.
3. Verify. Open a few events and check dates, times and venues.
4. Undo, if you need to. Each import can be removed completely, including the events, images and redirects it created.

What comes across: event titles, descriptions, dates, time zones, status and cover images, venues and organizers, categories and tags, and recurring rules from The Events Calendar Pro where they translate. Rules that do not translate import as single events and are flagged in the preview. Where an event has several organizers, the first is kept and the report says so. Old event addresses get 301 redirects to the new pages, so search results and shared links keep working. Running the import again only adds what is new, so you can import, keep the old plugin running for a week, and import the newer events later.

What does not come across, on purpose: orders, payments, sold tickets, check-in records and existing RSVPs. That history belongs to the old system. If you sell tickets, the cleanest switch is between events: finish selling for the current one on the old setup and open the next one on the new.

The step-by-step migration guide has the screens, and the comparison with The Events Calendar sets out where each plugin is the better fit.

What should you ask any plugin vendor about security?

This applies to every plugin you rely on, ours and everyone else’s. A vendor that has answered these questions before you ask is usually a good sign. A vendor that has not is not necessarily a bad one, but you should know where you stand.

1. How do I report a security problem to you? There should be a clear, private channel, such as a security email address or a disclosure program, written down somewhere you can find it.
2. Do you publish security advisories? Look for a changelog or an advisory page that says plainly when a release fixes a security issue, and for CVE identifiers where they apply.
3. How quickly do you ship fixes once a problem is confirmed? You are not looking for a promise of perfection, only for a stated process and some history to check it against.
4. Which versions get fixes? Some vendors patch only the latest release. If you stay on an older version for compatibility reasons, you should know whether it is still covered.
5. How will I find out about an update? Through the dashboard, a mailing list, a feed, or all of them.
6. Does a paid licence affect security updates? Find out whether the security fix for a paid add-on is delivered the same way as the free plugin’s, and what happens when a licence lapses.
7. What does the plugin store, and where? Knowing which data it keeps helps you judge the impact if something goes wrong.

Read the answers against the public record. A vulnerability database entry, such as the CVE record referred to above, shows how a past issue was disclosed and fixed, which says more than a promise does.

What Eventonomy gives you for free

The free plugin covers events with a capacity, RSVPs, waitlists that promote people automatically on free events, reminders a day and an hour before, recurring weekly and monthly events, calendar views, venues and organizers, custom registration questions and CSV exports of attendees. Pro adds paid tickets, QR check-in at the door, custom reminder timing and more. The Free vs Pro page has the full list.

Checklist

1. Open Plugins, then Installed Plugins, and write down the version of The Events Calendar and its add-ons on every site you look after.
2. If any is between 6.15.12 and 6.16.2, take a backup and update it today. Anything at 6.16.3 or later has the fix.
3. If you cannot update, deactivate the plugin until you can.
4. Delete plugins you no longer use.
5. Review your user list, change administrator and editor passwords, and turn on two-factor login.
6. Rotate the secret keys and salts in wp-config.php, or ask your host to.
7. Ask your host about logs and scans for the period the site ran an affected version.
8. Run a malware scan and treat the result as one data point.
9. Decide which plugins can auto-update and which you update by hand after a backup.
10. Set a monthly reminder to review versions.
11. Write down the version, the update date and what you checked.

Whatever you decide about your plugins, do step 1 today. The fix is one click, and it is the only part of this post that cannot wait.