#java

Improper Neutralization of Input During Web Page Generation ('Cross-site Scripting') vulnerability in Apache Archiva. This issue affects Apache Archiva: from 2.0.0. 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. Alternatively, you could configure a HTTP proxy in front of your Archiva instance to only forward requests that do not have malicious characters in the URL. NOTE: This vulnerability only affects products that are no longer supported by the maintainer.

** UNSUPPORTED WHEN ASSIGNED ** Incorrect Authorization vulnerability in Apache Archiva. Apache Archiva has a setting to disable user registration, however this restriction can be bypassed. As Apache Archiva has been retired, we do not expect to release a version of Apache Archiva that fixes this issue. You are recommended to look into migrating to a different solution, or isolate your instance from any untrusted users. NOTE: This vulnerability only affects products that are no longer supported by the maintainer

** UNSUPPORTED WHEN ASSIGNED ** Incorrect Authorization vulnerability in Apache Archiva: a vulnerability in Apache Archiva allows an unauthenticated attacker to modify account data, potentially leading to account takeover. This issue affects Apache Archiva: from 2.0.0. 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.

### Impact A user could type HTML into a field, including the field for the user's name, and then that HTML could be displayed on the screen as HTML. The HTML can also contain `<script>` tags allowing JavaScript to execute on the page. ### Patches The vulnerability has been patched in version 1.4.97 of the master branch. The Docker image on docker.io has been patched. ### Workarounds If upgrading is not possible, manually apply the changes of [4801ac7](https://github.com/jhpyle/docassemble/commit/4801ac7ff7c90df00ac09523077930cdb6dea2aa) and restart the server (e.g., by pressing Save on the Configuration screen). ### Credit The vulnerability was discovered by Riyush Ghimire (@richighimi). ### For more information If you have any questions or comments about this advisory: * Open an issue in [docassemble](https://github.com/jhpyle/docassemble/issues) * Join the [Slack channel](https://join.slack.com/t/docassemble/shared_invite/zt-2cspzjo9j-YyE7SrLmi5muAvnPv~Bz~A) * Email us at jhpy...

Plus: Mozilla patches 12 flaws in Firefox, Zoom fixes seven vulnerabilities, and more critical updates from February.

A Cross-Site Scripting vulnerability in Cockpit CMS affecting version 2.7.0. This vulnerability could allow an authenticated user to upload an infected PDF file and store a malicious JavaScript payload to be executed when the file is uploaded.

WordPress IDonate Blood Request Management System plugin versions 1.8.1 and below suffer from a persistent cross site scripting vulnerability.

http-swagger before 1.2.6 allows XSS via PUT requests, because a file that has been uploaded (via httpSwagger.WrapHandler and *webdav.memFile) can subsequently be accessed via a GET request. NOTE: this is independently fixable with respect to CVE-2022-24863, because (if a solution continued to allow PUT requests) large files could have been blocked without blocking JavaScript, or JavaScript could have been blocked without blocking large files.

The jose4j component before 0.9.4 for Java allows attackers to cause a denial of service (CPU consumption) via a large p2c (aka PBES2 Count) value.

### Summary The "frames.html" file within the Yard Doc's generated documentation is vulnerable to Cross-Site Scripting (XSS) attacks due to inadequate sanitization of user input within the JavaScript segment of the "frames.erb" template file. ### Details The vulnerability stems from mishandling user-controlled data retrieved from the URL hash in the embedded JavaScript code within the "frames.erb" template file. Specifically, the script lacks proper sanitization of the hash data before utilizing it to establish the top-level window's location. This oversight permits an attacker to inject malicious JavaScript payloads through carefully crafted URLs. Snippet from "frames.erb": ```erb <script type="text/javascript"> var match = unescape(window.location.hash).match(/^#!(.+)/); var name = match ? match[1] : '<%= url_for_main %>'; name = name.replace(/^(\w+):\/\//, '').replace(/^\/\//, ''); window.top.location = name; </script> ``` ### PoC (Proof of Concept) To exploit this vulner...