This article is a part of our Vulnerability Database (back to index)
Cross-site Scripting occurrences in Backports Sle
phpMyAdmin before 4.9.6 and 5.x before 5.0.3 allows XSS through the transformation feature via a crafted link. (2020-10-10, CVE-2020-26934)
Pagure before 5.6 allows XSS via the templates/blame.html blame view. (2020-09-25, CVE-2019-11556)
Insufficient policy enforcement in Blink in Google Chrome prior to 85.0.4183.83 allowed a remote attacker to leak cross-origin data via a crafted HTML page. (2020-09-21, CVE-2020-6562)
Insufficient policy enforcement in iOSWeb in Google Chrome on iOS prior to 85.0.4183.83 allowed a remote attacker to bypass navigation restrictions via a crafted HTML page. (2020-09-21, CVE-2020-6558)
Insufficient data validation in WebUI in Google Chrome prior to 84.0.4147.89 allowed a remote attacker who had compromised the renderer process to inject scripts or HTML into a privileged page via a crafted HTML page. (2020-07-22, CVE-2020-6535)
Insufficient validation of untrusted input in clipboard in Google Chrome prior to 83.0.4103.61 allowed a local attacker to inject arbitrary scripts or HTML (UXSS) via crafted clipboard contents. (2020-05-21, CVE-2020-6470)
An issue was discovered in Roundcube Webmail before 1.4.4. There is a cross-site scripting (XSS) vulnerability in rcube_washtml.php because JavaScript code can occur in the CDATA of an HTML message. (2020-05-04, CVE-2020-12625)
GNU Mailman 2.x before 2.1.30 uses the .obj extension for scrubbed application/octet-stream MIME parts. This behavior may contribute to XSS attacks against list-archive visitors, because an HTTP reply from an archive web server may lack a MIME type, and a web browser may perform MIME sniffing, conclude that the MIME type should have been text/html, and execute JavaScript code. (2020-04-24, CVE-2020-12137)
In phpMyAdmin 4.x before 4.9.5 and 5.x before 5.0.2, a SQL injection vulnerability was discovered where malicious code could be used to trigger an XSS attack through retrieving and displaying results (in tbl_get_field.php and libraries/classes/Display/Results.php). The attacker must be able to insert crafted data into certain database tables, which when retrieved (for instance, through the Browse tab) can trigger the XSS attack. (2020-03-22, CVE-2020-10803)
Insufficient policy enforcement in extensions in Google Chrome prior to 80.0.3987.87 allowed an attacker who convinced a user to install a malicious extension to bypass navigation restrictions via a crafted Chrome Extension. (2020-02-11, CVE-2020-6392)
Insufficient validation of untrusted input in Blink in Google Chrome prior to 80.0.3987.87 allowed a local attacker to bypass content security policy via a crafted HTML page. (2020-02-11, CVE-2020-6391)
Cacti 1.2.8 has stored XSS in data_sources.php, color_templates_item.php, graphs.php, graph_items.php, lib/api_automation.php, user_admin.php, and user_group_admin.php, as demonstrated by the description parameter in data_sources.php (a raw string from the database that is displayed by $header to trigger the XSS). (2020-01-16, CVE-2020-7106)
An issue was discovered in Open Ticket Request System (OTRS) 5.x before 5.0.34, 6.x before 6.0.16, and 7.x before 7.0.4. An attacker who is logged into OTRS as an agent or a customer user may upload a carefully crafted resource in order to cause execution of JavaScript in the context of OTRS. This is related to Content-type mishandling in Kernel/Modules/PictureUpload.pm. (2019-03-13, CVE-2019-9752)
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>