ghsa

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

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

### Impact When WebOb normalizes the HTTP Location header to include the request hostname, it does so by parsing the URL that the user is to be redirected to with Python's urlparse, and joining it to the base URL. `urlparse` however treats a `//` at the start of a string as a URI without a scheme, and then treats the next part as the hostname. `urljoin` will then use that hostname from the second part as the hostname replacing the original one from the request. ``` >>> parse.urlparse("//example.com/test/path") ParseResult(scheme='', netloc='example.com', path='/test/path', params='', query='', fragment='') ``` WebOb uses `urljoin` to take the request URI and joining the redirect location, so assuming the request URI is: `https://example.org//example.com/some/path`, and the URL to redirect to (for example by adding a slash automatically) is `//example.com/some/path/` that gets turned by `urljoin` into: ``` >>> parse.urljoin("https://example.org//attacker.com/some/path", "//attacker....

### Impact Several HTTP endpoints did not properly sanitize user input and/or query parameters. This could be exploited to inject and run unwanted shell commands ### Patches Fixed in 3.1.2 ### Workarounds No known workarounds

# Microsoft Security Advisory CVE-2024-38168 | .NET Denial of Service Vulnerability ## <a name="executive-summary"></a>Executive summary Microsoft is releasing this security advisory to provide information about a vulnerability in .NET 8.0. This advisory also provides guidance on what developers can do to update their applications to remove this vulnerability. A vulnerability exists in .NET when an attacker through unauthenticated requests may trigger a Denial of Service in ASP.NET HTTP.sys web server. This is a windows OS only vulnerability. ## Announcement Announcement for this issue can be found at https://github.com/dotnet/announcements/issues/320 ## <a name="mitigation-factors"></a>Mitigation factors Microsoft has not identified any mitigating factors for this vulnerability. ## <a name="affected-software"></a>Affected software * Any .NET 8.0 application running on .NET 8.0.7 or earlier. ## <a name="affected-packages"></a>Affected Packages The vulnerability affects any M...