CVE-2025-68153: 
NixOS vulnerability analysis and mitigation

CVE-2025-68153 is a resource poisoning vulnerability in Canonical's Juju application orchestration engine, classified as an incorrect authorization flaw (CWE-863). Any authenticated user, machine, or controller under a Juju controller can modify the resources of any application within the entire controller, regardless of their actual permissions. Affected versions span 2.9 through 2.9.55 and 3.6 through 3.6.18; the issue was disclosed on April 3, 2026, and patched in versions 2.9.56 and 3.6.19. It carries a CVSS v3.1 base score of 6.5 (Medium) and a CVSS v4.0 base score of 7.1 (High) (GitHub Advisory, Red Hat CVE).

The root cause is an absent or insufficient authorization check on the HTTP resource handler at the path /:modeluuid/applications/:application/resources/:resources. The handler accepted any authenticated principal — user, machine, or controller agent — without verifying that the caller held write permissions on the target model, violating the principle of least privilege (CWE-863). An attacker only needs to know three pieces of information — the model UUID, the application name, and the resource name — to issue a PUT request that overwrites the resource cache for any model on the controller; since many deployments use charm names for applications and resources are publicly listed on Charm Hub, the model UUID is often the only non-trivial prerequisite. The fix, committed as 26ff93c, splits the single ResourcesHandler into separate upload and download handlers, enforcing model write-access authorization exclusively on the PUT path (GitHub Advisory, Patch Commit).

Successful exploitation allows an authenticated attacker to overwrite application resources — including OCI container images and file-based resources — for any model across the entire Juju controller, directly impacting integrity with no confidentiality or availability impact at the CVSS level. In practice, however, the consequences can be severe: a compromised workload with machine credentials could replace a legitimate OCI image (e.g., a Kubernetes Vault container) with a trojanized version, enabling privilege escalation, secret exfiltration, and lateral movement to other systems. In multi-tenant environments, one tenant can interfere with another's deployments, and any charm relying on file resources for security controls could also be subverted (GitHub Advisory).

No public proof-of-concept exploit code has been published, and there is no evidence of in-the-wild exploitation at this time (GitHub Advisory). The EPSS score is approximately 0.013%, reflecting low current exploitation probability. The vulnerability is not listed in the CISA Known Exploited Vulnerabilities (KEV) catalog. Despite the absence of a PoC, the advisory notes the flaw is "very obvious from a code read" and requires minimal attacker knowledge, making it straightforward to exploit for any authenticated principal (GitHub Advisory).

1. Gain authentication: Obtain any valid credential for the target Juju controller — this could be a low-privileged user account, a compromised machine agent credential, or a controller agent token.
2. Enumerate target information: Identify the model UUID (obtainable via juju models or API calls), the application name (typically the charm name, publicly known from Charm Hub), and the resource name (also publicly listed on Charm Hub).
3. Craft a malicious resource: Prepare a trojanized file or OCI container image with the same file extension as the legitimate resource (e.g., a malicious Docker image tarball or a weaponized binary).
4. Upload the poisoned resource: Issue an HTTP PUT request to /:modeluuid/applications/:application/resources/:resource on the Juju controller API, supplying the malicious payload. The handler performs no write-permission check, so the upload succeeds regardless of the caller's actual authorization level.
5. Trigger resource consumption: Wait for or trigger a charm upgrade, scale-out, or unit restart that causes Juju to deploy the cached (now poisoned) resource to workloads, achieving code execution or security control bypass in the target model (GitHub Advisory, Patch Commit).

• Network: Unexpected HTTP PUT requests to /:modeluuid/applications/:application/resources/:resource on the Juju controller API originating from principals that do not normally perform resource uploads (e.g., machine agents, low-privileged users).
• Logs: Juju controller API access logs showing PUT requests to resource endpoints from machine or controller agent tags rather than administrative user accounts; mismatches between the uploading principal and the model owner.
• File System / Resource Cache: Unexpected changes to resource checksums or file sizes in the Juju resource store; OCI image digests that do not match those published on Charm Hub for the corresponding charm version.
• Process / Workload Behavior: Unusual process activity within charm workloads following a resource refresh or unit restart, particularly in OCI-based deployments (e.g., unexpected outbound connections, new privileged processes spawned by containerized services) (GitHub Advisory).

Upgrade Juju to version 2.9.56 or later (for the 2.9 branch) or 3.6.19 or later (for the 3.6 branch), which enforce model write-access authorization on resource upload endpoints (GitHub Advisory, Patch Commit). Until patching is complete, restrict network-level access to the Juju controller API to trusted users and systems only, and audit access logs for unauthorized PUT requests to resource endpoints. Additionally, review and tighten RBAC policies within your Juju deployment to limit the number of principals with controller access.

The vulnerability was reported by researcher 'tlm' and published via the GitHub Security Advisory program on April 1, 2026. The advisory author noted the flaw is "very straight forward to just read in the code" and declined to publish a PoC given the obviousness of the exploit path, indicating a low technical barrier for exploitation by any authenticated attacker (GitHub Advisory). Community tracking sites including VulDB and CVE Feed indexed the vulnerability shortly after disclosure, and it received brief coverage on Bluesky via automated CVE notification accounts.