CVE-2025-68152: 
NixOS vulnerability analysis and mitigation

CVE-2025-68152 is an incorrect authorization vulnerability in Canonical's Juju application orchestration engine that allows a compromised workload machine to read any log file for any entity in any model at any log level via the controller's debug log API endpoint. It affects Juju versions 2.9 through 2.9.55 and 3.6 through 3.6.18. The vulnerability was published on April 3, 2026, and patched in versions 2.9.56 and 3.6.19. It carries a CVSS v3.1 base score of 4.9 (Medium) and a CVSS v4.0 base score of 6.9 (Medium) (Github Advisory, Juju Security Advisory).

The root cause is CWE-863 (Incorrect Authorization): Juju's API server exposes a debug log streaming endpoint (/log) that authenticates callers but does not sufficiently restrict which authenticated identities can access cross-model or cross-entity logs. The authorizer for this endpoint permitted any machine agent tag kind — including workload machine agents — to stream logs without verifying that the machine's access should be scoped only to its own model. A compromised workload machine possesses an agent.conf file containing valid machine agent credentials, which can be used directly against the debug log endpoint to retrieve logs from the controller and any model at any verbosity level, including debug and trace. The fix (commit c91a1f4) tightened the debuglogAuth composite authorizer to require either controller agent/admin status or explicit model read permission, removing the overly broad machine agent allowance (Juju Security Advisory, Patch Commit c91a1f4).

A successful exploit allows an attacker who has already compromised a workload machine to read all log streams across every model and entity managed by the Juju controller, including debug and trace-level output. This can expose credentials, encryption keys, configuration secrets, and other sensitive data that applications inadvertently write to logs. While the vulnerability does not directly grant write access or code execution on the controller, the intelligence gathered from logs could enable further lateral movement or privilege escalation across the entire Juju deployment (Juju Security Advisory, Github Advisory).

No public proof-of-concept exploit code has been released, and there is no evidence of in-the-wild exploitation at this time. The EPSS score is approximately 0.011–0.013% (2nd percentile), indicating a low near-term exploitation probability. Exploitation requires an attacker to have already compromised a workload machine managed by the Juju controller — a significant prerequisite — but once that condition is met, the attack itself is straightforward and requires no additional privileges beyond the machine agent credentials found in agent.conf. The vulnerability is not listed in the CISA KEV catalog (Github Advisory, Juju Security Advisory).

1. Compromise a workload machine: Gain access to any machine managed as a Juju workload unit (e.g., via an application vulnerability, misconfiguration, or supply chain attack).
2. Retrieve machine agent credentials: Read the agent.conf file on the compromised machine (typically located at /var/lib/juju/agents/<machine-tag>/agent.conf), which contains the machine agent's tag and password used to authenticate to the Juju controller API.
3. Identify the controller API endpoint: Determine the Juju controller's API address and port (commonly found in agent.conf or via network enumeration).
4. Authenticate to the debug log endpoint: Use the extracted machine agent credentials to authenticate against the controller's /log HTTP/WebSocket endpoint (e.g., wss://<controller>:<port>/log).
5. Stream cross-model logs: Issue requests to the debug log endpoint specifying any model, entity, or log level — including controller-level and other models' logs — to exfiltrate sensitive information such as credentials, keys, or configuration data leaked in debug/trace output (Juju Security Advisory, Github Advisory).

• Network: Unexpected WebSocket connections to the Juju controller API port (default 17070) from workload machine IPs, particularly to the /log endpoint; connections requesting logs for models or entities other than the connecting machine's own model.
• Logs: Juju controller API access logs showing machine agent tags (e.g., machine-N) authenticating to the /log debug endpoint and requesting logs scoped to other models or the controller itself; repeated or bulk log streaming sessions from a single machine agent.
• File System: Unexpected reads or access timestamps on /var/lib/juju/agents/<machine-tag>/agent.conf on workload machines, which may indicate credential harvesting by a compromised process.
• Process: Unusual processes on workload machines (e.g., scripts, curl, or custom binaries) making outbound connections to the controller API port or reading Juju agent configuration files (Juju Security Advisory).

Canonical has released patched versions 2.9.56 (for the 2.9 branch) and 3.6.19 (for the 3.6 branch); organizations should upgrade immediately. The fixes are implemented in commits c91a1f4 (debug log endpoint authorization) and 22cdcf6 (tools upload authorization). As a compensating control prior to patching, operators should implement network segmentation to restrict workload machines from directly reaching the controller API port, apply strict security hardening to workload machines to reduce the risk of initial compromise, and audit controller API access logs for anomalous machine agent log streaming activity (Juju Security Advisory, Patch Commit c91a1f4, Patch Commit 22cdcf6).

The advisory was published by Juju maintainer wallyworld on April 1, 2026, with credit to reporter tlm. Community discussion has been limited, with automated CVE tracking services (VulDB, CVEFeed, Bluesky CVE bot) picking up the disclosure shortly after publication. No significant vendor statements beyond the GitHub security advisory or notable independent researcher commentary have been identified (Juju Security Advisory).