Latest News

### Impact A vulnerability has been identified whereby RKE2 deployments in 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\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 RKE2 in Windows environments. Linux environments are not affected by it.** Please consult the associated [MITRE ATT&CK - Technique - Exploitation for Privilege Escalation](https://attack.mitre.org/techniques/T1068/) for further information about this category of attack. ### Patches Patched versions include RKE2 `1.31.0`, `1.30.2`, `1.29.6`, `1.28.11` and `1.27.15`. ### Workarounds Users are advised to do a fresh install of their ...

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

Change Healtcare has confrimed that at least 100M US citizens personal data were impacted by their February data breach

Linux Foundation removes 11 Russian developers from the Linux kernel project due to U.S. sanctions. Linus Torvalds confirms…