Juju has a resource poisoning vulnerability
Date: 2026-04
Affected: go/github.com/juju/juju
Attack vector: auth-bypass
Category: vulnerability-disclosure
Severity: High
CVE: CVE-2025-68153
CWE: CWE-863
CVSS: 6.5 (CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:H/A:N)

### Summary Any authenticated user, machine or controller under a Juju controller can modify the resources of an application within the entire controller. This one is very straightforward to just read in the code: **Step 1:** The authorisation mechanism for the resource handler is defined [here](https://github.com/juju/juju/blob/1a8d84ec114c2e4f9921e30081e5a5549f7cbfc4/apiserver/internal/handlers/resources/resources.go#L77). One is only required to have been authed as either a user, machine or controller to pass this check. One requires no permissions on the controller nor does one need any further permissions on the models themselves. This handler is available under the following path format `/:modeluuid/applications/:application/resources/:resources`. See [here](https://github.com/juju/juju/blob/1a8d84ec114c2e4f9921e30081e5a5549f7cbfc4/apiserver/apiserver.go#L949). The handler defines no authorizer as supported by the handler struct [here](https://github.com/juju/juju/blob/1a8d84ec114c2e4f9921e30081e5a5549f7cbfc4/apiserver/apiserver.go#L696). One needs to know the following three bits of information to poison the resource cache on the controller: - model uuid - application name in the model - resource name in the model Given that a lot of deployments use the charm name for applications and the resources for charms are published on charm hub, this is a very low bar to meet, only requiring the model uuid. **Step 2:** If one passes the very basic authz check of step 1, o


Mitigations:

Architectural layers (MAESTRO):