Juju
cpe:2.3:a:canonical:juju:*:*:*:*:*:*:*
- >= 3.2.0, <= 3.6.19
- >= 4.0, <= 4.0.4
A vulnerability exists in Juju versions 3.2.0 prior to 3.6.19 and 4.0 prior to 4.0.4, where the internal Dqlite database cluster fails to enforce proper TLS client and server authentication. The issue arises because the Juju controller's database endpoint does not validate client certificates when a new node attempts to join the cluster. This flaw allows an unauthenticated attacker with network access to the Juju controller's Dqlite port to join the database cluster. Once connected, the attacker gains full read and write access to the database, leading to complete data compromise.
Exploitation of this vulnerability allows an attacker to join the Dqlite cluster of a Juju controller, read and modify all database information, and potentially escalate privileges.
To reproduce this vulnerability, bootstrap a Juju controller on a vulnerable version. After the controller is active, use a modified version of the 'go-dqlite' demo application to join the Dqlite cluster without proper authentication. The demo app can be configured to skip certificate verification, allowing it to connect to the Juju controller's Dqlite port and gain unauthorized access to the database.
Users can update to Juju versions 3.6.20 or 4.0.5, both of which address this vulnerability. If immediate updating is not possible, Juju controllers can be configured to block incoming connections to port 17666, except from other controller IP addresses. For environments using Kubernetes, apply a network policy to restrict access to the Dqlite port.
Our algorithm analyzes dozens of metrics to generate these 8 key vulnerability categories, which are then combined to calculate the overall risk score.