ghsa

### Impact It's possible to store a JavaScript which will be executed by anyone viewing the history of an attachment containing javascript in its name. For example, attachment a file with name `><img src=1 onerror=alert(1)>.jpg` will execute the alert. ### Patches This issue has been patched in XWiki 13.10.6 and 14.3RC1. ### Workarounds It is possible to replace viewattachrev.vm, the entry point for this attack, by a [patch](https://github.com/xwiki/xwiki-platform/commit/047ce9fa4a7c13f3883438aaf54fc50f287a7e8e)ed version from the patch without updating XWiki. ### References * https://jira.xwiki.org/browse/XWIKI-19612 ### For more information If you have any questions or comments about this advisory: * Open an issue in [Jira XWiki.org](https://jira.xwiki.org/) * Email us at [Security Mailing List](mailto:security@xwiki.org)

### Impact Denial of Service ### Details OPC UA specification describes a concept named _Subscriptions_. _Subscriptions_ monitor a set of _Monitored Items_ for _Notifications_ and return them to the _Client_ in response to _Publish_ requests. The server notifies the client about changes only in case the value is changed. Each monitored item is configured on a subscription, each subscription is linked to a single OPC UA session. Most OPC UA implementations set many controls and limitations for excessive memory consumption. For example: * What is the maximum allowed number of concurrent sessions * For each active sessions - what is the maximum allowed number of concurrent subscription per a single session * For each active subscription - what is the maximum allowed number of concurrent monitored items per a single subscription Clarity Research discovered a unique way to bypass those restrictions and fill up the OPC UA server process memory. The close session request closes a connec...

### Impact The function `_verify_root_self_signed()`, introduced in [v0.14.0](https://github.com/theupdateframework/tuf/releases/tag/v0.14.0), and which verifies self-signatures in a new root metadata file, counted multiple signatures by any new root key towards the new threshold. That is, any single new root key could theoretically provide enough signatures to meet the threshold for new key self-signatures required during root metadata update. A scenario where this attack could be relevant is amazingly unlikely in practice to the point where labeling this issue as a security advisory is potentially overstating the impact of the issue. Given that new root keys only become trusted by the client after a successful root metadata update, which also requires the quorum of signatures from old trusted root keys, this issue has been evaluated as low in severity. In particular, in order to exploit this vulnerability, an attacker must: 1. Control one new root key. 2. Craft a new root metadat...

### Impact Improper Authorization functions leads to non-privileged users running privileged API calls. If you have added users to your Netmaker platform who whould not have admin privileges, they could use their auth token to run admin-level functions via the API. In addition, differing response codes based on function calls allowed non-users to potentially brute force the determination of names of networks on the system. ### Patches This problem has been patched in v0.15.1. To apply: 1. docker-compose down 2. docker pull gravitl/netmaker:v0.15.1 3. docker-compose up -d ### For more information If you have any questions or comments about this advisory: Email us at [info@netmaker.io](mailto:info@netmaker.io) This vulnerability was brought to our attention by @tweidinger

### Impact Events retrieved from a remote homeserver using `/get_missing_events` did not have their signatures verified correctly. This could potentially allow a remote homeserver to provide invalid/modified events to Dendrite via this endpoint. Note that this does not apply to events retrieved through other endpoints (e.g. `/event`, `/state`) as they have been correctly verified. Homeservers that have federation disabled are not vulnerable. ### Patches The problem has been fixed in Dendrite 0.9.8. ### Workarounds There are no workarounds. ### Special thanks Tulir Asokan, who spotted the issue originally.

> ### Meta > * CVSS: `CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:C/C:L/I:L/A:N/E:F/RL:O/RC:C` (5.7) ### Problem Due to a parsing issue in upstream package [`masterminds/html5`](https://packagist.org/packages/masterminds/html5), malicious markup used in a sequence with special HTML comments cannot be filtered and sanitized. This allows to by-pass the cross-site scripting mechanism of [`typo3/html-sanitizer`](https://github.com/TYPO3/html-sanitizer). ### Solution Update to TYPO3 version 7.6.58 ELTS, 8.7.48 ELTS, 9.5.37 ELTS, 10.4.32 or 11.5.16 that fix the problem described above. ### Credits Thanks to David Klein who reported this issue, and to TYPO3 security team member Oliver Hader who fixed the issue. ### References * [TYPO3-CORE-SA-2022-011](https://typo3.org/security/advisory/typo3-core-sa-2022-011) * [GHSA-47m6-46mj-p235](https://github.com/TYPO3/html-sanitizer/security/advisories/GHSA-47m6-46mj-p235)

### Impact IRC allows you to specify multiple modes in a single mode command. Due to a bug in the underlying matrix-org/node-irc library, affected versions of matrix-appservice-irc perform parsing of such modes incorrectly, potentially resulting in the wrong user being given permissions. Mode commands can only be executed by privileged users, so this can only be abused if an operator is tricked into running the command on behalf of an attacker. ### Patches The vulnerability has been patched in matrix-appservice-irc 0.35.0. ### Workarounds Refrain from entering mode commands suggested by untrusted users. Avoid using multiple modes in a single command. ### References - https://matrix.org/blog/2022/09/02/security-release-of-matrix-appservice-irc-0-35-0-high-severity ### Credits Discovered and reported by [Val Lorentz](https://valentin-lorentz.fr/). ### For more information If you have any questions or comments about this advisory email us at [security@matrix.org](mailto:securi...

### Impact Attackers can specify a specific string of characters, which would confuse the bridge into combining an attacker-owned channel and an existing channel, allowing them to grant themselves permissions in the channel. ### Patched The vulnerability has been patched in matrix-appservice-irc 0.35.0. ### Workarounds Disable dynamic channel joining via `dynamicChannels.enabled` to prevent users from joining new channels, which prevents any new channels being bridged outside of what is already bridged, and what is specified in the config. ### References - https://matrix.org/blog/2022/09/02/security-release-of-matrix-appservice-irc-0-35-0-high-severity ### Credits Discovered and reported by [Val Lorentz](https://valentin-lorentz.fr/). ### For more information If you have any questions or comments about this advisory email us at [security@matrix.org](mailto:security@matrix.org).

Microsoft is releasing this security advisory to provide information about a vulnerability in .NET Core 3.1 and .NET 6.0. This advisory also provides guidance on what developers can do to update their applications to remove this vulnerability. A denial of service vulnerability exists in ASP.NET Core 3.1 and .NET 6.0 where a malicious client could cause a stack overflow which may result in a denial of service attack when an attacker sends a customized payload that is parsed during model binding. ## <a name="affected-software"></a>Affected software * Any .NET 6.0 application running on .NET 6.0.8 or earlier. * Any ASP.NET Core 3.1 application running on .NET Core 3.1.28 or earlier. If your application uses the following package versions, ensure you update to the latest version of .NET. ### <a name="ASP.NET Core 3.1"></a>.NET Core 3.1 Package name | Affected version | Patched version ------------ | ---------------- | ------------------------- [Microsoft.AspNetCore.App.Runtime.linux-arm]...

`<bytes::Bytes as axum_core::extract::FromRequest>::from_request` would not, by default, set a limit for the size of the request body. That meant if a malicious peer would send a very large (or infinite) body your server might run out of memory and crash. This also applies to these extractors which used `Bytes::from_request` internally: - `axum::extract::Form` - `axum::extract::Json` - `String` The fix is also in `axum-core` `0.3.0.rc.2` but `0.3.0.rc.1` _is_ vulnerable. Because `axum` depends on `axum-core` it is vulnerable as well. The vulnerable versions of `axum` are `<= 0.5.15` and `0.6.0.rc.1`. `axum` `>= 0.5.16` and `>= 0.6.0.rc.2` does have the fix and are not vulnerable. The patched versions will set a 2 MB limit by default.