ghsa

## Summary Using a recovery flow with an identification stage an attacker is able to determine if a username exists. ## Impact Only setups configured with a recovery flow are impacted by this. Anyone with a user account on a system with the recovery flow described above is susceptible to having their username/email revealed as existing. ## Details An attacker can easily enumerate and check users' existence using the recovery flow, as a clear message is shown when a user doesn't exist. Depending on configuration this can either be done by username, email, or both. The invalid and valid usernames should both show the same message and always send an email. Article for reference here: https://postmarkapp.com/guides/password-reset-email-best-practices#how-to-make-sure-your-password-reset-emails-are-secure ### For more information If you have any questions or comments about this advisory: - Email us at [[email protected]](mailto:[email protected])

### Impact Open Redirect Vulnerability. Maliciously crafted login links to known Jupyter Servers can cause successful login or an already logged-in session to be redirected to arbitrary sites, which should be restricted to Jupyter Server-served URLs. ### Patches Upgrade to Jupyter Server 2.7.2 ### Workarounds None. ### References Vulnerability reported by user davwwwx via the [bug bounty program](https://app.intigriti.com/programs/jupyter/jupyter/detail) [sponsored by the European Commission](https://commission.europa.eu/news/european-commissions-open-source-programme-office-starts-bug-bounties-2022-01-19_en) and hosted on the [Intigriti platform](https://www.intigriti.com/). - https://blog.xss.am/2023/08/CVE-2023-39968-jupyter-token-leak/

### Impact Improper cross-site credential checks on `/files/` URLs could allow exposure of certain file contents, or accessing files when opening untrusted files via "Open image in new tab". ### Patches Jupyter Server 2.7.2 ### Workarounds Use lower performance `--ContentsManager.files_handler_class=jupyter_server.files.handlers.FilesHandler`, which implements the correct checks. ### References Upstream patch for CVE-2019-9644 was not applied completely, leaving part of the vulnerability open. Vulnerability reported by Tim Coen via the [bug bounty program](https://app.intigriti.com/programs/jupyter/jupyter/detail) [sponsored by the European Commission](https://commission.europa.eu/news/european-commissions-open-source-programme-office-starts-bug-bounties-2022-01-19_en) and hosted on the [Intigriti platform](https://www.intigriti.com/).

### Summary When resolving a program, Python/Windows look for the current working directory, and after that the PATH environment (see big warning in https://docs.python.org/3/library/subprocess.html#popen-constructor). GitPython defaults to use the `git` command, if a user runs GitPython from a repo has a `git.exe` or `git` executable, that program will be run instead of the one in the user's `PATH`. ### Details This is more of a problem on how Python interacts with Windows systems, Linux and any other OS aren't affected by this. But probably people using GitPython usually run it from the CWD of a repo. The execution of the `git` command happens in https://github.com/gitpython-developers/GitPython/blob/1c8310d7cae144f74a671cbe17e51f63a830adbf/git/cmd.py#L277 https://github.com/gitpython-developers/GitPython/blob/1c8310d7cae144f74a671cbe17e51f63a830adbf/git/cmd.py#L983-L996 And there are other commands executed that should probably be aware of this problem. ### PoC On a Window...

### Impact @adobe/css-tools version 4.3.0 and earlier are affected by an Improper Input Validation vulnerability that could result in a denial of service while attempting to parse CSS. ### Patches The issue has been resolved in 4.3.1. ### Workarounds None ### References N/A

A heap-based buffer overflow exists in the qr_reader_match_centers function of ZBar 0.23.90. Specially crafted QR codes may lead to information disclosure and/or arbitrary code execution. To trigger this vulnerability, an attacker can digitally input the malicious QR code, or prepare it to be physically scanned by the vulnerable scanner.

Some MongoDB Drivers may erroneously publish events containing authentication-related data to a command listener configured by an application. The published events may contain security-sensitive data when specific authentication-related commands are executed. Without due care, an application may inadvertently expose this sensitive information, e.g., by writing it to a log file. This issue only arises if an application enables the command listener feature (this is not enabled by default). This issue affects the MongoDB C Driver 1.0.0 prior to 1.17.7, MongoDB PHP Driver 1.0.0 prior to 1.9.2, MongoDB Swift Driver 1.0.0 prior to 1.1.1, MongoDB Node.js Driver 3.6 prior to 3.6.10, MongoDB Node.js Driver 4.0 prior to 4.17.0 and MongoDB Node.js Driver 5.0 prior to 5.8.0. This issue also affects users of the MongoDB C++ Driver dependent on the C driver 1.0.0 prior to 1.17.7 (C++ driver prior to 3.7.0).

### Impact OpenPGP Cleartext Signed Messages are cryptographically signed messages where the signed text is readable without special tools: ``` -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 This text is signed. -----BEGIN PGP SIGNATURE----- wnUEARMIACcFgmTkrNAJkInXCgj0fgcIFiEE1JlKzzDGQxZmmHkYidcKCPR+ BwgAAKXDAQDWGhI7tPbhB+jlKwe4+yPJ+9X8aWDUG60XFNi/w8T7ZgEAsAGd WJrkm/H5AXGZsqyqqO6IWGF0geTCd4mWm/CsveM= -----END PGP SIGNATURE----- ``` These messages typically contain a "Hash: ..." header declaring the hash algorithm used to compute the signature digest. OpenPGP.js up to v5.9.0 ignored any data preceding the "Hash: ..." texts when verifying the signature. As a result, malicious parties could add arbitrary text to a third-party Cleartext Signed Message, to lead the victim to believe that the arbitrary text was signed. A user or application is vulnerable to said attack vector if it verifies the CleartextMessage by only checking the returned `verified` property, discarding the associate...

### Impact ONLY IMPACTS those use GitHub Status Notifications Log output when updating GitHub status is improperly set to FULL always. It's recommended to apply the patch and rotate the GitHub token used for github status notifications. Given that this would output github tokens to a log system, the risk is slightly higher than a "low" since token exposure could grant elevated access to repositories outside of control. If using READ restricted tokens, the exposure is such that the token itself could be used to access resources otherwise restricted from reads. ### Patches Patch is in progress. https://github.com/spinnaker/echo/pull/1316 ### Workarounds Disable GH Status Notifications. Filter your logs for Echo log data. Use read-only tokens that are limited in scope. ### References sig-security in slack: https://spinnakerteam.slack.com/archives/CFN8F5UR2

In SpringBlade V3.6.0 when executing SQL query, the parameters submitted by the user are not wrapped in quotation marks, which leads to SQL injection.