ghsa

In mcp-server-git versions prior to 2025.12.17, when the server is started with the --repository flag to restrict operations to a specific repository path, it did not validate that repo_path arguments in subsequent tool calls were actually within that configured path. This could allow tool calls to operate on other repositories accessible to the server process. The fix adds path validation that resolves both the configured repository and the requested path (following symlinks) and verifies the requested path is within the allowed repository before executing any git operations. Users are advised to upgrade to 2025.12.17 upon release to remediate this issue. Thank you to https://hackerone.com/yardenporat for reporting.

In mcp-server-git versions prior to 2025.12.17, the git_diff and git_checkout functions passed user-controlled arguments directly to git CLI commands without sanitization. Flag-like values (e.g., `--output=/path/to/file` for `git_diff`) would be interpreted as command-line options rather than git refs, enabling arbitrary file overwrites. The fix adds validation that rejects arguments starting with - and verifies the argument resolves to a valid git ref via rev_parse before execution. Users are advised to update to 2025.12.17 resolve this issue when it is released. Thank you to https://hackerone.com/yardenporat for reporting.

### Description In applications built with the Auth0-PHP SDK, the audience validation in access tokens is performed improperly. Without proper validation, affected applications may accept ID tokens as Access tokens. ### Affected product and versions Projects are affected if they meet the following preconditions: - Applications using the Auth0 Wordpress plugin with version between 5.0.0-BETA0 and 5.4.0, - Auth0 Wordpress plugin uses the Auth0-PHP SDK with versions between 8.0.0 and 8.17.0. ### Resolution Upgrade Auth0 Wordpress plugin to version 5.5.0 or greater. ### Acknowledgement Okta would like to thank Jafar Sadiq (iaf4r) for their discovery and responsible disclosure.

### Description In applications built with the Auth0-PHP SDK, the audience validation in access tokens is performed improperly. Without proper validation, affected applications may accept ID tokens as Access tokens. ### Affected product and versions Projects are affected if they meet the following preconditions: - Applications using the Auth0 Symfony SDK with versions between 5.0.0 and 5.5.0 - Auth0 Symfony SDK uses the Auth0-PHP SDK with versions between 8.0.0 and 8.17.0. ### Resolution Upgrade Auth0/symfony to version 5.6.0 or greater. ### Acknowledgement Okta would like to thank Jafar Sadiq (iaf4r) for their discovery and responsible disclosure.

### Description In applications built with the Auth0-PHP SDK, the audience validation in access tokens is performed improperly. Without proper validation, affected applications may accept ID tokens as Access tokens. ### Affected product and versions Users are affected if they meet the following preconditions: - Applications using the Auth0 laravel-auth0 SDK with versions between 7.0.0 and 7.19.0, - Auth0 laravel-auth0 SDK uses the Auth0-PHP SDK with versions between 8.0.0 and 8.17.0. ### Resolution Upgrade Auth0/laravel-auth0 to version 7.20.0 or greater. ### Acknowledgement Okta would like to thank Jafar Sadiq (iaf4r) for their discovery and responsible disclosure.

### Description In applications built with the Auth0-PHP SDK, the audience validation in access tokens is performed improperly. Without proper validation, affected applications may accept ID tokens as Access tokens. ### Affected product and versions Projects are affected if they meet the following preconditions: - Applications using the Auth0-PHP SDK, versions between v8.0.0 and v8.17.0, or - Applications using the following SDKs that rely on the Auth0-PHP SDK versions between v8.0.0 and v8.17.0: - a. Auth0/symfony, - b. Auth0/laravel-auth0, - c. Auth0/wordpress. ### Resolution Upgrade Auth0/Auth0-PHP to version 8.18.0 or greater. ### Acknowledgement Okta would like to thank Jafar Sadiq (iaf4r) for their discovery and responsible disclosure.

In mcp-server-git versions prior to 2025.9.25, the git_init tool accepted arbitrary filesystem paths and created Git repositories without validating the target location. Unlike other tools which required an existing repository, git_init could operate on any directory accessible to the server process, making those directories eligible for subsequent git operations. The tool was removed entirely, as the server is intended to operate on existing repositories only. Users are advised to upgrade to 2025.9.25 or newer to remediate this issue. Thank you to https://hackerone.com/yardenporat for disclosure, @0dd for contributing the fix.

Mattermost versions 10.11.x <= 10.11.6 and Mattermost GitHub plugin versions <=2.4.0 fail to validate plugin bot identity in reaction forwarding which allows attackers to hijack the GitHub reaction feature to make users add reactions to arbitrary GitHub objects via crafted notification posts.

Edge3 Worker RPC RCE on Airflow 2. This issue affects Apache Airflow Providers Edge3: before 2.0.0 - and only if projects installed and configured it on Airflow 2. The Edge3 provider support in Airflow 2 has been always development-only and not officially released, however if projects installed and configured Edge3 provider in Airflow 2, it implicitly enabled non-public (normally) API which was used to test Edge Provider in Airflow 2 during the development. This API allowed Dag author to perform Remote Code Execution in the webserver context, which Dag Author was not supposed to be able to do. If projects installed and configured Edge3 provider for Airflow 2, they should uninstall it and migrate to Airflow 3. The new Edge3 provider versions (>=2.0.0) has a minimum version of Airflow set to 3 and the RCE-prone Airflow 2 code is removed, so it should no longer be possible to use the Edge3 provider 2.0.0+ on Airflow 2. If projects used Edge Provider in Airflow 3, you they are not affe...

## Summary The `fsSize()` function in `systeminformation` is vulnerable to **OS Command Injection (CWE-78)** on Windows systems. The optional `drive` parameter is directly concatenated into a PowerShell command without sanitization, allowing arbitrary command execution when user-controlled input reaches this function. **Affected Platforms:** Windows only **CVSS Breakdown:** - **Attack Vector (AV:N):** Network - if used in a web application/API - **Attack Complexity (AC:H):** High - requires application to pass user input to `fsSize()` - **Privileges Required (PR:N):** None - no authentication required at library level - **User Interaction (UI:N):** None - **Scope (S:U):** Unchanged - executes within Node.js process context - **Confidentiality/Integrity/Availability (C:H/I:H/A:H):** High impact if exploited > **Note:** The actual exploitability depends on how applications use this function. If an application does not pass user-controlled input to `fsSize()`, it is not vulnerable. ...