ghsa

The Rust Security Response WG was notified that Cargo did not prevent extracting some malformed packages downloaded from alternate registries. An attacker able to upload packages to an alternate registry could fill the file system when Cargo downloaded the package. The severity of this vulnerability is "low" for users of alternate registries. Users relying on crates.io are not affected. Note that **by design** Cargo allows code execution at build time, due to build scripts and procedural macros. The vulnerabilities in this advisory allow performing a subset of the possible damage in a harder to track down way. Your dependencies must still be trusted if you want to be protected from attacks, as it's possible to perform the same attacks with build scripts and procedural macros. ## Disk space exaustion It was discovered that Cargo did not limit the amount of data extracted from compressed archives. An attacker could upload to an alternate registry a specially crafted package that extr...

OSU Open Source Lab VNCAuthProxy through 1.1.1 is affected by an vncap/vnc/protocol.py VNCServerAuthenticator authentication-bypass vulnerability that could allow a malicious actor to gain unauthorized access to a VNC session or to disconnect a legitimate user from a VNC session. A remote attacker with network access to the proxy server could leverage this vulnerability to connect to VNC servers protected by the proxy server without providing any authentication credentials. Exploitation of this issue requires that the proxy server is currently accepting connections for the target VNC server.

### Impact All rights checks that would normally prevent a user from viewing a document on a wiki can be bypassed using the login action and directly specified templates. This exposes title, content and comments of any document and properties of objects (class and property name must be known, though). This is also exploitable on [private wikis](https://www.xwiki.org/xwiki/bin/view/Documentation/AdminGuide/Access%20Rights/#HPrivateWiki). ### Patches This has been patched in versions 14.2 and 13.10.4 by properly checking view rights before loading documents and disallowing non-default templates in the login, registration and skin action. ### Workarounds It would be possible to protect all templates individually by adding code to check access rights first, but due to the number of templates and the fact that some of them need to be used without view rights, this seems impractical. ### References * https://jira.xwiki.org/browse/XWIKI-19549 * https://jira.xwiki.org/browse/XWIKI-18602 ##...

### Impact By passing a template of the distribution wizard to the xpart template, user accounts can be created even when user registration is disabled. This also circumvents any email verification. Before versions 14.2 and 13.10.4, this can also be exploited on a private wiki, thus potentially giving the attacker access to the wiki. Depending on the configured default rights of users, this could also give attackers write access to an otherwise read-only public wiki. Users can also be created when an external authentication system like LDAP is configured, but authentication fails unless the authentication system supports a bypass/local accounts are enabled in addition to the external authentication system. ### Patches This issue has been patched in XWiki 13.10.5 and 14.3RC1. ### Workarounds It is possible to replace `xpart.vm`, the entry point for this attack, by a patched version from the [patch](https://github.com/xwiki/xwiki-platform/commit/70c64c23f4404f33289458df2a08f7c4be022755...

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