ghsa

### Impact A vulnerability has been identified within Rancher where a cluster or node driver can be used to escape the `chroot` jail and gain root access to the Rancher container itself. In production environments, further privilege escalation is possible based on living off the land within the Rancher container itself. For the test and development environments, based on a –privileged Docker container, it is possible to escape the Docker container and gain execution access on the host system. This happens because: - During startup, Rancher appends the `/opt/drivers/management-state/bin` directory to the `PATH` environment variable. - In Rancher, the binaries `/usr/bin/rancher-machine`, `/usr/bin/helm_v3`, and `/usr/bin/kustomize` are assigned a UID of 1001 and a GID of 127 instead of being owned by the root user. - Rancher employs a jail mechanism to isolate the execution of node drivers from the main process. However, the drivers are executed with excessive permissions. - During the...

### Impact A vulnerability has been identified in the way that Rancher stores vSphere's CPI (Cloud Provider Interface) and CSI (Container Storage Interface) credentials used to deploy clusters through the vSphere cloud provider. This issue leads to the vSphere CPI and CSI passwords being stored in a plaintext object inside Rancher. This vulnerability is only applicable to users that deploy clusters in vSphere environments. The exposed passwords were accessible in the following objects: - Can be accessed by users that are cluster members of the provisioned clusters: - When provisioning a new cluster with the vSphere cloud provider through Rancher's UI (user interface), Cluster Templates and Terraform on the object `provisioning.cattle.io` in `spec.rkeConfig.chartValues.rancher-vsphere-cpi` and `spec.rkeConfig.chartValues.rancher-vsphere-csi`. - On the object `rke.cattle.io.rkecontrolplane` in `spec.chartValues.rancher-vsphere-cpi` and `spec.chartValues.rancher-vsphere-csi`. - Can...

### Impact A vulnerability has been identified whereby Rancher Manager deployments containing Windows nodes have weak Access Control Lists (ACL), allowing `BUILTIN\Users` or `NT AUTHORITY\Authenticated Users` to view or edit sensitive files which could lead to privilege escalation. The affected files include binaries, scripts, configuration and log files: ``` C:\etc\rancher\wins\config C:\var\lib\rancher\agent\rancher2_connection_info.json C:\etc\rancher\rke2\config.yaml.d\50-rancher.yaml C:\var\lib\rancher\agent\applied\*-*-applied.plan C:\usr\local\bin\rke2 C:\var\lib\rancher\capr\idempotence\idempotent.sh ``` RKE2 nodes expand the list to include the files below: ``` C:\etc\rancher\node\password C:\var\lib\rancher\rke2\agent\logs\kubelet.log C:\var\lib\rancher\rke2\data\v1.**.**-rke2r*-windows-amd64-*\bin\* C:\var\lib\rancher\rke2\bin\* ``` **This vulnerability is exclusive to deployments that contain Windows nodes. Linux-only environments are not affected by it.** Please con...

### Impact Zitadel allows administrators to disable the user self-registration. Due to a missing security check in versions prior to 2.63.4, disabling the "User Registration allowed" option only hid the registration button on the login page. Users could bypass this restriction by directly accessing the registration URL (/ui/login/loginname) and register a user that way. ### Patches 2.x versions are fixed on >= [2.64.0](https://github.com/zitadel/zitadel/releases/tag/v2.64.0) 2.63.x versions are fixed on >= [2.63.5](https://github.com/zitadel/zitadel/releases/tag/v2.63.5) 2.62.x versions are fixed on >= [2.62.7](https://github.com/zitadel/zitadel/releases/tag/v2.62.7) 2.61.x versions are fixed on >= [2.61.4](https://github.com/zitadel/zitadel/releases/tag/v2.61.4) 2.60.x versions are fixed on >= [2.60.4](https://github.com/zitadel/zitadel/releases/tag/v2.60.4) 2.59.x versions are fixed on >= [2.59.5](https://github.com/zitadel/zitadel/releases/tag/v2.59.5) 2.58.x versions are fixed on...

### Summary A flaw in the URL validation mechanism of Zitadel actions allows bypassing restrictions intended to block requests to localhost (127.0.0.1). The isHostBlocked check, designed to prevent such requests, can be circumvented by creating a DNS record that resolves to 127.0.0.1. This enables actions to send requests to localhost despite the intended security measures. ### Details While attempting to send a request directly to 127.0.0.1 via an action results in an error (see image below), the restriction can be bypassed using a custom DNS record. <img width="781" alt="image" src="https://github.com/user-attachments/assets/6d22dae8-407f-4420-a937-aca53d22d05d"> The relevant action code demonstrates the attempted request to 127.0.0.1: ``` let http = require('zitadel/http') let logger = require("zitadel/log") function make_api_call(ctx, api) { var user = http.fetch('http://127.0.0.1:8080/debug/metrics'); var api_r = http.fetch('https://obtjoiwgtaftuhbjugulyolvvxuvuuosq.oa...

### Impact For email-based accounts, users with insufficient privileges could reset and theoretically access privileged users' accounts by resetting their passwords. ### Patches This is fixed in v3.0.1. ### Workarounds No workarounds. ### For more information If you have any questions or comments about this advisory: Open an issue in https://github.com/autolab/Autolab/ Email us at [[email protected]](mailto:[email protected])

The Kademlia DHT (go-libp2p-kad-dht 0.20.0 and earlier) used in IPFS (0.18.1 and earlier) assigns routing information for content (i.e., information about who holds the content) to be stored by peers whose peer IDs have a small DHT distance from the content ID. This allows an attacker to censor content by generating many Sybil peers whose peer IDs have a small distance from the content ID, thus hijacking the content resolution process.

### Issue Snowflake recently learned about and remediated a set of vulnerabilities in the Snowflake Connector for Python. Under specific conditions, certain users credentials (or portions of those credentials) were logged locally by the Connector to the users own systems. The credentials were not logged by Snowflake. These vulnerabilities affect versions up to and including 3.12.2. Snowflake fixed the issue in version 3.12.3. ### Vulnerability Details When the logging level was set by the user to DEBUG, the Connector could have logged Duo passcodes (when specified via the “passcode” parameter) and Azure SAS tokens. Additionally, the [SecretDetector](https://docs.snowflake.com/en/developer-guide/python-connector/python-connector-example#logging) logging formatter, if enabled, contained bugs which caused it to not fully redact JWT tokens and certain private key formats. ### Solution Snowflake released version 3.12.3 of the Snowflake Connector for Python, which fixes these issues. We r...

### Impact When a user disables two-factor authentication via the Panel, a `DELETE` request with their current password in a query parameter will be sent. While query parameters are encrypted when using TLS, many webservers (including ones officially documented for use with Pterodactyl) will log query parameters in plain-text, storing a user's password in plain text. If a malicious user obtains access to these logs they could *potentially* authenticate against a user's account; assuming they are able to discover the account's email address or username **separately**. ### Patches This problem has been patched by <https://github.com/pterodactyl/panel/commit/8be2b892c3940bdc0157ccdab16685a72d105dd1> on the `1.0-develop` branch and released under `v1.11.8` as a single commit on top of `v1.11.7` <https://github.com/pterodactyl/panel/commit/75b59080e2812ced677dab516222b2a3bb34e3a4> Patch file: <https://github.com/pterodactyl/panel/commit/8be2b892c3940bdc0157ccdab16685a72d105dd1.patch> ...

### Summary  The AWS Load Balancer Controller includes an optional, default-enabled feature that manages WAF WebACLs on Application Load Balancers (ALBs) on your behalf. In versions 2.8.1 and earlier, if the WebACL annotation [1] [alb.ingress.kubernetes.io/wafv2-acl-arn](http://alb.ingress.kubernetes.io/wafv2-acl-arn) or [alb.ingress.kubernetes.io/waf-acl-id](http://alb.ingress.kubernetes.io/waf-acl-id) was absent on Ingresses, the controller would automatically disassociate any existing WebACL from the ALBs, including those associated by AWS Firewall Manager (FMS). Customers on impacted versions should upgrade to prevent this issue from occurring. ### Impact  WebACLs attached to ALBs managed by the AWS Load Balancer Controller through methods other than Ingress annotations may be automatically removed, leaving the ALBs unprotected by WebACL.  Impacted versions: [>=2.0.0;<2.8.2]  ### Patches  We addressed this issue in version 2.8.2 [2] and recommend customers upgrade. Now, if t...