Jaynornj

**Name of the Vulnerable Software and Affected Versions** OAuthenticator versions prior to 17.4.0 **Description** OAuthenticator is software that allows OAuth2 identity providers to be plugged in and used with JupyterHub. An authentication bypass issue exists that allows an attacker with an unverified email address on an Auth0 tenant to log in to JupyterHub. When `email` is used as the `username claim`, this gives users control over their username and the possibility of account takeover. This impacts any Auth0 tenant leveraging the `Auth0OAuthenticator` mapping the `email` claim to the JupyterHub username. **Recommendations** Upgrade OAuthenticator to version 17.4.0. As a workaround, check the `email verified` field in an `Authenticator.post auth hook` function. As a workaround, do not use `email` as the username claim. As a workaround, enforce email verification in Auth0.

Name of the Vulnerable Software and Affected Versions FastMCP versions (affected versions not specified) Description The `OpenAPIProvider` in FastMCP is susceptible to an authenticated Server-Side Request Forgery (SSRF) vulnerability due to insufficient URL encoding of path parameters. Specifically, the ` build url()` method directly substitutes parameter values into URL templates without proper encoding, and `urllib.parse.urljoin()` interprets `../` sequences as directory traversal. This allows an attacker controlling a path parameter to bypass the intended API prefix and access arbitrary backend endpoints, inheriting the authorization headers of the MCP provider. The vulnerability resides in the `fastmcp/utilities/openapi/director.py` file. The vulnerable function is ` build url()`. The API endpoint is constructed using a path template like `/api/v1/users/{user id}`. The vulnerable parameter is `user id`. A proof of concept demonstrates accessing an administrative endpoint (`/admin/delete-all`) by crafting a malicious payload containing `../../../admin/delete-all?` as the value for the `user id` parameter. This allows unauthorized access to internal APIs, potential privilege escalation, and data exfiltration. Recommendations URL-encode all path parameter values before substitution to prevent reserved characters from being interpreted as path delimiters. The updated ` build url()` method should use `urllib.parse.quote(str(param value), safe="")` to safely encode parameter values.

**Name of the Vulnerable Software and Affected Versions** pyLoad versions prior to 0.5.0b3.dev97 **Description** A Host Header Spoofing issue in the `@local check` decorator allows unauthenticated external attackers to bypass local-only restrictions. This grants access to the Click'N'Load API endpoints, enabling attackers to remotely queue arbitrary downloads, potentially leading to Server-Side Request Forgery (SSRF) and Denial of Service (DoS). The `@local check` implementation relies on the user-controlled `HTTP HOST` header to verify the origin. Attackers can spoof the `Host` header to `127.0.0.1:9666`, bypassing the IP address check and gaining access to protected functions. The affected API endpoints include: ''/flash/'' and ''/flash/<id>'', ''/flash/add'', ''/flash/addcrypted'', ''/flash/addcrypted2'', ''/flashgot'' and ''/flashgot pyload'', and ''/flash/checkSupportForUrl''. An attacker can use a `curl` command to send a POST request to one of the affected endpoints, spoofing the `Host` header. This allows them to add arbitrary URLs to the download queue, potentially leading to SSRF or DoS. **Recommendations** Update to pyLoad version 0.5.0b3.dev97 or later.

**Name of the Vulnerable Software and Affected Versions** joserfc versions 1.6.2 and earlier **Description** joserfc is a Python library implementing JSON Object Signing and Encryption (JOSE) standards. A resource exhaustion issue in joserfc can lead to a Denial of Service (DoS) through CPU exhaustion. When decrypting a JSON Web Encryption (JWE) token using Password-Based Encryption (PBES2) algorithms, the library reads the p2c (PBES2 Count) parameter from the token’s protected header without validation. An attacker can specify a large iteration count, forcing the server to expend significant CPU resources during token processing. This occurs at the JWA layer and affects all high-level JWE and JWT decryption interfaces if PBES2 algorithms are permitted by the application’s policy. **Recommendations** Versions prior to 1.6.3 should be updated.

**Authlib and Affected Versions** Authlib versions prior to 1.6.9 **Description** Authlib, a Python library for building OAuth and OpenID Connect servers, contains a flaw in its OpenID Connect (OIDC) ID Token validation logic. The internal hash verification function (` verify hash`) exhibits a fail-open behavior when it encounters an unsupported or unknown cryptographic algorithm. This allows an attacker to bypass integrity protections by supplying a forged ID Token with an unrecognized algorithm parameter. The library silently returns a successful validation result, violating cryptographic principles and OIDC specifications. This issue can lead to Token Substitution Attacks, potentially allowing attackers to use malicious Access Tokens or Authorization Codes. The vulnerability resides in the ` verify hash` function within `authlib/oidc/core/claims.py`. The function `create half hash` returns `None` for unknown algorithms, and ` verify hash` incorrectly interprets this as a successful verification. **Recommendations** Update to Authlib version 1.6.9 or later to resolve this issue.

**Name of the Vulnerable Software and Affected Versions** Authlib versions prior to 1.6.9 **Description** Authlib is a Python library used for building OAuth and OpenID Connect servers. A JWK Header Injection flaw exists in the library's JWS implementation, allowing an unauthenticated attacker to forge arbitrary JWT tokens that bypass signature verification. This occurs when `key=None` is passed to any JWS deserialization function, causing the library to extract and utilize a cryptographic key embedded within the attacker-controlled JWT's `jwk` header field. An attacker can sign a token with their own private key, embed the corresponding public key in the header, and have the server accept the forged token as valid, effectively circumventing authentication and authorization. This behavior violates RFC 7515 sections 4.1.3 and 5.2, which specify that the `jwk` header parameter is not recommended and the verification key must originate from the application context, not the token itself. The issue arises from a fallback mechanism within the library that silently trusts the attacker's embedded key when a key resolver callable returns `None` for unknown or rotated `kid` values, a common pattern in JWKS-based key lookup scenarios. This allows an attacker to impersonate any user or assume any privilege encoded in JWT claims without legitimate credentials. **Recommendations** Update Authlib to version 1.6.9 or later.

**Name of the Vulnerable Software and Affected Versions** Authlib versions prior to 1.6.9 **Description** Authlib, a Python library for building OAuth and OpenID Connect servers, contains a cryptographic padding oracle vulnerability in the implementation of the JSON Web Encryption (JWE) RSA1 5 key management algorithm. The library registers RSA1 5 in its default algorithm registry without requiring explicit opt-in and disables the constant-time Bleichenbacher mitigation implemented by the underlying cryptography library. This allows an attacker to exploit a weakness in the padding process to potentially decrypt encrypted keys. The vulnerability arises because Authlib raises a specific exception ('ValueError: Invalid "cek" length') when the padding is invalid, creating a distinguishable path from a valid padding scenario. This exception oracle, combined with the default configurations of common Python web frameworks (Flask, Django, and FastAPI), enables exploitation without additional server misconfiguration. The issue is present in versions prior to 1.6.9. **Recommendations** Update Authlib to version 1.6.9 or later.