ghsa

### Summary Diffie-Hellman key validation is insufficient, which can lead to insecure shared secrets and therefore breaks confidentiality. ### Details Russh does not validate Diffie-Hellman keys. It accepts received DH public keys $e$ where $e<0$, $e=1$, or $e \geq p-1$ from a misbehaving peer annd successfully performs key exchange. This is a violation of [RFC 4253, section 8](https://www.rfc-editor.org/rfc/rfc4253#section-8) and [RFC 8268, section 4](https://www.rfc-editor.org/rfc/rfc8268#section-4), which state that: >DH Public Key values MUST be checked and both conditions: > > - $1 < e < p-1$ > - $1 < f < p-1$ > > MUST be true. Values not within these bounds MUST NOT be sent or > accepted by either side. If either one of these conditions is > violated, then the key exchange fails. For example, a DH client public key $e=1$ would mean that the shared secret that the server calculates is always $K = e^y \mod{p} = 1^y \mod{p} = 1$. In other cases, an insecure order-2 subgroup...

Improper Authorization in GitHub repository nilsteampassnet/teampass prior to 3.0.0.23.

The twitter-bootstrap-rails Gem for Rails contains a flaw that enables a reflected cross-site scripting (XSS) attack. This flaw exists because the bootstrap_flash helper method does not validate input when handling flash messages before returning it to users. This may allow a context-dependent attacker to create a specially crafted request that would execute arbitrary script code in a user's browser session within the trust relationship between their browser and the server.

### Impact This vulnerability has the potential to steal a user's cookie and gain unauthorized access to that user's account through the stolen cookie or redirect users to other malicious sites. ### Patches Update to version 10.5.19 or apply this patch manually https://github.com/pimcore/pimcore/pull/14606.patch ### Workarounds Apply https://github.com/pimcore/pimcore/pull/14606.patch manually. ### References https://huntr.dev/bounties/2a64a32d-b1cc-4def-91da-18040d59f356/

### Impact Unsecured Name field in Document Types module in Settings. This vulnerability has the potential to steal a user's cookie and gain unauthorized access to that user's account through the stolen cookie or redirect users to other malicious sites. ### Patches Update to version 10.5.19 or apply this patch manually https://github.com/pimcore/pimcore/pull/14645.patch ### Workarounds Apply https://github.com/pimcore/pimcore/pull/14645.patch manually. ### References https://huntr.dev/bounties/e0829fea-e458-47b8-84a3-a74476d9638f/

### Impact Stored xss leads to steal cookies and other information of other users ### Patches Update to version 10.5.19 or apply this patch manually https://github.com/pimcore/pimcore/pull/14560.patch ### Workarounds Apply https://github.com/pimcore/pimcore/pull/14560.patch manually. ### References https://huntr.dev/bounties/31d97442-3f87-439f-83f0-1c7862ef0c7c/

Impact ZipSlip issue when use fsutil package to unzip files. When users use zip.Unzip to unzip zip files from a malicious attacker, they may be vulnerable to path traversal. Patches It has been fixed in v0.0.34, Please upgrade version to v0.0.34 or above. Workarounds No, users have to upgrade version. References

An attacker could use a specially crafted graphql query to execute a Distributed Denial of Service attack (DDOS attack) against a website. This mostly affects websites with publicly exposed and particularly large/complex graphql schemas. If your Silverstripe CMS project does not expose a public facing graphql schema, a user account is required to trigger the DDOS attack. If your site is hosted behind a content delivery network (CDN), such as Imperva or CloudFlare, this will likely further mitigate the risk. Upgrade to `silverstripe/graphql` 4.2.3 or 4.1.2 or above to remedy the vulnerability.

### Impact Utilizing a HTTP query parameter an attacker is able to redirect users from the web application to any domain. The URL of the intended redirect should always be checked for safety prior to forwarding the user. Other endpoints of the web application already do this, they check both that the domain is using the HTTPS protocol and that it exists on a domain associated with the application. An attacker is able to use this unintended functionality to redirect users to malicious sites. This particular security issue allows the attacker to make a phishing attempt seem much more trustworthy to a user of the web application as the initial site before redirection is familiar to them, as well as the actual URL which they have theoretically visited frequently. While this security issue does not directly impact the security of the web application, it is still not an acceptable scenario for the reasons mentioned above. ### Patches f0cb75e1e102f95f91e9254c66c797e821857690 fix(handlers...

### Impact If a malicious user has taken over a Kubernetes node where virt-handler (the KubeVirt node-daemon) is running, the virt-handler service account can be used to modify all node specs. This can be misused to lure-in system-level-privileged components (which can for instance read all secrets on the cluster, or can exec into pods on other nodes). This way a compromised node can be used to elevate privileges beyond the node until potentially having full privileged access to the whole cluster. The simplest way to exploit this, once a user could compromise a specific node, is to set with the virt-handler service account all other nodes to unschedulable and simply wait until system-critical components with high privileges appear on its node. Since this requires a node to be compromised first, the severity of this finding is considered Medium. ### Patches Not yet available. ### Workarounds Gatekeeper users can add a webhook which will block the `virt-handler` service account to...