Understanding CVE-2026-15026 in a WordPress Plugin

CVE-2026-15026 is the identifier for a security flaw in the WordPress plugin Import and export users and customers. The flaw lets a logged-in user with at least Subscriber-level access read certain WordPress post titles and content without proper permission. A Subscriber is one of WordPress’s lowest-access roles. Subscribers can manage their own profile and read site content.

The vulnerability affects plugin versions through 2.4.0. The plugin’s release history documents a fix in version 2.4.1; the WordPress.org listing showed version 2.5.8 when checked on October 24, 2026. Site owners should update to a current release and assess whether the vulnerable version exposed restricted content. The flaw is an information disclosure issue, not an anonymous site takeover.

How the flaw exposed post content

The plugin’s vulnerable code handled a request related to email templates. The CVE record says an authenticated user could reach an admin page with the post_type=acui_email_template parameter and obtain a WordPress nonce, a token commonly used to help protect requests against cross-site request forgery. The user could then send a background request to the plugin’s AJAX action and try different post IDs to retrieve titles and raw content.

A nonce does not establish that a user is allowed to read the requested data. The core failure was that the request handler did not adequately check the user’s authorization before returning post content. The CVE describes the action as email_template_selected; the plugin’s changelog refers to the handler as acui_email_template_selected.

The disclosed data could include drafts, private posts, or scheduled posts. It could also include password-protected posts and content in custom post types. A custom post type is a way for WordPress plugins to store records other than standard posts and pages. For example, a site that stores orders or CRM records as custom post types could have exposed content in those records. The CVE does not establish that every site stores sensitive information this way, or that every record on an affected site was exposed. See the NVD vulnerability record for the described access requirements and impact.

Affected versions and severity

CVSS scores describe how severe a vulnerability is. The 4.3 score indicates a low impact on confidentiality, with no stated impact on data integrity or service availability. NVD attributes that score to Wordfence, the CVE Numbering Authority for this record. NVD says it has not issued a separate assessment. A Medium score does not mean every affected site faces the same risk. The risk depends in part on what restricted content the site stores in posts and custom post types.

The available CVE record does not establish a confirmed exploitation campaign or show that a particular site was accessed. It also does not describe arbitrary code execution, account creation, or changes to site data. Those limits matter when assessing an incident: the documented risk is unauthorized reading by a low-privilege, authenticated user.

What site owners should do

Check the installed plugin version on every WordPress site that uses it. If a site runs version 2.4.0 or earlier, update the plugin. The official WordPress.org release history documents the fix in 2.4.1. The handler checks for the edit_others_posts capability, a WordPress permission that lets a user edit other users’ posts, and verifies that the requested post belongs to the email-template post type. The changelog also says the plugin stopped generating the related nonce on admin screens where the user lacks permission. Because the directory listed version 2.5.8 in October 2026, check the plugin page for the latest release rather than stopping at the minimum fixed version.

If an update cannot happen promptly, disable the plugin temporarily if the site can operate without it, and remove or restrict unnecessary accounts. Blocking new registrations alone does not address accounts that already exist. Once the plugin is updated, consider what the vulnerable code could have returned: review whether the site stores restricted or sensitive information in posts or custom post types.

If the site ran a vulnerable version, review available WordPress, hosting, and security logs for suspicious requests from logged-in users to admin AJAX endpoints. The public record does not describe a specific log entry to look for, so finding no obvious match does not prove that no one accessed the content. If sensitive information might have been exposed, assess notification or disclosure duties under the site’s policies and applicable laws. The CVE alone cannot determine whether a particular site experienced exposure or what obligations apply.

What I'm building

Delegate tasks. Get software.

Give Vroni a GitHub issue, bug report, spec, or rough idea. It reads the repo, plans the change, writes code, runs checks, and works toward a review-ready pull request.

Take a look at vroni.com