ghsa

An issue in ZIPFoundation v0.9.16 allows attackers to execute a path traversal via extracting a crafted zip file.

Cross Site Scripting vulnerabiltiy in Badaso v.0.0.1 thru v.2.9.7 allows a remote attacker to execute arbitrary code via a crafted payload to the Name of member parameter in the add new member function.

## Impact ### What kind of vulnerability is it? Apollo Server can log sensitive information (Studio API keys) if they are passed incorrectly (with leading/trailing whitespace) or if they have any characters that are invalid as part of a header value. ### Who is impacted? Users who (all of the below): * use either the schema reporting or usage reporting feature * use an Apollo Studio API key which has invalid header values * use the default fetcher (`node-fetch`) or configured their own `node-fetch` fetcher The following node snippet can test whether your API key has invalid header values. This code is taken directly from `node-fetch@2`'s header value validation code. ```js const invalidHeaderCharRegex = /[^\t\x20-\x7e\x80-\xff]/; if (invalidHeaderCharRegex.test('<YOUR_API_KEY>')) { console.log('potentially affected'); } console.log('unaffected'); ``` If the provided API key is not a valid header value, whenever Apollo Server uses that API key in a request (to Studio, for example),...

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