#java

The ABB BMS/BAS controller suffers from an authenticated reflected cross-site scripting vulnerability. Input passed to the GET parameter 'name' is not properly sanitised before being returned to the user. This can be exploited to execute arbitrary HTML/JS code in a user's browser session in context of an affected site.

A vulnerability in Koji was found. An unsanitized input allows for an XSS attack. Javascript code from a malicious link could be reflected in the resulting web page. It is not expected to be able to submit an action or make a change in Koji due to existing XSS protections in the code.

### Impact When calling the extended toHTMLEx method, it is possible to execute arbitrary JavaScript code. ### Patches The supplied patch resolves this vulnerability for SimpleXLSX. Use 1.1.13 ### Workarounds Don't use data publication via toHTMLEx *** This vulnerability was discovered by Aleksey Solovev (Positive Technologies)

The ABB BMS/BAS controller suffers from an authenticated OS command injection vulnerability. This can be exploited to inject and execute arbitrary shell commands through POST parameters, including REMOTE, IP1, IP2, IP3, IP4, and NAME, called by the syslogUpdate.php script.

Cybersecurity researchers have found that it's possible to use large language models (LLMs) to generate new variants of malicious JavaScript code at scale in a manner that can better evade detection. "Although LLMs struggle to create malware from scratch, criminals can easily use them to rewrite or obfuscate existing malware, making it harder to detect," Palo Alto Networks Unit 42 researchers

Popular npm packages, Rspack and Vant, were recently compromised with malicious code. Learn about the attack, the impact, and how to protect your projects from similar threats.

A file upload functionality in Piranha CMS 11.1 allows authenticated remote attackers to upload a crafted PDF file to /manager/media. This PDF can contain malicious JavaScript code, which is executed when a victim user opens or interacts with the PDF in their web browser, leading to a XSS vulnerability.

A stored cross-site scripting (XSS) vulnerability in Piranha CMS 11.1 allows remote attackers to execute arbitrary JavaScript in the web browser of a user, by creating a page via the /manager/pages and then adding a markdown content with the XSS payload.

Time-of-check Time-of-use (TOCTOU) Race Condition vulnerability in Apache Tomcat. This issue affects Apache Tomcat: from 11.0.0-M1 through 11.0.1, from 10.1.0-M1 through 10.1.33, from 9.0.0.M1 through 9.0.97. The mitigation for CVE-2024-50379 was incomplete. Users running Tomcat on a case insensitive file system with the default servlet write enabled (readonly initialisation parameter set to the non-default value of false) may need additional configuration to fully mitigate CVE-2024-50379 depending on which version of Java they are using with Tomcat: - running on Java 8 or Java 11: the system property sun.io.useCanonCaches must be explicitly set to false (it defaults to true) - running on Java 17: the system property sun.io.useCanonCaches, if set, must be set to false (it defaults to false) - running on Java 21 onwards: no further configuration is required (the system property and the problematic cache have been removed) Tomcat 11.0.3, 10.1.35 and 9.0.99 onwards will include check...

### Summary An **Improper URL Handling Vulnerability** allows an attacker to access sensitive local files on the server by exploiting the `file:///` protocol. This vulnerability is triggered via the **"real-browser"** request type, which takes a screenshot of the URL provided by the attacker. By supplying local file paths, such as `file:///etc/passwd`, an attacker can read sensitive data from the server. ### Details The vulnerability arises because the system does not properly validate or sanitize the user input for the URL field. Specifically: 1. The URL input (`<input data-v-5f5c86d7="" id="url" type="url" class="form-control" pattern="https?://.+" required="">`) allows users to input arbitrary file paths, including those using the `file:///` protocol, without server-side validation. 2. The server then uses the user-provided URL to make a request, passing it to a browser instance that performs the "real-browser" request, which takes a screenshot of the content at the given URL....