#git

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

### Summary An arbitrary file write vulnerability exists in the webcrack module when processing specifically crafted malicious code on Windows systems. This vulnerability is triggered when using the unpack bundles feature in conjunction with the saving feature. If a module name includes a path traversal sequence with Windows path separators, an attacker can exploit this to overwrite files on the host system. ### Details Source: [packages/webcrack/src/unpack/bundle.ts#L79](https://github.com/j4k0xb/webcrack/blob/241f9469e6401f3dabc6373233d85a5e76966b54/packages/webcrack/src/unpack/bundle.ts#L79) ```ts import { posix } from 'node:path'; import type { Module } from './module'; // eslint-disable-next-line @typescript-eslint/unbound-method const { dirname, join, normalize } = posix; /* ... snip ... */ const modulePath = normalize(join(path, module.path)); if (!modulePath.startsWith(path)) { throw new Error(`detected path traversal: ${module.path}`); } await mkdir(dirname(modulePath...

Security researchers say they’ve extracted digital management keys from select electronic lockers and revealed how they could be cloned.

### Summary An issue was identified in the Interchain Security (ICS) module that could result in the slashing of a validator for an "old" equivocation. The height-base filter for consumer equivocation evidence introduced in [v2.4.0-lsm](https://github.com/cosmos/interchain-security/releases/tag/v2.4.0-lsm) was re-enabled. ### Details ICS [v2.4.0-lsm](https://github.com/cosmos/interchain-security/releases/tag/v2.4.0-lsm) introduced a height-base filter for consumer equivocation evidence. This feature enables a provider to set per consumer chain minimum heights for which cryptographic evidence is considered valid. The Cosmos Hub [v14 upgrade](https://github.com/cosmos/gaia/releases/tag/v14.1.0) bumped ICS to v2.4.0-lsm and also set the minimum evidence height for both `neutron-1` and `stride-1` consumer chains to their respective height at that time (see [PR](https://github.com/cosmos/gaia/pull/2821)). As a result, "older" cryptographic evidence was no longer accepted by the Hub. ...

An ongoing social engineering campaign with alleged links to the Black Basta ransomware group has been linked to "multiple intrusion attempts" with the goal of conducting credential theft and deploying a malware dropper called SystemBC. "The initial lure being utilized by the threat actors remains the same: an email bomb followed by an attempt to call impacted users and offer a fake solution,"

In K7 Ultimate Security versions prior to 17.0.2019, the driver file (K7RKScan.sys - this version 15.1.0.7) allows local users to cause a denial of service (BSOD) or possibly have unspecified other impact because of a null pointer dereference from IOCtl 0x222010 and 0x222014. At the same time, the drive is accessible to all users in the "Everyone" group.