Juju fixes CloudSpec auth flaw leaking cloud credentials

TL;DR — Juju’s Controller CloudSpec API can be called by low-privilege authenticated users to exfiltrate the controller’s bootstrap cloud credentials, breaking a key authorization boundary.

What happened

Juju is Canonical’s application orchestration system, where a Juju controller manages models and communicates with backing clouds to deploy and operate workloads.

Canonical disclosed a Critical improper-authorization issue where any user who can log in to a controller (and who knows the controller model UUID) can call the CloudSpec method on the Controller facade and retrieve the cloud credentials used to bootstrap the controller. The advisory notes that while controller workers legitimately use CloudSpec, the API is also called by the CLI during forced controller destruction (e.g., juju kill-controller), and is exposed broadly to clients with only logon permission.

Credential-extraction bugs in orchestration control planes are consistently high-impact: controller bootstrap credentials often have broad cloud permissions, and controller APIs are frequently reachable from CI/CD runners and operator networks.

Who is impacted

• Organizations running Juju controllers on impacted trains (advisory: Juju < 2.9.57, Juju < 3.6.21, and 4.0.6 snap from 4.0/edge).
• Environments where the controller API is reachable by users who have logon permission but are not intended to have superuser or model admin capabilities.
• Higher-risk setups where cloud bootstrap credentials are long-lived and/or have wide IAM scope (the advisory explicitly targets exposure of the bootstrap credential).

What to do now

• Follow vendor remediation guidance and apply the latest patched release available at the time of writing (the advisory lists patched versions 2.9.57 and 3.6.21).
• Apply the vendor’s documented mitigation to reduce exposure while upgrading/rolling out fixes:

  "The only mitigation is to restrict ingress to the controller API port 17070 on all controller machines (for vm deployments) or the controller service (for k8s deployments)." "The Juju CLI and other clients like libjuju or JAAS require ingress to port 17070 so any restricted access will need to take into account those access requirements."

• Audit controller access: enumerate identities with controller logon permission and verify they should have any ability to read cloud credential material.
• If exposure is suspected, treat this as a secrets-compromise scenario: review access logs/telemetry around Controller facade calls (especially CloudSpec) and rotate the cloud credential used to bootstrap the controller (and any downstream credentials derived from it).

Additional Information

• Advisory: GHSA-w5fq-8965-c969 (juju/juju): https://github.com/juju/juju/security/advisories/GHSA-w5fq-8965-c969
• CVE record: https://raw.githubusercontent.com/CVEProject/cvelistV5/main/cves/2026/5xxx/CVE-2026-5412.json