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

Cross-site Scripting (XSS) - Stored in Packagist pimcore/pimcore prior to 10.2.

Stored cross-site scripting vulnerability in Quiz And Survey Master versions prior to 7.3.7 allows a remote authenticated attacker to inject an arbitrary script via an website that uses Quiz And Survey Master.

In Artica Pandora FMS version 7.0, an Attacker with write Permission can create an agent with an XSS Payload; when a user enters the agent definitions page, the script will get executed.

The User Registration, Login & Landing Pages WordPress plugin is vulnerable to Stored Cross-Site Scripting due to insufficient escaping via the loader_text parameter found in the ~/includes/templates/landing-page.php file which allows attackers with administrative user access to inject arbitrary web scripts, in versions up to and including 1.2.7. This affects multi-site installations where unfiltered_html is disabled for administrators, and sites where unfiltered_html is disabled.

An issue was discovered in WSO2 Identity Server through 5.9.0 and WSO2 IS as Key Manager through 5.9.0. A potential Reflected Cross-Site Scripting (XSS) vulnerability has been identified in the Management Console Basic Policy Editor user Interface.

orchardcore is vulnerable to Improper Neutralization of Input During Web Page Generation ('Cross-site Scripting')

cPanel before 60.0.25 allows self XSS in the alias upload interface (SEC-184).

OpenWrt 21.02.1 allows XSS via the Port Forwards Add Name screen.

Cross-site scripting (XSS) vulnerability in the FORM content object in TYPO3 4.2.x before 4.2.16, 4.3.x before 4.3.9, and 4.4.x before 4.4.5, allows remote authenticated users to inject arbitrary web script or HTML via unspecified vectors.

NeDi 1.9C is vulnerable to cross-site scripting (XSS) attack. The application allows an attacker to execute arbitrary JavaScript code via the Topology-Linked.php dv parameter.

NeDi 1.9C is vulnerable to cross-site scripting (XSS) attack. The application allows an attacker to execute arbitrary JavaScript code via the Assets-Management.php chg parameter.

NeDi 1.9C is vulnerable to cross-site scripting (XSS) attack. The application allows an attacker to execute arbitrary JavaScript code via the Assets-Management.php sn parameter.

An issue was discovered in phpList through 3.5.4. An XSS vulnerability occurs within the Import Administrators section via upload of an edited text document. This also affects the Subscriber Lists section.

CMS Made Simple 2.2.14 allows XSS via a Search Term to the admin/moduleinterface.php?mact=ModuleManager page.

IBM Infosphere BigInsights 4.2.0 and 4.2.5 is vulnerable to cross-site scripting. This vulnerability allows users to embed arbitrary JavaScript code in the Web UI thus altering the intended functionality potentially leading to credentials disclosure within a trusted session. IBM X-Force ID: 131397.

A vulnerability in the web-based management interface of Cisco Prime Infrastructure and Cisco Evolved Programmable Network Manager (EPNM) could allow an unauthenticated, remote attacker to conduct a cross-site scripting (XSS) attack against a user of the interface on an affected device. The vulnerability is due to insufficient validation of user-supplied input by the web-based management interface of an affected system. An attacker could exploit this vulnerability by injecting malicious code into specific pages of the interface. A successful exploit could allow the attacker to execute arbitrary script code in the context of the affected interface or access sensitive, browser-based information.

Certain NETGEAR devices are affected by stored XSS. This affects CBR40 before 2.5.0.10, EAX80 before 1.0.1.62, EX7500 before 1.0.0.72, R7900 before 1.0.4.38, R8000 before 1.0.4.68, RAX200 before 1.0.4.120, RBS40V before 2.6.1.4, RBW30 before 2.6.1.4, MR60 before 1.0.6.110, RAX20 before 1.0.2.82, RAX45 before 1.0.2.72, RAX80 before 1.0.4.120, MS60 before 1.0.6.110, RAX15 before 1.0.2.82, RAX50 before 1.0.2.72, RAX75 before 1.0.4.120, RBR750 before 3.2.16.6, RBR850 before 3.2.16.6, RBS750 before 3.2.16.6, RBS850 before 3.2.16.6, RBK752 before 3.2.16.6, and RBK852 before 3.2.16.6.

An issue was discovered in WSO2 Identity Server through 5.9.0 and WSO2 IS as Key Manager through 5.9.0. A potential Reflected Cross-Site Scripting (XSS) vulnerability has been identified in the Management Console Policy Administration user interface.

October is a free, open-source, self-hosted CMS platform based on the Laravel PHP Framework. In October CMS from version 1.0.319 and before version 1.0.469, backend users with access to upload files were permitted to upload SVG files without any sanitization applied to the uploaded files. Since SVG files support being parsed as HTML by browsers, this means that they could theoretically upload Javascript that would be executed on a path under the website's domain (i.e. /storage/app/media/evil.svg), but they would have to convince their target to visit that location directly in the target's browser as the backend does not display SVGs inline anywhere, SVGs are only displayed as image resources in the backend and are thus unable to be executed. Issue has been patched in Build 469 (v1.0.469) & v1.1.0.

On TP-Link TL-WR740N v4 and TL-WR740ND v4 devices, an attacker with access to the admin panel can inject HTML code and change the HTML context of the target pages and stations in the access-control settings via targets_lists_name or hosts_lists_name. The vulnerability can also be exploited through a CSRF, requiring no authentication as an administrator.

IBM DOORS Next Generation (DNG/RRC) 6.0 is vulnerable to cross-site scripting. This vulnerability allows users to embed arbitrary JavaScript code in the Web UI thus altering the intended functionality potentially leading to credentials disclosure within a trusted session. IBM X-Force ID: 133260.

In TimelineJS before version 3.7.0, some user data renders as HTML. An attacker could implement an XSS exploit with maliciously crafted content in a number of data fields. This risk is present whether the source data for the timeline is stored on Google Sheets or in a JSON configuration file. Most TimelineJS users configure their timeline with a Google Sheets document. Those users are exposed to this vulnerability if they grant write access to the document to a malicious inside attacker, if the access of a trusted user is compromised, or if they grant public write access to the document. Some TimelineJS users configure their timeline with a JSON document. Those users are exposed to this vulnerability if they grant write access to the document to a malicious inside attacker, if the access of a trusted user is compromised, or if write access to the system hosting that document is otherwise compromised. Version 3.7.0 of TimelineJS addresses this in two ways. For content which is intended to support limited HTML markup for styling and linking, that content is "sanitized" before being added to the DOM. For content intended for simple text display, all markup is stripped. Very few users of TimelineJS actually install the TimelineJS code on their server. Most users publish a timeline using a URL hosted on systems we control. The fix for this issue is published to our system such that **those users will automatically begin using the new code**. The only exception would be users who have deliberately edited the embed URL to "pin" their timeline to an earlier version of the code. Some users of TimelineJS use it as a part of a wordpress plugin (knight-lab-timelinejs). Version 3.7.0.0 of that plugin and newer integrate the updated code. Users are encouraged to update the plugin rather than manually update the embedded version of TimelineJS.

IBM Rational Quality Manager and IBM Rational Collaborative Lifecycle Management 5.0 through 5.0.2 and 6.0 through 6.0.5 are vulnerable to cross-site scripting. This vulnerability allows users to embed arbitrary JavaScript code in the Web UI thus altering the intended functionality potentially leading to credentials disclosure within a trusted session. IBM X-Force ID: 133263.

In Bludit v1.5.2 and v2.0.1, an XSS vulnerability is located in the new page, new category, and edit post function body message context. Remote attackers are able to bypass the basic editor validation to trigger cross site scripting. The XSS is persistent and the request method to inject via editor is GET. To save the editor context, the followup POST method request must be processed to perform the attack via the application side. The basic validation of the editor does not allow injecting script codes and blocks the context. Attackers can inject the code by using an editor tag that is not recognized by the basic validation. Thus allows a restricted user account to inject malicious script code to perform a persistent attack against higher privilege web-application user accounts.

A cross-site-scripting (XSS) vulnerability exists when Microsoft SharePoint Server does not properly sanitize a specially crafted web request to an affected SharePoint server, aka 'Microsoft Office SharePoint XSS Vulnerability'. This CVE ID is unique from CVE-2020-1450, CVE-2020-1456.

Stored Cross-site scripting (XSS) vulnerability in /cgi-bin/config2 on Vonage (Grandstream) HT802 devices allows remote authenticated users to inject arbitrary web script or HTML via the DHCP vendor class ID field (P148).

Versions of Grocy <= 2.7.1 are vulnerable to Cross-Site Scripting via the Create Shopping List module, that is rendered upon deleting that Shopping List. The issue was also found in users, batteries, chores, equipment, locations, quantity units, shopping locations, tasks, taskcategories, product groups, recipes and products. Authentication is required to exploit these issues and Grocy should not be publicly exposed. The linked reference details a proof-of-concept.

There is a stored Cross Site Scripting (XSS) vulnerability in maccms v10 through adding videos. XSS code can be inserted at parameter positions including name and remarks.

IBM Jazz Foundation (IBM Rational Collaborative Lifecycle Management 6.0.x) is vulnerable to cross-site scripting. This vulnerability allows users to embed arbitrary JavaScript code in the Web UI thus altering the intended functionality potentially leading to credentials disclosure within a trusted session. IBM X-Force ID: 133268.

In jfinal_cms >= 5.1 0, there is a storage XSS vulnerability in the background system of CMS. Because developers do not filter the parameters submitted by the user input form, any user with background permission can affect the system security by entering malicious code.

An issue was discovered in MediaWiki before 1.35.5, 1.36.x before 1.36.3, and 1.37.x before 1.37.1. Special:CheckUserLog allows CheckUser XSS because of date mishandling, as demonstrated by an XSS payload in MediaWiki:October.

IBM Rational Quality Manager and IBM Rational Collaborative Lifecycle Management 5.0 through 5.0.2 and 6.0 through 6.0.5 are vulnerable to cross-site scripting. This vulnerability allows users to embed arbitrary JavaScript code in the Web UI thus altering the intended functionality potentially leading to credentials disclosure within a trusted session. IBM X-Force ID: 133261.

A cross-site scripting (XSS) vulnerability in H.H.G Multistore v5.1.0 and below allows attackers to execute arbitrary web scripts or HTML via a crafted payload inserted into the State parameter under the Address Book module.

Slims9 Bulian 9.4.2 is affected by Cross Site Scripting (XSS) in /admin/modules/system/custom_field.php.

baserCMS before version 4.4.1 is vulnerable to Cross-Site Scripting. The issue affects the following components: Edit feed settings, Edit widget area, Sub site new registration, New category registration. Arbitrary JavaScript may be executed by entering specific characters in the account that can access the file upload function category list, subsite setting list, widget area edit, and feed list on the management screen. The issue was introduced in version 4.0.0. It is fixed in version 4.4.1.

In PrestaShop from version 1.5.0.0 and before version 1.7.6.8, users are allowed to send compromised files. These attachments allowed people to input malicious JavaScript which triggered an XSS payload. The problem is fixed in version 1.7.6.8.

In Wiki.js before version 2.5.162, an XSS payload can be injected in a page title and executed via the search results. While the title is properly escaped in both the navigation links and the actual page title, it is not the case in the search results. Commit a57d9af34c15adbf460dde6553d964efddf433de fixes this vulnerability (version 2.5.162) by properly escaping the text content displayed in the search results.

CALDERA 2.7.0 allows XSS via the Operation Name box.

A Stored Cross Site Scripting (XSS) vulnerability exists in bludit 3.13.1 via the TAGS section in login panel.

The Firstname and Lastname parameters in Global RADAR BSA Radar 1.6.7234.24750 and earlier are vulnerable to stored cross-site scripting (XSS) via Update User Profile.

The Social Slider Widget WordPress plugin before 1.8.5 allowed Authenticated Reflected XSS in the plugin settings page as the ‘token_error’ parameter can be controlled by users and it is directly echoed without being sanitized

OX App Suite through 7.10.3 allows stats/diagnostic?param= XSS.

Multiple cross-site scripting (XSS) vulnerabilities in Radius Manager 3.8.0 allow remote authenticated administrators to inject arbitrary web script or HTML via the (1) name or (2) descr parameter in an (a) update_usergroup or a (b) store_nas action to admin.php.

NeDi 1.9C is vulnerable to cross-site scripting (XSS) attack. The application allows an attacker to execute arbitrary JavaScript code via the Reports-Devices.php page st[] parameter.

Multiple XSS vulnerabilities in the Final Tiles Gallery plugin before 3.4.19 for WordPress allow remote attackers to inject arbitrary web script or HTML via the Title (aka imageTitle) or Caption (aka description) field of an image to wp-admin/admin-ajax.php.

Certain NETGEAR devices are affected by stored XSS. This affects CBR40 before 2.5.0.10, EAX80 before 1.0.1.64, EX3700 before 1.0.0.90, EX3800 before 1.0.0.90, EX6120 before 1.0.0.64, EX6130 before 1.0.0.44, EX7500 before 1.0.0.72, RBW30 before 2.6.1.4, RBK752 before 3.2.16.6, RBR750 before 3.2.16.6, RBS750 before 3.2.16.6, RBK852 before 3.2.16.6, RBR850 before 3.2.16.6, RBS850 before 3.2.16.6, and RBS40V before 2.6.1.4.

Bludit 3.12.0 allows stored XSS via JavaScript code in an SVG document to bl-kernel/ajax/logo-upload.php.

IBM Rational Quality Manager (RQM) 5.0 through 5.02 and 6.0 through 6.0.6 are vulnerable to cross-site scripting. This vulnerability allows users to embed arbitrary JavaScript code in the Web UI thus altering the intended functionality potentially leading to credentials disclosure within a trusted session. IBM X-Force ID: 133259.

In Wagtail before versions 2.7.4 and 2.9.3, when a form page type is made available to Wagtail editors through the `wagtail.contrib.forms` app, and the page template is built using Django's standard form rendering helpers such as form.as_p, any HTML tags used within a form field's help text will be rendered unescaped in the page. Allowing HTML within help text is an intentional design decision by Django; however, as a matter of policy Wagtail does not allow editors to insert arbitrary HTML by default, as this could potentially be used to carry out cross-site scripting attacks, including privilege escalation. This functionality should therefore not have been made available to editor-level users. The vulnerability is not exploitable by an ordinary site visitor without access to the Wagtail admin. Patched versions have been released as Wagtail 2.7.4 (for the LTS 2.7 branch) and Wagtail 2.9.3 (for the current 2.9 branch). In these versions, help text will be escaped to prevent the inclusion of HTML tags. Site owners who wish to re-enable the use of HTML within help text (and are willing to accept the risk of this being exploited by editors) may set WAGTAILFORMS_HELP_TEXT_ALLOW_HTML = True in their configuration settings. Site owners who are unable to upgrade to the new versions can secure their form page templates by rendering forms field-by-field as per Django's documentation, but omitting the |safe filter when outputting the help text.