CVE-2026-4370: 
NixOS vulnerability analysis and mitigation

CVE-2026-4370 is a critical authentication bypass vulnerability in Canonical's Juju orchestration software, affecting the internal Dqlite database cluster used by the Juju controller. The flaw stems from improper TLS client and server certificate validation: the controller's Dqlite endpoint does not validate client certificates when a new node attempts to join the cluster, and the client itself uses InsecureSkipVerify: true, enabling MITM attacks. Affected versions are Juju 3.2.0 through 3.6.19 and 4.0 through 4.0.4. It carries a CVSS v3.1 base score of 10.0 (Critical) (GitHub Advisory, Red Hat CVE).

The root cause is classified under CWE-295 (Improper Certificate Validation) and CWE-306 (Missing Authentication for Critical Function), with the GitHub advisory additionally citing CWE-287 (Improper Authentication) and CWE-296 (Improper Following of a Certificate's Chain of Trust). In juju/internal/database/node.go (lines 312–324), the TLS listen configuration sets ClientCAs but never enforces client certificate verification, while the dial configuration sets InsecureSkipVerify: true, meaning neither side of the TLS handshake is properly authenticated. An attacker with network reachability to the Juju controller's Dqlite port (default TCP/17666) can use a self-signed certificate to join the cluster as a peer node — no prior credentials or privileges are required (GitHub Advisory).

Once an attacker joins the Dqlite cluster, they gain full read and write access to the underlying controller database, enabling complete data compromise across all models managed by the controller. This includes the ability to escalate privileges (e.g., modifying user records), alter firewall configurations, exfiltrate cloud credentials and secrets stored in the database, and disrupt availability by corrupting cluster data. The changed scope (S:C) in the CVSS score reflects that a compromise of the Juju controller database can cascade to all workloads and infrastructure managed by that controller (GitHub Advisory, Feedly).

A detailed proof-of-concept exploit is publicly available in the official GitHub Security Advisory, using the dqlite-demo tool to join the cluster and execute arbitrary SQL against the controller database — including modifying user records and escalating privileges. The advisory provides concrete commands, server IPs, and port numbers demonstrating real-world exploitation. As of the time of reporting, there is no confirmed evidence of in-the-wild exploitation, and no threat actor attribution has been made. The EPSS score is approximately 0.035% (low probability of near-term exploitation), and the vulnerability does not appear in the CISA KEV catalog at this time (GitHub Advisory, Feedly).

1. Reconnaissance: Identify internet-facing or network-accessible Juju controllers running versions 3.2.0–3.6.19 or 4.0–4.0.4. Scan for TCP port 17666 (Dqlite replication port) using tools like nmap or masscan.
2. Prepare the exploit tool: Build or obtain the dqlite-demo tool (based on the go-dqlite demo app). The tool generates a self-signed TLS certificate internally — no valid CA-signed certificate is needed because the server does not validate client certificates.
3. Join the Dqlite cluster: Run the tool specifying a local listener address and the target controller's Dqlite endpoint:

   dqlite-demo --db 192.168.1.25:9999 --join 10.151.236.15:17666

   The server accepts the connection without verifying the client certificate, admitting the attacker as a cluster peer.
4. Switch to the controller database: Once connected, use the .switch controller meta-command to access the Juju controller database.
5. Read or modify data: Execute arbitrary SQL queries to exfiltrate sensitive data or modify records:

   select * from user;
   update user set display_name='Silly Admin' where name='admin';

6. Escalate or persist: Modify user access levels, extract cloud credentials, alter model configurations, or open firewall ports — all via direct SQL manipulation of the controller database (GitHub Advisory).

• Network: Unexpected inbound TCP connections to port 17666 on Juju controller nodes from IP addresses that are not other known controller nodes; outbound connections from the controller to unknown external IPs on high-numbered ports (attacker's --db listener address).
• Logs: Dqlite cluster membership changes logged by the Juju controller showing new, unexpected node addresses joining the cluster; TLS handshake completions from unrecognized source IPs on port 17666.
• Database: Unexpected modifications to the user table (e.g., changed display_name or access fields); new or altered records in credential, model, or firewall-related tables; audit log entries reflecting SQL changes not initiated by known Juju clients.
• Process/System: Presence of the dqlite-demo binary or similar Go-based Dqlite client tools on systems with network access to the controller; creation of temporary directories under /tmp/dqlite-demo/ on attacker-controlled hosts (GitHub Advisory).

Patch (recommended): Upgrade Juju to version 3.6.20 (for the 3.x branch) or 4.0.5 (for the 4.x branch), which fix the improper TLS certificate validation (GitHub Advisory).

Workarounds (if patching is not immediately possible):

• Option 1 – Disable HA: If High Availability is not required, reduce the cluster to a single controller node, eliminating the need for Dqlite replication. Block port 17666 at the firewall.
• Option 2 – Firewall restriction: Use ufw or equivalent to restrict ingress on TCP/17666 to only known Juju controller IP addresses:

  sudo ufw allow from <controller-ip> to any port 17666 proto tcp
  sudo ufw deny 17666/tcp
  sudo ufw enable

• Kubernetes controllers: Apply a NetworkPolicy restricting port 17666 ingress to only the controller pod itself.

Revert any workaround configuration changes after applying the official patch to avoid interfering with future unattended upgrades (GitHub Advisory).

The vulnerability received coverage from security news outlets including Security Online, which highlighted the CVSS 10.0 score and the risk of complete database compromise (Security Online). The Hacker Wire also covered the authentication bypass on Mastodon and its website (The Hacker Wire). Community discussion on Mastodon and Bluesky noted the severity of the unauthenticated cluster join capability and the availability of a working PoC. The advisory was credited to researchers hpidcock (finder), tlm (analyst), manadart (remediation developer), and wallyworld (coordinator) from the Juju team (GitHub Advisory).