The Events Calendar Security Flaws: Protect Your Event Website and Registrations

In this guide

If your website uses The Events Calendar, check its version history and event-comment configuration against the September 2026 security advisory. If there are signs of compromise, preserve upcoming events, registrations and transaction records before cleanup. Updating the plugin and recovering an incident are related tasks, but they do not establish the same thing.

The recovery target is a trustworthy event website that shows correct event information and grants the intended access. A working calendar view does not prove that ticket sales, private attendee data or organizer access survived an incident correctly.

Check both event-comment conditions

The Wordfence advisory describes two independent unauthenticated vulnerability chains leading to remote code execution in The Events Calendar. The documented exposure requires comments enabled on the target event and the plugin’s “Show comments on event pages” option active. The report explains that pending-comment preview can trigger the chains without moderator approval.

It identified 6.17.4.1 as the fully patched release at publication. Treat that as the historical fix boundary; check the latest supported vendor release before updating today. An affected installation and matching settings warrant action, but do not prove that an attacker exploited your site.

Record the current and earlier plugin versions where known, the relevant settings and whether comments were enabled on individual events during the period under review. “Comments require approval” does not remove the documented preview condition. Disabling comments now does not establish whether they were enabled earlier.

Map the event platform, including separate extensions

List The Events Calendar and every connected ticketing, booking, ecommerce, membership or event-submission component. Record their own versions and responsibilities. A fix for one component does not automatically establish the security or compatibility of every extension sharing the event page.

The event owner should identify:

• Upcoming event names, dates, timezones, venues and organizer details.
• Ticket types, capacities, prices and approved purchase destinations.
• Registration and attendee records that must remain private.
• Payments, refunds and bookings created since the latest trusted backup.
• Check-in tools, confirmation messages and external calendar or CRM connections.

Use a private recovery worksheet rather than exporting attendee lists into an ordinary support thread. The purpose is to identify the business records needed for reconciliation, not to collect more personal information than the investigation requires.

Choose patch verification or incident recovery

If there are no unauthorized changes and you are responding to the advisory, preserve a recovery point, apply supported patches and test the configured event workflows. Keep the version and settings evidence. Avoid announcing that the site was hacked solely because it needed an update.

If there are unknown administrators, altered event content, suspicious files or other compromise evidence, coordinate containment and investigation. Preserve logs and incident snapshots before destructive changes. Review event comments and content carefully, but do not assume deleting visible comments removes malicious files or unauthorized access.

The WordPress security logging guide can help establish the timeline. Developers should investigate code and database changes; hosts should handle evidence beyond the site’s permissions or serving environment. Owners should approve the correct event information and legitimate staff access.

Preserve registrations before restoring data

A backup from before the incident may omit newer attendees, refunds or venue changes. Compare the recovery cutoff with the live registration system and payment provider before replacing the database. Decide which records are authoritative and how newer legitimate activity will be reconciled.

WordPress’s backup documentation explains why both files and the database matter. For an event business, restoration also needs agreement about current bookings. Use the safe restore guide to plan that decision instead of restoring an old site merely because its calendar looks correct.

Replace affected code from trusted sources and review custom templates or event integrations. If public registration or sales must pause, define the reopening checks and provide an approved support route for existing attendees. Avoid reopening an unreviewed clone that sends duplicate confirmations or accepts competing bookings.

Verify event pages and dependent journeys

Start with public information: title, date, timezone, venue, organizer, price and contact details. Check representative single-event pages, list views, recurring events if used, mobile presentation and links to outside booking systems. Confirm that exported or subscribed calendar information points to the intended site.

Then test the workflows actually installed. An editor should be able to save an event without unexpected privilege changes. A visitor should be able to follow the intended registration path. A supported sandbox purchase should create the expected order, ticket or booking and send the correct notification. A user without access should not reach private attendee records.

Check capacity, cancellation and check-in behavior where these are part of the business setup. Document any extension-specific limits rather than assuming a single test covers all event types. If enquiry destinations or public organizer details were changed, use the contact-form tampering guide for additional verification.

Record installed patched versions, relevant settings, reconciled records and acceptance results. Review logs after reopening and assign responsibility for checking the next real event registration. A security fix should leave the platform both protected and usable for its actual event workflow.

FAQs

Are moderated comments enough to avoid the documented issue?

The advisory describes a pending-comment preview path that does not require moderator approval. Review both the event’s comment setting and the plugin’s show-comments option, then apply a supported patched release.

Does updating The Events Calendar remove an existing compromise?

No. It addresses the fixed vulnerability. Unauthorized files, accounts or altered records require investigation and cleanup based on evidence from your installation.

Can I restore an older backup before my next event?

Only with a plan for newer registrations, payments and event changes. Reconcile those records first so recovery does not silently lose attendees or restore incorrect capacity.

Prepared for website owners by Nithu / Suthakaran Nithursan. Dated advisory facts link to primary sources. Examples are illustrative and are not client results or guarantees.