This article is a part of our Vulnerability Database (back to index)
Cross-site Scripting occurrences in Openshift Container Platform
A flaw was found in noobaa-core in versions before 5.7.0. This flaw results in the name of an arbitrarily URL being copied into an HTML document as plain text between tags, including potentially a payload script. The input was echoed unmodified in the application response, resulting in arbitrary JavaScript being injected into an application's response. The highest threat to the system is for confidentiality, availability, and integrity. (2021-06-02, CVE-2021-3529)
A flaw was found in the Ceph Object Gateway, where it supports request sent by an anonymous user in Amazon S3. This flaw could lead to potential XSS attacks due to the lack of proper neutralization of untrusted input. (2020-04-23, CVE-2020-1760)
A stored cross-site scripting vulnerability in Jenkins 2.191 and earlier, LTS 2.176.2 and earlier allowed attackers with Overall/Administer permission to configure the update site URL to inject arbitrary HTML and JavaScript in update center web pages. (2019-08-28, CVE-2019-10383)
A reflected XSS vulnerability exists in authorization flow of OpenShift Container Platform versions: openshift-online-3, openshift-enterprise-3.4 through 3.7 and openshift-enterprise-3.9 through 3.11. An attacker could use this flaw to steal authorization data by getting them to click on a malicious link. (2019-07-11, CVE-2019-3889)
The f:validateButton form control for the Jenkins UI did not properly escape job URLs in Jenkins 2.171 and earlier and Jenkins LTS 2.164.1 and earlier, resulting in a cross-site scripting (XSS) vulnerability exploitable by users with the ability to control job names. (2019-04-10, CVE-2019-1003050)
A stored, DOM based, cross-site scripting (XSS) flaw was found in Prometheus before version 2.7.1. An attacker could exploit this by convincing an authenticated user to visit a crafted URL on a Prometheus server, allowing for the execution and persistent storage of arbitrary scripts. (2019-03-26, CVE-2019-3826)
An cross-site scripting vulnerability exists in Jenkins Blue Ocean Plugins 1.10.1 and earlier in blueocean-commons/src/main/java/io/jenkins/blueocean/commons/stapler/Export.java, blueocean-commons/src/main/java/io/jenkins/blueocean/commons/stapler/export/ExportConfig.java, blueocean-commons/src/main/java/io/jenkins/blueocean/commons/stapler/export/JSONDataWriter.java, blueocean-rest-impl/src/main/java/io/jenkins/blueocean/service/embedded/UserStatePreloader.java, blueocean-web/src/main/resources/io/jenkins/blueocean/PageStatePreloadDecorator/header.jelly that allows attackers with permission to edit a user's description in Jenkins to have Blue Ocean render arbitrary HTML when using it as that user. (2019-02-06, CVE-2019-1003013)
An cross-site scripting vulnerability exists in Jenkins Config File Provider Plugin 3.4.1 and earlier in src/main/resources/lib/configfiles/configfiles.jelly that allows attackers with permission to define shared configuration files to execute arbitrary JavaScript when a user attempts to delete the shared configuration file. (2019-02-06, CVE-2019-1003014)
Kibana versions 5.3.0 to 6.4.1 had a cross-site scripting (XSS) vulnerability via the source field formatter that could allow an attacker to obtain sensitive information from or perform destructive actions on behalf of other Kibana users. (2018-09-19, CVE-2018-3830)
A cross site scripting flaw exists in the tetonic-console component of Openshift Container Platform 3.11. An attacker with the ability to create pods can use this flaw to perform actions on the K8s API as the victim. (2018-09-11, CVE-2018-10937)
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>