ghsa

An authenticated system user at the root, namespace, or database levels can use the `DEFINE ANALYZER` statement to point to arbitrary file locations on the file system, and should the file be tab separated with two columns, the analyzer can be leveraged to exfiltrate the content. This issue was discovered and patched during an code audit and penetration test of SurrealDB by cure53, the severity defined within cure53's preliminary finding is Low, matched by our CVSS v4 assessment. ### Impact Limited to unauthorised access to 2 column TSV files on the file system ### Patches A patch has been created that introduces a new environment variable, `SURREAL_FILE_ALLOWLIST` , which contains a list of allowed file paths. When a mapping file is processed, the mapper checks if the file’s path is within one of the allowed paths. - Versions 2.1.5, 2.2.2 and later are not affected by this issue. ### Workarounds Users unable to update may want to limit those with root, namespace, or database leve...

In order to prevent DoS situations due to infinite recursions, SurrealDB implements a limit of nested calls for both native functions and embedded JavaScript functions. However, in SurrealDB instances with embedded scripting functions enabled, it was found that this limit can be circumvented by utilizing both at the same time. If a native function contains JavaScript which issues a new query that calls that function, the recursion limit is not triggered. Once executed, SurrealDB will follow the path of infinite recursions until the system runs out of memory, prior to the recursion limit being triggered. This vulnerability can only affect SurrealDB servers explicitly enabling the scripting capability with `--allow-scripting` or `--allow-all` and equivalent environment variables `SURREAL_CAPS_ALLOW_SCRIPT=true` and `SURREAL_CAPS_ALLOW_ALL=true`. This issue was discovered and patched during an code audit and penetration test of SurrealDB by cure53, the severity defined within cure53'...

A vulnerability was found where an attacker can crash the database via crafting a HTTP query that returns a null byte. The problem relies on an uncaught exception in the `net` module, where the result of the query will be converted to JSON before showing as the HTTP response to the user in the **/sql** endpoint. ### Impact This vulnerability allows any authenticated user to crash a SurrealDB instance by sending a crafted query with a null byte to the /sql endpoint. Where SurrealDB is used as an application backend, it is possible that an application user can crash the SurrealDB instance and thus the supported application through crafted inputs that exploit this attack vector. ### Patches A patch has been introduced that ensures the error is caught and converted as an error. - Versions 2.2.2, 2.1.5 and 2.0.5 and later are not affected by this isssue ### Workarounds Affected users who are unable to update may want to limit the ability of untrusted clients to run arbitrary queries ...

### Impact User enumeration is possible by performing a timing attack on the login or password reset pages with user credentials. This was originally disclosed in https://www.silverstripe.org/download/security-releases/ss-2017-005/ for CMS 3 but was not patched in CMS 4+ ### References - https://www.silverstripe.org/download/security-releases/ss-2017-005 - https://www.silverstripe.org/download/security-releases/ss-2025-001

Mattermost versions 9.11.x <= 9.11.8  fail to enforce proper access controls on the /api/v4/audits endpoint, allowing users with delegated granular administration roles who lack access to Compliance Monitoring to retrieve User Activity Logs.

The internal `Channel` type's `Drop` method has a race which could, in some circumstances, lead to a double-free. This could result in memory corruption. Quoting from the [upstream description in merge request \#1187](https://github.com/crossbeam-rs/crossbeam/pull/1187#issue-2980761131): > The problem lies in the fact that `dicard_all_messages` contained two paths that could lead to `head.block` being read but only one of them would swap the value. This meant that `dicard_all_messages` could end up observing a non-null block pointer (and therefore attempting to free it) without setting `head.block` to null. This would then lead to `Channel::drop` making a second attempt at dropping the same pointer. The bug was introduced while fixing a memory leak, in upstream [MR \#1084](https://github.com/crossbeam-rs/crossbeam/pull/1084), first published in 0.5.12. The fix is in upstream [MR \#1187](https://github.com/crossbeam-rs/crossbeam/pull/1187) and has been published in 0.5.15

A Helm contributor discovered that a specially crafted JSON Schema within a chart can lead to a stack overflow. ### Impact A JSON Schema file within a chart can be crafted with a deeply nested chain of references, leading to parser recursion that can exceed the stack size limit and trigger a stack overflow. ### Patches This issue has been resolved in Helm v3.17.3. ### Workarounds Ensure that the JSON Schema within any charts loaded by Helm does not have a large number of nested references. These JSON Schema files are larger than 10 MiB. ### For more information Helm's security policy is spelled out in detail in our [SECURITY](https://github.com/helm/community/blob/master/SECURITY.md) document. ### Credits Disclosed by Jakub Ciolek at AlphaSense.

A Helm contributor discovered that a specially crafted chart archive file can cause Helm to use all available memory and have an out of memory (OOM) termination. ### Impact A chart archive file can be crafted in a manner where it expands to be significantly larger uncompressed than compressed (e.g., >800x difference). When Helm loads this specially crafted chart, memory can be exhausted causing the application to terminate. ### Patches This issue has been resolved in Helm v3.17.3. ### Workarounds Ensure that any chart archive files being loaded by Helm do not contain files that are large enough to cause the Helm Client or SDK to use up available memory leading to a termination. ### For more information Helm's security policy is spelled out in detail in our [SECURITY](https://github.com/helm/community/blob/master/SECURITY.md) document. ### Credits Disclosed by Jakub Ciolek at AlphaSense.

### Impact A bad actor with access to edit content in the CMS could send a specifically crafted encoded payload to the server, which could be used to inject a JavaScript payload on the front end of the site. The payload would be sanitised on the client-side, but server-side sanitisation doesn't catch it. The server-side sanitisation logic has been updated to sanitise against this attack. ### Reported by James Nicoll from Fujitsu Cyber ### References - https://www.silverstripe.org/download/security-releases/cve-2025-30148

An elemental block can include an XSS payload, which can be executed when viewing the "Content blocks in use" report. The vulnerability is specific to that report and is a result of failure to cast input prior to including it in the grid field. ### References - https://www.silverstripe.org/download/security-releases/CVE-2025-25197