WordPress Core Cross Site Scripting / SQL Injection

2022.08.31
Credit: Khalilov Moe
Risk: Medium
Local: No
Remote: Yes
CVE: N/A
CWE: CWE-89
CWE-79

Description: SQL Injection via Links LIMIT clause Affected Versions: WordPress Core < 6.0.2 Researcher: FVD CVE ID: Pending CVSS Score: 8.0 (High) CVSS Vector:CVSS:3.1/AV:N/AC:H/PR:H/UI:N/S:C/C:H/I:H/A:H Fully Patched Version: 6.0.2 The WordPress Link functionality, previously known as “Bookmarks”, is no longer enabled by default on new WordPress installations. Older sites may still have the functionality enabled, which means that millions of legacy sites are potentially vulnerable, even if they are running newer versions of WordPress. Fortunately, we found that the vulnerability requires administrative privileges and is difficult to exploit in a default configuration. It is possible that 3rd party plugins or themes might allow this vulnerability to be used by editor-level users or below, and in these cases the Wordfence firewall will block any such exploit attempts. Vulnerable versions of WordPress failed to successfully sanitize the limit argument of the link retrieval query in the get_bookmarks function, used to ensure that only a certain number of links were returned. In a default configuration, only the Links legacy widget calls the get_bookmarks function in a way that allows this argument to be set by a user. Legacy widgets involve additional safeguards, and the injection point of the query itself poses additional difficulties, making this vulnerability nontrivial to exploit. Description: Contributor+ Stored Cross-Site Scripting via use of the_meta function Affected Versions: WordPress Core < 6.0.2 Researcher: John Blackbourn CVE ID: Pending CVSS Score: 4.9 (Medium) CVSS Vector: CVSS:3.1/AV:N/AC:H/PR:L/UI:N/S:C/C:L/I:L/A:N Fully Patched Version: 6.0.2 WordPress content creators, such as Contributors, Editors, Authors, and Administrators, have the ability to add custom fields to any page and post created. The purpose of this is to make it possible for site content creators to add and associate additional data to posts and pages. WordPress has several functions available to site owners to display custom fields created and associated with posts and pages. One of these functions is the the_meta function which retrieves the supplied post’s or page’s custom field data, which is stored as post meta data, through the get_post_custom_keys and get_post_custom_values functions. Once the custom fields for a post/page are retrieved, the function outputs the post meta keys and values data as a list. Unfortunately, in versions older than 6.0.2 this data was unescaped on output making it possible for any injected scripts in post meta keys and values to be executed. Due to the fact that any user with access to the post editor can add custom meta fields, users with access to the editor such as contributors could inject malicious JavaScript that executes on any page or post where this function is called. WordPress core does not call the_meta anywhere in its codebase by default. As such this vulnerability does require a plugin or theme that calls the the_meta function, or for this function to have been programmatically added to a PHP file for execution, so the vast majority of site owners are not vulnerable to this issue. The the_meta function is considered deprecated as of 6.0.2 and get_post_meta is the recommended alternative. The Wordfence Threat Intelligence Team deployed a firewall rule to help protect Wordfence Premium, Care & Response customers today. Wordfence Free users will receive the same protection in 30 days on September 29, 2022. Description: Stored Cross-Site Scripting via Plugin Deactivation and Deletion errors Affected Versions: WordPress Core < 6.0.2 Researcher: Khalilov Moe CVE ID: Pending CVSS Score: 4.7 (Medium) CVSS Vector: CVSS:3.1/AV:N/AC:H/PR:N/UI:R/S:C/C:L/I:L/A:N Fully Patched Version: 6.0.2 The final vulnerability involves the error messages displayed when a plugin has been deactivated due to an error, or when a plugin can not be deleted due to an error. As these error messages were not escaped, any JavaScript present in these error messages would execute in the browser session of an administrator visiting the plugins page. This vulnerability would require a separate malicious or vulnerable plugin or other code to be installed on the site, which would typically require an administrator to install it themselves. In almost all cases where this vulnerability might be exploitable an attacker would already have a firm foothold on the vulnerable site. Our built-in XSS rule should block any attempts to generate crafted error messages based on user input to a vulnerable plugin, and the Wordfence scanner will detect any malicious plugins uploaded by an administrator. Conclusion In today’s article, we covered three vulnerabilities patched in the WordPress 6.0.2 Security and Maintenance Release. Most actively used WordPress sites should be patched via automatic updates within the next 24 hours, and any sites that remain vulnerable would only be exploitable under very specific circumstances. We have released a firewall rule to Wordfence Premium, Care, and Response users to protect against any exploits targeting the the_meta function and this rule should become available to Wordfence free users after 30 days, on on September 29, 2022. As always, we strongly recommend updating your site to a patched version of WordPress if it hasn’t been updated automatically. As long as you are running a version of WordPress greater than 3.7, an update is available to patch these vulnerabilities while keeping you on the same major version, so you will not need to worry about compatibility issues. Props to Khalilov Moe, John Blackbourn, & FVD for discovering and responsibly disclosing these vulnerabilities. Special thanks to Wordfence Threat Intelligence Lead Chloe Chamberland for collaborating on this post.


Vote for this issue:
50%
50%


 

Thanks for you vote!


 

Thanks for you comment!
Your message is in quarantine 48 hours.

Comment it here.


(*) - required fields.  
{{ x.nick }} | Date: {{ x.ux * 1000 | date:'yyyy-MM-dd' }} {{ x.ux * 1000 | date:'HH:mm' }} CET+1
{{ x.comment }}

Copyright 2022, cxsecurity.com

 

Back to Top