Source
ghsa
### Impact Prior to `ethereum` crate v0.18.0, signature malleability (according to EIP-2) was only checked for "legacy" transactions, but not for EIP-2930, EIP-1559 and EIP-7702 transactions. This is a specification deviation and therefore a high severity advisory if the `ethereum` crate is used for Ethereum mainnet. Note that signature malleability itself is not a security issue, and therefore if the `ethereum` crate is used on a single-implementation blockchain, it's a low/informational severity advisory. ### Patches The issue is fixed in `ethereum` v0.18.0 ### Workarounds You can also manually check transaction malleability outside of the crate. But it's recommended to simply upgrade the version. ### References See PR: https://github.com/rust-ethereum/ethereum/pull/67
### Summary This vulnerability affects JUnit's support for writing Open Test Reporting XML files which is an opt-in feature of `junit-platform-reporting`. If a repository is cloned using a GitHub token or other credentials in its URL, for example: ```bash git clone https://${GH_APP}:${GH_TOKEN}@github.com/example/example.git ``` The credentials are captured by `OpenTestReportGeneratingListener` which produces (trimmed for brevity): ```xml <infrastructure> <git:repository originUrl="https://username:token@github.com/example/example.git" /> </infrastructure> ``` ### Details https://github.com/junit-team/junit5/blob/6b7764dac92fd35cb348152d1b37f8726875a4e0/junit-platform-reporting/src/main/java/org/junit/platform/reporting/open/xml/OpenTestReportGeneratingListener.java#L183 I think this should be configurable in some way to exclude select git information or exclude it entirely. ### PoC 1. Clone a repo using a GitHub token as shown above. 2. Enable the listener `junit.platfor...
Versions of Filesystem prior to 0.6.3 & 2025.7.1 could allow access to unintended files in cases where the prefix matches an allowed directory. Users are advised to upgrade to 2025.7.1 to resolve the issue. Thank you to Elad Beber (Cymulate) for reporting these issues.
Versions of Filesystem prior to 0.6.3 & 2025.7.1 could allow access to unintended files via symlinks within allowed directories. Users are advised to upgrade to 2025.7.1 to resolve. Thank you to Elad Beber (Cymulate) for reporting these issues.
### Summary Certs generated by v4 contain their private key. ## Details ### Background Recently, I encountered an API in Go that’s easy to misuse: sha512.Sum384 and sha512.New384().Sum look very similar and behave very differently. https://go.dev/play/p/kDCqqoYk84k demonstrates this. I want to discuss extending static analysis to detect this case with the go community, but before I do that, I want to make a best-effort pass at open-source projects to fix the existing bugs. I figured that if there were any vulnerabilities out there, they would be easy to find once that discussion begins, so it’s better to address them early. This work is a hobby project and has no affiliation with my employer, so I may be slow to respond due to existing commitments. ### PoC https://go.dev/play/p/vSW0U3Hq4qk ### Impact [This code](https://github.com/juju/utils/blob/0141ef0ee74a0cac603c5c9e4aff194008722f41/cert/cert.go#L120) (cert.NewLeaf) generates certs with the SubjectKeyId set to `sha512.Ne...
There is a heap buffer overflow when writing a sufficiently large (>64k encoded with default settings) image in the DDS format due to writing into a buffer without checking for available space. This only affects users who save untrusted data as a compressed DDS image. * Unclear how large the potential write could be. It is likely limited by process segfault, so it's not necessarily deterministic. It may be practically unbounded. * Unclear if there's a restriction on the bytes that could be emitted. It's likely that the only restriction is that the bytes would be emitted in chunks of 8 or 16. This was introduced in Pillow 11.2.0 when the feature was added.
### Impact Graylog users can gain elevated privileges by creating and using API tokens for the local Administrator or any other user for whom the malicious user knows the ID. For the attack to succeed, the attacker needs a user account in Graylog. They can then proceed to issue hand-crafted requests to the Graylog REST API and exploit a weak permission check for token creation. ### Workarounds In Graylog version `6.2.0` and above, regular users can be restricted from creating API tokens. The respective configuration can be found in `System > Configuration > Users > "Allow users to create personal access tokens"`. This option should be *Disabled*, so that only administrators are allowed to create tokens. ### Recommended Actions After upgrading Graylog from a vulnerable version to a patched version, administrators are advised to perform the following steps to ensure the integrity of their system: #### Review API tokens An overview of all existing API tokens is available at `Syste...
### Summary A command injection vulnerability exists in the `git-mcp-server` MCP Server. The vulnerability is caused by the unsanitized use of input parameters within a call to `child_process.exec`, enabling an attacker to inject arbitrary system commands. Successful exploitation can lead to remote code execution under the server process's privileges. The server constructs and executes shell commands using unvalidated user input directly within command-line strings. This introduces the possibility of shell metacharacter injection (`|`, `>`, `&&`, etc.). ### Details The MCP Server exposes tools (`git_add`, `git_init`, `git_logs`, etcc) to perform several git operations. An MCP Client can be instructed to execute additional actions for example via indirect prompt injection when asked to read git logs. Below some example of vulnerable code and different ways to test this vulnerability including a real example of indirect prompt injection that can lead to arbitrary command injection...
### Impact The `nativeImage.createFromPath()` and `nativeImage.createFromBuffer()` functions call a function downstream that is vulnerable to a heap buffer overflow. An Electron program that uses either of the affected functions is vulnerable to a buffer overflow if an attacker is in control of the image's height, width, and contents. ### Workaround There are no app-side workarounds for this issue. You must update your Electron version to be protected. ### Patches - `v28.3.2` - `v29.3.3` - `v30.0.3` ### For More Information If you have any questions or comments about this advisory, email us at [security@electronjs.org](mailto:security@electronjs.org).
Mattermost versions 10.5.x <= 10.5.5, 9.11.x <= 9.11.15, 10.8.x <= 10.8.0, 10.7.x <= 10.7.2, 10.6.x <= 10.6.5 fail to properly enforce channel member management permissions when adding participants to playbook runs. This allows authenticated users with member-level permissions to bypass system admin restrictions and add or remove users to/from private channels via the playbook run participants feature, even when the 'Manage Members' permission has been explicitly removed. This can lead to unauthorized access to sensitive channel content and allow guest users to gain channel management privileges.