#xss

### Duplicate Advisory This advisory has been withdrawn because it is a duplicate of GHSA-5h9g-x5rv-25wg. This link is maintained to preserve external references. ### Original Description TinyMCE versions before 5.10.0 are affected by a cross-site scripting vulnerability. A remote and unauthenticated attacker could introduce crafted image or link URLs that would result in the execution of arbitrary JavaScript in an editing user's browser.

### Duplicate Advisory This advisory has been withdrawn because it is a duplicate of GHSA-5h9g-x5rv-25wg. This link is maintained to preserve external references. ### Original Description TinyMCE versions before 5.6.0 are affected by a stored cross-site scripting vulnerability. An unauthenticated and remote attacker could insert crafted HTML into the editor resulting in arbitrary JavaScript execution in another user's browser.

WebCalendar version 1.3.0 suffers from reflective and persistent cross site scripting vulnerabilities.

# Impact There is a potential for a mutation XSS (mXSS) vulnerability in AntiSamy caused by flawed parsing of the HTML being sanitized. To be subject to this vulnerability the `preserveComments` directive must be enabled in your policy file and also allow for certain tags at the same time. As a result, certain crafty inputs can result in elements in comment tags being interpreted as executable when using AntiSamy's sanitized output. # Patches Patched in OWASP AntiSamy .NET 1.2.0 and later. See important remediation details in the reference given below. # Workarounds If you cannot upgrade to a fixed version of the library, the following mitigation can be applied until you can upgrade: Manually edit your AntiSamy policy file (e.g., antisamy.xml) by deleting the `preserveComments` directive or setting its value to `false`, if present. Also it would be useful to make AntiSamy remove the `noscript` tag by adding this in your tag definitions under the `<tagrules>` node (or deleting it ...

Mattermost version 8.1.6 and earlier fails to sanitize channel mention data in posts, which allows an attacker to inject markup in the web client.

### Impact Users with access to backend forms that include a [ColorPicker FormWidget](https://wintercms.com/docs/v1.2/docs/backend/forms#color-picker) can provide a value that would then be rendered unescaped in the backend form, potentially allowing for a stored XSS attack. By default, only the Brand Settings (`backend.manage_branding`) and Mail Brand Settings (`system.manage_mail_templates`) forms include the `colorpicker` formwidget, however it is also common for theme's to include it on their Theme Customization (`cms.manage_theme_options`) form. Although this was a security issue, it's important to note that its severity is relatively low. To exploit the vulnerability, an attacker would already need to have trusted access to the Winter CMS backend and they would then need to convince a user with higher privileges than them to visit an affected Form in the backend. These two factors limit the potential harm of this vulnerability. That being said, all users are advised to update ...

### 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.