Dima Tisnek

**Name of the Vulnerable Software and Affected Versions** Juju versions 3.0.0 through 3.6.18 **Description** Juju’s authorization for the 'secret-set' tool is flawed, allowing a grantee to update secret content. Even when an error is logged during an exploitation attempt, the secret is still updated, and the new value becomes visible to both the owner and the grantee. This can lead to reading or updating other secrets. The issue stems from broad Kubernetes access policy, enabling updates without proper authorization checks. Exploitation does not require additional network access or authentication beyond being a designated grantee. The vulnerability impacts applications owning the secret and any third-party applications with access to the same Kubernetes secret backend. The `secret-set` function is involved in this issue. **Recommendations** Versions prior to 3.0.0 are not affected. Versions 3.0.0 through 3.6.18 are affected. At the moment, there is no information about a newer version that contains a fix for this vulnerability.

**Name of the Vulnerable Software and Affected Versions** Juju versions 3.0.0 through 3.6.18 **Description** Juju versions 3.0.0 through 3.6.18 are susceptible to a confused deputy issue stemming from predictable secret IDs (XIDs). When a secret owner grants permissions to a secret to a grantee, the owner relies solely on the predictable XID to verify ownership. A malicious grantee capable of requesting secrets can predict past secrets granted by the same owner to other grantees, potentially allowing them to utilize resources granted by those previous secrets. Successful exploitation requires a specific configuration, data semantic, and an administrator deploying at least two applications, one controlled by the attacker. The issue arises because the grantee lacks a mechanism to determine the origin of a secret ID, and the IDs are predictable. An attacker can exploit this by passing a secret ID belonging to a legitimate application to a provider application, potentially leading to unauthorized access or modification of resources. The API endpoint used for secret information retrieval is not explicitly mentioned, but the issue involves the handling of secret IDs. The vulnerable parameter is the `secret id` passed to the provider application. **Recommendations** Versions prior to 3.0.0 are not affected. Versions 3.0.0 through 3.6.18 should implement longer, random secret IDs to make guessing sibling secret IDs infeasible. Versions 3.0.0 through 3.6.18 should implement a grantee secret API to allow applications to verify the provenance of secret IDs.