Skip to content

GHSA-gfgr-6hrj-85ww CVE-2026-32691 GO-2026-4769

Juju affected by timing ownership claim attack on new external back-end secrets

Medium Go
Severity
5.3 / 10
Medium · CVSS 3.1
Exploit chance (EPSS)
0.24%
Chance of exploitation in the next 30 days. Higher than 15.39% of scored vulnerabilities.
Known exploited
No
Not in CISA's catalog
Weakness
CWE-708 Incorrect Ownership Assignment
Fix
3.6.19
Upgrade github.com/juju/juju to this version or later

Description

A race condition in the secrets management subsystem of Juju versions 3.0.0 through 3.6.18 allows an authenticated unit agent to claim ownership of a newly initialized secret. Between generating a Juju Secret ID and creating the secret's first revision, an attacker authenticated as another unit agent can claim ownership of a known secret. This leads to the attacking unit being able to read the content of the initial secret revision.

Impact

Between generating a Secret ID and creating the secret's first revision, an attacker authenticated as another unit agent can claim ownership of a known secret. This leads to the attacking unit being able to read the content of the initial secret revision.

Patches

3.6.19

Affected versions

Go

PackageVulnerableFixed in
github.com/juju/juju
>= 3.0.0, < 3.6.19
3.6.19
github.com/juju/juju
all versions
No fix yet

How to fix

Move to the fixed version or later with your package manager, update the lockfile, and run your tests. If the package only arrives through another dependency, upgrade that dependency first. If none of its releases pulls a fixed version yet, force the version with your package manager's override.

github.com/juju/juju Go → 3.6.19

go
go get github.com/juju/juju@v3.6.19 && go mod tidy

Severity breakdown

CVSS 3.1 5.3

CVSS:3.1/AV:N/AC:H/PR:L/UI:N/S:U/C:H/I:N/A:N

Attack vector
Network
Attack complexity
High
Privileges required
Low
User interaction
None
Scope
Unchanged
Confidentiality
High
Integrity
None
Availability
None

Weakness

CWE-708: Incorrect Ownership Assignment

The product assigns an owner to a resource, but the owner is outside of the intended control sphere.

How to prevent it
  • Policy: Periodically review the privileges and their owners.

References

Timeline

  1. Published
  2. Last updated by the source
  3. Latest EPSS score
AdvisorySeverityWhy it's related
GHSA-7m55-2hr4-pw78
Juju: In-Memory Token Store for Discharge Tokens Lacks Concurrency Safety and Persistence
Medium Also affects github.com/juju/juju
GHSA-w5fq-8965-c969
Juju: CloudSpec method leaking cloud credentials
Medium Also affects github.com/juju/juju
GHSA-245v-p8fj-vwm2
Juju has a resource poisoning vulnerability
Medium Also affects github.com/juju/juju
GHSA-j6f6-jp3p-53mw
Juju: Read All Controller Logs From Compromised Workload
Medium Also affects github.com/juju/juju
GHSA-gvrj-cjch-728p
Juju has Improper TLS Client/Server authentication and certificate verification on Database Cluster
Critical Also affects github.com/juju/juju
GHSA-5cj2-rqqf-hx9p
Juju affected by Confused Deputy IDOR attack via Predictable user specified ID in Juju Secrets
Medium Also affects github.com/juju/juju
GHSA-439w-v2p7-pggc
Juju has unauthorized access to out-of-scope Kubernetes secrets
High Also affects github.com/juju/juju
GHSA-89x7-5m5m-mcmm
Juju has unauthorized update of out-of-scope Vault secrets
Medium Also affects github.com/juju/juju
Is this in your code?

MergeHarbor checks every repository's dependencies against this database, ranks what matters by exploitability and reachability, routes it to the owning team and opens the fix pull request.

Check your repos with MergeHarbor