The Elements Kit Lite and Elements Kit Pro WordPress Plugins before 2.2.0 have a number of widgets that are vulnerable to stored Cross-Site Scripting (XSS) by lower-privileged users such as contributors, all via a similar method.

The Contact Form & Lead Form Elementor Builder WordPress plugin before 1.6.4 does not sanitise and escape some lead values, which could allow unauthenticated users to perform Cross-Site Scripting attacks against logged in admin viewing the inserted Leads

The WordPress Multisite User Sync/Unsync WordPress plugin before 2.1.2 does not sanitise and escape the wmus_source_blog and wmus_record_per_page parameters before outputting them back in attributes, leading to Reflected Cross-Site Scripting issues

The PDF Flipbook, 3D Flipbook WordPress – DearFlip WordPress plugin before 1.7.10 does not escape the class attribute of its shortcode before outputting it back in an attribute, which could allow users with a role as low as Contributor to perform Stored Cross-Site Scripting attacks

The WooCommerce Upload Files WordPress plugin before 59.4 ran a single sanitization pass to remove blocked extensions such as .php. It was possible to bypass this and upload a file with a PHP extension by embedding a "blocked" extension within another "blocked" extension in the "wcuf_file_name" parameter. It was also possible to perform a double extension attack and upload files to a different location via path traversal using the "wcuf_current_upload_session_id" parameter.

The WP Login Security and History WordPress plugin through 1.0 did not have CSRF check when saving its settings, not any sanitisation or validation on them. This could allow attackers to make logged in administrators change the plugin's settings to arbitrary values, and set XSS payloads on them as well

The Newsmag WordPress theme before 5.0 does not sanitise the td_block_id parameter in its td_ajax_block AJAX action, leading to an unauthenticated Reflected Cross-site Scripting (XSS) vulnerability.

The mediamaticAjaxRenameCategory AJAX action of the Mediamatic WordPress plugin before 2.8.1, available to any authenticated user, does not sanitise the categoryID parameter before using it in a SQL statement, leading to an SQL injection

The Business Directory Plugin – Easy Listing Directories for WordPress WordPress plugin before 5.11.2 suffered from lack of sanitisation in the label of the Form Fields, leading to Authenticated Stored Cross-Site Scripting issues across various pages of the plugin.

Low privileged users can use the AJAX action 'cp_plugins_do_button_job_later_callback' in the Login as User or Customer (User Switching) WordPress plugin before 1.8, to install any plugin (including a specific version) from the WordPress repository, as well as activate arbitrary plugin from then blog, which helps attackers install vulnerable plugins and could lead to more critical vulnerabilities like RCE.

The 404 to 301 – Redirect, Log and Notify 404 Errors WordPress plugin before 3.0.9 does not have CSRF check in place when cleaning the logs, which could allow attacker to make a logged in admin delete all of them via a CSRF attack

Gridpro Request Management for Windows Azure Pack before 2.0.7912 allows Directory Traversal for remote code execution, as demonstrated by ..\\ in a scriptName JSON value to ServiceManagerTenant/GetVisibilityMap.

In the Amazon AWS WorkSpaces client 3.0.10 through 3.1.8 on Windows, argument injection in the workspaces:// URI handler can lead to remote code execution because of the Chromium Embedded Framework (CEF) --gpu-launcher argument. This is fixed in 3.1.9.

The WPcalc WordPress plugin through 2.1 does not sanitize user input into the 'did' parameter and uses it in a SQL statement, leading to an authenticated SQL Injection vulnerability.

In the Orange Form WordPress plugin through 1.0, the process_bulk_action() function in "admin/orange-form-email.php" performs an unprepared SQL query with an unsanitized parameter ($id). Only admin can access the page that invokes the function, but because of lack of CSRF protection, it is actually exploitable and could allow attackers to make a logged in admin delete arbitrary posts for example

The WP User Manager WordPress plugin before 2.6.3 does not ensure that the user ID to reset the password of is related to the reset key given. As a result, any authenticated user can reset the password (to an arbitrary value) of any user knowing only their ID, and gain access to their account.

Unvaludated input in the 301 Redirects - Easy Redirect Manager WordPress plugin, versions before 2.51, did not sanitise its "Redirect From" column when importing a CSV file, allowing high privilege users to perform SQL injections.

The Shortcodes Ultimate WordPress plugin before 5.10.2 allows users with Contributor roles to perform stored XSS via shortcode attributes. Note: the plugin is inconsistent in its handling of shortcode attributes; some do escape, most don't, and there are even some attributes that are insecure by design (like [su_button]'s onclick attribute).

The Page View Count WordPress plugin before 2.4.9 does not escape the postid parameter of pvc_stats shortcode, allowing users with a role as low as Contributor to perform Stored XSS attacks. A post made by a contributor would still have to be approved by an admin to have the XSS triggered in the frontend, however, higher privilege users, such as editor could exploit this without the need of approval, and even when the blog disallows the unfiltered_html capability.

The Yes/No Chart WordPress plugin before 1.0.12 did not sanitise its sid shortcode parameter before using it in a SQL statement, allowing medium privilege users (contributor+) to perform Blind SQL Injection attacks