CVE-2026-5412: Juju Controller Facade Allows Low-Privilege Cloud Credential Theft

Executive Summary

A critical authorization vulnerability (CVE-2026-5412) has been disclosed in Juju, Canonical's open-source cloud orchestration platform. The flaw exists in the Controller facade — the central management interface for Juju controllers — where an authorization check is missing for the CloudSpec API method. Any authenticated Juju user, regardless of their assigned role, can invoke this API to retrieve the cloud provider credentials used during controller bootstrap.

CVSS Score: 9.9 (Critical)

These bootstrap credentials are typically highly privileged cloud IAM credentials (AWS access keys, Azure service principal secrets, GCP service account keys, or OpenStack credentials) that have full control over the underlying cloud infrastructure. Exposure of these credentials hands an attacker the keys to the entire cloud environment the Juju controller manages — far beyond the Juju deployment itself.

This vulnerability affects Juju prior to 2.9.57 and Juju prior to 3.6.21. All deployments should upgrade immediately.

Vulnerability Overview

Affected Products

Technical Analysis

Root Cause

The Juju Controller facade exposes a CloudSpec API method that returns the full cloud specification for a given cloud-credential pair — including the raw credential material used to bootstrap the controller. The authorization gate for this method does not enforce role-level restrictions: it verifies that the caller is an authenticated Juju user, but does not verify whether that user has been granted the superuser or cloud admin permissions required to access sensitive controller configuration.

As a result, any Juju user with even the lowest-privilege role assignment (e.g., a user invited only to work on a single model) can directly call CloudSpec against the controller cloud and receive the bootstrap credential values in the response.

Attack Flow

1. Attacker obtains any Juju user account (social engineering, phishing, or legitimate access)
2. Attacker connects to the Juju controller API endpoint (TCP 17070 by default)
3. Attacker calls the CloudSpec API method against the controller cloud
4. The Controller facade returns the full cloud credential — AWS keys, Azure secrets, GCP SA JSON, etc.
5. Attacker uses the extracted credentials to access the underlying cloud provider directly
6. Full control of all cloud infrastructure managed by the Juju controller: VMs, storage, networking, IAM

Scope of Credential Exposure

Bootstrap credentials in Juju are typically provisioned with broad permissions because they are used by the controller to create, manage, and destroy all infrastructure within the Juju model scope. Depending on the cloud provider, the extracted credentials may grant:

• AWS: AdministratorAccess or custom IAM policies covering EC2, VPC, S3, IAM, and more
• Azure: Contributor or Owner role on subscriptions managed by the controller
• GCP: Owner or Editor role on projects, or service account keys with compute/storage admin
• OpenStack: admin credentials with full API access to Nova, Neutron, Cinder, and Keystone
• LXD/MAAS: Root-equivalent control over bare-metal or container infrastructure

Impact Assessment

Immediate Remediation

Step 1: Upgrade Juju

# Check current Juju version
juju version
 
# Upgrade Juju client and controller (snap-based)
sudo snap refresh juju
 
# For the Juju controller itself — upgrade the controller
juju upgrade-controller
 
# Verify the upgraded version
juju version

Step 2: Rotate Bootstrap Credentials Immediately

Even after patching, assume credentials may have already been exfiltrated and rotate them across all cloud providers:

AWS:

# Identify the IAM user/role used for Juju bootstrap
aws iam list-access-keys --user-name <juju-bootstrap-user>
 
# Delete old access key and create a new one
aws iam delete-access-key --user-name <juju-bootstrap-user> --access-key-id <OLD_KEY_ID>
aws iam create-access-key --user-name <juju-bootstrap-user>
 
# Update Juju credential with new key
juju update-credential aws <credential-name>

Azure:

# Reset Azure service principal password used by Juju
az ad sp credential reset --id <juju-sp-app-id>

GCP:

# Delete old service account key and create a new one
gcloud iam service-accounts keys delete <OLD_KEY_ID> --iam-account=<juju-sa@project.iam.gserviceaccount.com>
gcloud iam service-accounts keys create new-key.json --iam-account=<juju-sa@project.iam.gserviceaccount.com>

Step 3: Audit Juju User Access

Review all users with access to the Juju controller and revoke any accounts that should not have access:

# List all users on the controller
juju users
 
# Review model access grants
juju models --all
 
# Remove unauthorized or suspicious users
juju remove-user <username>
 
# Revoke model access for a user
juju revoke <username> read <model-name>

Step 4: Review Controller Audit Logs

# Check Juju controller audit logs for CloudSpec API calls
juju debug-log --include-module juju.apiserver --level DEBUG | grep -i "cloudspec\|cloud-spec\|credential"
 
# Review recent logins and API activity
juju debug-log --include-module juju.apiserver.authentication --level INFO

Detection Indicators

Post-Remediation Checklist

1. Upgrade all Juju controllers to 2.9.57+ (2.x branch) or 3.6.21+ (3.x branch) immediately
2. Rotate all cloud provider bootstrap credentials regardless of whether exploitation is confirmed
3. Audit Juju users — remove all accounts that no longer require access
4. Review cloud audit logs (AWS CloudTrail, Azure Activity Log, GCP Audit Logs) for evidence of credential abuse
5. Enable alerting on CloudSpec API invocations and unusual credential API activity
6. Apply least-privilege to Juju bootstrap credentials — scope IAM permissions to only what the controller needs
7. Enable MFA on all Juju user accounts where supported
8. Notify cloud teams to review IAM activity for the period prior to patching

References

• NVD — CVE-2026-5412
• Juju Documentation — Credentials
• Juju GitHub — Security Releases
• Canonical Security Advisories