The Events Calendar Path Traversal (CVE-2026-3585): Patched

Update, September 15, 2026: This post originally said no patch existed for CVE-2026-3585. That was already wrong on the day it ran: The Events Calendar 6.15.17.1, which fixes it, shipped March 9, 2026, ten days before this post's original publication. We've corrected the record below, along with an installs figure that overstated the plugin's WordPress.org count. See also our new post on two unauthenticated RCE flaws disclosed in the same plugin in September 2026, which don't need an Author account at all, just comments turned on.

A path traversal vulnerability in The Events Calendar, one of the most popular events plugins on WordPress.org, was publicly disclosed in March 2026. The Events Calendar has more than 600,000 active installs according to WordPress.org, and the bug let an authenticated attacker with Author-level access or higher read arbitrary files on the server. It's fixed, in version 6.15.17.1.

CVE-2026-3585 is rated CVSS 7.5 HIGH. Here is everything you need to know: what it does, how it works, who was at risk, what files attackers could target, and what to check now that a fix exists.

What Is The Events Calendar?

Before getting into the vulnerability, it helps to understand the scale. The Events Calendar is developed by StellarWP (formerly Modern Tribe) and has been active since 2009. It is free and available on WordPress.org, where it is one of the most widely used events plugins.

More than 600,000 active installations is not an estimate, it is a floor. WordPress.org counts only direct .org installations. The plugin is also distributed via the developer's own website and bundled by themes, so the real number of sites running it is likely higher.

That installation count is why this disclosure matters beyond its CVSS score. A 7.5 rating is high severity, but not the highest. The impact here is multiplied by the sheer number of sites exposed.

The Vulnerability: Path Traversal in ajax_create_import

The flaw exists in a function called ajax_create_import. This function is part of the plugin's event import system, which allows site owners to import events from external files in various formats.

How Path Traversal Works

A path traversal vulnerability, also called a directory traversal vulnerability, occurs when user-supplied input is used to construct a file path and the application fails to properly sanitize or validate that input.

In a correctly implemented application, when a user requests a file, the application ensures that file path stays within the expected directory. In a vulnerable application, an attacker can supply a path like:

../../../../wp-config.php

The ../ sequences navigate up the directory tree. If the application passes this input to a file-reading function without stripping or blocking directory traversal sequences, the server reads wp-config.php, or any other file the web server process has permission to read.

The Specific Flaw

In ajax_create_import, the plugin accepts user-supplied input as part of a file import path. The validation logic is insufficient to block traversal sequences. An authenticated user with Author-level access can supply a crafted path that causes the server to read and return the contents of files outside the intended import directory.

The vulnerability requires authentication at Author level or above. This is not zero-click. But it is a significantly lower bar than it might appear in practice.

Who Is Actually at Risk

The authentication requirement creates a false sense of security for many site administrators. "My site requires login, so outside attackers cannot trigger this" is true only for fully private sites. It is not true for the majority of sites running The Events Calendar.

Consider the typical deployment contexts:

Community and event sites often allow user registration so attendees can RSVP, manage their own event submissions, or access member content. Any registered user who has been granted Author access, even a trusted volunteer, represents a potential exploitation vector if their account is compromised.

Multi-author blogs and publications routinely have 5-50 contributor accounts at Author level or above. A phishing attack targeting any one of those accounts gives an external attacker the access needed to exploit this vulnerability.

Membership sites with content submission features frequently assign Author or Contributor roles to members as part of normal site operation.

Sites that previously had contributors may still have inactive Author accounts that were never deactivated. Those accounts are valid authentication credentials for this exploit.

The practical question is not "does my site require login" but rather "do I have any Author-level accounts I cannot fully vouch for." For most sites running The Events Calendar, the honest answer is yes.

What Attackers Can Read

Once an attacker has a valid Author-level session, the exploitation path is straightforward: craft a file import request with a traversal payload targeting sensitive files on the server.

wp-config.php: The Primary Target

wp-config.php is almost always the first file targeted in path traversal attacks against WordPress. It contains:

Database credentials: hostname, database name, username, and password. With these, an attacker can connect to your database directly (if exposed to the network) or exfiltrate its contents.
Authentication keys and salts: these constants are used to sign and verify authentication cookies. An attacker who knows your keys can forge a valid admin session cookie without knowing any password.
Table prefix: useful for constructing targeted SQL queries if the attacker accesses the database separately.
Custom configuration constants: API keys, service credentials, feature flags, or any other secrets your theme or plugins define in wp-config.php.

A single successful read of wp-config.php can give an attacker everything they need to compromise the entire WordPress installation, even without exploiting any additional vulnerabilities.

Other High-Value Targets

Depending on the server configuration, attackers may also target:

.env files: many modern WordPress setups use .env for environment variables. These often contain API keys, payment processor credentials, email service credentials, and other secrets that are far more sensitive than database access.
Server configuration files: php.ini, nginx or Apache config files can reveal hosting details, directory structures, and potential misconfigurations.
SSH keys: if the web server process has read access to SSH key files in the user's home directory, these can enable server-level access.
Other WordPress configuration files: some plugins store credentials or API keys in their own configuration files in predictable locations.

Escalation to Remote Code Execution

Path traversal vulnerabilities are sometimes dismissively characterized as "read-only," as if being able to read arbitrary files is somehow limited. In practice, file-read capabilities often chain into full server compromise.

The most direct escalation path: an attacker reads wp-config.php, extracts database credentials, connects to the database (directly or through a separate vulnerability), and inserts a PHP backdoor that keeps working after the visible infection is cleaned up into the database, which then gets executed when the site renders. This requires database network access, which is not always available, but the credential exposure from wp-config.php still enables a wide range of follow-on attacks.

A more reliable escalation path involves chaining the file-read with a file-upload capability. The attacker uploads a PHP file through The Events Calendar's import functionality or any other file upload vector on the site, then uses the path traversal to read the upload's location and verify execution. This is not always possible but it is a well-understood attack pattern.

Current Patch Status

CVE-2026-3585 is fixed. The Events Calendar 6.15.17.1, released March 9, 2026, closes the flaw. Its changelog describes the fix as stronger file type and location checks during aggregator imports. That patch shipped before this post's original publication date, so the "no patch available" claim that used to run here was already stale on day one.

If your site runs a version older than 6.15.17.1, update immediately regardless of how old the version is. The Events Calendar has shipped multiple releases since, and the current version on WordPress.org is 6.17.4.1. That later version also closes two unrelated, more severe unauthenticated RCE bugs; see our September 2026 writeup for those.

What You Can Do Right Now

Update first. This vulnerability has been patched since March 9, 2026. The steps below are still useful defense in depth, since Author-level account hygiene protects against more than just this one CVE.

Audit Your Author-Level Accounts

This is the highest-leverage action available right now. The vulnerability requires authentication, so reducing the number of valid Author-level credentials limits who can trigger it.

Go to Users > All Users in your WordPress admin and filter by Role > Author. For each account:

Is this account still actively used?
Is the email address associated with it still under the account owner's control?
Does this account need Author-level access, or can it be downgraded to Contributor or Subscriber?

Remove or deactivate any accounts that are not actively needed. Downgrade roles where full Author access is not required. Reset passwords for any accounts where you have doubt about security.

Enable Two-Factor Authentication for Authors

If you cannot remove Author accounts, adding two-factor authentication (2FA) significantly raises the bar for account compromise. Even if an attacker phishes a contributor's password, 2FA prevents them from logging in. Plugins like WP 2FA or two-factor authentication features in security suites can apply this site-wide.

Restrict wp-config.php Access at the Server Level

You can add a layer of protection by preventing web server access to wp-config.php at the server configuration level, separate from WordPress's own access controls. In Apache, adding the following to your .htaccess file prevents direct web requests to the file:

<Files wp-config.php>
order allow,deny
deny from all
</Files>

Note: this does not protect against server-side file reads triggered by PHP code. A path traversal exploit in PHP code can bypass .htaccess restrictions because it is a server-side read, not a web request. But defense in depth is still valuable, since this prevents opportunistic direct-URL access.

Monitor for Suspicious File Access

If your hosting environment supports PHP error logging or web server access logging, watch for requests to AJAX endpoints that include .. sequences in parameters. Many WAFs and security plugins can flag or block path traversal patterns in request parameters.

Consider Temporarily Disabling the Import Feature

If your site does not actively use The Events Calendar's import functionality, you may be able to reduce the attack surface by disabling or restricting access to the import endpoints through your firewall or WAF rules. This is a partial mitigation, the vulnerability exists in the codebase regardless, but limiting who can reach the vulnerable function narrows the attack surface.

How to Tell If You Have Been Compromised

If you ran The Events Calendar 6.15.17 or earlier at any point, and have Author-level accounts you cannot fully account for, it is worth checking for signs of compromise, whether or not you've since updated.

Look for:

Unexpected admin accounts under Users > All Users
Recently modified PHP files: check your file manager or run find /path/to/wordpress -name "*.php" -newer /path/to/reference-file to find files modified in the last 30 days
Unfamiliar content in wp-config.php: any lines you did not add yourself warrant investigation
Outbound connections from your server to unknown IPs: visible in server logs or through your hosting dashboard

If you find evidence of compromise, run a full security scan to assess the damage and determine next steps.

The Broader Pattern: High-Popularity Plugins Are High-Value Targets

CVE-2026-3585 is not unique in the history of WordPress security. Large, widely-deployed plugins attract more researcher attention and more attacker attention than obscure plugins precisely because of their scale. Finding a vulnerability in a plugin with 600,000 installations is exponentially more valuable to an attacker than finding the same vulnerability in a plugin with 6,000 installations.

The same failure shape turned up again later in 2026, in plugins with a different job entirely: a subscriber-level bug in Perfmatters let attackers delete arbitrary files including wp-config.php, and separately, an anonymous form submission was enough to trigger file deletion in Formidable Forms' signatures add-on. Missing path validation on a user-supplied filename keeps producing the same class of bug no matter what the plugin does.

This is a structural property of the WordPress ecosystem. The plugins that provide the most value, and therefore get the most installs, create the largest attack surfaces when they have vulnerabilities. It is not a reason to avoid popular plugins, but it is a reason to monitor their security disclosures closely.

Running automated scans on your WordPress sites helps catch outdated plugin versions before they can be exploited. WP Vanguard checks plugin versions against a vulnerability database of 38,000+ CVEs and flags any matches, no SSH access required.

How the Patch Reached Sites

The fix shipped the normal way: a plugin update on WordPress.org. Sites with automatic plugin updates enabled received 6.15.17.1 without anyone doing anything. Sites with manual updates needed someone to apply it through Plugins, then Installed Plugins, then Update.

If you manage sites with automatic updates disabled, for The Events Calendar or anything else, this is a good prompt to check your current version against the plugin's changelog rather than assuming a staging cycle already caught it.

Scan your site for vulnerable plugin versions | View pricing | Weekly vulnerability report