Affected Versions: WordPress Core < 6.0.3 and Gutenberg < 14.3.1
Common Vulnerability Scoring System: 6.4 (Medium)
WordPress allows any user that can edit posts, to add a block linking to an RSS feed. While the contents of any feed imported this way are escaped, errors in retrieving the feed would be displayed on the page containing the feed. These included the error status code and content-type header. This means that a contributor-level attacker could create a page on a site they controlled that returned an error code and a malicious script in the content-type response header. They could then add a post containing an RSS block linking to their malicious “feed” and submit it for review. When an administrator previewed the post, the malicious script in the Content-Type header would be executed in their browser.
Authenticated Stored Cross-Site Scripting via Search Block
Affected Versions: WordPress Core < 6.0.3 and Gutenberg < 14.3.1
Common Vulnerability Scoring System: 6.4 (Medium)
It is possible for users that can edit posts to inject malicious JavaScript via the Search Block”s Text color and Background color attributes. Doing so requires bypassing the filtering provided by the “safecss_filter_attr” function and is not trivial.
Authenticated Stored Cross-Site Scripting via Featured Image Block
Affected Versions: WordPress Core < 6.0.3 and Gutenberg < 14.3.1
Common Vulnerability Scoring System: 6.4 (Medium)
It is possible for users that can edit posts to inject malicious JavaScript via the Featured Image block. Doing so requires bypassing the filtering provided by the “safecss_filter_attr” function and is not trivial. A similar issue also appears to have been patched in the Navigation block, though it was not announced and may not be exploitable.
Authenticated Stored Cross-Site Scripting in Widget Block
Affected Versions: WordPress Core < 6.0.3 and Gutenberg < 14.3.1
Common Vulnerability Scoring System: 4.8 (Medium)
It is possible for administrator-level users to inject malicious JavaScript via the Widget Group “title” attribute. This is unlikely to be exploited as administrator-level users typically have a number of other ways to add arbitrary scripts to a website.
Stored XSS via wp-mail.php
Affected Versions: WordPress Core < 6.0.3
Common Vulnerability Scoring System: 7.2 (High)
In WordPress, site owners have the ability to create posts by sending emails to the target WordPress site. These requests are processed through the /wp-mail.php file which uses wp_insert_post () to add the emailed post to the target website. This functionality didn’t check what level the user was sending the request and therefore did not perform any sanitization on the submitted post data. This meant that users without the unfiltered_html capability, with access to submitting posts via email, could inject malicious JavaScript into posts that would execute whenever someone accessed the post. WordPress now sets any user submitting a post via email to the user ID of 0 which will ensure that all posts pass through wp_kses. This feature is disabled by default, so most installations likely are not vulnerable.
Authenticated Stored Cross-Site Scripting via Customizer
Affected Versions: WordPress Core < 6.0.3
Common Vulnerability Scoring System: 5.5 (Medium)
It is possible for administrator-level users to add malicious JavaScript to the Blog Name via the Customizer that will execute in the browser of any site visitor. This is unlikely to be exploited as administrator-level users typically have a number of other ways to add arbitrary scripts to a website.
Affected Versions: WordPress Core < 6.0.3
Common Vulnerability Scoring System: 5.5 (Medium)
It is possible for users with the “unfiltered_html” capability, including administrators and editors, to add malicious JavaScript to existing comments using the comment editor. This is unlikely to be exploited as administrator-level users typically have a number of other ways to add arbitrary scripts to a website.
Reflected Cross-Site Scripting via SQL Injection in Media Library
Affected Versions: WordPress Core < 6.0.3
Common Vulnerability Scoring System: 8.8 (High)
It is possible to craft a search query via the media library that results in a malicious JavaScript being echoed out onto the page. As it is possible to generate a link to the media library with the search query pre-populated via the “s” parameter, this can be used to perform a reflected Cross-Site Scripting (XSS) attack. While this would require social engineering to exploit and crafting an appropriate payload is nontrivial, the attacker does not need to be authenticated, making this potentially the most exploitable vulnerability patched in this release. We may update our assessment if a proof of concept becomes available.
SQL Injection via WP_Date_Query
Affected Versions: WordPress Core < 6.0.3
Common Vulnerability Scoring System: 8.8 (High)
The “sanitize_query” function used in the “WP_Date_Query ” class failed to sanitize all relations where it was expecting “AND” or “OR” in the query. It is possible that a third-party plugin or theme might perform a date query in an unsafe way that resulted in SQL injection, though WordPress core is not vulnerable itself. This is similar to the fixes released back in version 5.8.3.
Cross-Site Request Forgery via wp-trackback.php
Affected Versions: WordPress Core < 6.0.3
Common Vulnerability Scoring System: 8.8 (High)
Similar to the above XSS via wp-mail.php, the Trackback functionality of WordPress did not explicitly state the intended user identity which means that any request to wp-trackback.php would assume the identity of the user whose cookies are sent with the request. This would make it possible for an unauthenticated user to trigger a trackback assuming the identity of another user, granted they could trick that other user into performing the action. In new versions of WordPress, the identity will always be a non-existent user with the ID of 0, which represents an unauthenticated user.
Shared User Instance Weakness
Affected Versions: WordPress Core < 6.0.3
Common Vulnerability Scoring System: 3.7 (Low)
This fix appears to have been necessary to safely use the wp_set_current_user ( 0 ); method to patch the previously mentioned XSS and CSRF in wp-mail.php and wp-trackback.php vulnerabilities. The previous functionality may have resulted in third party plugins or themes using the wp_set_current_user function in a way that could lead to privilege escalation and users being able to perform more actions than originally intended. We may update our assessment if a proof of concept becomes available.
Post Author Email Disclosure via wp-mail.php
Affected Versions: WordPress Core < 6.0.3
Common Vulnerability Scoring System: 5.3 (Medium)
The post by email functionality has the ability to enable logging. This can contain a post author’s email address which can be considered sensitive information and has the potential to be publicly accessible. This feature is disabled by default, so most installations likely are not vulnerable.
Data Exposure via the REST Terms/Tags Endpoint
Affected Versions: WordPress Core < 6.0.3
Common Vulnerability Scoring System: 4.3 (Medium)
The REST API endpoint for terms and tags did not perform enough validation on the user requesting information about terms and tags for a given post. This made it possible for users with access to terms and tags, such as a contributor, to determine those details on all posts not belonging to them, even when in a private status. This does not reveal critical information, and as such it is not likely to be exploited.
Information Disclosure via Multi-Part Email Content Leakage in wp-mail.php
Affected Versions: WordPress Core < 6.0.3
Common Vulnerability Scoring System: 3.7 (Low)
In cases where wp-mail was used to send multiple emails or multi-part emails within a single request, the email “altBody” (frequently used to provide a text alternative to HTML-formatted emails) was not cleared between messages, which could result in users receiving message contents intended for other recipients. While this would require a plugin configured to send multiple messages with altBody text and would be almost impossible to exploit on purpose, it could still lead to exposure of highly sensitive information.
Open Redirect via wp_nonce_ays
Affected Versions: WordPress Core < 6.0.3
Common Vulnerability Scoring System: 4.7 (Medium)
It was possible to generate a link with an invalid nonce and the _wp_http_referer query string parameter set to an external site. If an attacker was able to trick a logged-in user into clicking on the crafted link, they would be redirected to the external site.
