#git

Directus v10.13.0 allows an authenticated external attacker to modify presets created by the same user to assign them to another user. This is possible because the application only validates the user parameter in the 'POST /presets' request but not in the PATCH request. When chained with CVE-2024-6533, it could result in account takeover.

Cybersecurity researchers have discovered a new variant of the Gafgyt botnet that's targeting machines with weak SSH passwords to ultimately mine cryptocurrency on compromised instances using their GPU computational power. This indicates that the "IoT botnet is targeting more robust servers running on cloud native environments," Aqua Security researcher Assaf Morag said in a Wednesday analysis.

Directus v10.13.0 allows an authenticated external attacker to execute arbitrary JavaScript on the client. This is possible because the application injects an attacker-controlled parameter that will be stored in the server and used by the client into an unsanitized DOM element. When chained with CVE-2024-6534, it could result in account takeover.

In HashiCorp Nomad and Nomad Enterprise from 0.6.1 up to 1.16.13, 1.7.10, and 1.8.2, the archive unpacking process is vulnerable to writes outside the allocation directory during migration of allocation directories when multiple archive headers target the same file. This vulnerability, CVE-2024-7625, is fixed in Nomad 1.6.14, 1.7.11, and 1.8.3. Access or compromise of the Nomad client agent at the source allocation first is a prerequisite for leveraging this vulnerability.

### Summary Allocating an untrusted amount of memory allows any unauthenticated user to OOM a russh server. ### Details An SSH packet consists of a 4-byte big-endian length, followed by a byte stream of this length. After parsing and potentially decrypting the 4-byte length, russh allocates enough memory for this bytestream, as a performance optimization to avoid reallocations later. https://github.com/Eugeny/russh/blob/4eaa080e7532662023f75e8fff45b743fe607f8c/russh/src/cipher/mod.rs#L254 But this length is entirely untrusted and can be set to any value by the client, causing this much memory to be allocated, which will cause the process to OOM within a few such requests. RFC 4253 contains an explicit section on packet length limits: https://datatracker.ietf.org/doc/html/rfc4253#section-6.1 > However, implementations SHOULD check that the packet length is reasonable in order for the implementation to avoid denial of service and/or buffer overflow attacks. ### PoC Running the `...

### Summary The Ultralytics action available at https://github.com/marketplace/actions/ultralytics-actions is vulnerable to GitHub Actions script injection. If anyone uses the action within a workflow that runs on the `pull_request_target` trigger, then an attacker can inject arbitrary code into that workflow using a crafted branch name. ### Details The issue exists because the `action.yml` is a composite action and uses certain fields by GitHub context expression within a `run` step: ``` echo "github.event.pull_request.head.ref: ${{ github.event.pull_request.head.ref }}" echo "github.ref: ${{ github.ref }}" echo "github.head_ref: ${{ github.head_ref }}" echo "github.base_ref: ${{ github.base_ref }}" ``` In this case, `github.head_ref` and `github.event.pull_request.head.ref` are user controlled and can be used to inject code. ### PoC 1. Create a fork of any repository that uses `ultralytics/actions` within a workflow that runs on `pull_request_ta...

A wrong assumption made when handling ECMAScript's `AsyncGenerator` operations can cause an uncaught exception on certain scripts. ## Details Boa's implementation of `AsyncGenerator` makes the assumption that the state of an `AsyncGenerator` object cannot change while resolving a promise created by methods of `AsyncGenerator` such as `%AsyncGeneratorPrototype%.next`, `%AsyncGeneratorPrototype%.return`, or `%AsyncGeneratorPrototype%.throw`. However, a carefully constructed code could trigger a state transition from a getter method for the promise's `then` property, which causes the engine to fail an assertion of this assumption, causing an uncaught exception. This could be used to create a Denial Of Service attack in applications that run arbitrary ECMAScript code provided by an external user. ## Patches Version 0.19.0 is patched to correctly handle this case. ## Workarounds Users unable to upgrade to the patched version would want to use [`std::panic::catch_unwind`](https://doc.r...

The Trix editor, versions prior to 2.1.4, is vulnerable to XSS when pasting malicious code. This vulnerability is a bypass of the fix put in place for https://github.com/basecamp/trix/security/advisories/GHSA-qjqp-xr96-cj99. In https://github.com/basecamp/trix/pull/1149, we added sanitation for Trix attachments with a `text/html` content type. However, Trix only checks the content type on the paste event's `dataTransfer` object. As long as the `dataTransfer` has a content type of `text/html`, Trix parses its contents and creates an `Attachment` with them, even if the attachment itself doesn't have a `text/html` content type. Trix then uses the attachment content to set the attachment element's `innerHTML`. ### Impact An attacker could trick a user to copy and paste malicious code that would execute arbitrary JavaScript code within the context of the user's session, potentially leading to unauthorized actions being performed or sensitive information being disclosed. ### Patches **Upda...

### Impact The validator for the RichText fieldtype blocklists `javascript:` and `vbscript:` in links to prevent XSS. This can leave other options open, and the check can be circumvented using upper case. Content editing permissions for RichText content is required to exploit this vulnerability, which typically means Editor role or higher. The fix implements an allowlist instead, which allows only approved link protocols. The new check is case insensitive. ### Patches - See "Patched versions". - https://github.com/ezsystems/ezplatform-richtext/commit/6131975108fa9756e17043e7a06a4e72f786f842 (and follow-ups https://github.com/ezsystems/ezplatform-richtext/commit/8b75c603dfd1ad6f6f3db15ae2324876683cbaf9 and https://github.com/ezsystems/ezplatform-richtext/commit/7bbc6d024c6146d1e1ba84d27a3ebffe9459613e and https://github.com/ezsystems/ezplatform-richtext/commit/2c652915625c47b493a2be06924f4c87d1df7d8e and https://github.com/ezsystems/ezplatform-richtext/commit/dbe816f3ff4c903cc508dfdcdc...

### Impact The validator for the RichText fieldtype blocklists `javascript:` and `vbscript:` in links to prevent XSS. This can leave other options open, and the check can be circumvented using upper case. Content editing permissions for RichText content is required to exploit this vulnerability, which typically means Editor role or higher. The fix implements an allowlist instead, which allows only approved link protocols. The new check is case insensitive. ### Patches - See "Patched versions". - https://github.com/ibexa/fieldtype-richtext/commit/59e9c1a9da60597f60cf7338bf289dccaa7e27ca (and follow-up https://github.com/ibexa/fieldtype-richtext/commit/0a3b830e8806d5169f697351fdc48ffd95a25c67) ### Workarounds None. ### References - Same issue in v3.3: https://github.com/ezsystems/ezplatform-richtext/security/advisories/GHSA-rhm7-7469-rcpw - Ibexa advisory: https://developers.ibexa.co/security-advisories/ibexa-sa-2024-005-persistent-xss-in-richtext ### Credit This vulnerability was di...