Krugov Artyom

The Live Composer WordPress plugin before 2.1.24 does not sanitise and escape some of its page-builder module settings before outputting them, allowing users with access to the builder (Administrator by default) to inject arbitrary JavaScript that executes when the affected page is viewed by any visitor; this has impact even on administrators where the unfiltered html capability is disallowed, e.g. in multisite setups.

The Live Composer WordPress plugin before 2.1.24 does not sanitise and escape some of its staff member settings before outputting them in pages, which could allow high-privilege users such as administrators to perform Stored Cross-Site Scripting attacks even when the unfiltered html capability is disallowed (e.g. in multisite setups).

The Live Composer WordPress plugin before 2.1.24 does not sanitise and escape some of its module settings before outputting them in an href attribute, which could allow high-privilege users such as administrators to perform Stored Cross-Site Scripting attacks even when the unfiltered html capability is disallowed (e.g. in multisite setups).

The Live Composer WordPress plugin before 2.1.24 does not sanitise and escape some of its Button module settings before outputting them on the front end, which could allow high-privilege users such as administrators to perform Stored Cross-Site Scripting attacks even when the unfiltered html capability is disallowed (e.g. in multisite setups).

Insufficient sanitization and escaping of custom post type slug settings used in front-end links allows high-privilege users, such as administrators, to execute Stored Cross-Site Scripting (XSS) attacks. This issue persists even when the `unfiltered html` capability is disabled, which is common in multisite configurations. Stored XSS occurs when a malicious script is permanently stored on the target server and served to other users.

The plugin fails to sanitize and escape a job specification setting before it is reflected on an admin-area settings page. This allows users with management capabilities, such as Administrators, to store a malicious payload that executes in the browser of any administrator viewing the page. This results in Stored Cross-Site Scripting (XSS), a condition where malicious scripts are permanently stored on the target server and served to other users.

Stored Cross-Site Scripting (XSS) occurs because the plugin fails to escape certain settings field values before they are displayed on the admin settings page. This allows high-privilege users, such as administrators, to execute malicious scripts. The issue is particularly significant in multisite installations where administrators lack the `unfiltered html` capability, which normally prevents the execution of unfiltered HTML and scripts.

An issue exists in the administrative image-browsing feature where a directory path is not properly restricted to the site boundaries. This allows authenticated users with high privileges, such as single-site administrators and multisite sub-site administrators, to perform path traversal. Path traversal is a technique used to access files and directories that are stored outside the intended web root folder by manipulating file paths.

Insufficient input sanitization and output escaping in the plugin allow high-privilege users, such as administrators, to perform Stored Cross-Site Scripting (XSS) attacks. This occurs when settings are outputted on an admin page, enabling the injection of arbitrary web scripts that execute when a user accesses the affected page. This issue specifically impacts multi-site installations and environments where the `unfiltered html` capability is disabled.

The plugin fails to properly escape the `after-label` value of the slider. This allows users with the Author role or higher to store a malicious payload that is subsequently re-injected into the Document Object Model (DOM) by a bundled client-side script. This can lead to the execution of arbitrary code in the browser of any user, including administrators, who views the affected slider.

Stored Cross-Site Scripting (XSS) occurs because a campaign image text field is not properly sanitized and escaped before being output in an HTML attribute. This allows users with a high-privilege campaign-management role to execute malicious scripts on the front-end campaign page.

Insufficient sanitization and escaping of a place-category setting before it is output on an admin page allows high-privilege users, such as editors and above, to execute Stored Cross-Site Scripting (XSS) attacks. This occurs even in environments where the `unfiltered html` capability is disabled, such as multisite setups. Stored Cross-Site Scripting is a type of attack where malicious scripts are permanently stored on the target server.

The plugin fails to properly sanitize and escape a parameter before outputting it back to the page. This leads to Reflected Cross-Site Scripting (XSS), a flaw where malicious scripts are reflected off a web application to the user's browser, which could be leveraged against high-privilege users such as administrators.

The WP Lightbox 2 WordPress plugin does not properly sanitise and escape certain settings. This could allow users with high privileges, such as administrators, to carry out Stored Cross-Site Scripting (XSS) attacks. This is possible even when the `unfiltered html` capability is disabled, for example, in a multisite configuration. The issue involves insufficient input validation, potentially allowing malicious scripts to be injected and executed within the application.

The Reading progressbar WordPress plugin does not properly sanitise and escape certain settings. This could allow users with high privileges, such as administrators, to carry out Stored Cross-Site Scripting (XSS) attacks. This is possible even when the `unfiltered html` capability is disabled, for example, in a multisite setup. Stored XSS occurs when malicious scripts are persistently stored on the target server, allowing them to be delivered to other users who access the affected content.

The software does not properly sanitize and escape parameters when outputting them on the page. This could allow users with a contributor role or higher to perform Cross-Site Scripting attacks.

Name of the Vulnerable Software and Affected Versions: AI ChatBot for WordPress plugin versions prior to 7.1.0 Description: The AI ChatBot for WordPress plugin does not sanitise and escape some of its settings. This could allow high-privilege users, such as administrators, to perform Stored Cross-Site Scripting (XSS) attacks, even when the `unfiltered html` capability is disallowed, for example, in a multisite setup. Recommendations: Update to version 7.1.0 or later.

The plugin does not validate and escape certain block options before displaying them on a page or post, potentially allowing users with contributor roles and above to execute Stored Cross-Site Scripting attacks.

Name of the Vulnerable Software and Affected Versions: Contact Form Plugin WordPress plugin versions prior to 1.1.29 Description: The issue concerns the Contact Form Plugin WordPress plugin, where some settings are not properly sanitized and escaped, potentially allowing high-privilege users, such as contributors, to perform Stored Cross-Site Scripting attacks. Recommendations: For versions prior to 1.1.29, update to version 1.1.29 or later to resolve the issue. As a temporary workaround, consider restricting access to the plugin's settings to minimize the risk of exploitation.

Name of the Vulnerable Software and Affected Versions: WP Map Block versions prior to 2.0.3 Description: The issue concerns the WP Map Block WordPress plugin, which does not validate and escape some of its block options before outputting them back in a page or post where the block is embedded. This could allow users with the contributor role and above to perform Stored Cross-Site Scripting attacks. Recommendations: For WP Map Block versions prior to 2.0.3, update to version 2.0.3 or later to resolve the issue. As a temporary workaround, consider restricting the use of the WP Map Block plugin until a patch is applied, especially for users with the contributor role and above.