ghsa

## Impact Users running Vega/Vega-lite JSON definitions could run unexpected JavaScript code when drawing graphs, unless the library is used with the `vega-interpreter`. ## Workarounds - Use `vega` with [expression interpreter](https://vega.github.io/vega/usage/interpreter/) - Upgrade to a [newer Vega version](https://github.com/vega/vega/releases/tag/v5.32.0) (`5.32.0`) ### POC Summary Calling `replace` with a `RegExp`-like pattern calls `RegExp.prototype[@@replace]`, which can then call an attacker-controlled `exec` function. ### POC Details Consider the function call `replace('foo', {__proto__: /h/.constructor.prototype, global: false})`. Since `pattern` has `RegExp.prototype[@@replace]`, `pattern.exec('foo')` winds up being called. The resulting malicious call looks like this: ``` replace(<string argument>, {__proto__: /h/.constructor.prototype, exec: <function>, global: false}) ``` Since functions cannot be returned from this, an attacker that wishes to escalate to XSS mu...

Improper Control of Generation of Code ('Code Injection') vulnerability in Apache Kylin. If an attacker gets access to Kylin's system or project admin permission, the JDBC connection configuration maybe altered to execute arbitrary code from the remote. You are fine as long as the Kylin's system and project admin access is well protected. This issue affects Apache Kylin: from 4.0.0 through 5.0.1. Users are recommended to upgrade to version 5.0.2 or above, which fixes the issue.

Server-Side Request Forgery (SSRF) vulnerability in Apache Kylin. Through a kylin server, an attacker may forge a request to invoke "/kylin/api/xxx/diag" api on another internal host and possibly get leaked information. There are two preconditions: 1) The attacker has got admin access to a kylin server; 2) Another internal host has the "/kylin/api/xxx/diag" api endpoint open for service. This issue affects Apache Kylin: from 5.0.0 through 5.0.1. Users are recommended to upgrade to version 5.0.2, which fixes the issue.

### Impact In `vega` 5.30.0 and lower, `vega-functions` 5.15.0 and lower , it was possible to call JavaScript functions from the Vega expression language that were not meant to be supported. ### Patches Patched in `vega` `5.31.0` / `vega-functions` `5.16.0` ### Workarounds _Is there a way for users to fix or remediate the vulnerability without upgrading?_ - Run `vega` without `vega.expressionInterpreter`. This mode is not the default as it is slower. - Using the interpreter [described in CSP safe mode](https://vega.github.io/vega/usage/interpreter/) (Content Security Policy) prevents arbitrary Javascript from running, so users of this mode are not affected by this vulnerability. ### References - Reported to Vega-Lite by @kprevas Nov 8 2024 in https://github.com/vega/vega-lite/issues/9469 & https://github.com/vega/vega/issues/3984 Reproduction of the error in Vega by @mattijn ``` { "$schema": "https://vega.github.io/schema/vega/v5.json", "signals": [ { "name...

### Summary User supplied values passed through to certain attributes in form widgets are not fully escaped for potentially dangerous tokens, and in some cases are rendered in browser as valid html tags. ### Details Attributes passed to the widget (such as `label_field`) containing `<`, `>`, and similar tokens are not fully escaped. This results in some raw values reaching the widget, and rendering in part or fully. For example, a label of: `"Test User <script>I can pass this to the label_field and it gets rendered</script>"` is rendered in the choices's label visually as `"Test User "` with the trailing space, and what appears as an un-executed script tag following it (which is visible when viewing source). The actual output rendered in the browser for this example is: `<div role="option" data-value="63f205b6" class="item" data-ts-item="">Test User <script>I can pass this to the label_field and it gets rendered</script></div>` The script tags appears to be valid in Chrome dev tool...

Affected versions of this crate only validated the `index` argument of `HashTable::get_bucket` and `HashTable::get_chain` against the input-controlled `bucket_count` and `chain_count` fields, but not against the size of the ELF section. As a result, a malformed ELF file could trigger out-of-bounds reads in a consumer of the HashTable API by setting these fields to inappropriately large values that would fall outside the relevant hash table section, and by introducing correspondingly out-of-bounds hash table indexes elsewhere in the ELF file.

### Describe the Bug In Directus, when a **Flow** with the "_Webhook_" trigger and the "_Data of Last Operation_" response body encounters a ValidationError thrown by a failed condition operation, the API response includes sensitive data. This includes environmental variables, sensitive API keys, user accountability information, and operational data. This issue poses a significant security risk, as any unintended exposure of this data could lead to potential misuse.    ### To Reproduce **Steps to Reproduce:** 1. Create a Flow in Directus with: - Trigger: Webhook - Response Body: Data of Last Operation 2. Add a condition that is likely to fail. 3. Trigger the Flow with any input data that will fail the condition...

### Summary The `search` query parameter allows users with access to a collection to filter items based on fields they do not have permission to view. This allows the enumeration of unknown field contents. ### Details The searchable columns (numbers & strings) are not checked against permissions when injecting the `where` clauses for applying the search query. This leads to the possibility of enumerating those un-permitted fields. ### PoC - Create a collection with a string / numeric field, configure the permissions for the public role to not include the field created - Create items with identifiable content in the not permitted field - Query the collection and include the field content in the `search` parameter - See that results are returned, even tho the public user does not have permission to view the field content ### Impact This vulnerability is a very high impact, as for example Directus instances which allow public read access to the user avatar are vulnerable to have th...

### Summary Since the user status is not checked when verifying a session token a suspended user can use the token generated in session auth mode to access the API despite their status. ### Details There is a check missing in `verifySessionJWT` to verify that a user is actually still active and allowed to access the API. Right now one can extract the session token obtained by, e.g. login in to the app while still active and then, after the user has been suspended continue to use that token until it expires. ### PoC * Create an active user * Log in with that user and note the session cookie * Suspend the user (and don't trigger an `/auth/refresh` call, as that invalidates the session * Access the API with `Authorization: Bearer <token>` ### Impact This weakens the security of suspending users.

### Summary There's some tools that use Directus to sync content and assets. Some of those tools use HEAD method, like Shopify, to check the existence of files. Although, when making many HEAD requests at once, at some point, all assets are being served as 403. ### Details When I was investigating this issue, I have found that after the burst of HEAD requests, the amount of `sockets` held on [Agent on NodeHttpHandler](https://github.com/smithy-lang/smithy-typescript/blob/main/packages/node-http-handler/src/node-http-handler.ts#L189) was always equal to [`STORAGE_CLOUD_MAX_SOCKETS`](https://github.com/directus/directus/blob/main/packages/storage-driver-s3/src/index.ts#L89) making it impossible to have new connections causing assets to be inaccessible. After looking into this [issue on AWS SDK](https://github.com/aws/aws-sdk-js-v3/issues/6691) I found that if the [stream is requested](https://github.com/directus/directus/blob/main/api/src/services/assets.ts#L213), it needs to be consum...