WordPress Vulnerability News: Critical Plugin Flaws Put Sites at Risk

The complete fix arrived in version 6.17.4.1. WordPress.org now lists 6.17.5 as the latest release, so site owners should update to the newest official version rather than stopping at the minimum patched build.

Two points matter before anyone panics:

• The plugin’s 600,000-plus active installations are not 600,000 confirmed vulnerable sites.
• A vulnerable version is not proof that a website has been compromised.

If your site uses The Events Calendar, check the installed version now. Update it, confirm that the update completed, and review the site if it ran an affected version. This article explains the risk without reproducing exploit instructions.

What Happened in the Latest WordPress Vulnerability News?

Wordfence researchers disclosed two independent vulnerability chains in The Events Calendar on September 14, 2026. Both received a critical CVSS score of 9.8. Both could be reached without a normal WordPress login when the required site settings were present.

The affected plugin is used to publish events, calendars, venues, and organizers. Its official WordPress.org listing shows more than 600,000 active installations.

The flaws are tracked as:

• CVE-2026-78159: A code-injection path affecting versions up to and including 6.17.3. Wordfence lists 6.17.3.1 as the first patched version for this flaw.
• CVE-2026-78006: A PHP object-injection path affecting versions up to and including 6.17.4. Wordfence lists 6.17.4.1 as the first patched version for this flaw.

Because the second issue remained present in 6.17.4, updating only to that version was not enough. The safe practical choice on September 21 is 6.17.5, the latest version available from WordPress.org.

The distinction between a minimum fixed version and the latest release is easy to miss. A security article may name the first patched build, while the developer publishes another update a few days later. Always check the official plugin page before acting on an older screenshot or search result.

Why These Plugin Flaws Are Serious

Remote code execution means an attacker may be able to make the web server run unauthorized code. That can put the WordPress installation, its data, and connected services at risk.

A successful attack could lead to outcomes such as:

• unauthorized administrator access;
• malicious changes to site files;
• visitor redirects or injected spam;
• theft of information available to the compromised account or server process;
• persistent malware or backdoors;
• disruption of site operations.

These are possible consequences, not evidence that each affected website experienced them.

The lack of a login requirement raises the priority. The Wordfence technical advisory says both attack paths depended on comments being enabled and visible on event pages. A pending-comment preview could reach the vulnerable processing path before a moderator approved the comment.

That configuration requirement narrows exposure, but it does not make an outdated installation safe. Site owners may not remember which custom post types allow comments, and settings can change during a redesign, migration, or plugin update.

Security also affects more than the server. A compromised site can expose visitors to malicious downloads, damage customer trust, interrupt advertising campaigns, and create crawling or indexing problems. Our guide to technical SEO and website health explains why security maintenance belongs alongside performance, access, and other technical controls.

Is Your WordPress Site Affected?

Start with the plugin inventory. These two CVEs do not affect a WordPress site that does not have The Events Calendar installed.

Your site needs prompt attention if all or part of the following description applies:

• The Events Calendar is installed.
• The installed version is 6.17.4 or older.
• Comments are or were enabled on event posts.
• Event pages are publicly accessible.
• The site ran an affected version after the vulnerability details became public.

An inactive plugin should not be ignored. If the files remain on the server, remove the plugin when you no longer need it. Deactivation is useful during troubleshooting, but deletion reduces unnecessary software and future maintenance work.

Installed, Vulnerable, and Compromised Mean Different Things

Security headlines often collapse three separate facts:

1. Installed: The plugin exists on the website.
2. Vulnerable: The installed version and site conditions match a known security issue.
3. Compromised: Evidence shows that an attacker successfully used the weakness or another route.

A popular plugin can have hundreds of thousands of installations without every copy running the same version. Some sites update quickly. Others do not use the configuration required by a specific attack path.

This is why the active-install count describes reach, not confirmed victims.

What WordPress Site Owners Should Do Now

The right response begins with a version check, not a generic security scan.

1. Find Every Copy of the Plugin

In the WordPress dashboard, open Plugins > Installed Plugins and look for The Events Calendar.

Agencies and companies with several websites should check every environment they manage. Include production, staging, campaign sites, event microsites, and old installations that still resolve publicly.

Write down the site, plugin version, update status, and person responsible. A short inventory is more useful than assuming someone else handled the update.

2. Create or Confirm a Usable Backup

Before a significant update, confirm that a recent backup exists and can be restored. A backup that has never been checked is only a hope.

The official WordPress upgrade guidance recommends backing up the database and WordPress files, then verifying that those backups are usable.

Do not overwrite the only known-clean backup if you suspect a compromise. Preserve it until the investigation establishes what happened.

3. Update Through an Official Source

Install the latest version offered through the WordPress dashboard or the developer’s official channel. As of this article’s fact-check date, WordPress.org lists The Events Calendar 6.17.5.

Avoid plugin packages from download mirrors, file-sharing sites, or messages claiming to contain a special patch. A security update should not create a second supply-chain risk.

4. Confirm the Version After Updating

Return to the Installed Plugins screen and confirm the version number. Then clear relevant caches and test the event pages that matter to the business.

Check at least:

• the main calendar;
• individual event pages;
• event search or filters;
• registration or ticket links;
• mobile layouts;
• any custom templates connected to the plugin.

An update notification disappearing does not prove that every site function still works.

5. Review Comment Settings

Disable comments on event posts if the site does not need them. This reduces an unnecessary entry point, but it is not a replacement for updating the plugin.

If event discussions are important, keep the patched version installed and apply sensible moderation and anti-spam controls.

6. Look for Signs That Deserve Investigation

If the site ran an affected version, review the period between exposure and patching. Useful evidence may include web-server logs, security alerts, WordPress activity logs, hosting records, and file-integrity results.

Potential warning signs include:

• administrator accounts nobody recognizes;
• unexpected changes to plugin, theme, or core files;
• unfamiliar executable files in writable directories;
• redirects that appear only for some visitors;
• unexplained changes to scheduled tasks or configuration;
• sharp traffic or conversion changes that line up with technical anomalies.

No single symptom proves that this vulnerability was used. Analytics can reveal that something changed, but it cannot replace server evidence. The web analytics guide explains how to interpret website data in context rather than treating one metric as a diagnosis.

7. Escalate When the Evidence Points to Compromise

Do not clean an important business site by deleting files at random. That can remove evidence, leave persistence behind, or make the site harder to recover.

Contact the hosting provider or an experienced incident-response professional. Preserve relevant logs and backups, rotate exposed credentials, close the vulnerable path, and determine the scope before declaring the incident resolved.

For U.S. organizations that may have exposed personal information, the FTC’s data-breach response guide recommends securing operations, preserving evidence, involving appropriate experts, and checking applicable notification duties. State and sector requirements differ, so legal advice may be needed.

Are the Events Calendar Flaws Being Exploited?

This question needs careful wording.

Wordfence’s current vulnerability records display recently blocked attempts targeting the two flaws. That supports treating the updates as urgent. It does not establish that every attempt succeeded or that a large share of the plugin’s users were compromised.

Public numbers from a firewall provider describe what that provider observed across protected sites. They do not measure the entire WordPress ecosystem.

The practical decision does not depend on proving a mass campaign. The flaws are critical, the attack paths can be reached without a normal account, and fixes are available. Updating is the sensible response.

Other WordPress Security News to Check This Week

Anyone searching for WordPress security news today needs a date attached to the answer. These additional items were current when this article was checked on September 21, 2026.

WooCommerce Wholesale Lead Capture

Wordfence reported active exploitation of an unauthenticated file-upload flaw in the premium WooCommerce Wholesale Lead Capture plugin. The issue is tracked as CVE-2026-27540 and affects versions through 2.0.3.1.

The Wordfence incident report names 2.0.3.2 as the patched version and says its firewall had blocked more than 100,000 exploit attempts by September 14.

Sites using this plugin should install the newest official release and investigate unexpected executable files or other signs of compromise. The word “active” matters here because researchers reported observed attacks, not only a theoretical path.

Tutor LMS

A separate high-severity issue affects Tutor LMS versions through 4.0.7. CVE-2026-78175 can lead to remote code execution for a subscriber-level account under the documented conditions. Open student registration can lower the practical barrier on learning sites.

Wordfence says version 4.0.8 fixed the issue. The official Tutor LMS page now lists 4.0.9, so administrators should update to the latest official release.

The research advisory does not claim widespread successful exploitation. Keep that distinction when sharing the story.

WordPress Core 7.1.1

Plugin updates do not replace core updates. WordPress released version 7.1.1 on September 17 with 11 security fixes and recommended immediate installation.

Read the official WordPress 7.1.1 release notice and use the appropriate supported release for your environment.

These are separate issues. Updating WordPress core does not patch a vulnerable plugin, and updating a plugin does not patch WordPress core.

How to Read WordPress Security News Without Overreacting

Good security reporting helps a site owner make a decision. It should not turn every disclosure into a claim that the whole internet has been hacked.

Use this sequence when a new alert appears.

Confirm the Exact Product

Plugin names can be similar. Match the name, developer, and plugin slug before changing the site.

Check the Affected Version Range

“A WordPress plugin is vulnerable” is incomplete. The key question is whether your installed version falls inside the affected range.

Separate the First Patch From the Latest Release

The first fixed version tells you where the vulnerable range ends. The latest official release is usually the better destination unless the vendor documents a compatibility reason to choose another supported branch.

Check What an Attacker Needs

Some flaws require an administrator account. Others need only a subscriber, a public form, or no account at all. Configuration requirements can change risk, but they should not become an excuse to leave vulnerable software in place.

Look for Evidence of Exploitation

“Could be exploited,” “proof of concept exists,” “attempts were blocked,” and “successful exploitation is confirmed” are different statements. Reliable reporting should say which one the evidence supports.

Prefer Direct Sources

Start with the developer’s changelog, the WordPress.org listing, the CVE record, and the researcher who disclosed the issue. A news summary can add context, but it should not replace the source that defines affected and fixed versions.

Build a WordPress Security Routine Before the Next Alert

Security news is useful only when someone can turn it into action.

Self-hosted WordPress gives a team substantial control, but that control includes maintenance responsibility. Our CMS versus WordPress guide explains that trade-off in the wider platform decision.

For an ordinary U.S. business site, a workable routine should include the following practices.

Assign Ownership

Name the person or provider responsible for core, plugin, theme, PHP, and hosting updates. “The team” is not an owner.

Keep an Inventory

Record the software each site uses and remove components that no longer serve a business need. Include inactive plugins, premium tools, custom integrations, and staging sites.

Triage Updates by Risk

Review security updates promptly. High-impact sites may need a short staging test, but testing should not become an indefinite delay.

Use Defense in Depth

Updates are essential, yet no single control is enough. Strong authentication, least-privilege accounts, protected backups, logging, secure hosting, and a web application firewall can reduce risk or improve detection.

The official WordPress hardening guide recommends current software, trusted sources, limited access, backups, and preparation for recovery.

Test Recovery

Schedule restore tests instead of discovering during an incident that the backup is incomplete, inaccessible, or infected.

Keep Useful Logs

Decide how long the organization needs web, application, security, and hosting logs. Retention should support investigation and fit the business’s legal and operational needs.

Document the Response Path

Write down who can take a site offline, contact the host, approve emergency work, notify leadership, and involve legal counsel. A short plan saves time when an alert affects a revenue or customer-facing site.

Common Mistakes After a Vulnerability Alert

Assuming Every WordPress Site Is Affected

A plugin flaw affects sites that use that plugin and match the vulnerable conditions. Check before making a claim.

Treating Deactivation as a Permanent Fix

Deactivation may interrupt a specific path, but outdated files still create maintenance risk. Update the plugin or remove it if it is no longer needed.

Updating Without Verifying

Confirm the installed version and test important site functions. A failed update or broken deployment should not go unnoticed.

Restoring a Backup Without Closing the Entry Point

A clean restore can be compromised again if the vulnerable plugin, exposed credential, or malicious account remains.

Depending on a Security Plugin Alone

A firewall and scanner can add valuable protection. They do not remove the need for patches, backups, access control, and human review.

Publishing a Victim Count Without Evidence

Active installations, vulnerable copies, attack attempts, and confirmed compromises measure different things. Label the number you actually have.

Frequently Asked Questions

What is the current WordPress vulnerability news?

As of September 21, 2026, two critical flaws in The Events Calendar are a major concern. Versions through 6.17.4 were affected, and the complete fix arrived in 6.17.4.1. WordPress.org currently lists 6.17.5 as the latest release.

Other current items include active exploitation of WooCommerce Wholesale Lead Capture versions through 2.0.3.1, a patched Tutor LMS flaw affecting versions through 4.0.7, and the WordPress 7.1.1 core security release.

Is every site using The Events Calendar compromised?

No. An affected version creates exposure under the documented conditions, but exposure is not proof of compromise. Site owners should update and review available evidence if the site ran a vulnerable version.

Is version 6.17.4 of The Events Calendar safe?

No. CVE-2026-78006 affects versions up to and including 6.17.4. Version 6.17.4.1 contains the complete fix for the two critical issues discussed here. The latest official version on the fact-check date is 6.17.5.

Should I disable comments on event pages?

Disable them if the site does not need them. That can reduce exposure to comment-dependent attack paths, but it does not replace the plugin update.

Does updating WordPress core fix vulnerable plugins?

No. WordPress core, plugins, and themes are separate software components. Each needs its own updates.

Should WordPress plugins update automatically?

Automatic updates can shorten exposure, especially on smaller sites with reliable backups. High-impact sites may use managed staging and monitoring instead. The process should still ensure that security fixes are tested and deployed promptly.

What should I do if I think my site was hacked?

Preserve logs and backups, limit further access, contact the host or a qualified incident-response professional, rotate relevant credentials, and investigate the full scope. U.S. businesses should also assess whether personal information was exposed and whether notification laws apply.

WordPress Vulnerability News Should Lead to Action

The lesson from this week’s WordPress security news is not that every WordPress site is unsafe. It is that a website’s security depends on the software actually installed and the speed of the maintenance process behind it.

For The Events Calendar, the immediate task is clear: update to the latest official version, confirm the installed build, and review the site if it ran 6.17.4 or earlier. Owners of WooCommerce Wholesale Lead Capture and Tutor LMS also have specific updates to check, while every WordPress administrator should review the 7.1.1 core security release.

Keep an inventory. Verify claims at the source. Patch promptly. Test backups before you need them. If evidence suggests a compromise, treat it as an incident rather than a routine plugin update.