Source
ghsa
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
### Impact This security advisory resolves a vulnerability in the RichText field type. By entering a maliciously crafted input into the RichText XML, an attacker could perform an attack using XML external entity (XXE) injection, which might be able to read files on the server. To exploit this vulnerability the attacker would need to already have edit permission to content with RichText fields, which typically means Editor role or higher. The fix removes unsafe elements from XML code, while preserving safe elements. If you have a stored XXE attack in your content drafts, the fix prevents it from extracting data both during editing and preview. However, if such an attack has already been published and the result is stored in the content, it is unfortunately not possible to detect and remove it by automatic means. ### Credits This vulnerability was discovered and reported to Ibexa by Dennis Henke, Thorsten Niephaus, Marat Aytuganov, and Stephan Sekula of [Compass Security Deutschland Gm...
### Impact This security advisory resolves a vulnerability in the RichText field type. By entering a maliciously crafted input into the RichText XML, an attacker could perform an attack using XML external entity (XXE) injection, which might be able to read files on the server. To exploit this vulnerability the attacker would need to already have edit permission to content with RichText fields, which typically means Editor role or higher. The fix removes unsafe elements from XML code, while preserving safe elements. If you have a stored XXE attack in your content drafts, the fix prevents it from extracting data both during editing and preview. However, if such an attack has already been published and the result is stored in the content, it is unfortunately not possible to detect and remove it by automatic means. ### Credits This vulnerability was discovered and reported to Ibexa by Dennis Henke, Thorsten Niephaus, Marat Aytuganov, and Stephan Sekula of [Compass Security Deutschland Gm...
Yii 2 before 2.0.52 mishandles the attaching of behavior that is defined by an __class array key, a CVE-2024-4990 regression, as exploited in the wild in February through April 2025.
### Impact _What kind of vulnerability is it? Who is impacted?_ **Description:** This vulnerability affects confidential client applications, including daemons, web apps, and web APIs. Under specific circumstances, sensitive information such as client secrets or certificate details may be exposed in the service logs of these applications. Service logs are intended to be handled securely. **Impact:** The vulnerability impacts service logs that meet the following criteria: - **Logging Level:** Logs are generated at the information level. - **Credential Descriptions:** containing: - Local file paths with passwords. - Base64 encoded values. - Client secret. Additionally, logs of services using Base64 encoded certificates or certificate paths with password credential descriptions are also affected if the certificates are invalid or expired, regardless of the log level. Note that these credentials are not usable due to their invalid or expired status. If your service log...