This article is a part of our Vulnerability Database (back to index)
Cross-site Scripting occurrences in Wordpress
Cross-site scripting vulnerability in WordPress versions prior to 6.0.3 allows a remote unauthenticated attacker to inject an arbitrary script . (2022-12-05, CVE-2022-43497)
Cross-site scripting vulnerability in WordPress versions prior to 6.0.3 allows a remote unauthenticated attacker to inject an arbitrary script . (2022-12-05, CVE-2022-43500)
WordPress is a free and open-source content management system written in PHP and paired with a MariaDB database. Low-privileged authenticated users (like author) in WordPress core are able to execute JavaScript/perform stored XSS attack, which can affect high-privileged users. This has been patched in WordPress version 5.8.3. Older affected versions are also fixed via security release, that go back till 3.7.37. We strongly recommend that you keep auto-updates enabled. There are no known workarounds for this issue. (2022-01-06, CVE-2022-21662)
WordPress is a free and open-source content management system written in PHP and paired with a MySQL or MariaDB database. ### Impact The issue allows an authenticated but low-privileged user (like contributor/author) to execute XSS in the editor. This bypasses the restrictions imposed on users who do not have the permission to post `unfiltered_html`. ### Patches This has been patched in WordPress 5.8, and will be pushed to older versions via minor releases (automatic updates). It's strongly recommended that you keep auto-updates enabled to receive the fix. ### References https://wordpress.org/news/category/releases/ https://hackerone.com/reports/1142140 ### For more information If you have any questions or comments about this advisory: * Open an issue in [HackerOne](https://hackerone.com/wordpress) (2021-09-09, CVE-2021-39201)
WordPress is a free and open-source content management system written in PHP and paired with a MySQL or MariaDB database. In affected versions the widgets editor introduced in WordPress 5.8 beta 1 has improper handling of HTML input in the Custom HTML feature. This leads to stored XSS in the custom HTML widget. This has been patched in WordPress 5.8. It was only present during the testing/beta phase of WordPress 5.8. (2021-09-09, CVE-2021-39202)
WordPress before 5.5.2 allows stored XSS via post slugs. (2020-11-02, CVE-2020-28038)
WordPress before 5.5.2 allows XSS associated with global variables. (2020-11-02, CVE-2020-28034)
In affected versions of WordPress, a special payload can be crafted that can lead to scripts getting executed within the search block of the block editor. This requires an authenticated user with the ability to add content. This has been patched in version 5.4.1, along with all the previously affected versions via a minor release (5.3.3, 5.2.6, 5.1.5, 5.0.9, 4.9.14, 4.8.13, 4.7.17, 4.6.18, 4.5.21, 4.4.22, 4.3.23, 4.2.27, 4.1.30, 4.0.30, 3.9.31, 3.8.33, 3.7.33). (2020-04-30, CVE-2020-11030)
In affected versions of WordPress, a vulnerability in the stats() method of class-wp-object-cache.php can be exploited to execute cross-site scripting (XSS) attacks. This has been patched in version 5.4.1, along with all the previously affected versions via a minor release (5.3.3, 5.2.6, 5.1.5, 5.0.9, 4.9.14, 4.8.13, 4.7.17, 4.6.18, 4.5.21, 4.4.22, 4.3.23, 4.2.27, 4.1.30, 4.0.30, 3.9.31, 3.8.33, 3.7.33). (2020-04-30, CVE-2020-11029)
In affected versions of WordPress, files with a specially crafted name when uploaded to the Media section can lead to script execution upon accessing the file. This requires an authenticated user with privileges to upload files. This has been patched in version 5.4.1, along with all the previously affected versions via a minor release (5.3.3, 5.2.6, 5.1.5, 5.0.9, 4.9.14, 4.8.13, 4.7.17, 4.6.18, 4.5.21, 4.4.22, 4.3.23, 4.2.27, 4.1.30, 4.0.30, 3.9.31, 3.8.33, 3.7.33). (2020-04-30, CVE-2020-11026)
In affected versions of WordPress, a cross-site scripting (XSS) vulnerability in the navigation section of Customizer allows JavaScript code to be executed. Exploitation requires an authenticated user. This has been patched in version 5.4.1, along with all the previously affected versions via a minor release (5.3.3, 5.2.6, 5.1.5, 5.0.9, 4.9.14, 4.8.13, 4.7.17, 4.6.18, 4.5.21, 4.4.22, 4.3.23, 4.2.27, 4.1.30, 4.0.30, 3.9.31, 3.8.33, 3.7.33). (2020-04-30, CVE-2020-11025)
In wp-includes/formatting.php in WordPress 3.7 to 5.3.0, the function wp_targeted_link_rel() can be used in a particular way to result in a stored cross-site scripting (XSS) vulnerability. This has been patched in WordPress 5.3.1, along with all the previous WordPress versions from 3.7 to 5.3 via a minor release. (2019-12-27, CVE-2019-20042)
In WordPress before 5.3.1, authenticated users with lower privileges (like contributors) can inject JavaScript code in the block editor, which is executed within the dashboard. It can lead to an admin opening the affected post in the editor leading to XSS. (2019-12-26, CVE-2019-16781)
WordPress users with lower privileges (like contributors) can inject JavaScript code in the block editor using a specific payload, which is executed within the dashboard. This can lead to XSS if an admin opens the post in the editor. Execution of this attack does require an authenticated user. This has been patched in WordPress 5.3.1, along with all the previous WordPress versions from 3.7 to 5.3 via a minor release. Automatic updates are enabled by default for minor releases and we strongly recommend that you keep them enabled. (2019-12-26, CVE-2019-16780)
WordPress before 5.2.4 is vulnerable to a stored XSS attack to inject JavaScript into STYLE elements. (2019-10-17, CVE-2019-17672)
WordPress before 5.2.4 is vulnerable to stored XSS (cross-site scripting) via the Customizer. (2019-10-17, CVE-2019-17674)
WordPress before 5.2.3 allows reflected XSS in the dashboard. (2019-09-11, CVE-2019-16221)
WordPress before 5.2.3 allows XSS in media uploads because wp_ajax_upload_attachment is mishandled. (2019-09-11, CVE-2019-16217)
WordPress before 5.2.3 allows XSS in post previews by authenticated users. (2019-09-11, CVE-2019-16223)
WordPress before 5.2.3 allows XSS in shortcode previews. (2019-09-11, CVE-2019-16219)
WordPress before 5.2.3 allows XSS in stored comments. (2019-09-11, CVE-2019-16218)
WordPress before 5.2.3 has an issue with URL sanitization in wp_kses_bad_protocol_once in wp-includes/kses.php that can lead to cross-site scripting (XSS) attacks. (2019-09-11, CVE-2019-16222)
In WordPress before 4.9.9 and 5.x before 5.0.1, contributors could modify new comments made by users with greater privileges, possibly causing XSS. (2018-12-14, CVE-2018-20153)
In WordPress before 4.9.9 and 5.x before 5.0.1, crafted URLs could trigger XSS for certain use cases involving plugins. (2018-12-14, CVE-2018-20150)
In WordPress before 4.9.9 and 5.x before 5.0.1, when the Apache HTTP Server is used, authors could upload crafted files that bypass intended MIME type restrictions, leading to XSS, as demonstrated by a .jpg file without JPEG data. (2018-12-14, CVE-2018-20149)
Before WordPress 4.9.5, the version string was not escaped in the get_the_generator function, and could lead to XSS in a generator tag. (2018-04-16, CVE-2018-10102)
WordPress before 4.9.2 has XSS in the Flash fallback files in MediaElement (under wp-includes/js/mediaelement). (2018-01-18, CVE-2018-5776)
Why Cross-site Scripting can be dangerous
Cross site scripting is an attack where a web page executes code that is injected by an adversary. It usually appears, when users input is presented. This attack can be used to impersonate a user, take over control of the session, or even steal API keys.
The attack can be executed e.g. when you application injects the request parameter directly into the HTML code of the page returned to the user:
https://server.com/confirmation?message=Transaction+Complete
what results in:
<span>Confirmation: Transaction Complete</span>
In that case the message can be modified to become a valid Javascript code, e.g.:
https://server.com/confirmation?message=<script>dangerous javascript code here</script>
and it will be executed locally by the user's browser with full access to the user's personal application/browser data:
<span>Confirmation: <script>dangerous javascript code here</script></span>