CVE-2025-68152: Cross-Model Log Leakage via Incorrect Authorization in Juju API

Juju operates as an application orchestration engine that manages workloads across multiple infrastructure providers. The system architecture relies on a centralized controller that communicates with individual machine agents running on deployed workloads. These agents report status, execute lifecycle hooks, and transmit diagnostic data back to the controller via authenticated API connections.

CVE-2025-68152 identifies an authorization flaw in how the Juju API server handles access to the debug log streaming service. The vulnerability manifests as an Incorrect Authorization issue (CWE-863) within the endpoint responsible for serving diagnostic logs to authenticated clients. The system fails to enforce proper boundary checks between different logical models managed by the same controller.

An attacker with root access to a single managed workload can leverage the local machine agent credentials to access the Juju API. Due to the lack of strict access controls, the attacker can request and stream debug logs for any entity in the environment. This includes workloads belonging to isolated models and the controller infrastructure itself.

The vulnerability compromises the multi-tenant isolation guarantees of the Juju controller. It exposes sensitive operational data, environment variables, and application secrets written to standard output or trace logs across the entire orchestrated environment.

The root cause of CVE-2025-68152 is a missing scope validation check in the authorization handler within the Juju API server. Juju organizes workloads into isolated administrative domains called models. Every API request must undergo validation to ensure the requester possesses explicit permissions to access resources within the targeted model.

In the vulnerable implementation, the endpoint authorization logic relied exclusively on entity classification. The authorizer verified that the incoming request originated from an entity presenting a valid MachineTagKind or ControllerAgentTagKind. The system confirmed the identity of the requester as a valid machine agent but omitted verification of the authorization context relative to the requested resource.

When a client requests debug logs, the API endpoint accepts a ModelUUID or EntityTag parameter to specify the target resource. The API server did not mandate that the authenticated machine agent must belong to the specified ModelUUID. The system implicitly trusted any authenticated machine agent to read logs from any model present on the controller.

This architectural oversight violates the principle of least privilege. The authorization boundary resided at the global authentication level rather than the model-specific permission level. The system design erroneously operated on the assumption that machine agents would strictly request data pertinent to their own operational context.

The vulnerability existed within the authorization definitions located in apiserver/apiserver.go and apiserver/debuglog.go. The authorization handler for the debug log endpoint utilized a simple tag-based check. The vulnerable configuration initialized the authorizer as tagKindAuthorizer{names.MachineTagKind, names.ControllerAgentTagKind}.

The patch implemented in commit c91a1f4046956874ba77c8b398aecee3d61a2dc3 restructures this logic to utilize a CompositeAuthorizer. The Juju developers introduced a permission-based verification model alongside the existing entity type checks.

// Vulnerable Implementation
func debuglogAuth(...) Authorizer {
    return tagKindAuthorizer{names.MachineTagKind, names.ControllerAgentTagKind}
}
 
// Patched Implementation
func debuglogAuth(...) Authorizer {
    return CompositeAuthorizer{
        tagKindAuthorizer{names.MachineTagKind, names.ControllerAgentTagKind},
        modelPermissionAuthorizer{perm: permission.ReadAccess},
    }
}

The addition of modelPermissionAuthorizer{perm: permission.ReadAccess} enforces a strict check against the requested ModelUUID. The API server now queries the internal permission state to confirm that the specific machine agent holds explicit read access to the target model. If the agent attempts to request logs for an external model, the authorization handler denies the request with an HTTP 403 Forbidden error.

Commit 1a8d84ec114c2e4f9921e30081e5a5549f7cbfc4 addresses a related variant of this vulnerability involving synthetic applications. The codebase now rejects requests for cross-model relations (SaaS proxies) during resource listing and configuration retrieval. This modification prevents attackers from pivoting through external relation proxies to extract configuration data from adjacent models.

Exploiting CVE-2025-68152 requires the attacker to possess elevated privileges on a Juju-managed workload machine. The attacker must access the local file system to extract the controller connection details. The primary target is the configuration file located at /var/lib/juju/agents/machine-<ID>/agent.conf.

This configuration file contains the API endpoints for the Juju controller, the machine agent's unique identifier, and the cryptographic password used for authentication. The attacker parses this file to extract the necessary parameters to establish an authenticated session with the central controller. The connection is initiated over TCP port 17070 using HTTPS or WebSockets.

Once authenticated, the attacker constructs a payload targeting the DebugLog RPC endpoint. The request includes parameters specifying a target model that the attacker wishes to monitor. The attacker supplies the ModelUUID of a high-value environment, such as a production database model or the controller model itself.

The controller API server validates the agent credentials but fails to validate the requested model scope. The server opens a continuous log stream back to the attacker. The attacker captures the output, analyzing the stream for operational data, authentication tokens, or internal network topology information.

The impact of CVE-2025-68152 is classified as High for confidentiality due to the comprehensive exposure of system logs. Juju controllers aggregate vast amounts of diagnostic data from orchestrated applications. These logs frequently contain sensitive lifecycle event data, including application installation routines, configuration updates, and relation hooks.

Operators often configure charms to output debug information during deployment or failure scenarios. This output inadvertently includes raw database connection strings, API tokens for external services, and administrative credentials. An attacker streaming these logs gains access to these secrets, facilitating lateral movement across distinct infrastructure domains.

The vulnerability bypasses Juju's primary model isolation mechanism. Organizations use models to separate development, staging, and production environments, or to isolate different tenants on shared infrastructure. Subverting this isolation means a compromise in a low-security development model directly exposes the telemetry and secrets of high-security production models.

The CVSS v4.0 score of 6.9 reflects the targeted nature of the attack and the severe consequences of the data exposure. The attack requires high privileges on the initial workload, but the network-based access to the controller API and the lack of user interaction make the exploitation path highly reliable.

The primary remediation for CVE-2025-68152 is the application of the official security patches provided by the vendor. Organizations running Juju 2.9.x must upgrade their controllers and machine agents to version 2.9.56. Environments utilizing the Juju 3.6.x branch require an upgrade to version 3.6.19.

In scenarios where immediate patching is not feasible, administrators must enforce strict network segmentation. The Juju controller API interface, typically exposed on TCP port 17070, requires access control restrictions. Network access control lists must ensure that workload machines route traffic exclusively to the controller API without accessing other administrative interfaces.

Security teams must implement robust monitoring on the Juju controller logs. Auditing the API request logs for unusual DebugLog invocations provides a reliable detection mechanism. Analysts should look for machine agents requesting log streams for ModelUUID values that do not match their assigned deployment model.

If an organization suspects a workload compromise, all associated machine agent credentials require immediate rotation. Re-provisioning the affected machine agent generates a new authentication password, invalidating stolen agent.conf credentials and severing the attacker's unauthorized access to the API server.