#xss

### Summary Regardless of the role or privileges, no user should be able to inject malicious JavaScript (JS) scripts into the body HTML. an XSS (Cross-Site Scripting) vulnerability, specifically a Stored XSS, which affects all pages of the website. Once the JS script is embedded in the body HTML, the XSS will trigger on any page a victim visits, such as the about, blog, contact, or any other pages, except for the panel. ### Impact This vulnerability allows attackers to inject malicious JS or HTML through a crafted payload into the vulnerable spot, achieving persistence and attacking numerous visitors or anyone accessing the website. The attack can be widespread and affect many users because the malicious JS will execute on every page, unlike an injection on a specific page (e.g., injecting on the About page would only affect that page). In this case, a single injection point leads to the execution of the malicious JS on all pages. ### Patches - [**Formwork 1.13.1**](https://github.co...

It has been discovered that the output of field validation errors in the Form Framework is vulnerable to cross-site scripting.

Failing to properly encode user input, frontend forms handled by the form framework (system extension “form”) are vulnerable to cross-site scripting.

It has been discovered that `t3://` URL handling and typolink functionality are vulnerable to cross-site scripting. Not only regular backend forms are affected but also frontend extensions which use the rendering with typolink.

It has been discovered that the output table listing in the “Files” backend module is vulnerable to cross-site scripting when a file extension contains malicious sequences. Access to the file system of the server - either directly or through synchronization - is required to exploit the vulnerability.

Failing to properly encode user input, templates using built-in Fluid ViewHelpers are vulnerable to cross-site scripting.

### Impact TokenController get parameter formName not sanitized in returned input field leads to XSS. _What kind of vulnerability is it? Who is impacted?_ ### Patches _Has the problem been patched? What versions should users upgrade to?_ ### Workarounds _Is there a way for users to fix or remediate the vulnerability without upgrading?_ Create a custom Symfony Request listener which checks for the get value of `form` for the TokenController and if not valid stop the request dispatching and return a error status code. ### References _Are there any links users can visit to find out more?_

A stored Cross-Site Scripting (XSS) vulnerability was identified in the zenml-io/zenml repository, specifically within the 'logo_url' field. By injecting malicious payloads into this field, an attacker could send harmful messages to other users, potentially compromising their accounts. The vulnerability affects version 0.55.3 and was fixed in version 0.56.2. The impact of exploiting this vulnerability could lead to user account compromise.

It has been discovered that Neos is vulnerable to several XSS attacks. Through these vulnerabilities, an attacker could tamper with page rendering, redirect victims to a fake login page, or capture user credentials (such as cookies). With the potential backdoor upload an attacker could gain access to the server itself, to an extent mainly limited by the server setup.

Failing to properly encode information from external sources, language pack handling in the install tool is vulnerable to cross-site scripting.