ghsa

### Impact If the "full-elastic-stack" example vector configuration was used for a real cluster, the previous values of kubernetes secrets would have been disclosed in the audit messages. ### Patches The example has been updated to fix this in commit db1aa5b867256b0a7bf206544c6981ab068b73dc ### Workarounds Replace ```yaml if .request.requestKind.kind == "Secret" { del(.request.object.data) .request.object.data.redacted = "REDACTED" del(.request.oldObject.data) .request.oldObject.data.redacted = "REDACTED" } ``` In the vector "audit-files-json-parser-and-redaction" step with ```yaml if .request.requestKind.kind == "Secret" { # Redact the secret data del(.request.object.data) .request.object.data.redacted = "REDACTED" del(.request.oldObject.data) .request.oldObject.data.redacted = "REDACTED" # Remove the previously set secret data - N...

The default values for Session.config.KeepAliveInterval and Session.config.ConnectionWriteTimeout of 30s and 10s create the possibility for timed out writes that most aren't handling in their readers. Calls to Stream.Read on one side of a connection will hang until the underlying Session is closed if the corresponding Stream.Write call on the other side it's waiting for returns with ErrConnectionWriteTimeout. This happens in the case of network congestion between the two sides. If you keep Session.sendCh full (fixed capacity of 64) for ConnectionWriteTimeout, but for less than the KeepAliveInterval + ConnectionWriteTimeout (which would kill the Session), Stream.Write will return ErrConnectionWriteTimeout. The state of the underlying Session or Stream is not modified. When this happens, the other side's Stream.Read call that's waiting for that write will never return because there's no timeout for this edge-case. Since no keep alive timed out, you can continue to use the Session once...

### Issue Snowflake discovered and remediated a vulnerability in the Snowflake NodeJS Driver. File permissions checks of the temporary credential cache could be bypassed by an attacker with write access to the local cache directory. This vulnerability affects versions 1.12.0 through 2.0.1 on Linux. Snowflake fixed the issue in version 2.0.2. ### Vulnerability Details On Linux, when either EXTERNALBROWSER or USERNAME_PASSWORD_MFA authentication methods are used with temporary credential caching enabled, the Snowflake NodeJS Driver will cache temporary credentials in a local file. Due to a bug, the check verifying that the cache file can be accessed only by the user running the Driver always succeeded, but didn’t verify the permissions or the ownership correctly. An attacker with write access to the local cache folder could plant an empty file there and the Driver would use it to store temporary credentials instead of rejecting it due to overly broad permissions. ### Solution Snowflak...

### Issue Snowflake discovered and remediated a vulnerability in the Snowflake JDBC Driver. On Linux systems, when temporary credential caching is enabled, the Snowflake JDBC Driver will cache temporary credentials locally in a world-readable file. This vulnerability affects versions 3.6.8 through 3.21.0. Snowflake fixed the issue in version 3.22.0. ### Vulnerability Details On Linux, when either EXTERNALBROWSER or USERNAME_PASSWORD_MFA authentication methods are used with temporary credential caching enabled, the Snowflake JDBC Driver will cache temporary credentials in a local file. In the vulnerable versions of the Driver, this file is created with world-readable permissions. ### Solution Snowflake released version 3.22.0 of the Snowflake JDBC Driver, which fixes this issue. We recommend users upgrade to version 3.22.0. ### Additional Information If you discover a security vulnerability in one of our products or websites, please report the issue to HackerOne. For more informatio...

### Issue Snowflake discovered and remediated a vulnerability in the Snowflake JDBC Driver. When the EXTERNALBROWSER authentication method is used on Windows, an attacker with write access to a directory in the %PATH% can escalate their privileges to the user that runs the vulnerable JDBC Driver version. This vulnerability affects versions 3.2.3 through 3.21.0 on Windows. Snowflake fixed the issue in version 3.22.0. ### Vulnerability Details When the EXTERNALBROWSER authentication method is selected, the Snowflake JDBC Driver on non-macOS operating systems tries to open the SSO URL using xdg-open. Because xdg-open is a Linux program that doesn’t exist in a default Windows installation, a sufficiently privileged attacker could place a malicious executable in one of the directories on the %PATH% and achieve local privilege escalation to the user running the JDBC Driver. ### Solution Snowflake released version 3.22.0 of the Snowflake JDBC Driver, which fixes this issue. We recommend us...

When using the `??` operator, output escaping was missing for the expression on the left side of the operator.

RuoYi v4.8.0 was discovered to allow unauthorized attackers to view the session ID of the admin in the system monitoring. This issue can allow attackers to impersonate Admin users via using a crafted cookie.

Insecure permissions in RuoYi v4.8.0 allows authenticated attackers to escalate privileges by assigning themselves higher level roles.

An issue in the reset password interface of ruoyi v4.8.0 allows attackers with Admin privileges to cause a Denial of Service (DoS) by duplicating the login name of the account.

Hive creates a credentials file to a temporary directory in the file system with permissions 644 by default when the file permissions are not set explicitly. Any unauthorized user having access to the directory can read the sensitive information written into this file. Users are recommended to upgrade to version 4.0.1, which fixes this issue.