ghsa

### Summary CWE-200: Exposure of Sensitive Information to an Unauthorized Actor Access to information you should not have access to when the permissions rely on `$CURRENT_USER` for filtering. ### Details The permission filters (i.e. `user_created IS $CURRENT_USER`) are not properly checked when using GraphQL subscription resulting in unauthorized users getting event on their subscription which they should not be receiving according to the permissions. This can be any collection but out-of-the box the `directus_users` collection is configured with such a permissions filter allowing you to get updates for other users when changes happen. An example: ```graphql subscription { directus_users_mutated { event data { id last_access last_page } } } ``` ### Patches https://github.com/directus/directus/pull/19155 ### Workarounds Disable GraphQL Subscriptions ### References

> ### 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 The [WordCount](https://ckeditor.com/cke4/addon/wordcount) plugin ([`npm:ckeditor-wordcount-plugin`](https://www.npmjs.com/package/ckeditor-wordcount-plugin)) for CKEditor4 is vulnerable to cross-site scripting when switching to the source code mode. This plugin is enabled via the `Full.yaml` configuration present, but is not active in the default configuration. In default scenarios, exploiting this vulnerability requires a valid backend user account. However, if custom plugins are used on the website frontend, which accept and reflect rich-text content submitted by users, no authentication is required. ### Solution Update to TYPO3 versions 9.5.42 ELTS, 10.4.39 ELTS, 11.5.30, 12.4.4 that fix the problem described above. ### Credits Thanks to Sybille Peters who reported this issue, and to TYPO3 core & security team member Oliver Hader who fixed the issue. ### References * [TYPO3-CORE-SA-2023-...

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)

> ### CVSS: `CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:L/I:N/A:N/E:F/RL:O/RC:C` (3.5) ### Problem In multi-site scenarios, enumerating the HTTP query parameters `id` and `L` allowed out-of-scope access to rendered content in the website frontend. For instance, this allowed visitors to access content of an internal site by adding handcrafted query parameters to the URL of a site that was publicly available. ### Solution Update to TYPO3 versions 9.5.42 ELTS, 10.4.39 ELTS, 11.5.30, 12.4.4 that fix the problem described above. > ℹ️ **Strong security defaults - Manual actions required** > Resolving sites by the `id` and `L` HTTP query parameters is now denied per default. However, it is still allowed to resolve a particular page by e.g. `https://example.org/?id=123&L=0` - as long as the `page-id 123` is in the scope of the site configured for the `base-url example.org`. > The new feature flag `security.frontend.allowInsecureSiteResolutionByQueryParameters` - which is disabled per default - can ...

### 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.*"`

### 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...