Cross-site scripting (XSS) vulnerability in the file browser in notebook/notebookapp.py in IPython Notebook before 3.2.2 and Jupyter Notebook 4.0.x before 4.0.5 allows remote attackers to inject arbitrary web script or HTML via a folder name. NOTE: this was originally reported as a cross-site request forgery (CSRF) vulnerability, but this may be inaccurate.

Jupyter Notebook before 5.7.2 allows XSS via a crafted directory name because notebook/static/tree/js/notebooklist.js handles certain URLs unsafely.

Jupyter Notebook before 5.7.1 allows XSS via an untrusted notebook because nbconvert responses are considered to have the same origin as the notebook server. In other words, nbconvert endpoints can execute JavaScript with access to the server API. In notebook/nbconvert/handlers.py, NbconvertFileHandler and NbconvertPostHandler do not set a Content Security Policy to prevent this.

jupyter-server is the backend for Jupyter web applications. Improper cross-site credential checks on `/files/` URLs could allow exposure of certain file contents, or accessing files when opening untrusted files via "Open image in new tab". This issue has been addressed in commit `87a49272728` which has been included in release `2.7.2`. Users are advised to upgrade. Users unable to upgrade may use the lower performance `--ContentsManager.files_handler_class=jupyter_server.files.handlers.FilesHandler`, which implements the correct checks.

Jupyter Notebook before 5.5.0 does not use a CSP header to treat served files as belonging to a separate origin. Thus, for example, an XSS payload can be placed in an SVG document.

In Jupyter Notebook versions 7.0.0 through 7.5.5, JupyterLab versions 4.5.6 and earlier, and the corresponding @jupyter-notebook/help-extension and @jupyterlab/help-extension packages before 7.5.6 and 4.5.7, a stored cross-site scripting issue in the help command linker can be chained with attacker-controlled notebook content to steal authentication tokens with a single click. An attacker can craft a malicious notebook file containing elements that appear indistinguishable from legitimate controls and trigger execution when a user interacts with them. Successful exploitation allows theft of the user's authentication token and complete takeover of the Jupyter session through the REST API, including reading files, creating or modifying files, accessing kernels to execute arbitrary code, and creating terminals for shell access. This issue has been fixed in Notebook 7.5.6, JupyterLab 4.5.7, @jupyter-notebook/help-extension 7.5.6, and @jupyterlab/help-extension 4.5.7. As a workaround, disable the affected help extensions or set allowCommandLinker to false in the sanitizer configuration.

jupyterlab is an extensible environment for interactive and reproducible computing, based on the Jupyter Notebook Architecture. This vulnerability depends on user interaction by opening a malicious notebook with Markdown cells, or Markdown file using JupyterLab preview feature. A malicious user can access any data that the attacked user has access to as well as perform arbitrary requests acting as the attacked user. JupyterLab v3.6.8, v4.2.5 and Jupyter Notebook v7.2.2 have been patched to resolve this issue. Users are advised to upgrade. There is no workaround for the underlying DOM Clobbering susceptibility. However, select plugins can be disabled on deployments which cannot update in a timely fashion to minimise the risk. These are: 1. `@jupyterlab/mathjax-extension:plugin` - users will loose ability to preview mathematical equations. 2. `@jupyterlab/markdownviewer-extension:plugin` - users will loose ability to open Markdown previews. 3. `@jupyterlab/mathjax2-extension:plugin` (if installed with optional `jupyterlab-mathjax2` package) - an older version of the mathjax plugin for JupyterLab 4.x. To disable these extensions run: ```jupyter labextension disable @jupyterlab/markdownviewer-extension:plugin && jupyter labextension disable @jupyterlab/mathjax-extension:plugin && jupyter labextension disable @jupyterlab/mathjax2-extension:plugin ``` in bash.

nbdime provides tools for diffing and merging of Jupyter Notebooks. In affected versions a stored cross-site scripting (XSS) issue exists within the Jupyter-owned nbdime project. It appears that when reading the file name and path from disk, the extension does not sanitize the string it constructs before returning it to be displayed. The diffNotebookCheckpoint function within nbdime causes this issue. When attempting to display the name of the local notebook (diffNotebookCheckpoint), nbdime appears to simply append .ipynb to the name of the input file. The NbdimeWidget is then created, and the base string is passed through to the request API function. From there, the frontend simply renders the HTML tag and anything along with it. Users are advised to patch to the most recent version of the affected product.

JupyterLab is a user interface for Project Jupyter which will eventually replace the classic Jupyter Notebook. In affected versions untrusted notebook can execute code on load. In particular JupyterLab doesn’t sanitize the action attribute of html `<form>`. Using this it is possible to trigger the form validation outside of the form itself. This is a remote code execution, but requires user action to open a notebook.

The Jupyter notebook is a web-based notebook environment for interactive computing. In affected versions untrusted notebook can execute code on load. Jupyter Notebook uses a deprecated version of Google Caja to sanitize user inputs. A public Caja bypass can be used to trigger an XSS when a victim opens a malicious ipynb document in Jupyter Notebook. The XSS allows an attacker to execute arbitrary code on the victim computer using Jupyter APIs.

The GitHub Security Lab discovered sixteen ways to exploit a cross-site scripting vulnerability in nbconvert. When using nbconvert to generate an HTML version of a user-controllable notebook, it is possible to inject arbitrary HTML which may lead to cross-site scripting (XSS) vulnerabilities if these HTML notebooks are served by a web server (eg: nbviewer).

Jupyter Server Proxy allows users to run arbitrary external processes alongside their notebook server and provide authenticated web access to them. Versions of 3.x prior to 3.2.4 and 4.x prior to 4.2.0 have a reflected cross-site scripting (XSS) issue. The `/proxy` endpoint accepts a `host` path segment in the format `/proxy/<host>`. When this endpoint is called with an invalid `host` value, `jupyter-server-proxy` replies with a response that includes the value of `host`, without sanitization [2]. A third-party actor can leverage this by sending a phishing link with an invalid `host` value containing custom JavaScript to a user. When the user clicks this phishing link, the browser renders the response of `GET /proxy/<host>`, which runs the custom JavaScript contained in `host` set by the actor. As any arbitrary JavaScript can be run after the user clicks on a phishing link, this issue permits extensive access to the user's JupyterLab instance for an actor. Patches are included in versions 4.2.0 and 3.2.4. As a workaround, server operators who are unable to upgrade can disable the `jupyter-server-proxy` extension.

JupyterHub is an open source multi-user server for Jupyter notebooks. By tricking a user into visiting a malicious subdomain, the attacker can achieve an XSS directly affecting the former's session. More precisely, in the context of JupyterHub, this XSS could achieve full access to JupyterHub API and user's single-user server. The affected configurations are single-origin JupyterHub deployments and JupyterHub deployments with user-controlled applications running on subdomains or peer subdomains of either the Hub or a single-user server. This vulnerability is fixed in 4.1.0.

JupyterLab is an extensible environment for interactive and reproducible computing, based on the Jupyter Notebook and Architecture. This vulnerability depends on user interaction by opening a malicious Markdown file using JupyterLab preview feature. A malicious user can access any data that the attacked user has access to as well as perform arbitrary requests acting as the attacked user. JupyterLab version 4.0.11 has been patched. Users are advised to upgrade. Users unable to upgrade should disable the table of contents extension.

Ignite Realtime Openfire 4.6.0 has plugins/clientcontrol/spark-form.jsp Reflective XSS.

CXUUCMS V3 allows class="layui-input" XSS.

MediaWiki before 1.35.1 allows XSS via BlockLogFormatter.php. MediaWiki:blanknamespace potentially can be output as raw HTML with SCRIPT tags via LogFormatter::makePageLink(). This affects MediaWiki 1.33.0 and later.

PHPJabbers File Sharing Script 1.0 has stored XSS in the comments section.

Online Birth Certificate System Project V 1.0 is affected by cross-site scripting (XSS). This vulnerability can result in an attacker injecting the XSS payload in the User Registration section. When an admin visits the View Detail of Application section from the admin panel, the attacker can able to steal the cookie according to the crafted payload.

XSS in signup form in Project Worlds Online Examination System 1.0 allows remote attacker to inject arbitrary code via the name field

XXL-JOB 2.2.0 allows Stored XSS (in Add User) to bypass the 20-character limit via xxl-job-admin/src/main/java/com/xxl/job/admin/controller/UserController.java.

JIZHICMS 1.5.1 contains a cross-site scripting (XSS) vulnerability in the component /user/release.html, which allows attackers to arbitrarily add an administrator cookie.

DokuWiki through 2017-02-19b has XSS in the at parameter (aka the DATE_AT variable) to doku.php.

A cross-site scripting (XSS) vulnerability exists in the SabaiApps WordPress Directories Pro plugin version 1.3.45 and previous, allows attackers who have convinced a site administrator to import a specially crafted CSV file to inject arbitrary web script or HTML as the victim is proceeding through the file import workflow.

Froxlor through 0.10.22 does not perform validation on user input passed in the customermail GET parameter. The value of this parameter is reflected in the login webpage, allowing the injection of arbitrary HTML tags.

Multiple cross-site scripting (XSS) vulnerabilities in WordPress before 3.5.2 allow remote attackers to inject arbitrary web script or HTML via vectors involving (1) uploads of media files, (2) editing of media files, (3) installation of plugins, (4) updates to plugins, (5) installation of themes, or (6) updates to themes.

Cross-site Scripting (XSS) - Generic in GitHub repository neorazorx/facturascripts prior to 2022.09.

Cross Site Scripting (XSS) vulnerability via the 'Full Name' parameter in the User Registration section of User Registration & Login System with Admin Panel 1.0.

Multiple vulnerabilities in the web-based management interface of Cisco Firepower Management Center (FMC) Software could allow an unauthenticated, remote attacker to conduct a cross-site scripting (XSS) attack against a user of the interface. These vulnerabilities are due to insufficient validation of user-supplied input by the web-based management interface. An attacker could exploit these vulnerabilities by persuading a user of the interface to click a crafted link. A successful exploit could allow the attacker to execute arbitrary script code in the context of the interface or access sensitive, browser-based information.

An XSS issue was discovered in admin/install.php in MantisBT before 1.3.12 and 2.x before 2.5.2. Some variables under user control in the MantisBT installation script are not properly sanitized before being output, allowing remote attackers to inject arbitrary JavaScript code, as demonstrated by the $f_database, $f_db_username, and $f_admin_username variables. This is mitigated by the fact that the admin/ folder should be deleted after installation, and also prevented by CSP.

XOOPS Core 2.5.8 has stored XSS in imagemanager.php because of missing MIME type validation in htdocs/class/uploader.php.

EGavilan Barcodes generator 1.0 is affected by: Cross Site Scripting (XSS) via the index.php. An Attacker is able to inject the XSS payload in the web application each time a user visits the website.

A vulnerability in the web-based management interface of Cisco Email Security Appliance (ESA) could allow an unauthenticated, remote attacker to conduct a cross-site scripting (XSS) attack against a user of the web-based management interface of an affected device. The vulnerability exists because the web-based management interface of the affected device does not properly validate user-supplied input. An attacker could exploit this vulnerability by persuading a user to click a malicious link. A successful exploit could allow the attacker to execute arbitrary script code in the context of the affected interface or to access sensitive, browser-based information.

Cross-site scripting (XSS) vulnerability in Online Examination System 1.0 via the q parameter to feedback.php.

Cross-site scripting (XSS) vulnerability in call_entry.php in Call Center Software 0,93 allows remote attackers to inject arbitrary web script or HTML via the problem_desc parameter, as demonstrated by the ONLOAD attribute of a BODY element.

app/View/Elements/genericElements/SingleViews/Fields/genericField.ctp in MISP 2.4.135 has XSS via the authkey comment field.

A vulnerability in the web-based management interface of Cisco Unified Communications Manager, Cisco Unified Communications Manager Session Management Edition, Cisco Unified Communications Manager IM &amp; Presence Service, and Cisco Unity Connection could allow an unauthenticated, remote attacker to conduct a cross-site scripting (XSS) attack against a user of the interface. The vulnerability is due to insufficient validation of user-supplied input by the web-based management interface of the affected software. An attacker could exploit this vulnerability by persuading a user of the interface to click a crafted link. 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.

A vulnerability in the logging component of Cisco Identity Services Engine could allow an unauthenticated remote attacker to conduct cross-site scripting attacks. The vulnerability is due to the improper validation of endpoint data stored in logs used by the web-based interface. An attacker could exploit this vulnerability by sending malicious endpoint data to the targeted system. An exploit could allow the attacker to execute arbitrary script code in the context of the affected interface or to access sensitive, browser-based information.

XSS exists in Liferay Portal before 7.0 CE GA4 via a crafted title or summary that is mishandled in the Web Content Display.

A Reflected Cross Site Scripting (XSS) vulnerability exists in the authorization function exposed by RESTful Web Api of IBM Worklight Framework 6.1, 6.2, 6.3, 7.0, 7.1, and 8.0. The vulnerable parameter is "scope"; if you set as its value a "realm" not defined in authenticationConfig.xml, you get an HTTP 403 Forbidden response and the value will be reflected in the body of the HTTP response. By setting it to arbitrary JavaScript code it is possible to modify the flow of the authorization function, potentially leading to credential disclosure within a trusted session.

A vulnerability in the web UI of Cisco Firepower Management Center (FMC) Software could allow an unauthenticated, remote attacker to conduct a cross-site scripting (XSS) attack against a user of the web-based management interface of the FMC Software. The vulnerability is due to insufficient validation of user-supplied input by the web-based management interface. An attacker could exploit this vulnerability by persuading a user of the interface to click a crafted link. A successful exploit could allow the attacker to execute arbitrary script code in the context of the interface or to access sensitive, browser-based information.

A vulnerability in the web-based management interface of Cisco Data Center Network Manager (DCNM) could allow an unauthenticated, remote attacker to conduct a cross-site scripting (XSS) attack against a user of the interface. The vulnerability is due to insufficient input validation by the web-based management interface. An attacker could exploit this vulnerability by interacting with the interface in a way that injects malicious content in a log file. 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.

MediaWiki before 1.35.1 allows XSS via BlockLogFormatter.php. Language::translateBlockExpiry itself does not escape in all code paths. For example, the return of Language::userTimeAndDate is is always unsafe for HTML in a month value. This affects MediaWiki 1.12.0 and later.

A cross-site scripting (XSS) vulnerability in the LiteSpeed Cache plugin before 3.6.1 for WordPress can be exploited via the Server IP setting.

Multiple vulnerabilities in the web-based management interface of Cisco DNA Center software could allow an unauthenticated, remote attacker to conduct a cross-site scripting (XSS) attack against a user of the interface of an affected device. The vulnerabilities exist because the web-based management interface on an affected device does not properly validate user-supplied input. An attacker could exploit these vulnerabilities by persuading a user of the interface to click a crafted link. 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.

In MediaWiki before 1.35.1, the combination of Html::rawElement and Message::text leads to XSS because the definition of MediaWiki:recentchanges-legend-watchlistexpiry can be changed onwiki so that the output is raw HTML.

Cross Site Scripting (XSS) vulnerability in Digisol DG-HR3400 can be exploited via the NTP server name in Time and date module and "Keyword" in URL Filter.

XSS in the Add Expense Component of EGavilan Media Expense Management System 1.0 allows an attacker to permanently store malicious JavaScript code via the 'description' field

A cross site scripting (XSS) vulnerability in index.php of Wayang-CMS v1.0 allows attackers to execute arbitrary web scripts or HTML via a constructed payload created by adding the X-Forwarded-For field to the header.

PacsOne Server (PACS Server In One Box) below 7.1.1 is affected by cross-site scripting (XSS).