Pr00Fof3Xpl0It

**Name of the Vulnerable Software and Affected Versions** OAuthenticator versões anteriores a 17.4.0 **Description** OAuthenticator é um software que permite que provedores de identidade OAuth2 sejam conectados e usados com o JupyterHub. Existe uma falha de bypass de autenticação que permite que um invasor com um endereço de e-mail não verificado em um tenant Auth0 faça login no JupyterHub. Quando `email` é usado como `username claim`, isso dá aos usuários controle sobre seu nome de usuário e a possibilidade de assumir o controle da conta. Isso afeta qualquer tenant Auth0 que utilize o `Auth0OAuthenticator` mapeando a claim `email` para o nome de usuário do JupyterHub. **Recommendations** Atualize o OAuthenticator para a versão 17.4.0. Como alternativa, verifique o campo `email verified` em uma função `Authenticator.post auth hook`. Como alternativa, não use `email` como a claim de nome de usuário. Como alternativa, force a verificação de e-mail no Auth0.

Nome do Software Vulnerável e Versões Afetadas FastMCP versões (versões afetadas não especificadas) Descrição O `OpenAPIProvider` no FastMCP é suscetível a uma vulnerabilidade de Server-Side Request Forgery (SSRF) autenticada devido à codificação de URL insuficiente de parâmetros de caminho. Especificamente, o método ` build url()` substitui diretamente os valores dos parâmetros nos modelos de URL sem codificação adequada, e `urllib.parse.urljoin()` interpreta sequências `../` como travessia de diretório. Isso permite que um invasor que controla um parâmetro de caminho ignore o prefixo de API pretendido e acesse endpoints de backend arbitrários, herdando os cabeçalhos de autorização do provedor MCP. A vulnerabilidade reside no arquivo `fastmcp/utilities/openapi/director.py`. A função vulnerável é ` build url()`. O endpoint da API é construído usando um modelo de caminho como `/api/v1/users/{user id}`. O parâmetro vulnerável é `user id`. Uma prova de conceito demonstra o acesso a um endpoint administrativo (`/admin/delete-all`) criando um payload malicioso contendo `../../../admin/delete-all?` como o valor para o parâmetro `user id`. Isso permite acesso não autorizado a APIs internas, possível escalonamento de privilégios e exfiltração de dados. Recomendações Codifique em URL todos os valores de parâmetros de caminho antes da substituição para evitar que caracteres reservados sejam interpretados como delimitadores de caminho. O método ` build url()` atualizado deve usar `urllib.parse.quote(str(param value), safe="")` para codificar com segurança os valores dos parâmetros.

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