#xss

### Impact Users with the `media.manage_media` permission can upload files to the Media Manager and rename them after uploading. Previously, media manager files were only sanitized on upload, not on renaming, which could have allowed a stored XSS attack. Although this was a security issue, it's important to note that its severity is low. To exploit the vulnerability, an attacker would already need to have trusted permissions in the Winter CMS backend. This means they would already have extensive access and control within the system. Additionally, to execute the XSS, the attacker would need to convince the victim to directly visit the URL of the maliciously uploaded SVG, and the application would have to be using local storage where uploaded files are served under the same domain as the application itself instead of a CDN. This is because all SVGs in Winter CMS are rendered through an img tag, which prevents any payloads from being executed directly. These two factors significantly l...

WhatACart version 2.0.7 suffers from a cross site scripting vulnerability.

ShopSite version 14.0 suffers from a persistent cross site scripting vulnerability.

WSO2 Registry has been identified as vulnerable due to improper output encoding, a Stored Cross Site Scripting (XSS) attack can be carried out by an attacker injecting a malicious payload into the Registry feature of the Management Console.

Hospital Management System versions 4.0 and below suffer from cross site scripting, remote shell upload, and remote SQL injection vulnerabilities.

automad up to 1.10.9 is vulnerable to stored cross-site scripting in the `sitename` argument because the `SharedController` class that handles form data and saving shared information does not properly sanitize the user input on the client side when rendering the data. The attack may be launched remotely and an exploit has been disclosed publicly.

Apache Airflow, versions 2.6.0 through 2.7.3 has a stored XSS vulnerability that allows a DAG author to add an unbounded and not-sanitized javascript in the parameter description field of the DAG. This Javascript can be executed on the client side of any of the user who looks at the tasks in the browser sandbox. While this issue does not allow to exit the browser sandbox or manipulation of the server-side data - more than the DAG author already has, it allows to modify what the user looking at the DAG details sees in the browser - which opens up all kinds of possibilities of misleading other users. Users of Apache Airflow are recommended to upgrade to version 2.8.0 or newer to mitigate the risk associated with this vulnerability

### Impact resque-web in resque versions before 2.1.0 is vulnerable to reflected XSS through the current_queue parameter in the path of the queues endpoint. ### Patches v2.1.0 ### Workarounds No known workarounds at this time. It is recommended to not click on 3rd party or untrusted links to the resque-web interface until you have patched your application. ### References https://github.com/resque/resque/issues/1679 https://github.com/resque/resque/pull/1687

### Impact The following paths in resque-web have been found to be vulnerable to reflected XSS: ``` /failed/?class=<script>alert(document.cookie)</script> /queues/><img src=a onerror=alert(document.cookie)> ``` ### Patches v2.2.1 ### Workarounds No known workarounds at this time. It is recommended to not click on 3rd party or untrusted links to the resque-web interface until you have patched your application. ### References https://github.com/resque/resque/pull/1790

### Impact Reflected XSS can be performed using the current_queue portion of the path on the /queues endpoint of resque-web. ### Patches v2.6.0 ### Workarounds No known workarounds at this time. It is recommended to not click on 3rd party or untrusted links to the resque-web interface until you have patched your application. ### References https://github.com/resque/resque/pull/1865