GHSA-245V-P8FJ-VWM2
Vulnerability from github – Published: 2026-04-03 18:29 – Updated: 2026-04-06 17:37Summary
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. 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. The handler defines no authorizer as supported by the handler struct here.
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, one is now allowed free rein for 'PUT' and 'GET' methods to the handler. This security report will only focus on 'PUT' as it is the most interesting. The 'PUT' handler will gladly take whatever is uploaded to it as long as it has the same file extension defined by the resource.
If the resource already exists in the controller's cache, it will be uploaded with whatever is supplied by the upload, see here and here.
That is it. One can successfully poison the resource cache for any model in the controller.
PoC
A proof of concept has not been done for this because it is so obvious from the code read that it is not deemed necessary.
A realistic example of how this can be used: if there is a compromised workload in Juju that has machine credentials, then one can modify the OCI resources for any other model in the controller. For example, if the controller was running a k8s vault, one could change the docker image in use to a trojan horse version that allows obtaining root access to all the vault secrets.
Once this poison has been performed, the attacker can then leverage the vault secrets to go other places.
Impact
Any charm deployment where a resource could be modified to inject security vulnerabilities into another workload. The most obvious is OCI containers as one gets execution escalation, but if a file resource had security controls in it, this could also be leveraged. For the file case, this would need to be examined on a case-by-case basis.
{
"affected": [
{
"package": {
"ecosystem": "Go",
"name": "github.com/juju/juju"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "0.0.0-20260120044552-26ff93c903d5"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2025-68153"
],
"database_specific": {
"cwe_ids": [
"CWE-863"
],
"github_reviewed": true,
"github_reviewed_at": "2026-04-03T18:29:54Z",
"nvd_published_at": "2026-04-03T16:16:23Z",
"severity": "HIGH"
},
"details": "### Summary\nAny authenticated user, machine or controller under a Juju controller can modify the resources of an application within the entire controller.\n\nThis one is very straightforward to just read in the code:\n\n**Step 1:**\nThe 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.\n\nThis 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).\n\nOne needs to know the following three bits of information to poison the resource cache on the controller:\n- model uuid\n- application name in the model\n- resource name in the model\n\nGiven 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.\n\n**Step 2:**\nIf one passes the very basic authz check of step 1, one is now allowed free rein for \u0027PUT\u0027 and \u0027GET\u0027 methods to the handler. This security report will only focus on \u0027PUT\u0027 as it is the most interesting. The \u0027PUT\u0027 handler will gladly take whatever is uploaded to it as long as it has the same file extension defined by the resource.\n\nIf the resource already exists in the controller\u0027s cache, it will be uploaded with whatever is supplied by the upload, see [here](https://github.com/juju/juju/blob/1a8d84ec114c2e4f9921e30081e5a5549f7cbfc4/apiserver/internal/handlers/resources/resources.go#L219) and [here](https://github.com/juju/juju/blob/1a8d84ec114c2e4f9921e30081e5a5549f7cbfc4/domain/resource/service/resource.go#L388).\n\nThat is it. One can successfully poison the resource cache for any model in the controller.\n\n### PoC\nA proof of concept has not been done for this because it is so obvious from the code read that it is not deemed necessary.\n\nA realistic example of how this can be used: if there is a compromised workload in Juju that has machine credentials, then one can modify the OCI resources for any other model in the controller. For example, if the controller was running a k8s vault, one could change the docker image in use to a trojan horse version that allows obtaining root access to all the vault secrets.\n\nOnce this poison has been performed, the attacker can then leverage the vault secrets to go other places.\n\n### Impact\nAny charm deployment where a resource could be modified to inject security vulnerabilities into another workload. The most obvious is OCI containers as one gets execution escalation, but if a file resource had security controls in it, this could also be leveraged. For the file case, this would need to be examined on a case-by-case basis.",
"id": "GHSA-245v-p8fj-vwm2",
"modified": "2026-04-06T17:37:41Z",
"published": "2026-04-03T18:29:54Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/juju/juju/security/advisories/GHSA-245v-p8fj-vwm2"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-68153"
},
{
"type": "WEB",
"url": "https://github.com/juju/juju/commit/26ff93c903d55b0712c6fb3f6b254710edb971d4"
},
{
"type": "PACKAGE",
"url": "https://github.com/juju/juju"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "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",
"type": "CVSS_V4"
}
],
"summary": "Juju has a resource poisoning vulnerability"
}
Sightings
| Author | Source | Type | Date |
|---|
Nomenclature
- Seen: The vulnerability was mentioned, discussed, or observed by the user.
- Confirmed: The vulnerability has been validated from an analyst's perspective.
- Published Proof of Concept: A public proof of concept is available for this vulnerability.
- Exploited: The vulnerability was observed as exploited by the user who reported the sighting.
- Patched: The vulnerability was observed as successfully patched by the user who reported the sighting.
- Not exploited: The vulnerability was not observed as exploited by the user who reported the sighting.
- Not confirmed: The user expressed doubt about the validity of the vulnerability.
- Not patched: The vulnerability was not observed as successfully patched by the user who reported the sighting.