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.
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.
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.
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-server is the backend for Jupyter web applications. Open Redirect Vulnerability. Maliciously crafted login links to known Jupyter Servers can cause successful login or an already logged-in session to be redirected to arbitrary sites, which should be restricted to Jupyter Server-served URLs. This issue has been addressed in commit `29036259` which is included in release 2.7.2. Users are advised to upgrade. There are no known workarounds for this vulnerability.
The Jupyter Server provides the backend (i.e. the core services, APIs, and REST endpoints) for Jupyter web applications like Jupyter notebook, JupyterLab, and Voila. In Jupyter Server before version 1.1.1, an open redirect vulnerability could cause the jupyter server to redirect the browser to a different malicious website. All jupyter servers running without a base_url prefix are technically affected, however, these maliciously crafted links can only be reasonably made for known jupyter server hosts. A link to your jupyter server may *appear* safe, but ultimately redirect to a spoofed server on the public internet. This same vulnerability was patched in upstream notebook v5.7.8. This is fixed in jupyter_server 1.1.1. If upgrade is not available, a workaround can be to run your server on a url prefix: "jupyter server --ServerApp.base_url=/jupyter/".
Jupyter Notebook before version 6.1.5 has an Open redirect vulnerability. A maliciously crafted link to a notebook server could redirect the browser to a different website. All notebook servers are technically affected, however, these maliciously crafted links can only be reasonably made for known notebook server hosts. A link to your notebook server may appear safe, but ultimately redirect to a spoofed server on the public internet. The issue is patched in version 6.1.5.
JupyterHub is software that allows one to create a multi-user server for Jupyter notebooks. Prior to version 5.4.4, an open redirect vulnerability in JupyterHub allows attackers to construct links which, when clicked, take users to the JupyterHub login page, after which they are sent to an arbitrary attacker-controlled site outside JupyterHub instead of a JupyterHub page, bypassing JupyterHub's check to prevent this. This issue has been patched in version 5.4.4.
Jupyter Server is the backend for Jupyter web applications. In jupyter_server versions through 2.17.0, the next query parameter in the login flow is insufficiently validated in `LoginFormHandler._redirect_safe()`, which allows redirects to arbitrary external domains via values such as `///example.com`. An attacker can use a crafted login URL to redirect users to a malicious site and facilitate phishing attacks. This issue is fixed in version 2.18.0.
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.
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.
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).
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.
An XSSI (cross-site inclusion) vulnerability in Jupyter Notebook before 5.7.6 allows inclusion of resources on malicious pages when visited by users who are authenticated with a Jupyter server. Access to the content of resources has been demonstrated with Internet Explorer through capturing of error messages, though not reproduced with other browsers. This occurs because Internet Explorer's error messages can include the content of any invalid JavaScript that was encountered.
jupyterlab is an extensible environment for interactive and reproducible computing, based on the Jupyter Notebook Architecture. Prior to 4.5.7, JupyterLab's HTML sanitizer allowlists data-commandlinker-command and data-commandlinker-args on button elements, while CommandLinker listens for all click events on document.body and executes the named command without checking whether the element came from trusted JupyterLab UI. A notebook with a pre-saved HTML cell output containing a deceptive button can trigger arbitrary JupyterLab commands - including arbitrary code execution - on a single user click, without any code being submitted for execution by the user. This vulnerability is fixed in 4.5.7.
JupyterHub is software that allows users to create a multi-user server for Jupyter notebooks. In versions 4.1.0 through 5.4.4, XSRF protection (updated in 4.1.0) inappropriately treated requests with Sec-Fetch-Mode: no-cors as same-origin requests, bypassing XSRF checks. The JSON API is not affected, only HTTP form endpoints, such as /hub/spawn and /hub/accept-share, meaning attackers could trigger server spawn (but not access the server) and if the attacker is a JupyterHub user permitted to share access to their server, cause a user to accept a share and have access to the attacker's server. This issue has been fixed in version 5.4.5. If developers are unable to immediately upgrade, they can temporarily mitigate this issue by dropping requests to JupyterHub with Sec-Fetch-Mode: no-cors if they are using a reverse proxy.
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.
JupyterHub 1.1.0 allows CSRF in the admin panel via a request that lacks an _xsrf field, as demonstrated by a /hub/api/user request (to add or remove a user account).
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.
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.
A vulnerability in the web-based management interface of Cisco Prime Infrastructure 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 affected software. The vulnerability is due to insufficient validation of user-supplied input in multiple sections of 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 reflected cross-site scripting (XSS) vulnerability exists in the authentication endpoint of multiple WSO2 products due to missing output encoding of user-supplied input. A malicious actor can exploit this vulnerability to inject arbitrary JavaScript into the authentication flow, potentially leading to UI modifications, redirections to malicious websites, or data exfiltration from the browser. While this issue could allow an attacker to manipulate the user’s browser, session-related sensitive cookies remain protected with the httpOnly flag, preventing session hijacking.
A Cross-site scripting (XSS) vulnerability in /api_vedo/ in Vedo Suite version 2024.17 allows remote attackers to inject arbitrary Javascript or HTML code and potentially trigger code execution in victim's browser.
WeGIA is a web manager for charitable institutions. Versions 3.6.6 and below have a Reflected Cross-Site Scripting (XSS) vulnerability in the listar_memorandos_ativos.php endpoint. An attacker can inject arbitrary JavaScript or HTML tags into the sccd GET parameter, which is then directly echoed into the HTML response without any sanitization or encoding. The script /html/memorando/listar_memorandos_ativos.php handles dynamic success messages to users using query string parameters. Similar to other endpoints in the Memorando module, it checks if $_GET['msg'] equals 'success'. If this condition is met, it directly concatenates and reflects $_GET['sccd'] into an HTML alert <div>. This issue is resolved in version 3.6.7.
SAP Supplier Relationship Management (Master Data Management Catalog - SRM_MDM_CAT, before versions 3.73, 7.31, 7.32) does not sufficiently encode user-controlled inputs, resulting in Cross-Site Scripting (XSS) vulnerability.
A template injection vulnerability leading to reflected cross-site scripting (XSS) has been identified in version 1.7.1, requiring authenticated admin access for exploitation. The vulnerability exists in the 'r' parameter and allows attackers to inject malicious Angular expressions that execute JavaScript code in the context of the application. The flaw can be exploited through GET requests to the summary endpoint as well as POST requests to specific Wicket interface endpoints, though the GET method provides easier weaponization. This vulnerability enables authenticated administrators to execute arbitrary client-side code, potentially leading to session hijacking, data theft, or further privilege escalation attacks.
The WP Attachments plugin for WordPress is vulnerable to Reflected Cross-Site Scripting via the ‘attachment_id’ parameter in all versions up to, and including, 5.0.12 due to insufficient input sanitization and output escaping. This makes it possible for unauthenticated attackers to inject arbitrary web scripts in pages that execute if they can successfully trick a user into performing an action such as clicking on a link.
A vulnerability classified as problematic has been found in Tmall Demo up to 20250505. Affected is an unknown function of the component Search Box. The manipulation leads to cross site scripting. It is possible to launch the attack remotely. The exploit has been disclosed to the public and may be used. This product is using a rolling release to provide continious delivery. Therefore, no version details for affected nor updated releases are available. The vendor was contacted early about this disclosure but did not respond in any way.
The Post Grid Master plugin for WordPress is vulnerable to Reflected Cross-Site Scripting via the ‘argsArray['read_more_text']’ parameter in all versions up to, and including, 3.4.13 due to insufficient input sanitization and output escaping. This makes it possible for unauthenticated attackers to inject arbitrary web scripts in pages that execute if they can successfully trick a user into performing an action such as clicking on a link.
NextChat contains a cross-site scripting (XSS) vulnerability in the HTMLPreview component of artifacts.tsx that allows attackers to execute arbitrary JavaScript code when HTML content is rendered in the AI chat interface. The vulnerability occurs because user-influenced HTML from AI responses is rendered in an iframe with 'allow-scripts' sandbox permission without proper sanitization. This can be exploited through specifically crafted prompts that cause the AI to generate malicious HTML/JavaScript code. When a user views the HTML preview, the injected JavaScript executes in the user's browser context, potentially allowing attackers to exfiltrate sensitive information (including API keys stored in localStorage), perform actions on behalf of the user, and steal session data.
A cross-site scripting (XSS) vulnerability exists when Microsoft SQL Server Reporting Services (SSRS) does not properly sanitize a specially-crafted web request to an affected SSRS server, aka 'Microsoft SQL Server Reporting Services XSS Vulnerability'.
The BSK Contact Form 7 Blacklist WordPress plugin through 1.0.1 does not sanitise and escape the inserted_count parameter before outputting it back in the page, leading to a Reflected Cross-Site Scripting which could be used against high privilege users such as admin
CMSimple 5.4 contains a cross-site scripting vulnerability that allows attackers to bypass input filtering by using HTML to Unicode encoding. Attackers can inject malicious scripts by encoding payloads like ')-alert(1)// and execute arbitrary JavaScript when victims interact with delete buttons.
IPFire 2.29 DNS management interface (dns.cgi) fails to properly sanitize user-supplied input in the NAMESERVER, REMARK, and TLS_HOSTNAME query parameters, resulting in a reflected cross-site scripting (XSS) vulnerability.
Cross site scripting (XSS) vulnerability in Hustoj 2025-01-31 via the TID parameter to thread.php.
A vulnerability in the web-based interface of Cisco Unified Communications Manager and Cisco Unified Communications Manager Session Management Edition (SME) could allow an unauthenticated, remote attacker to conduct a cross-site scripting (XSS) attack against a user of the web-based interface of the affected software. The vulnerability is due to insufficient validation of user-supplied input by the web-based 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.
WeGIA is a web manager for charitable institutions. Versions 3.6.6 and below have a Reflected Cross-Site Scripting (XSS) vulnerability in the novo_memorandoo.php endpoint. An attacker can inject arbitrary JavaScript into the sccs GET parameter, which is directly echoed into the HTML response without any sanitization or encoding. The script /html/memorando/novo_memorandoo.php reads HTTP GET parameters to display dynamic success messages to the user. At approximately line 273, the code checks if $_GET['msg'] equals 'success'. If true, it directly concatenates $_GET['sccs'] into an HTML alert <div> and outputs it to the browser. This issue has been fixed in version 3.6.7.
A cross-site scripting (XSS) vulnerability exists in the LB-Link BL-CPE300M 01.01.02P42U14_06 router's web interface. The /goform/goform_get_cmd_process endpoint fails to sanitize user input in the cmd parameter before reflecting it into a text/html response. This allows unauthenticated attackers to inject arbitrary JavaScript, which is executed in the context of the router's origin when the crafted URL is accessed. The issue requires user interaction to exploit.
MyBB Delete Account Plugin 1.4 contains a cross-site scripting vulnerability in the account deletion reason input field. Attackers can inject malicious scripts that will execute in the admin interface when viewing delete account reasons.
CloudClassroom-PHP-Project 1.0 contains a reflected Cross-site Scripting (XSS) vulnerability in the email parameter of the postquerypublic endpoint. Improper sanitization allows an attacker to inject arbitrary JavaScript code that executes in the context of the user s browser, potentially leading to session hijacking or phishing attacks.
ImportExportTools NG 10.0.4 contains a persistent HTML injection vulnerability in the email export module that allows remote attackers to inject malicious HTML payloads. Attackers can send emails with crafted HTML in the subject that execute during HTML export, potentially compromising user data or session credentials.
A vulnerability, which was classified as problematic, has been found in Tmall Demo up to 20250505. Affected by this issue is some unknown functionality of the file /tmall/admin/ of the component Product Details Page. The manipulation of the argument Product Name/Product Title leads to cross site scripting. The attack may be launched remotely. The exploit has been disclosed to the public and may be used. Continious delivery with rolling releases is used by this product. Therefore, no version details of affected nor updated releases are available. The vendor was contacted early about this disclosure but did not respond in any way.
The WooCommerce plugin for WordPress is vulnerable to PostMessage-Based Cross-Site Scripting via the 'customize-store' page in all versions up to, and including, 9.4.2 due to insufficient input sanitization and output escaping on PostMessage data. This makes it possible for unauthenticated attackers to inject arbitrary web scripts in pages that execute if they can successfully trick a user into performing an action such as clicking on a link.
PHPGurukul Online DJ Booking Management System 2.0 is vulnerable to Cross Site Scripting (XSS) in odms/admin/view-user-queries.php.
A file upload vulnerability was discovered in CS Cart 4.18.3, allows attackers to execute arbitrary code. CS Cart 4.18.3 allows unrestricted upload of HTML files, which are rendered directly in the browser when accessed. This allows an attacker to upload a crafted HTML file containing malicious content, such as a fake login form for credential harvesting or scripts for Cross-Site Scripting (XSS) attacks. Since the content is served from a trusted domain, it significantly increases the likelihood of successful phishing or script execution against other users.
An issue was discovered in Zoho ManageEngine AssetExplorer. There is XSS via the SearchN.do search field.
The Music Request Manager WordPress plugin through 1.3 does not have CSRF check in some places, and is missing sanitisation as well as escaping, which could allow attackers to make logged in admin add Stored XSS payloads via a CSRF attack
A stored blind XSS vulnerability exists in the Contact Page of the Phpgurukul Medical Card Generation System 1.0 mcgs/contact.php. The name field fails to properly sanitize user input, allowing an attacker to inject malicious JavaScript.