Juju Dqlite Cluster Authentication Bypass - Unauthenticated Database Access

Vulnerability Description

This vulnerability represents a critical authentication and certificate verification failure in Juju's Dqlite cluster communication layer. The root cause is twofold: (1) the server does not validate client certificates before accepting connections to the Dqlite endpoint, and (2) the client does not verify the server's certificate, creating bidirectional trust bypass. This violates TLS mutual authentication (mTLS) principles essential for distributed database security. Any process with network routability to the controller's Dqlite port can bypass all authentication mechanisms and gain direct database access.

Impact & PoC Significance

The PoC demonstrates that an attacker can join a Dqlite cluster without credentials, gaining equivalent access to the controller's entire state database. This includes user accounts, model configurations, firewall rules, SSH keys, and secrets. The vulnerability is reliably exploitable and requires only network access—no credential compromise or complex attack chain. The PoC's significance lies in proving that standard network isolation is the only current defense; Juju provides no application-layer protections.

Detection Guidance

Network Indicators:

• Unexpected connections to the Dqlite port (typically 19291) from unauthorized subnets
• Monitoring controller pods/VMs for inbound Dqlite connections outside expected deployment topology
• Anomalous TLS handshakes lacking valid client certificates (if logging at TLS layer)

Log Indicators:

• Dqlite cluster membership changes (node join events) from unexpected sources
• Configuration changes in controller models without corresponding audit trails
• Failed authentication attempts at Juju API layer paired with successful database modifications

Defensive Tools:

• Network segmentation rules blocking non-controller access to Dqlite ports
• TLS inspection to identify connections without valid client certs (requires endpoint logging)
• Database activity monitoring for unexpected query patterns or data exfiltration

Mitigation Steps

1. Immediate: Isolate controller Dqlite ports (19291) at network boundaries; allow only inter-controller and approved management traffic
2. Patch: Upgrade to patched Juju versions enforcing client certificate validation and server certificate verification (check advisory for fixed versions)
3. Workaround: Deploy controllers in air-gapped networks or behind API gateways requiring authentication before cluster access
4. Configuration: Enable firewall rules rejecting unauthenticated Dqlite traffic; consider mTLS enforcement at infrastructure layer if available
5. Audit: Review recent controller cluster join events and database access logs for suspicious activity

Risk Assessment

Likelihood: High in internet-facing or multi-tenant cloud deployments lacking network segmentation. Moderate in corporate environments with strict firewalling. The barrier to exploitation is purely network access—no exploit code or zero-day knowledge required.

Threat Actor Interest: Critical infrastructure, cloud providers, and multi-tenant SaaS platforms using Juju are high-value targets. The ability to fully compromise cluster state makes this attractive for persistence and lateral movement. Opportunistic scanning of exposed Dqlite ports is probable.