“Never Assume Anything” – Unauthenticated Stored Cross-Site Scripting Vulnerability Exposed in 14 Email Logging Plugins

“Never Assume Anything” – that is the 4th Guiding Principle written in the Security section of the WordPress Common APIs Handbook for developers. When it comes to WordPress plugin security, assumptions can be dangerous. This became evident when the Wordfence Threat Intelligence team discovered an Unauthenticated Stored Cross-Site Scripting (XSS) vulnerability in 14 different email logging plugins. The common thread? An assumption that the contents of emails generated within a WordPress instance could not be influenced by external actors. This oversight potentially exposed over 600,000 users to significant security risks.

We contacted all affected vendors after initial discovery between June 4, 2023 and June 11, 2023. Some developers were responsive while others were not, however all plugins except for one received updates to address these vulnerabilities.

All Wordfence Premium, Wordfence Care, and Wordfence Response customers, as well as those still using the free version of our plugin, are protected against any exploits targeting these vulnerabilities by the Wordfence firewall’s built-in Cross-Site Scripting protection.

Vulnerability Overview

Affected Plugins

Below is a table detailing the affected plugins, along with their respective slugs, CVEs, links, reported dates, disclosed dates, and fixed versions.

Technical Analysis

Our investigation began with identifying the easiest and most common way to get user-supplied input into an email generated by the WordPress instance: contact forms. Often made accessible to unauthenticated site visitors, we found that input submitted via the Contact Form 7 plugin’s default contact form (a plugin used by over 5 million users), was not escaped when displayed within the email logging page of any of the 14 plugins we examined. This opened the door to an unauthenticated stored XSS attack.

Note that this vulnerability cannot be exploited without the presence of the vulnerable email logging plugins. While we used Contact Form 7 to provide a contact form for our proof-of-concept, it’s important to clarify that Contact Form 7, by itself, is not vulnerable and does sanitize its output. The vulnerability arises when a contact form plugin is used in combination with one of the email logging plugins mentioned in this post, which do not sanitize their output. Therefore, it is these email logging plugins that are vulnerable in this scenario, not Contact Form 7.

All plugins affected by this vulnerability have a feature designed to display any emails sent by the WordPress instance where they are installed. For some of these plugins, this is the primary feature, and for others this is a secondary feature, which may need to be enabled.

In this vulnerability analysis, we will be highlighting Post SMTP, an SMTP plugin for WordPress that includes email logging functionality (enabled by default) which is used by over 300,000 users.

Post SMTP Email Log Settings

We replicated a typical WordPress site contact form by entering the [contact-form-7] shortcode into a WordPress page. We then accessed this page as an unauthenticated user and entered the payload into the ‘Your name’, ‘Subject’, and ‘Your message’ fields.

The default Contact Form 7 contact form with XSS payloads entered into the form fields

Then, as an administrator, we navigated to the Post SMTP Email Log page where the payload in the ‘Subject’ field immediately fired.

XSS payload in the ‘Subject’ field triggers upon access to the administrative Email Log page

Clicking on the ‘View’ link for the email log entry caused the payload in all fields to execute.

XSS payload in the ‘Your name’ field triggers upon access to the administrative Email Log page

XSS payload in the ‘Your message’ field triggers upon access to the administrative Email Log page

Conclusion

In this blog post, we highlighted a significant vulnerability affecting a large number of WordPress users. The fact that so many plugins providing the same functionality were vulnerable to the same attack method suggests a blind spot in the plugin developers’ security considerations. The potential for malicious input from an email generated via a contact form was seemingly overlooked.

If exploited, an XSS vulnerability of this nature can lead to a complete site takeover, especially on WordPress sites that have not implemented the suggestions from the WordPress hardening guide. This vulnerability underscores the importance of not only keeping your plugins updated but also ensuring that your site is properly hardened against potential attacks. This is a stark reminder that when it comes to security, we must never assume anything.

We encourage WordPress users to verify that their sites are updated to the latest patched version if an affected plugin is being used.

All Wordfence users, including those running Wordfence Premium, Wordfence Care, and Wordfence Response, as well as sites still running the free version of Wordfence, are fully protected against this vulnerability.

If you know someone who uses any of these plugins on their site, we recommend sharing this advisory with them to ensure their site remains secure, as these vulnerabilities pose a significant risk.

For security researchers looking to disclose vulnerabilities responsibly and obtain a CVE ID, you can submit your findings to Wordfence Intelligence and potentially earn a spot on our leaderboard.