Juju Dqlite Cluster TLS Auth Bypass — Unauthenticated Database Access (CVE-2026-4370)

Executive Summary

A critical authentication bypass vulnerability (CVE-2026-4370) has been disclosed in Canonical's Juju charm deployment framework, affecting the internal Dqlite database cluster used by Juju controllers. The vulnerability stems from the controller's database endpoint failing to validate TLS client and server certificates, meaning any network-accessible attacker can establish a direct, unauthenticated connection to the internal database. With a CVSS score of 10.0, this is a maximum-severity finding that exposes the full state of all Juju-managed infrastructure to unauthorized access and manipulation.

CVSS Score: 10.0 (Critical) CVSS Vector: CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:H

Vulnerability Overview

Affected Products

Juju is Canonical's open-source application modelling framework, widely used to deploy and manage complex distributed applications on cloud infrastructure including Kubernetes, AWS, Azure, GCP, and on-premises bare metal. The Juju controller is the central authority managing all charm state, credentials, and configuration — making its database an extremely high-value target.

Technical Details

Root Cause

The Juju controller exposes a Dqlite cluster endpoint for internal database replication among controller nodes. This endpoint is intended to be accessible only to authenticated controller peers using mutual TLS (mTLS). However, the implementation fails to enforce certificate validation for both client and server certificates, meaning:

1. The server does not verify that connecting clients present a valid, trusted certificate
2. Clients connecting to the endpoint are not required to authenticate themselves

This effectively nullifies the TLS transport's authentication guarantees, leaving the Dqlite endpoint as an unauthenticated network service on whatever port it binds to.

Attack Chain

1. Attacker identifies the Juju controller's Dqlite cluster endpoint
   (default port binding on the controller's management address)
 
2. Attacker initiates a TLS connection to the Dqlite endpoint
   without presenting a valid client certificate
 
3. The controller accepts the connection due to missing
   certificate validation logic
 
4. Attacker gains full read/write access to the Dqlite database,
   which contains:
   - All charm configuration and secrets
   - Cloud credential references
   - Model topology and unit state
   - User credentials and API tokens
 
5. Attacker exfiltrates cloud credentials, injects malicious
   configuration, or disrupts all managed workloads

Why CVSS 10.0?

The perfect score reflects the combination of:

• Network-accessible exploitation with no prerequisites
• Zero authentication required — no credentials, no tokens
• Changed scope — successfully exploiting the database gives an attacker lateral movement across all cloud infrastructure managed by the Juju controller
• Full CIA triad impact — all data can be read, modified, or destroyed

Impact Assessment

Recommendations

Immediate Actions

1. Upgrade Juju immediately to version 3.6.19 or 4.0.4 — these releases enforce proper TLS certificate validation on the Dqlite endpoint
2. Audit Dqlite endpoint network exposure — confirm the controller's management address is not reachable from untrusted network segments
3. Rotate all credentials stored in Juju models, including cloud provider keys, charm secrets, and API tokens
4. Review Juju controller audit logs for unexpected database connections originating from non-controller IP addresses

Network-Level Mitigations (Pre-Patch)

- Firewall the Dqlite port (default: 17666/tcp) to controller
  peer IPs only — deny all other inbound connections
- Apply network segmentation so the controller management
  network is isolated from application/user networks
- Enable network-level mTLS proxies (e.g., Envoy) in front
  of the Dqlite endpoint as a compensating control
- Monitor for unusual outbound traffic from the Juju controller
  host — credential abuse typically results in unexpected API calls
  to cloud provider endpoints

Post-Upgrade Verification

1. Confirm running Juju version: juju version
2. Verify controller is running 3.6.19+ or 4.0.4+:
   juju show-controller --format=json | jq '.controller.agent-version'
3. Test that the Dqlite endpoint now rejects unauthenticated
   connections (certificate validation enforced)
4. Rotate all model credentials:
   juju update-credential <cloud> <credential-name>
5. Audit model configurations for unauthorized changes

Detection Indicators

Example Detection Rule (Suricata)

alert tcp any any -> $JUJU_CONTROLLER 17666 (
  msg:"CVE-2026-4370 Juju Dqlite Unauthenticated Connection Attempt";
  flow:to_server,established;
  content:"|16 03|";
  depth:2;
  classtype:attempted-admin;
  sid:9026437;
  rev:1;
)

Post-Remediation Checklist

1. Verify upgrade — confirm all controller nodes run Juju 3.6.19+ or 4.0.4+
2. Rotate cloud credentials — all provider keys referenced by models should be regenerated
3. Audit model configurations — review charm configs for unauthorized changes introduced during any potential exploitation window
4. Review Juju user accounts — check for newly added admin users or API token grants
5. Enable Juju audit logging if not already active: juju model-config audit-log-exclude-methods=""
6. Network scan — confirm Dqlite port is no longer reachable from untrusted subnets post-patch
7. Update SIEM rules to alert on unexpected connections to the Juju controller management port

References

• NIST NVD — CVE-2026-4370
• Canonical Juju Documentation
• Dqlite — Distributed SQLite
• CWE-295: Improper Certificate Validation
• CWE-306: Missing Authentication for Critical Function