ghsa

Passbolt uses three cookies: a session cookie, a CSRF protection cookie and a cookie to keep track of the multiple-factor authentication process. Both the session cookie and the mfa cookie are properly set HTTP-only to prevent an attacker from retrieving the content of those cookies if they managed to exploit an XSS. The /auth/verify.json endpoint returns a JSON that, among other things, contains the cookies sent in the request. (similar to the TRACE HTTP method) An attacker who manages to leverage an XSS vulnerability could retrieve the session cookies of a legitimate user, effectively granting them the ability to retrieve information (such as encrypted password list or group list) without requiring user interaction. This vulnerability has a low impact, but no immediate risk due to it requiring the exploitation of an XSS vulnerability that has yet to be found.

Passbolt sends e-mail to users to warn them about different type of events such as the creation, modification or deletion of a password. Those e-mails may contain user-specified input, such as a password’s title or description. Passbolt does not escape the user’s input properly, resulting in the user being able to inject HTML code in an e-mail. An authenticated attacker could share a password containing an img HTML tag in its description with an other user to obtain information about their mail user-agent. This vulnerability has a very low impact. Most MUA do not embed remote images to protect their users’ privacy.

### Summary Servers based on aiosmtpd accept extra unencrypted commands after STARTTLS, treating them as if they came from inside the encrypted connection. This could be exploited by a MitM attack. ### References * [NO STARTTLS: Similar vulnerabilities discovered by previous researchers.](https://nostarttls.secvuln.info/)

### Impact Executing policy checks using custom schematron files invokes an XSL transformation that may theoretically lead to a remote code execution (RCE) vulnerability. ### Patches This has been patched and users should upgrade to veraPDF v1.24.2 ### Workarounds This doesn't affect the standard validation and policy checks functionality, veraPDF's common use cases. Most veraPDF users don't insert any custom XSLT code into policy profiles, which are based on Schematron syntax rather than direct XSL transforms. For users who do, only load custom policy files from sources you trust. ### References Original issue: <https://github.com/veraPDF/veraPDF-library/issues/1415>

OroPlatform is prone to open redirection which could allow attackers to redirect users to external website.

OroCRM is prone to open redirection which could allow attackers to redirect users to external website.

## Duplicate Advisory This advisory has been withdrawn because it is a duplicate of GHSA-4qqq-9vqf-3h3f. This link is maintained to preserve external references. ## Original Description In scrapy/scrapy, an issue was identified where the Authorization header is not removed during redirects that only change the scheme (e.g., HTTPS to HTTP) but remain within the same domain. This behavior contravenes the Fetch standard, which mandates the removal of Authorization headers in cross-origin requests when the scheme, host, or port changes. Consequently, when a redirect downgrades from HTTPS to HTTP, the Authorization header may be inadvertently exposed in plaintext, leading to potential sensitive information disclosure to unauthorized actors. The flaw is located in the _build_redirect_request function of the redirect middleware.

A remote code execution (RCE) vulnerability exists in the berriai/litellm project due to improper control of the generation of code when using the `eval` function unsafely in the `litellm.get_secret()` method. Specifically, when the server utilizes Google KMS, untrusted data is passed to the `eval` function without any sanitization. Attackers can exploit this vulnerability by injecting malicious values into environment variables through the `/config/update` endpoint, which allows for the update of settings in `proxy_server_config.yaml`.

In Tor Arti before 1.2.3, circuits sometimes incorrectly have a length of 3 (with full vanguards), aka TROVE-2024-004.

In Tor Arti before 1.2.3, STUB circuits incorrectly have a length of 2 (with lite vanguards), aka TROVE-2024-003.