CVE-2026-32694: 
NixOS vulnerability analysis and mitigation

CVE-2026-32694 is a Confused Deputy / Insecure Direct Object Reference (IDOR) vulnerability in Canonical's Juju application orchestration framework, caused by the use of predictable XID-based secret identifiers. Affecting Juju versions 3.0.0 through 3.6.18, it allows a malicious grantee application to predict secret IDs previously granted by the same secret owner to other grantees, and then abuse those secrets to access or manipulate resources they were not authorized to use. The vulnerability was published on March 18, 2026, with a patch released in version 3.6.19. It carries a CVSS v3.1 base score of 6.6 (Medium), reflecting high attack complexity and the requirement for elevated privileges (GitHub Advisory, Github Advisory).

The root cause is twofold: Juju secret IDs are generated using XIDs (CWE-343: Predictable Value Range from Previous Values), which encode a timestamp, machine ID, process ID, and a monotonic counter — making them highly predictable for secrets created close in time on the same host. Additionally, Juju provides no API for a grantee (Provider application) to verify the provenance or owner of a secret ID it receives, enabling an authorization bypass through user-controlled keys (CWE-639). An attacker controlling a malicious application (Evil) that is integrated with the same Provider as a legitimate application (Good) can observe or infer the XID of Good's secret, then pass that secret ID to the Provider as if it were their own, causing the Provider to perform operations using Good's credentials or resources on Evil's behalf. Exploitation requires a specific multi-application deployment topology where both a legitimate and a malicious application are related to the same third-party Provider application (GitHub Advisory).

If successfully exploited, a malicious grantee application can exfiltrate secrets belonging to a legitimate application, read or mutate resources accessible via those secrets, and effectively impersonate the legitimate application's identity within the Juju model. The impact spans confidentiality (secret content exposure), integrity (unauthorized resource mutation), and availability (potential disruption of workloads dependent on those secrets). Because the attack is mediated through a trusted Provider application acting as a confused deputy, forensic attribution after the fact is extremely difficult (GitHub Advisory, Github Advisory).

No confirmed in-the-wild exploitation has been observed, and no runnable exploit code is publicly available — the GitHub Security Advisory describes the attack mechanics conceptually but does not provide actionable exploit steps targeting a real deployment (GitHub Advisory). The EPSS score is approximately 0.06% (19th percentile), indicating a low near-term exploitation probability. The vulnerability is not listed in the CISA Known Exploited Vulnerabilities (KEV) catalog. Exploitation requires high privileges (control of a deployed application), high attack complexity (specific multi-app topology), and precise timing to predict XID values, significantly limiting the realistic attacker pool (Github Advisory).

1. Reconnaissance: Identify a target Juju deployment (versions 3.0.0–3.6.18) where a legitimate application (Good) and an attacker-controlled application (Evil) are both integrated with the same Provider application via Juju relations.
2. Establish relation: Deploy the Evil application and integrate it with the Provider application, obtaining a legitimate secret grant from the Provider relationship.
3. Observe XID structure: Note the XID-format secret ID received by the Evil application (e.g., d34vslfmp25c76301hsg), which encodes timestamp, machine ID, PID, and counter.
4. Predict sibling secret IDs: Using knowledge of XID generation (timestamp + machine ID + PID + monotonic counter), enumerate nearby XID values to identify the secret ID that the Good application likely communicated to the Provider around the same time.
5. Inject predicted secret ID: Pass the predicted secret ID (belonging to Good) to the Provider application via the Evil application's relation databag, as if it were Evil's own secret.
6. Trigger confused deputy action: The Provider, lacking any API to verify secret provenance, reads or acts on Good's secret on behalf of Evil — potentially exfiltrating Good's secret content or mutating resources accessible via Good's credentials (GitHub Advisory).

• Logs: Juju audit logs showing a secret ID associated with one application (Good) being accessed or referenced within the relation databag of a different application (Evil); unexpected secret-get or secret-info-get hook tool invocations referencing secret IDs not granted to the calling unit.
• Juju Model State: Secret access events where the accessing application's relation does not match the relation through which the secret ID was originally communicated; Provider application performing operations using secrets owned by an unexpected application.
• Behavioral: Unusual or unexpected resource access patterns originating from the Provider application that correlate with credentials or secrets belonging to the Good application; discrepancies between the secret owner recorded in Juju state and the application that passed the secret ID to the Provider (GitHub Advisory).

Upgrade Juju to version 3.6.19 or later, which addresses the vulnerability (the fix commit is d06919e) (Github Advisory). As an interim measure, administrators should audit all secret grants in their Juju models and avoid deploying untrusted applications that receive secret grants alongside trusted applications related to the same Provider. Restricting which applications can be integrated with shared Provider applications reduces the attack surface until patching is complete. The advisory also recommends that future Juju versions adopt longer, cryptographically random secret IDs (e.g., 128-bit nonces) and introduce a grantee secret API allowing Providers to verify secret provenance (GitHub Advisory).

The vulnerability was reported by researcher dimaqq and coordinated by hpidcock from the Juju project. An analysis was published by Infinit Security describing it as an IDOR attack via predictable secret IDs in Juju. The openSUSE security announce list and Linux Security also covered the issue in the context of downstream package advisories. Overall community reaction has been measured, reflecting the high exploitation complexity and the availability of a patch.