ghsa

Versions of froxlor/froxlor prior to release 2.1.0 did not regenerate session ids appropriately which may result in session fixation.

In versions of nilsteampassnet/teampass prior to 3.0.9 some user input was not properly sanitized which may have lead to stored cross-site scripting (XSS) vectors in the application.

In versions of nilsteampassnet/teampass prior to 3.0.9 some user input was not properly sanitized which may have lead to stored cross-site scripting (XSS) vectors in the application.

Versions of the package dottie before 2.0.4 are vulnerable to Prototype Pollution due to insufficient checks, via the `set()` function and the current variable in the `/dottie.js` file.

HashiCorp Consul 1.4.0 through 1.5.0 has Incorrect Access Control. Keys not matching a specific ACL rule used for prefix matching in a policy can be deleted by a token using that policy even with default deny settings configured.

### Issue Snowflake was informed via our bug bounty program of a command injection vulnerability in the Snowflake NodeJS driver via SSO browser URL authentication. ### Impacted driver package: snowflake-connector-nodejs ### Impacted version range: before [Version 1.6.21](https://community.snowflake.com/s/article/Node-js-Driver-Release-Notes) ### Attack Scenario In order to exploit the potential for command injection, an attacker would need to be successful in (1) establishing a malicious resource and (2) redirecting users to utilize the resource. The attacker could set up a malicious, publicly accessible server which responds to the SSO URL with an attack payload. If the attacker then tricked a user into visiting the maliciously crafted connection URL, the user’s local machine would render the malicious payload, leading to a remote code execution. This attack scenario can be mitigated through URL whitelisting as well as common anti-phishing resources. ### Solution On April 1...

### Issue Snowflake was informed via our bug bounty program of a command injection vulnerability in the Snowflake Golang driver via SSO browser URL authentication. ### Impacted driver package: gosnowflake ### Impacted version range: before [Version 1.6.19](https://community.snowflake.com/s/article/Go-Snowflake-Driver-Release-Notes) ### Attack Scenario In order to exploit the potential for command injection, an attacker would need to be successful in (1) establishing a malicious resource and (2) redirecting users to utilize the resource. The attacker could set up a malicious, publicly accessible server which responds to the SSO URL with an attack payload. If the attacker then tricked a user into visiting the maliciously crafted connection URL, the user’s local machine would render the malicious payload, leading to a remote code execution. This attack scenario can be mitigated through URL whitelisting as well as common anti-phishing resources. ### Solution On March 21, 2023, Sn...

### Issue Snowflake was informed via our bug bounty program of a command injection vulnerability in the Snowflake Python connector via SSO browser URL authentication. ### Impacted driver package: snowflake-connector-python ### Impacted version range: before [Version 3.0.2](https://community.snowflake.com/s/article/Snowflake-Connector-for-Python-Release-Notes) ### Attack Scenario In order to exploit the potential for command injection, an attacker would need to be successful in (1) establishing a malicious resource and (2) redirecting users to utilize the resource. The attacker could set up a malicious, publicly accessible server which responds to the SSO URL with an attack payload. If the attacker then tricked a user into visiting the maliciously crafted connection URL, the user’s local machine would render the malicious payload, leading to a remote code execution. This attack scenario can be mitigated through URL whitelisting as well as common anti-phishing resources. ### ...

### Impact The Gatsby framework prior to versions 4.25.7 and 5.9.1 contain a Local File Inclusion vulnerability in the `__file-code-frame` and `__original-stack-frame` paths, exposed when running the Gatsby develop server (`gatsby develop`). The following steps can be used to reproduce the vulnerability: ``` # Create a new Gatsby project $ npm init gatsby $ cd my-gatsby-site # Start the Gatsby develop server $ gatsby develop # Execute the Local File Inclusion vulnerability in __file-code-frame $ curl "http://127.0.0.1:8000/__file-code-frame?filePath=/etc/passwd&lineNumber=1" # Execute the Local File Inclusion vulnerability in __original-stack-frame $ curl "http://127.0.0.1:8000/__original-stack-frame?moduleId=/etc/hosts&lineNumber=1&skipSourceMap=1" ``` It should be noted that by default `gatsby develop` is only accessible via the localhost `127.0.0.1`, and one would need to intentionally expose the server to other interfaces to exploit this vulnerability by using server options...

### Impact There are two separate security vulnerabilities here: (1) a security vulnerability that allows users to read arbitrary files on the machines that are running shared Gradio apps (2) the ability of users to use machines that are sharing Gradio apps to proxy arbitrary URLs ### Patches Both problems have been solved, please upgrade `gradio` to `3.34.0` or higher ### Workarounds Not possible to workaround except by taking down any shared Gradio apps ### References Relevant PRs: * https://github.com/gradio-app/gradio/pull/4406 * https://github.com/gradio-app/gradio/pull/4370