CVE-2026-5412: Broken Access Control in Juju API Leads to Cloud Credential Leak

Juju operates as a model-driven operator lifecycle manager, coordinating application deployments across various cloud environments. The Juju API server facilitates remote management by exposing functionality through specific interfaces called facades. These facades are accessed via a JSON-RPC interface, typically bound to TCP port 17070 on the controller node.

The vulnerable component resides within the Controller facade, specifically within the CloudSpec method implementation. This method returns operational and configuration details about the specific cloud environment currently managed by the controller. Clients routinely query this endpoint to retrieve connection metadata and regional configuration states.

The vulnerability is formally classified as CWE-285: Improper Authorization. The core issue lies in the system's failure to enforce role-based access control (RBAC) constraints on the data returned by the CloudSpec method. The system relies entirely on basic authentication and possession of a model identifier, failing to verify administrative privileges.

The Common Vulnerability Scoring System (CVSS v3.1) evaluates this flaw at 9.9 out of 10.0. The score reflects the critical nature of the vulnerability: it requires no user interaction, operates over the network, requires only low-level privileges, and completely alters the scope of the attack by compromising the independent cloud infrastructure.

The root cause is a failure to enforce functional-level access controls within the Juju RPC request pipeline prior to object serialization. The CloudSpec method accepts a model UUID as its primary argument and retrieves the corresponding cloud specification from the state database. The method processes this request uniformly for all authenticated users.

Prior to the patch, the application logic only verified two conditions: the client established a valid authentication session, and the supplied model UUID existed within the system. The controller lacked explicit validation checks to determine if the requesting user held administrative rights over the requested model. The system trusted the client application to request only the data it was permitted to view.

The database returns a CloudSpec object containing several fields, including the sensitive Credential attribute. This specific field stores the plaintext secrets required to interact with the cloud provider API. Depending on the environment, this field contains AWS IAM keys, Azure service principal secrets, or OpenStack credentials used during the initial controller bootstrap.

Because the API server serializes the complete CloudSpec object without applying context-aware data filtering, the sensitive payload is transmitted across the network to the requesting client. Any user with a baseline login permission on the controller receives the unredacted data structure, bypassing intended authorization boundaries.

Canonical addressed the vulnerability via pull request 22206, modifying the core authorization logic within apiserver/common/cloudspec/cloudspec.go. The developers introduced a data redaction phase immediately preceding the API response serialization. The patch inspects the caller's identity and permissions dynamically.

The implementation utilizes a two-tier authorization model to distinguish between internal agents and external users. The server evaluates the request context to identify the caller's source. Internal system components, such as Controller Agents or Model Agents, and users holding the global Superuser role bypass the granular checks and receive the full data structure.

For standard user clients, the patch introduces a systematic iteration over the requested model entities. The code invokes an explicit AdminAccess authorization check for each individual model. This function queries the access control list to verify that the specific authenticated user possesses administrative rights for the target UUID.

When the AdminAccess check fails, the application executes a structural redaction. The patch explicitly nullifies the Credential field by assigning it a nil value within the memory structure.

Exploitation begins with network access to the Juju controller API, operating on TCP port 17070. The attacker must possess valid credentials for an account provisioned on the controller. The specific privilege level of this account is irrelevant; minimal login access satisfies the vulnerability's prerequisites.

The attacker initiates a standard JSON-RPC session using the acquired credentials. Following authentication, the attacker requires the target controller's model UUID to construct the subsequent payload. This identifier is frequently exposed through unauthenticated or low-privileged metadata endpoints within the Juju discovery API.

With the model UUID confirmed, the attacker constructs a direct RPC call to the Controller facade. The payload invokes the CloudSpec method, passing the discovered model UUID as the target parameter. The attacker submits this carefully formatted JSON payload through the established authenticated socket.

The API server processes the request and responds with a JSON object encompassing the complete cloud specification. The attacker parses this response to isolate the Credential block. The extracted plaintext string immediately grants the attacker the underlying cloud provider API access rights, completing the exploit chain.

The security impact extends completely beyond the Juju controller ecosystem to the underlying cloud infrastructure provider. The leaked bootstrap credentials possess extensive administrative permissions by design, as they must manage compute instances, storage volumes, and network security policies required by the Juju application.

An attacker extracting these credentials gains unconstrained control over the target cloud environment via the provider's standard APIs (e.g., AWS CLI, Azure Resource Manager). They can provision unauthorized infrastructure, delete critical production databases, or alter network configurations to expose internal services to the public internet.

The CVSS vector CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:H precisely maps this structural boundary violation. The critical "Scope: Changed" (S:C) metric indicates that a vulnerability within the Juju software directly compromises the functionally distinct cloud infrastructure layer. The impacts to Confidentiality, Integrity, and Availability are uniformly High.

The attack profile presents high risk due to its low operational complexity. Exploitation relies on standard API requests and requires no specific memory corruption vectors or timing techniques. Attackers can fully automate the extraction process and integrate the technique into standard post-exploitation toolkits.

Administrators must immediately upgrade affected Juju controller deployments to version 2.9.57 or 3.6.21. These patched releases integrate the mandatory access control enforcement mechanisms required to protect the CloudSpec endpoint. System operators should utilize standard Juju upgrade procedures to apply the new binaries across their fleets.

Software updates block future unauthorized access but provide no remediation for prior credential exposure. Administrators must operate under the assumption that the controller's bootstrap cloud credentials were compromised if untrusted users maintained login access to the vulnerable versions.

Security teams must execute an immediate cryptographic rotation of the affected cloud provider credentials. This process involves generating new IAM keys, service principals, or API tokens within the cloud provider console, updating the Juju controller with the new secrets, and permanently revoking the previous credentials.

Organizations must systematically apply the principle of least privilege across their Juju deployments. Administrators must audit controller user accounts and aggressively prune unnecessary login permissions. Access to the controller API must be restricted at the network level, utilizing strict firewalls or zero-trust overlays to permit connections only from authorized administration subnets.