ghsa

### 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.

An Insecure Direct Object Reference (IDOR) in Pagekit CMS v1.0.18 allows attackers to escalate privileges. The project was archived as of December 1, 2023.

### Duplicate Advisory This advisory has been withdrawn because it is a duplicate of GHSA-cjwg-qfpm-7377. This link is maintained to preserve external references. ### Original Description In python-jose 3.3.0 (specifically jwe.decrypt), a vulnerability allows an attacker to cause a Denial-of-Service (DoS) condition by crafting a malicious JSON Web Encryption (JWE) token with an exceptionally high compression ratio. When this token is processed by the server, it results in significant memory allocation and processing time during decompression.

In jose4j before 0.9.5, an attacker can cause a Denial-of-Service (DoS) condition by crafting a malicious JSON Web Encryption (JWE) token with an exceptionally high compression ratio. When this token is processed by the server, it results in significant memory allocation and processing time during decompression.

An authenticated arbitrary file upload vulnerability in the /storage/poc.php component of Pagekit CMS v1.0.18 allows attackers to execute arbitrary code via uploading a crafted PHP file. The project is archived as of December 1, 2023.

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.

Mattermost versions 10.11.x <= 10.11.4 fail to validate redirect URLs on the /error page, which allows an attacker to redirect a victim to a malicious site via a crafted link opened in a new tab.

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...