Wordpress 6.0.3 Patch Analysis
Summary
WordPress Core is the most popular web Content Management System (CMS). This free and open-source CMS written in PHP allows developers to develop web applications quickly by allowing customization through plugins and themes. WordPress can work in both a single-site or a multisite installation.
WordPress version 6.0.3 was released on 17 October 2022. As it is a security release, it contains only security patches for multiple vulnerabilities. Rémy Marot and I have analyzed some of these patches and this article focuses on three of these patches.
Stored XSS in WordPress Core via Comment Editing
Wordpress is an OpenSource software, and its code is available on Github. A Github feature allows us to compare the differences between two branches: 6.0.2 and 6.0.3.
The modifications are not too important and the commits / modifications messages are explicit enough to associate a commit to a fix :
With the following information:
- Vulnerability name: “Stored XSS in WordPress Core via Comment Editing”
- Commit message: “Comments: Apply kses when editing comments.”
- The modified file: “wp-includes/comment.php”
It is understandable that comment editing enables stored XSS in Wordpress.
The default Wordpress installation contains a demo “Hello World” article that also contains a comment:
Simply edit the comment with a user having one of the following privileges :
- Administrator
- Editor
Because these are the only privileges that have the necessary “unfiltered_html” capabilities to inject HTML code.
Insert a payload such as “<svg onload=alert(1)>” in the comment :
This executes the payload directly on the page of the article where the comment appeared :
An unauthenticated user can exploit this vulnerability with editor or administrator privileges.
Version 6.0.3 fixes this vulnerability by stripping the payload through “add_filter” function :
Sender’s email address is exposed in wp-mail.php & Stored XSS via wp-mail.php
As for the previously described vulnerability, we can continue to associate commits to vulnerabilities.
To give some context to this vulnerability, you should know that it is possible to post articles on WordPress by email.
The principle is simple: you configure WordPress to access a specific email address via the POP protocol. When a user sends an email to the configured address, WordPress automatically creates an article with the subject of the email as the article title and the body of the email as its content.
This feature doesn’t seem to be used often, at least without an additional plugin. The first step is to configure the “Post by Email” feature in the administration interface :
Once configured, it is possible to access the page http://wordpress/wp-mail.php even without authentication. Accessing this page triggers the mail harvesting function and display a summary, which also has the effect of leaking the sender’s email.
Once the harvesting task completes, Wordpress automatically creates posts according to the following conditions:
- If a user is associated with the sender’s email, the post will be created
- If the user has the necessary privileges, the post will be automatically published. If not, the post will be pending - Otherwise the article is created with the admin user but it remains pending
The payload automatically executes on the page of the article or on the homepage of the blog if the article appears there.
An unauthenticated user can exploit this vulnerability, but it still requires them to know the email used for the publications.
Version 6.0.3 fixes this vulnerability by removing the display of the sender in the “wp-mail.php” page and by not creating the post if it contains a payload.
