#git

An improper neutralization of input during web page generation ('Cross-site Scripting') [CWE-79] vulnerability in Apache Felix Healthcheck Webconsole Plugin version 2.0.2 and prior may allow an attacker to perform a reflected cross-site scripting (XSS) attack. Upgrade to Apache Felix Healthcheck Webconsole Plugin 2.1.0 or higher.

> ### CVSS: `CVSS:3.1/AV:N/AC:H/PR:N/UI:R/S:C/C:L/I:L/A:N/E:F/RL:O/RC:C` (4.4) ### Problem Due to an encoding issue in the serialization layer, malicious markup nested in a `noscript` element was not encoded correctly. `noscript` is disabled in the default configuration, but might have been enabled in custom scenarios. This allows bypassing the cross-site scripting mechanism of [`typo3/html-sanitizer`](https://packagist.org/packages/typo3/html-sanitizer). ### Solution Update to `typo3/html-sanitizer` versions 1.5.1 or 2.1.2 that fix the problem described. ### Credits Thanks to David Klein and Yaniv Nizry who reported this issue, and to TYPO3 security team members Oliver Hader and Benjamin Franzke who fixed the issue. ### References * [TYPO3-CORE-SA-2023-002](https://typo3.org/security/advisory/typo3-core-sa-2023-002)

### Impact Spring supports [Matrix variables](https://docs.spring.io/spring-framework/reference/web/webmvc/mvc-controller/ann-methods/matrix-variables.html). When Spring integration is used, Armeria calls Spring controllers via `TomcatService` or `JettyService` with the path that may contain matrix variables. In this situation, the Armeria decorators might not invoked because of the matrix variables. Let's see the following example: ``` // Spring controller @GetMapping("/important/resources") public String important() {...} // Armeria decorator ServerBuilder sb = ... sb.decoratorUnder("/important/", authService); ``` If an attacker sends a request with `/important;a=b/resources`, the request would bypass the authrorizer ### Patches - https://github.com/line/armeria-ghsa-wvp2-9ppw-337j/commit/9b0ec3e099cc05fbff11d7f1012a1dddb0000d0c ### Workarounds Users can add decorators using regex. `e.g. "regex:^/important.*"`

Tuleap is a free and open source suite to improve management of software development and collaboration. Prior to version 14.10.99.4 of Tuleap Community Edition and prior to versions 14.10-2 and 14.9-5 of Tuleap Enterprise Edition, content displayed in the "card fields" (visible in the kanban and PV2 apps) is not properly escaped. A malicious user with the capability to create an artifact or to edit a field used as a card field could force victim to execute uncontrolled code. Tuleap Community Edition 14.10.99.4, Tuleap Enterprise Edition 14.10-2, and Tuleap Enterprise Edition 14.9-5 contain a fix.

### Impact Private messages or posts might be leaked to third parties if victim opens the attackers site while browsing nodebb. ### Patches * Patched in v3.1.3 * Backported to v2.x line via v2.8.13 ### Workarounds Users can cherry-pick https://github.com/NodeBB/NodeBB/commit/51096ad2345fb1d1380bec0a447113489ef6c359 if they are on v3.x If you are running v2.x of NodeBB, you can cherry-pick a5d92da9ddac5607ab7f737520a66eaed6d3ddee followed by 62e162cf1e735e42462be1db9b4954b5a69accdf

### Summary The application contains a reflected cross-site scripting via URL-parameter `?k304=...` and `?setck=...` ### Details A reflected cross-site scripting (XSS) vulnerability exists in the web interface of the application that could allow an attacker to execute malicious javascript code by tricking users into accessing a malicious link. The worst-case outcome of this is being able to move or delete existing files on the server, or upload new files, using the account of the person who clicks the malicious link. It is recommended to change the passwords of your copyparty accounts, unless you have inspected your logs and found no trace of attacks. ### Checking for exposure if copyparty is running behind a reverse proxy, you can check the access-logs for traces of attacks, by grepping for URLs containing `?hc=` with `<` somewhere in its value, for example using the following command: * nginx: ```bash (gzip -dc access.log*.gz; cat access.log) | sed -r 's/" [0-9]+ .*//' | grep...

### Impact the ecrecover precompile does not fill the output buffer if the signature does not verify, see https://github.com/ethereum/go-ethereum/blob/b058cf454b3bdc7e770e2b3cec83a0bcb48f55ee/core/vm/contracts.go#L188. however, the ecrecover builtin will still return whatever is at memory location 0. this means that the if the compiler has been convinced to write to the 0 memory location with specially crafted data (generally, this can happen with a hashmap access or immutable read) just before the ecrecover, a signature check might pass on an invalid signature. ### Patches v0.3.10 ### Workarounds _Is there a way for users to fix or remediate the vulnerability without upgrading?_ ### References _Are there any links users can visit to find out more?_

### Summary Using AbstractUnArchiver for extracting an archive might lead to an arbitrary file creation and possibly remote code execution. ### Description When extracting an archive with an entry that already exists in the destination directory as a symbolic link whose target does not exist - the resolveFile() function will return the symlink's source instead of its target, which will pass the verification that ensures the file will not be extracted outside of the destination directory. Later Files.newOutputStream(), that follows symlinks by default, will actually write the entry's content to the symlink's target. ### Impact Whoever uses plexus archiver to extract an untrusted archive is vulnerable to an arbitrary file creation and possibly remote code execution. ### Technical Details In [AbstractUnArchiver.java](https://github.com/codehaus-plexus/plexus-archiver/blob/plexus-archiver-4.7.1/src/main/java/org/codehaus/plexus/archiver/AbstractUnArchiver.java#L342): ```java protecte...

### Impact An authenticated user can download a debug or artifact bundle from arbitrary organizations and projects with a known bundle ID. The user does not need to be a member of the organization or have permissions on the project. ### Patches A patch was issued to ensure authorization checks are properly scoped on requests to retrieve debug or artifact bundles. Authenticated users who do not have the necessary permissions on the particular project are no longer able to download them. **Sentry SaaS users do not need to take any action. [Self-Hosted Sentry](https://github.com/getsentry/self-hosted) users should upgrade to version 23.5.2 or higher.** ### References - [Restrict file downloads to Project](https://github.com/getsentry/sentry/pull/49680)

### Impact Authenticated users can inject malicious code in widgets with units, which is then executed both in the element preview (back end) and on the website (front end). ### Patches Update to Contao 4.9.42, 4.13.28 or 5.1.10. ### Workarounds Disable login for all untrusted back end users. ### References https://contao.org/en/security-advisories/cross-site-scripting-in-widgets-with-units ### For more information If you have any questions or comments about this advisory, open an issue in [contao/contao](https://github.com/contao/contao/issues/new/choose). ### Credits Thanks to Maximilian Seilmaier from usd AG for reporting this vulnerability.