ghsa

### Impact When an "Internal System Error" occurs in the JSPUI, then entire exception (including stack trace) is available. Information in this stacktrace may be useful to an attacker in launching a more sophisticated attack. This vulnerability only impacts the JSPUI. _This vulnerability does NOT impact the XMLUI or 7.x._ ### Patches _DSpace 6.x:_ * Fixed in 6.4 via commit: https://github.com/DSpace/DSpace/commit/afcc6c3389729b85d5c7b0230cbf9aaf7452f31a * 6.x patch file: https://github.com/DSpace/DSpace/commit/afcc6c3389729b85d5c7b0230cbf9aaf7452f31a.patch (may be applied manually if an immediate upgrade to 6.4 or above is not possible) _DSpace 5.x:_ * The 6.x patch file can also be applied to an older 5.x installation. * Alternatively, you can simply apply the workaround documented below. The detailed error information embedded in `internal.jsp` is not necessary for the JSPUI to function. #### Apply the patch to your DSpace If at all possible, we recommend upgrading your DSpace...

### Description When a Solana Pay transaction is located using a [reference key](https://github.com/solana-labs/solana-pay/blob/master/SPEC.md#reference), it may be checked to represent a transfer of the desired amount to the recipient, using the supplied [`validateTransfer` function](https://github.com/solana-labs/solana-pay/blob/master/core/src/validateTransfer.ts). An edge case regarding this mechanism could cause the validation logic to validate multiple transfers. ### Impact Most known Solana Pay point of sale applications are currently run on physical point of sale devices, which makes this issue unlikely to occur. However, there may be web-based point of sale applications using the protocol where it may be more likely to occur. ### Patches This issue has been patched as of version [`0.2.1`](https://www.npmjs.com/package/@solana/pay/v/0.2.1). Users of the Solana Pay SDK should upgrade to it.

In some situations, the Image module does not correctly check access to image files not stored in the standard public files directory when generating derivative images using the image styles system. Access to a non-public file is checked only if it is stored in the "private" file system. However, some contributed modules provide additional file systems, or schemes, which may lead to this vulnerability. This vulnerability is mitigated by the fact that it only applies when the site sets (Drupal 9) `$config['image.settings']['allow_insecure_derivatives']` or (Drupal 7) `$conf['image_allow_insecure_derivatives']` to TRUE. The recommended and default setting is FALSE, and Drupal core does not provide a way to change that in the admin UI. Some sites may require configuration changes following this security release. Review the release notes for your Drupal version if you have issues accessing files or image styles after updating.

### Impact An attacker may be able to cause a denial-of-service (DoS) condition on the server on which the product is running. This affects untangle versions up to and including 1.2.0 ### Patches The problem has been fixed with version 1.2.1 ### Workarounds None ### References https://jvn.jp/en/jp/JVN30454777/ ### For more information If you have any questions or comments about this advisory: * Open an [issue](https://github.com/stchris/untangle/issues)

### Impact An attacker may be able to read the contents of local files. This affects untangle versions up to and including 1.2.0 ### Patches The problem has been fixed with version 1.2.1 ### Workarounds None ### References https://jvn.jp/en/jp/JVN30454777/ ### For more information If you have any questions or comments about this advisory: * Open an [issue](https://github.com/stchris/untangle/issues)

### Impact An information disclosure vulnerability in `next-auth` before `v4.10.2` and `v3.29.9` allows an attacker with log access privilege to obtain excessive information such as an identity provider's secret in the log (which is thrown during OAuth error handling) and use it to leverage further attacks on the system, like impersonating the client to ask for extensive permissions. ### Patches We patched this vulnerability in `v4.10.2` and `v3.29.9` by moving the log for `provider` information to the debug level. In addition, we added a warning for having the `debug: true` option turned on in production and documented it [here](https://next-auth.js.org/warnings#debug_enabled). > You have enabled the debug option. It is meant for development only, to help you catch issues in your authentication flow and you should consider removing this option when deploying to production. One way of only allowing debugging while not in production is to set debug: process.env.NODE_ENV !== "production...

### Impact Access to lateral directories when using `app.static` if using encoded `%2F` URLs. Parent directory traversal is not impacted. ### Patches - v20.12.7 (LTS) - v21.12.2 (LTS) - v22.6.1 ### References https://github.com/sanic-org/sanic/issues/2478 https://github.com/sanic-org/sanic/pull/2495 ### For more information If you have any questions or comments about this advisory: * Open an issue in [the community forums](https://community.sanicframework.org/) * Ping us on [the Discord server](https://discord.gg/FARQzAEMAA)

### Impact Users electing to prevent others starting private discussions with themselves. > Please note that admins and others with appropriate permissions can always bypass this preference, as was the case before. ### Patches Users of Byobu should update the extension to version 1.1.7, where this has been patched. **This version is only supported on v1.2.0 and later of Flarum Core.** Users of Byobu with Flarum 1.0 or 1.1 should upgrade to Flarum 1.2 or later, or evaluate the impact this issue has on your forum's users and choose to disable the extension if needed. ### Workarounds There are no workarounds for this issue.

## Impact Untrusted websocket connections can cause an out-of-memory (OOM) process abort in a client or a server. The root cause of the issue is during dataframe parsing. Affected versions would allocate a buffer based on the declared dataframe size, which may come from an untrusted source. When `Vec::with_capacity` fails to allocate, the default Rust allocator will abort the current process, killing all threads. This affects only sync (non-Tokio) implementation. Async version also does not limit memory, but does not use `with_capacity`, so DoS can happen only when bytes for oversized dataframe or message actually got delivered by the attacker. This is a security concern for you, if - your server application handles untrusted websocket connections - OR your client application connects to untrusted websocket servers ## Patches The crashes are fixed in version **0.26.5** by imposing default dataframe size limits. Affected users are advised to update to this version. Note that default ...

The package @acrontum/filesystem-template before 0.0.2 are vulnerable to Arbitrary Command Injection due to the fetchRepo API missing sanitization of the href field of external input.