EUVD-2026-17847
GHSA-gvrj-cjch-728p
Severity by source
AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:H
Primary rating from NVD · only source for this CVE.
CVSS VectorNVD
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:H
Lifecycle Timeline
4DescriptionCVE.org
A vulnerability was identified in Juju from version 3.2.0 until 3.6.19 and from version 4.0 until 4.0.4, where the internal Dqlite database cluster fails to perform proper TLS client and server authentication. Specifically, the Juju controller's database endpoint does not validate client certificates when a new node attempts to join the cluster. An unauthenticated attacker with network reachability to the Juju controller's Dqlite port can exploit this flaw to join the database cluster. Once joined, the attacker gains full read and write access to the underlying database, allowing for total data compromise.
AnalysisAI
Unauthenticated remote database cluster compromise in Canonical Juju (versions 3.2.0-3.6.19 and 4.0-4.0.4) allows complete data exfiltration and manipulation through missing TLS certificate validation on Dqlite database endpoints. The controller's database cluster accepts unauthorized node joins from any network-accessible attacker, granting full read/write access to all stored credentials, configurations, and orchestration data. With CVSS 10.0 (AV:N/AC:L/PR:N/UI:N) and EPSS data unavailable, this represents a critical authentication bypass in infrastructure-as-code environments. No public exploit identified at time of analysis, though exploitation requires only network access to the Dqlite port without authentication complexity.
Technical ContextAI
Juju is Canonical's application modeling and orchestration framework for deploying and managing cloud applications across multiple substrates (Kubernetes, AWS, Azure, OpenStack, bare metal). The Juju controller uses Dqlite-a distributed SQLite implementation with Raft consensus-to maintain cluster state, including cloud credentials, model configurations, charm metadata, and machine provisioning data. This vulnerability (CWE-295: Improper Certificate Validation) stems from the Dqlite database listener failing to validate client certificates during TLS handshakes when new nodes attempt cluster membership. The CPE identifier cpe:2.3:a:canonical:juju confirms this affects Canonical's Juju product across the specified version ranges. In proper mTLS implementations, both client and server certificates must be validated against trusted certificate authorities; the absence of client certificate validation transforms the authentication model from mutual TLS to effectively no authentication, as any client can present an arbitrary or self-signed certificate. This is particularly severe for Dqlite, where cluster membership inherently grants database-level privileges rather than requiring additional authorization layers.
RemediationAI
Upgrade immediately to Juju version 3.6.20 or later for the 3.x series, or version 4.0.5 or later for the 4.x series, which implement proper mutual TLS client certificate validation in the Dqlite cluster authentication mechanism. Consult Canonical's official security advisory at https://github.com/juju/juju/security/advisories/GHSA-gvrj-cjch-728p for version-specific upgrade procedures and any additional mitigation guidance. As an interim workaround pending upgrade, implement network segmentation to restrict access to the Juju controller's Dqlite port (typically TCP 17071) exclusively to authenticated controller nodes using firewall rules, security groups, or network policies-this reduces attack surface but does not eliminate the underlying authentication vulnerability. Organizations should audit Juju controller access logs for unexpected cluster join attempts or unauthorized database connections during the vulnerability window, and rotate all stored cloud credentials, SSH keys, and certificates accessible through the Juju database as a precautionary measure if unauthorized access is suspected. Given the severity, this patch should be prioritized in emergency change windows rather than standard maintenance cycles.
Juju before 1.25.12, 2.0.x before 2.0.4, and 2.1.x before 2.1.3 uses a UNIX domain socket without setting appropriate pe
In Juju versions prior to 3.6.8 and 2.9.52, any authenticated controller user was allowed to upload arbitrary agent bina
The /charms endpoint on a Juju controller lacked sufficient authorization checks, allowing any user with an account on t
JUJU_CONTEXT_ID is a predictable authentication secret. Rated high severity (CVSS 8.0), this vulnerability is low attack
The /log endpoint on a Juju controller lacked sufficient authorization checks, allowing unauthorized users to access deb
Authorization bypass in Canonical Juju Controller facade allows authenticated users to extract bootstrap cloud credentia
An authorization bypass vulnerability in Canonical's Juju versions 3.0.0 through 3.6.18 allows authenticated users with
An issue was discovered in Juju that resulted in the leak of the sensitive context ID, which allows a local unprivileged
An authorization bypass vulnerability exists in the Vault secrets back-end implementation of Canonical's Juju orchestrat
Unauthorized resource modification in Juju application orchestration engine allows any authenticated controller user to
Juju application orchestration engine versions 2.9 to 2.9.55 and 3.6 to 3.6.18 allow a compromised workload machine to r
A predictable secret identifier (XID) vulnerability in Juju versions 3.0.0 through 3.6.18 allows a malicious grantee to
Same weakness CWE-295 – Improper Certificate Validation
View allSame technique Information Disclosure
View allVendor StatusVendor
Debian
| Release | Status | Fixed Version | Urgency |
|---|---|---|---|
| (unstable) | fixed | (unfixed) | - |
Share
External POC / Exploit Code
Leaving vuln.today