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 **Description**: WordPress Core <= 6.3.1 – Authenticated (Subscriber+) Arbitrary Shortcode Execution **Affected Versions**: WordPress Core < 6.3.2 **Researcher**: [James Golovich]() & [WhiteCyberSec]() **CVE ID**: Pending **CVSS Score**: 5.4(Medium) **CVSS Vector**: [CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:L/I:L/A:N]() **Fully Patched Version**: 6.3.2 [Wordfence Intelligence Reference]() [Link to Commit ]() 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 **Description**: WordPress Core 5.6-6.3.1 - Reflected Cross-Site Scripting via Application Password Requests **Affected Versions**: WordPress Core < 6.3.2 **Researcher**: [mascara7784]() **CVE ID**: Pending **CVSS Score**: 6.1(Medium) **CVSS Vector**: [CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:C/C:L/I:L/A:N]() **Fully Patched Version**: 6.3.2 [Wordfence Intelligence Reference]() [Link to Commit ]() 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 **Description**: WordPress Core <= 6.3.1 - Authenticated(Contributor+) Sensitive Information Exposure via Comments on Protected Posts **Affected Versions**: WordPress Core < 6.3.2 **Researcher**: [JB Audras(WordPress Security Team)]() & [Rafie Muhammad(Patchstack)]() **CVE ID**: Pending **CVSS Score**: 4.3(Medium) **CVSS Vector**: [CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:L/I:N/A:N]() **Fully Patched Version**: 6.3.2 [Wordfence Intelligence Reference]() [Link to Commit]() 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 **Description**: WordPress Core 4.7.0-6.3.1 - Sensitive Information Exposure via User Search REST Endpoint **Affected Versions**: WordPress Core < 6.3.2 **Researcher**: [Marc Montpas(Automattic)]() **CVE ID**: Pending **CVSS Score**: 5.3(Medium) **CVSS Vector**: [CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:N/A:N]() **Fully Patched Version**: 6.3.2 [Wordfence Intelligence Reference]() [Link to Commit]() 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 **Description**: WordPress Core 4.7.0-6.3.1 - Denial of Service via Cache Poisoning **Affected Versions**: WordPress Core < 6.3.2 **Researcher**: [s5s]() & [raouf_maklouf]() **CVE ID**: Pending **CVSS Score**: 5.3(Medium) **CVSS Vector**: [CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:L]() **Fully Patched Version**: 6.3.2 [Wordfence Intelligence Reference]() [Link to Commit]() 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 **Description**: WordPress Core 6.3-6.3.1 – Authenticated (Contributor+) Stored Cross-Site Scripting via Footnotes Block **Affected Versions**: WordPress Core < 6.3.2 **Researcher**: [Jorge Costa(WordPress Core Team)]() **CVE ID**: Pending **CVSS Score**: 6.4(Medium) **CVSS Vector**: [CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:C/C:L/I:L/A:N]() **Fully Patched Version**: 6.3.2 [Wordfence Intelligence Reference]() [Link to Commit]() 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 **Description**: WordPress Core 5.9-6.3.1 - Authenticated(Contributor+) Stored Cross-Site Scripting via navigation attributes **Affected Versions**: WordPress Core 5.9-6.3.1 **Researcher**: [Rafie Muhammad]() & [Edouard L of Patchstack]() **CVE ID**: Pending **CVSS Score**: 6.4(Medium) **CVSS Vector**: [CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:C/C:L/I:L/A:N]() **Fully Patched Version**: 6.3.2 [Wordfence Intelligence Reference]() [Link to Commit]() 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._ The post [WordPress 6.3.2 Security Release - What You Need to Know]() appeared first on [Wordfence]().

WordPress 6.3.2 Security Release – What You Need to Know