ghsa

### Impact Python's "format" functionality allows someone controlling the format string to "read" all objects accessible through recursive attribute lookup and subscription from objects he can access. This can lead to critical information disclosure. With `RestrictedPython`, the format functionality is available via the `format` and `format_map` methods of `str` (and `unicode`) (accessed either via the class or its instances) and via `string.Formatter`. All known versions of `RestrictedPython` are vulnerable. ### Patches The issue will be fixed in 5.4 and 6.2. ### Workarounds There are no workarounds to fix the issue without upgrading. ### References * https://docs.python.org/3/library/stdtypes.html#str.format_map * http://lucumr.pocoo.org/2016/12/29/careful-with-str-format/ * https://www.exploit-db.com/exploits/51580 ### For more information If you have any questions or comments about this advisory: * Open an issue in the [RestrictedPython issue tracker](https://github.com/zope...

The `pytorch/pytorch` `filter-test-configs` workflow is vulnerable to an expression injection in Actions, allowing an attacker to potentially leak secrets and alter the repository using the workflow. ### Details The [`filter-test-configs`](https://github.com/pytorch/pytorch/blob/ec26947c586dd323d741da80008403664c533f65/.github/actions/filter-test-configs/action.yml) workflow is using the raw `github.event.workflow_run.head_branch` value inside the `filter` step: ```yaml - name: Select all requested test configurations shell: bash env: GITHUB_TOKEN: ${{ inputs.github-token }} JOB_NAME: ${{ steps.get-job-name.outputs.job-name }} id: filter run: | ... python3 "${GITHUB_ACTION_PATH}/../../scripts/filter_test_configs.py" \ ... --branch "${{ github.event.workflow_run.head_branch }}" ``` In the event of a repository using `filter-test-configs` in a `pull_request_target`-triggered workflow, an attacker could use a malicious branch name to gain command ex...

### Summary In order to resolve some git references, GitPython reads files from the `.git` directory, in some places the name of the file being read is provided by the user, GitPython doesn't check if this file is located outside the `.git` directory. This allows an attacker to make GitPython read any file from the system. ### Details This vulnerability is present in https://github.com/gitpython-developers/GitPython/blob/1c8310d7cae144f74a671cbe17e51f63a830adbf/git/refs/symbolic.py#L174-L175 That code joins the base directory with a user given string without checking if the final path is located outside the base directory. I was able to exploit it from three places, but there may be more code paths that lead to it: https://github.com/gitpython-developers/GitPython/blob/1c8310d7cae144f74a671cbe17e51f63a830adbf/git/repo/base.py#L605 https://github.com/gitpython-developers/GitPython/blob/1c8310d7cae144f74a671cbe17e51f63a830adbf/git/repo/base.py#L620 https://github.com/gitpython-d...

### Impact A flaw in the cryptographic authentication scheme in borgbackup allowed an attacker to fake archives and potentially indirectly cause backup data loss in the repository. The attack requires an attacker to be able to 1. insert files (with no additional headers) into backups 2. gain write access to the repository This vulnerability does not disclose plaintext to the attacker, nor does it affect the authenticity of existing archives. Creating plausible fake archives may be feasible for empty or small archives, but is unlikely for large archives. Affected are all borgbackup releases prior to 1.2.5. Note: CVSS scoring model seemed to badly fit for this case, thus I manually set score to "moderate". ### Patches The issue has been fixed in borgbackup 1.2.5. Additionally to installing the fixed code, users must follow the upgrade procedure as documented in the change log. ### Workarounds Data loss after being attacked can be avoided by reviewing the archives (timestamp and ...

Older versions of the package are vulnerable to Command Injection as an attacker controlled parameter. As a result, attackers may run malicious commands. For example: ``` const find = require("find-exec"); find("mplayer; touch hacked") ``` This creates a file named "hacked" on the filesystem. You should never allow users to control commands to find, since this package attempts to run every command provided. Thanks to @miguelafmonteiro for reporting.

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