CVE-2025-68153: Incorrect Authorization Leading to Resource Poisoning in Juju Apiserver

Juju is an application orchestration engine designed to manage software applications, referred to as charms, across diverse physical and cloud infrastructures. The Juju apiserver facilitates the management of these resources, providing endpoints for administrative tasks. A critical security flaw exists within the resource management endpoint of the Juju apiserver. This endpoint handles the upload and retrieval of associated application resources, such as OCI images and binary file blobs.

The vulnerability, identified as CVE-2025-68153, is an incorrect authorization flaw classified under CWE-863. It allows any authenticated entity within a Juju controller to bypass intended logical boundaries. Specifically, the apiserver fails to enforce model-scoped authorization checks during resource modification requests. This oversight exposes the entire controller environment to cross-model interference.

An attacker with low-level privileges, such as a compromised machine agent in a development model, can exploit this flaw. By issuing crafted HTTP requests, the attacker can overwrite application resources in structurally isolated models. This resource poisoning creates a direct path to cross-model privilege escalation and remote code execution on targeted workloads.

The root cause resides in the implementation of the Juju apiserver's resource handler endpoint. The specific route affected is /:modeluuid/applications/:application/resources/:resource. This endpoint is responsible for processing both read and write operations for application resources. Prior to the fix, the apiserver processed these requests through a unified handler structure.

During processing, the handler utilized a generic authentication function named stateForRequestAuthenticated. This function verified the existence and basic validity of the requester's authentication token. It successfully confirmed that the requester was a known entity to the Juju controller. However, the function did not assess the contextual authorization required for the specific operation.

The apiserver failed to verify if the authenticated entity possessed explicit Write or Admin permissions for the modeluuid specified in the HTTP path. Consequently, the application state was retrieved and modified based solely on the entity's global authentication status. This decoupled the authorization logic from the logical model boundaries established by the Juju architecture.

Because of this architectural separation failure, an authenticated user could construct a request specifying a target modeluuid they did not own. The apiserver accepted the request, processed the payload, and committed the changes to the internal cache. This flaw effectively nullified the multi-tenant isolation guarantees provided by Juju models.

The remediation, introduced in commit 26ff93c903d55b0712c6fb3f6b254710edb971d4, addresses the authorization bypass through structural separation and rigorous permission checks. The Juju maintainers decoupled the unified resource endpoint. They implemented distinct handlers: ResourcesUploadHandler for HTTP PUT requests and ResourcesDownloadHandler for HTTP GET requests.

// Conceptual representation of the patched routing
if r.Method == http.MethodPut {
    handler = newResourcesUploadHandler(authorizer)
} else if r.Method == http.MethodGet {
    handler = newResourcesDownloadHandler()
}

To secure the upload path, the developers introduced a new resourcesUploadAuthorizer. This component utilizes a CompositeAuthorizer to enforce strict model-scoped checks. The requester must now demonstrate either global ControllerAdmin privileges or explicit WriteAccess permissions on the targeted model. This modification correctly aligns the authorization requirements with the targeted resource path.

// Patched authorization enforcement
func (a *resourcesUploadAuthorizer) Authorize(user user.User, model string) error {
    if !a.hasWriteAccess(user, model) && !a.isControllerAdmin(user) {
        return errors.Forbiddenf("user %s cannot modify resources in model %s", user.Name(), model)
    }
    return nil
}

The patch also includes supplementary defensive measures. The api/httpclient.go file was updated to properly propagate HTTP 401 (Unauthorized) and HTTP 403 (Forbidden) response codes to the client, preventing the masking of access failures. Furthermore, new logic explicitly rejects resource modification attempts targeting synthetic applications, which act as logical proxies rather than concrete workloads.

Exploitation of CVE-2025-68153 requires the attacker to hold valid authentication credentials for the Juju controller. This prerequisite is frequently satisfied by compromising a low-privileged machine agent within any model managed by the controller. Network access to the Juju apiserver is also required to issue the malicious HTTP requests.

The attacker begins by enumerating or predicting the modeluuid of a high-value target model. They must also identify a specific application deployed within that model, such as a Kubernetes control plane component or a secrets management service. With this information, the attacker constructs a malicious payload tailored to the target application's expected resource format, such as a backdoored OCI container image.

The injection phase involves transmitting an HTTP PUT request to the apiserver. The request targets the victim's modeluuid and application name, while utilizing the attacker's legitimate authentication token.

PUT /model/victim-model-uuid/applications/target-app/resources/resource-name HTTP/1.1
Authorization: Bearer attacker-token
Content-Type: application/octet-stream
 
[Malicious Payload Data]

Upon receiving the request, the vulnerable apiserver overwrites the legitimate resource in its cache with the attacker's payload. The execution phase occurs asynchronously. When the target application performs an operation that triggers a resource pull, it retrieves the poisoned resource. This ingestion leads directly to the execution of the attacker's payload within the security context of the target workload.

The vulnerability carries a CVSS 4.0 base score of 7.1, reflecting a High severity rating. The vector CVSS:4.0/AV:N/AC:L/AT:N/PR:L/UI:N/VC:N/VI:H/VA:N/SC:N/SI:N/SA:N highlights the network attack vector and low complexity. The primary impact is assessed entirely within the Integrity dimension (VI:H), as the direct consequence is the unauthorized modification of application resources.

While the base metric evaluates confidentiality as None, the downstream consequences of resource poisoning are severe. By injecting a compromised OCI image or executing a modified binary blob, an attacker achieves remote code execution on the target workload. This execution occurs with the privileges of the compromised application, enabling subsequent data exfiltration, lateral movement, or destruction.

The fundamental security impact is the complete breakdown of Juju's logical isolation model. The architecture assumes that workloads in separate models cannot interfere with one another. CVE-2025-68153 negates this guarantee, allowing an attacker to escalate privileges horizontally across different development environments or vertically into critical production systems.

The primary remediation for CVE-2025-68153 is to upgrade Juju controllers to the fixed versions provided by the vendor. Organizations utilizing the 2.9 branch must upgrade to version 2.9.56. Environments operating on the 3.6 branch require an update to version 3.6.19. Applying these patches enforces the necessary model-scoped authorization checks.

For systems where immediate patching is unfeasible, administrators should aggressively restrict network access to the Juju apiserver. Implementing strict firewall rules to ensure only trusted network segments can reach the management endpoints limits the exposure. Additionally, administrators must review and minimize the permissions granted to machine agents, reducing the likelihood of initial credential compromise.

Security operations teams should implement specific detection mechanisms. Monitoring Juju apiserver access logs is critical. Defenders should trigger alerts on HTTP PUT requests targeting the /model/*/applications/*/resources/* endpoint, specifically analyzing requests where the authenticated entity's associated model does not match the URI path.

To ensure ongoing integrity, organizations should implement automated verification of application resources. Periodically auditing the SHA256 hashes of deployed charm resources against known-good values from Charmhub will detect successful poisoning attempts. This defense-in-depth strategy provides visibility into unauthorized state changes even if the primary boundary is breached.