If you received an email from me pointing you to this page, it is because your website appears to be running a version of Events Manager (the WordPress plugin events-manager, by Marcus Sykes / wp-events-plugin.com) that falls within the affected range of a known security issue. This page explains what the issue is, how to work out whether it applies to your site at all, and how to update.

Before anything else, the most important fact about this notice: a version in the affected range does not by itself mean your site is exposed. The issue described below is only exploitable when Events Manager is configured to accept bookings from visitors who are not logged in (the plugin’s “No-User-Account Booking Mode”). If your site requires an account to book, or does not take bookings at all, it is very likely not exposed even on an affected version. I can read your plugin version from public files, but I cannot see your booking configuration, so this notice is a precautionary heads-up, not a confirmed finding about your site.

The issue is CVE-2026-12987, an unauthenticated PHP object injection leading to SQL injection in the plugin’s booking system. The authority that assigned the CVE did not publish a severity score; Patchstack rates the same finding 8.8 out of 10 (high). It affects versions 4.0.0 through 7.3.6 and is fixed in 7.3.7. If you are running an affected version, update Events Manager to 7.3.7 or later (the current 7.4.x release is recommended). There is no indication that this issue is being exploited anywhere.

A word on urgency, because this is the most conditional notice I have sent: how much it matters for you depends almost entirely on that booking setting. If bookings on your site require a login, updating is routine plugin maintenance. If your site does take public bookings from visitors without an account, please treat the update as a priority: in that configuration, the flaw could let an attacker read data from your site’s database (such as password hashes and secret keys) without logging in. Even then, this page is a precautionary heads-up, not an incident report, and no emergency response is implied.

This is a plugin flaw, not a WordPress core flaw. A fully up-to-date WordPress does not protect you if the Events Manager plugin itself is on an affected version.

Is this message legitimate?

Yes. This is a good-faith, responsible-disclosure notice from an independent security researcher. I am not asking you for money, passwords, or access to your site, and I have not attempted to break into it, upload anything, or exploit anything.

All I did was look at publicly visible files that your website serves to every visitor (the same way your homepage is public) and note the version number that the Events Manager plugin publishes in its public readme.txt file. I specifically did not touch the booking system, and nothing about this check touches your data, your admin area, or any private part of your site (more detail under What I did and did not do below).

If you would like to verify who I am, see the contact details at the bottom of this page and the About page.

Why this matters

Events Manager is one of the longest-standing events and bookings plugins for WordPress (in the official directory since 2008, with around 6.3 million downloads over its lifetime). It lets a site publish events and take bookings for them, including, if the operator chooses, bookings from visitors who do not have a user account on the site.

In affected versions, when a visitor submits a booking, the custom registration fields they fill in are stored as booking data, and when the plugin later loads that booking it unpacks (“deserializes”) the stored data without restricting what it is allowed to contain. Specially crafted input can therefore be turned into program objects of the attacker’s choosing (PHP object injection), and a chain of such objects reaches a database query that is not properly parameterised (SQL injection). The practical effect on a site in the vulnerable configuration: an attacker with no account and no login could read arbitrary data from the site’s database, such as password hashes and the secret keys WordPress uses.

Two things keep this in perspective. First, the entry point is the public booking form, so the attack only works where a visitor who is not logged in can submit a booking. That is exactly the “No-User-Account Booking Mode” precondition: if booking on your site requires an account, the vulnerable path is not reachable by anonymous visitors, and your site is very likely not exposed even on an affected version. Second, this is a data-read issue, not a server or administrator takeover: it does not by itself let an attacker run code on your server or log into your admin area. And to repeat it plainly, there is no indication of active exploitation: it is not in CISA’s Known Exploited Vulnerabilities catalog, its exploitation-likelihood score (EPSS) is near zero, and I am aware of no exploitation reports.

If my email cited this issue, it means the version your site reports falls within the affected range. I did not test whether your particular site is exploitable, and I cannot see how your booking system is configured; all I observed is that the site reports an affected version.

Am I affected?

Two questions decide it, in this order.

First: do you accept bookings from visitors who are not logged in? This is the deciding question, and only you can answer it.

  • If bookings on your site require an account or a login, or your site does not take bookings at all, you are very likely not exposed, even on an affected version. Updating is still recommended, as ordinary maintenance.
  • If your site accepts bookings from visitors without an account (Events Manager calls this “No-User-Account Booking Mode”), the issue applies to you, and you should update promptly.
  • To check: in the WordPress admin, look in Events Manager’s booking settings for the option that allows bookings without a user account. Or simply test it from the outside: open one of your event pages in a private browsing window and see whether you can fill in and submit a booking without being asked to log in.

Second: which version are you running? You do not have to take my word for it.

From the public manifest (no login needed): open yourdomain.com/wp-content/plugins/events-manager/readme.txt in a browser. Note that this plugin ships its readme as readme.txt (lowercase). The Stable tag: line near the top is the version your install reports, and this is the same public file I read.

From the WordPress admin area (if you have access):

  1. Log in to your WordPress dashboard (usually at yourdomain.com/wp-admin).
  2. Go to Plugins then Installed Plugins.
  3. Find Events Manager and note the version shown beneath its name.

Then apply this rule, and note that versions compare numerically, not alphabetically:

  • 4.0.0 through 7.3.6: potentially affected (subject to the booking-mode question above), update now.
  • 7.3.7 or newer: already fixed. This includes 7.3.7.1, which was a follow-up fix for a non-security display regression, not a second security release: both 7.3.7 and 7.3.7.1 contain the security fix. It also includes all current 7.4.x releases.
  • Older than 4.0: not affected by this issue. The vulnerable booking-data handling first shipped in the plugin’s 4.0 rewrite, so earlier releases do not carry it (a release that old has plenty of other reasons to be updated, but this notice is not one of them).
  • Do not be misled by text ordering: Events Manager used version strings like 5.99912 before 6.0 (the vendor was stuck on a 5.999.x numbering scheme until 6.0), and such a version is an old release below 6.0, inside the affected range, not something newer than 7. Compare each number in turn rather than reading the version as text.

How to upgrade

The safest path is to update through WordPress itself, and to back up first:

  1. Back up your site (files and database) before making changes. Most hosting providers offer one-click backups, or use a WordPress backup plugin.
  2. In the WordPress admin, go to Dashboard then Updates, or Plugins then Installed Plugins. If an Events Manager update is listed, install it from here.
  3. If you prefer the command line, WP-CLI does the same thing: wp plugin update events-manager.
  4. If no update appears, you can get the latest release directly from the plugin’s page on the WordPress.org directory, Events Manager, and update via Plugins then Add New Plugin then Upload Plugin.
  5. After updating, confirm the new version number (7.3.7 or later; the current 7.4.x release is recommended) using the steps above, and check that your events and bookings pages work normally.

While you are in there, it is worth confirming that WordPress core and your other plugins are up to date, since the same principle applies to all of them.

After updating

Updating to 7.3.7 or later closes the issue, and for most sites that is the whole task. There is no indication this flaw has been exploited anywhere, so no emergency response is implied: you do not need to treat your site as compromised or take it offline.

One follow-up is worth considering, and it is conditional on the same booking question. If your site was taking public bookings from visitors without an account while on an affected version, then the data the flaw could reach (database contents, including password hashes and secret keys) was at least theoretically readable, even though there is no evidence anyone did so. In that case, two routine precautions are sensible:

  • Have a look over recent bookings and user activity for anything that seems off, in the ordinary way you would review site activity.
  • Rotate the secrets that live in your database and configuration: regenerate WordPress’s secret keys and salts in wp-config.php (new values are one click away at the official secret-key generator; swapping them signs all users out once), and change your database password via your hosting panel. Because password hashes were among the data theoretically readable, having administrator accounts refresh their passwords is a reasonable extra step.

Treat this as ordinary security housekeeping, not incident response. If bookings on your site have always required a login (or you take no bookings), updating alone is enough.

What I did and did not do

To be fully transparent about the check behind my email: I only read public files that your site already serves to every visitor, specifically the plugin’s public readme.txt file and your homepage. I did not access your WordPress admin area, your database, or any private part of the site. In particular, I did not touch the vulnerable booking path, and I did not test or exploit anything.

This is a version-based observation: your site reports a version in the affected range. Because this issue is configuration-dependent, a site in that range may not be exposed at all (if bookings require a login, or no bookings are taken), and it may also already be mitigated by other means, such as a web application firewall. This notice is not a statement that your site was exploitable at the time I checked.

I do not have a webmaster / I am stuck

If you are not the person who maintains the site, please forward this page to whoever does (your web developer, agency, or hosting provider). They will recognize the steps above quickly.

If you are maintaining the site yourself and get stuck, I am happy to help point you in the right direction at no cost. Reach out using the contact details below.

Contact

Evan Harris, Security Researcher

I reach out about issues like this purely to help operators secure their sites. If you would prefer not to be contacted again, just let me know and I will honor that.

References

Official advisories and tracking

Vendor / plugin