CVE-2026-1237: 
vulnerability analysis and mitigation

CVE-2026-1237 is a broken Cross-Model Relation (CMR) authorization vulnerability in Canonical's Juju orchestration framework, allowing a malicious user to forge macaroon tokens and maintain otherwise revoked or expired cross-model permissions. It affects Juju versions 2.9.x, 3.6.x, and 4.x (Go module github.com/juju/juju up to and including 0.0.0-20260127110037-9b1a0e53a4a4). The vulnerability was published on January 28, 2026, and assigned a CVSS v4 base score of 2.1 (Low) (GitHub Advisory, Red Hat CVE).

The root cause is twofold: improper verification of cryptographic signatures (CWE-347) and continued operation on expired or revoked resources (CWE-672). When the Juju controller cannot locate the root key to verify a macaroon — either because the key is absent or the macaroon has expired — it falls back to extracting declared caveats from the unvalidated (and therefore untrusted) macaroon and blindly uses those facts to mint a new, valid macaroon. An attacker who knows that user X has access to offer Y can craft a macaroon asserting this fact; the controller, failing to verify it, issues a fresh valid macaroon via a discharge endpoint that requires no authentication, effectively granting the attacker access as user X. Exploitation requires adjacent network access, low-level privileges, and the ability to interact with the Juju controller's macaroon discharge endpoint (GitHub Advisory, Juju Security Advisory).

Successful exploitation allows a malicious actor to impersonate a legitimate user and consume cross-model relation offers without proper authorization, even after permissions have been explicitly revoked or have expired. This results in low-level confidentiality, integrity, and availability impacts on both the vulnerable Juju system and any subsequent systems connected via cross-model relations. A compromised or malicious charm could indefinitely maintain access to another charm's workload, potentially enabling unauthorized data access or service manipulation across model boundaries (GitHub Advisory, Feedly).

There is no public proof-of-concept exploit and no evidence of in-the-wild exploitation at the time of writing (Feedly). The vulnerability is not listed in the CISA Known Exploited Vulnerabilities catalog. The EPSS score is approximately 0.012% (2nd percentile), indicating a very low probability of exploitation in the near term (GitHub Advisory). No threat actor attribution has been reported.

1. Reconnaissance: Identify a Juju deployment with cross-model relations (CMR) enabled and determine a target offer (offer Y) that a known user (user X) has or had access to. Confirm the Juju controller is reachable from an adjacent network position.
2. Craft a malicious macaroon: Mint a macaroon containing declared caveats asserting that user X has access to offer Y. This does not require knowledge of any root key — the macaroon is intentionally unverifiable by the controller.
3. Submit the macaroon to the controller: Send the crafted macaroon to the Juju controller in a cross-model relation request. The controller attempts to verify the macaroon, fails (due to missing root key or expiry), and falls back to extracting the declared caveats.
4. Trigger macaroon discharge: The controller mints a new macaroon requiring proof that user X has access to offer Y and contacts the discharge endpoint. Since the discharge endpoint does not require authentication and user X legitimately has (or had) access, the discharge succeeds.
5. Receive and use the valid macaroon: The controller returns a newly minted, valid macaroon to the attacker. The attacker uses this macaroon to consume the offer as user X, maintaining cross-model relation access even if permissions were revoked (Juju Security Advisory, GitHub Advisory).

• Network: Unexpected or repeated requests to the Juju controller's macaroon discharge endpoint from unfamiliar sources or low-privilege accounts; cross-model relation traffic originating from charms whose permissions were previously revoked.
• Logs: Juju controller logs showing macaroon verification failures followed immediately by successful discharge and issuance of new macaroons for the same user/offer pair; repeated authorization attempts for offers where permissions have been revoked.
• Application: Cross-model relations remaining active or re-establishing after explicit permission revocation; charms continuing to interact with offers they should no longer have access to.

No official patch is available for any affected version (2.9.x, 3.6.x, 4.x) as of the time of writing (Juju Security Advisory). Recommended interim mitigations include: implementing strict database access controls to prevent unauthorized modification of macaroon-related records; restricting network access to the Juju controller and its discharge endpoint to trusted adjacent hosts only; auditing and monitoring cross-model relation states and charm authorization logs for anomalous persistent access; and considering disabling cross-model relations where not strictly necessary until a patch is released (Feedly). A proposed fix exists as a pull request in the juju/juju repository but has not been merged due to compatibility concerns with model migrations.

Red Hat has acknowledged the vulnerability and published a CVE entry (Red Hat CVE). The advisory was authored by researcher korhlibri and published via the juju/juju GitHub security advisory process. No significant broader media coverage or notable community commentary beyond standard vulnerability database aggregation has been observed.