WordPress 6.3.2 Security Release – What You Need to Know

WordPress Core 6.3.2 was released today, on October 12, 2023. It includes a number of security fixes and additional hardening against commonly exploited vulnerabilities. While all of the vulnerabilities are of Medium severity, several of them are impactful enough to potentially allow site takeover, and thus the 6.3.2 update has the most significant security fixes we’ve seen in a while.

Many of these patches have been backported to every version of WordPress since 4.1, with just a few being backported to the major version in which the functionality was released. WordPress has supported automatic core updates for security releases since WordPress 3.7, and the vast majority of WordPress sites should receive a patch for their major version of WordPress automatically over the next 24 hours. We recommend verifying that your site has been automatically updated to one of the patched versions. Patched versions are available for every major version of WordPress since 4.1, so you can update without risking compatibility issues.

The Wordfence Threat Intelligence Team released two new firewall rules today to protect Wordfence Premium, Wordfence Care, and Wordfence Response customers against the most impactful vulnerabilities patched, and these rules will be available to free Wordfence users in 30 days, on November 11th, 2023.

If your site has not been updated automatically we strongly recommend updating manually as soon as possible, as one of the vulnerabilities patched in this release can be used by an attacker with a low-privileged contributor-level account to take over a site.

Technical Analysis and Overview

As with every WordPress core release containing security fixes, the Wordfence Threat Intelligence team analyzed the code changes in detail to evaluate the impact of these vulnerabilities on our customers, and to ensure our customers remain protected.

No More ShortCode Abuse

WordPress Core is vulnerable to arbitrary shortcode execution in versions up to, and including, 6.3.1 due to a lack of input validation on the ‘shortcode’ parameter in the parse_media_shortcode AJAX function. This allows authenticated attackers, with subscriber-level privileges and above, to execute arbitrary shortcodes.

While this patch does not address a specific vulnerability, it blocks a common vector that enables attackers to exploit vulnerabilities that use shortcodes. Before WordPress 6.3.2, any authenticated user, including subscribers could execute any shortcode by calling the built-in ‘parse-media-shortcode’ AJAX handler.

The changeset in WordPress 6.3.2 restricts this AJAX handler to media shortcodes, and requires the ’embed’ shortcode to be associated with an active post ID that the user can access.

This means that a large range of SQL Injection, Sensitive Information Disclosure, and Remote Code Execution vulnerabilities that required only an active user login can now only be exploited by Contributor-level users or above.

You can find several of the shortcode-based vulnerabilities we reference by searching the Wordfence Intelligence vulnerability database.

Previously our team could not add a firewall rule to prevent the execution of arbitrary shortcodes due to the varying use cases. Fortunately, with this patch and change, the expected behavior of the parse-media-shortcode action has been restricted by WordPress Core, so we were able to create a generic firewall rule that will prevent arbitrary execution of shortcodes that are not in the allowlist from the function. Wordfence Premium, Care, and Response customers received this rule today, while those still on the free version of Wordfence will receive this rule after a 30 day delay on November 11th, 2023.

Reflected Cross-Site Scripting via Application Passwords

WordPress Core is vulnerable to Reflected Cross-Site Scripting via the ‘success_url’ and ‘reject_url’ parameters when requesting application passwords in versions between 5.6 and 6.3.1 due to insufficient input sanitization and output escaping of pseudo protocol URIs. This makes it possible for unauthenticated attackers to inject arbitrary web scripts in pages that execute if they can successfully trick a user into performing an action such as clicking on a link and accepting or rejecting the application password.

WordPress allows applications to request application passwords to be generated for them. WordPress before 6.3.2 fails to validate the redirect URIs used when a password is authorized or rejected, which means that an attacker could generate a URL for an application password request containing data: and javascript: pseduo protocol redirects. If the victim visits this URL on their site and approves or rejects the application password request, they could be redirected to a URI that executes JavaScript on their browser. WordPress 6.3.2 contains a patch for this issue.

As with all Cross-Site Scripting vulnerabilities, this can be used to take over a site by creating malicious administrators and backdoors.

All Wordfence users, including Wordfence free, Wordfence Premium, Wordfence Care, and Wordfence Response users are protected against this vulnerability by the Wordfence Firewall’s Built-in Cross-Site Scripting protection. Additionally, Wordfence disables application passwords by default.

Comment Visibility

WordPress Core is vulnerable to Sensitive Information Exposure in versions up to, and including, 6.3.1 via the comments listing. This allows authenticated users, with contributor-level privileges or above, to view comments on protected posts.

Prior to WordPress 6.3.2, it was possible for users to view comments on posts even when they did not have access to those posts. While this is in most cases a relatively low-impact issue, WordPress 6.3.2 contains a patch protecting the privacy of comments on private or protected posts..

Removing POP Chains

While WordPress Core has not had a known Object Injection vulnerability for some time, Object Injection vulnerabilities in various plugins and themes are regularly discovered by researchers, including Wordfence’s own in-house Threat Intelligence team.

All Object Injection vulnerabilities require POP chains in order to be successful. Prior to WordPress 6.3.2, potential POP chains were present in the WP_Theme, WP_Block_Type_Registry, WP_Block_Patterns_Registry, Requests/Session, Request/Iri, and Requests/Hooks classes. While we were unable to develop a functioning exploit for these in the time available, the patches involved indicate that they are designed to prevent unexpected Object Unserialization that could lead to Remote Code Execution. Credit to Marc Montpas of Automattic for discovering the vulnerable POP chains.

The Wordfence Threat Intelligence Team will continue reverse engineering this patch to determine if a firewall rule will be necessary, but at this time it has not received an official vulnerability entry because it is not technically a vulnerability on its own.

No More Searching By Email

WordPress Core is vulnerable to Sensitive Information Exposure in versions between 4.7.0 and 6.3.1 via the User REST endpoint. While the search results do not display user email addresses unless the requesting user has the ‘list_users’ capability, the search is applied to the user_email column. This can allow unauthenticated attackers to brute force or verify the email addresses of users with published posts or pages on the site.

While WordPress prior to 6.3.2 did not directly display user email addresses to users without the “list_users” capability, it still searched the user email column in wp_users. This meant that it was possible to brute-force search or verify the email address of any user with a published post or page by including the partial email address in the search parameter, potentially impacting user privacy. The patch for this limits the search columns for users without the “list_users” capability to only the columns displayed.

Cache Poisoning Denial of Service

WordPress Core is vulnerable to Denial of Service via Cache Poisoning in versions between 4.7.0 and 6.3.1. In cases where the X-HTTP-Method-Override header was sent in a request to a REST endpoint and the endpoint returned a 4xx error, the error could be cached, resulting in denial of service.

Responses to REST API requests are not cached for logged-in users, but WordPress Core before 6.3.2 had an edge case where, in heavily cached configurations, an unauthenticated attacker could send a request to the REST API using the X-HTTP-Method-Override header to a public endpoint and receive a 4xx error, either because the endpoint restricts access to those methods or does not support them at all. In cases where the error is cached, any other unauthenticated visitors attempting to retrieve data from that endpoint would see the cached 4xx error.

Contributor+ Stored Cross-Site Scripting in Footnotes

WordPress Core is vulnerable to Stored Cross-Site Scripting via the footnotes block in versions between 6.3 and 6.3.1 due to insufficient input sanitization and output escaping on the footnotes block. This makes it possible for authenticated attackers with contributor-level and above permissions to inject arbitrary web scripts in pages that will execute whenever a user accesses an injected page.

WordPress prior to 6.3.2 did not adequately sanitize the content of footnote blocks, allowing authenticated users, with Contributor-level privileges or above, to insert JavaScript that would execute when a page containing the footnotes was visited. While input is partially escaped on the client-side, it is possible to intercept a request and add unescaped script tags to the footnote metadata. WordPress has released a patch for this vulnerability in 6.3.2.

As with all Cross-Site Scripting vulnerabilities, this can be used to take over a site by creating malicious administrators and backdoors.

We have released a firewall rule to protect Wordfence Premium, Wordfence Care, and Wordfence Response users against this vulnerability, and free Wordfence users will receive the same protection in 30 days, on November 11th, 2023.

Contributor+ Stored Cross-Site Scripting in Navigation Links

WordPress Core is vulnerable to Stored Cross-Site Scripting via the arrow navigation block attributes in versions between 5.9 and 6.3.1 due to insufficient input sanitization and output escaping. This makes it possible for authenticated attackers with contributor-level privileges and above to inject arbitrary web scripts in pages that will execute whenever a user accesses an injected page.

WordPress Core’s Block Editor includes a navigation block that includes arrows or chevrons to display previous and next posts. WordPress before 6.3.2 failed to adequately check or sanitize the attribute defining whether to use an arrow or a chevron. As a result, any user with access to the post editor could insert malicious JavaScript into the arrow navigation element, which would be executed whenever a visitor accessed that page. As with all Cross-Site Scripting vulnerabilities, this can be used to take over a site by creating malicious administrators and backdoors. We were unable to successfully exploit this vulnerability at the time of publication, but will update this post if we are able to achieve a proof of concept, along with a firewall rule if needed to protect our users.

Conclusion

WordPress 6.3.2 includes patches for 5 Medium-Severity vulnerabilities as well as hardening against separate Object Injection vulnerabilities found in third-party plugins and themes. Several of these vulnerabilities are trivial to exploit and we recommend updating immediately if your site has not yet automatically done so.

We have released firewall rules to protect Wordfence Premium, Wordfence Care, and Wordfence Response customers against the most impactful vulnerabilities and these rules will be available to free Wordfence users in 30 days, on November 11th, 2023.

If you know someone who uses WordPress and isn’t keeping it automatically updated, we recommend sharing this advisory with them to ensure their site remains secure, as several of 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.

Special thanks to the security researchers who responsibly disclosed these vulnerabilities, as well as to Threat Intelligence Lead Chloe Chamberland for her assistance with this article and for writing the firewall rules to protect Wordfence customers.

This article was written by Ramuel Gall, a former Wordfence Senior Security Researcher.