#java

Reflected Cross-Site Scripting (XSS) in Microweber CMS 2.0 via the layout parameter on the /admin/page/create page allows arbitrary JavaScript execution in the context of authenticated admin users.

Reflected Cross-Site Scripting (XSS) in the id parameter of the live_edit.module_settings API endpoint in Microweber CMS2.0 allows execution of arbitrary JavaScript.

A Stored Cross-Site Scripting (XSS) vulnerability in Microweber CMS 2.0 allows attackers to inject malicious scripts into user profile fields, leading to arbitrary JavaScript execution in admin browsers.

A prototype pollution vulnerability exists in @nyariv/sandboxjs versions <= 0.8.23, allowing attackers to inject arbitrary properties into Object.prototype via crafted JavaScript code. This can result in a denial-of-service (DoS) condition or, under certain conditions, escape the sandboxed environment intended to restrict code execution. The vulnerability stems from insufficient prototype access checks in the sandbox’s executor logic, particularly in the handling of JavaScript function objects returned.

### Summary Unauthorized reflected Cross-Site-Scripting when accessing the URL for recent uploads with the `filter` parameter containing JavaScript code. ### Details When accessing the recent uploads page at `/?ru`, users can filter the results using an input field at the top. This field appends a filter parameter to the URL, which reflects its value directly into a `<script>` block without proper escaping. This vulnerability allows for reflected Cross-Site Scripting (XSS) and can be exploited against both authenticated and unauthenticated users, enabling unwanted actions in the victims browser. ### PoC A URL like this will execute `alert(1)`: ``` https://127.0.0.1:3923/?ru&filter=</script><script>alert(1)</script> ```

A carefully crafted request when creating a header link using the wiki markup syntax, which could allow the attacker to execute javascript in the victim's browser and get some sensitive information about the victim. Further research by the JSPWiki team showed that the markdown parser allowed this kind of attack too. Apache JSPWiki users should upgrade to 2.12.3 or later.

A carefully crafted request using the Image plugin could trigger an XSS vulnerability on Apache JSPWiki, which could allow the attacker to execute javascript in the victim's browser and get some sensitive information about the victim. Apache JSPWiki users should upgrade to 2.12.3 or later.

** UNSUPPORTED WHEN ASSIGNED ** Improper Output Neutralization for Logs vulnerability in Apache Struts. This issue affects Apache Struts Extras: before 2. When using LookupDispatchAction, in some cases, Struts may print untrusted input to the logs without any filtering. Specially-crafted input may lead to log output where part of the message masquerades as a separate log line, confusing consumers of the logs (either human or automated).  As this project is retired, we do not plan to release a version that fixes this issue. Users are recommended to find an alternative or restrict access to the instance to trusted users. NOTE: This vulnerability only affects products that are no longer supported by the maintainer.

Cybersecurity researchers are calling attention to an ongoing campaign that distributes fake cryptocurrency trading apps to deploy a compiled V8 JavaScript (JSC) malware called JSCEAL that can capture data from credentials and wallets. The activity leverages thousands of malicious advertisements posted on Facebook in an attempt to redirect unsuspecting victims to counterfeit sites that instruct

React conquered XSS? Think again. That's the reality facing JavaScript developers in 2025, where attackers have quietly evolved their injection techniques to exploit everything from prototype pollution to AI-generated code, bypassing the very frameworks designed to keep applications secure. Full 47-page guide with framework-specific defenses (PDF, free). JavaScript conquered the web, but with