Juju, Canonical’s open-source tool for deploying and managing applications on clouds and bare metal, has a critical authorization flaw in its controller. Any authenticated user, machine agent, or controller node can overwrite resources—like OCI images or binaries—for any application in any model under that controller. This poisons the resource cache, potentially injecting malware into unrelated workloads.
The vulnerability stems from lax checks in the API handler for resources. Code at commit resources.go L77 only requires basic authentication as a user, machine, or controller. No model-specific permissions or ownership verification follow. The handler registers at paths like /:modeluuid/applications/:application/resources/:resource, as defined in apiserver.go, without a custom authorizer.
How the Exploit Works
To poison a resource, an attacker needs three pieces of info: the target model’s UUID, application name, and resource name. Model UUIDs leak easily—via logs, API responses, or shared controller access. Application names often match public charm names from the Charmhub store. Resource names are equally discoverable there; for example, many charms pull OCI images listed openly.
Once identified, a simple PUT request to the handler uploads arbitrary content, as long as it matches the expected file extension. The code at L219 and resource.go L388 blindly overwrites existing cache entries. No content validation or signature checks block this. A compromised machine agent—common in workload breaches—gains these creds automatically.
No PoC code exists because the flaw is blatant in a static read. Juju 3.x branches, including up to recent releases like 3.5, inherit this if unpatched. Canonical maintains Juju; check your controller version against release notes.
Real-World Impact
This breaks model isolation, Juju’s core promise. Controllers host multiple models for tenants or environments, assuming cross-model firewalls. A single breached workload lets attackers pivot controller-wide.
Consider a Kubernetes operator using Vault for secrets management. Poison its OCI image resource to a malicious Docker image. When the controller deploys or updates Vault pods across models, they run your trojan. Extract Vault tokens, escalate to cloud creds, databases, or lateral moves. Financial firms using Juju for compliance-heavy deploys face amplified risk—think compromised payment gateways or trading bots.
Juju powers Ubuntu deployments at scale: telecoms, telcos like Vodafone, and clouds via MAAS. Per GitHub stats, juju/juju has 2.5k stars, active forks. In multi-model setups (common for dev/staging/prod), exposure multiplies. CVSS? Likely 8.8+ (high privileges via low auth).
Why this matters: Resource poisoning echoes SolarWinds or XZ Utils, but automated via orchestration. Juju’s charm ecosystem—thousands of snaps—amplifies supply chain risks. Attackers don’t need root; machine agents suffice, and breaches hit 30% of containers per recent reports.
Mitigation and Fixes
Isolate models aggressively: spin up dedicated controllers per tenant or high-value model. Revoke machine agent creds on suspicion—rotate via juju kill-controller or model recreation.
Patch ASAP. Canonical hasn’t publicly acknowledged yet, but audit issues. Upstream fix likely adds ownership checks, e.g., authorizer.HasPermission(permission, modelTag). Verify resources with SHA256 hashes post-deploy.
Run juju resources --model <model> --application <app> to inspect. Monitor API logs for anomalous PUTs to resource endpoints. For air-gapped setups, this underscores reviewing agent auth scopes.
Bottom line: Treat Juju controllers as high-value targets. This vuln exposes why orchestration security demands zero-trust auth, not “just logged in.” Upgrade, segment, audit—now.
