CVE-2026-5774

mediumpriority · track · 26EPSS 0.003 · 22 %ileEUUS
grimoire priorityP3 · Track
Exploitable?
—
no known exploitation
Likely / severe?
0.30% (22nd) EPSS
CVSS 6.4 · medium
Is it mine?
7 products
Check your exposure
Who says so?
4 sources
cnnvd · enisa_euvd · osv · nvd

EPSS · scored 2026-10-24

Improper synchronization of the userTokens map in the API server in Canonical Juju 4.0.5, 3.6.20, and 2.9.56 may allow an authenticated user to possibly cause a denial of service on the server or possibly reuse a single-use discharge token.

01

cvss

Technical severity, 0–10. One row per scoring source.

6.4
010

base score 0–10 · higher = more severe · hover a vector to decode⚠ sources disagree · low–medium · 2.3–6.4

v3.16.4mediumCVSS:3.1/AV:N/AC:H/PR:L/UI:N/S:U/C:L/I:L/A:Hprimary · NVD / NIST USexploitability 1.6 · impact 4.7
v3.16.4mediumCVSS:3.1/AV:N/AC:H/PR:L/UI:N/S:U/C:L/I:L/A:Hsecondary · OSV
v4.06.1mediumCVSS:4.0/AV:N/AC:H/AT:P/PR:L/UI:N/VC:N/VI:N/VA:H/SC:N/SI:N/SA:Nsecondary · ENISA EU
v4.06mediumCVSS:4.0/AV:N/AC:H/AT:P/PR:L/UI:N/VC:N/VI:N/VA:H/SC:N/SI:N/SA:N/E:X/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:Xsecondary · security@ubuntu.com
v4.02.3lowCVSS:4.0/AV:N/AC:H/AT:P/PR:L/UI:N/VC:N/VI:N/VA:H/SC:N/SI:N/SA:N/E:U/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:Xsecondary · CVSS-BT (t0sche)
02

ssvc

A stakeholder decision — act, attend, or track — from exploitation and impact.

Exploitation: poc · Automatable: no · Technical Impact: partialcoordinatorcisa_ssvcUS
03

weaknesses

The CWE weakness classes this flaw belongs to.

04

affected products (7)

Products and version ranges known to be affected.

05

advisories (2)

Vendor and ecosystem advisories describing this.

  • GHSA-7m55-2hr4-pw78Juju: In-Memory Token Store for Discharge Tokens Lacks Concurrency Safety and Persistence2026-04-10ghsa · osvUS

    ### Summary The localLoginHandlers struct in the Juju API server maintains an in-memory map to store discharge tokens following successful local authentication. This map is accessed concurrently from multiple HTTP handler goroutines without any synchronization primitive protecting it. The absence of a mutex or equivalent mechanism means that concurrent reads, writes, and deletes on the map can trigger Go runtime panics and may allow a discharge token to be consumed more than once before deletion completes. ### Details When a user authenticates through the local login flow, a discharge token is generated and stored in a plain `map[string]string` field named userTokens. The form handler writes to this map when authentication succeeds, and the third-party caveat checker reads from and deletes from the same map when a discharge request arrives. Both code paths execute inside goroutines dispatched by the HTTP server, meaning concurrent requests will access the map simultaneously. Go's runtime detects concurrent map access and will terminate the process with a fatal error when a write races with another write or read. This makes the API server susceptible to a denial-of-service attack from any authenticated user who can trigger simultaneous discharge requests. Beyond the crash scenario, the read-then-delete sequence in the caveat checker is not atomic. Two goroutines processing the same token concurrently may both pass the existence check before either executes the deletion, allowing a single-use discharge token to be accepted more than once and effectively replaying authentication. The struct definition that introduces the unsafe field is shown below. ```go type localLoginHandlers struct { authCtxt *authContext userTokens map[string]string } ``` The concurrent access originates from the caveat checker calling `username, ok := h.userTokens[tokenString]` followed by `delete(h.userTokens, tokenString)` with no lock held, while formHandler concurrently executes `h.userTokens[token] = username` in a separate goroutine. ### PoC ```go package main import ( "net/http" "sync" ) func main() { token := "acquired-discharge-token" endpoint := "https://target-juju-api:17070/local-login/discharge" var wg sync.WaitGroup for i := 0; i < 20; i++ { wg.Add(1) go func() { defer wg.Done() req, _ := http.NewRequest("GET", endpoint+"?token="+token, nil) http.DefaultClient.Do(req) }() } wg.Wait() } ``` ### Impact Any authenticated user who obtains a valid discharge token can send a burst of concurrent requests to the discharge endpoint. The most reliable outcome is a Go runtime panic caused by concurrent map access, which terminates the Juju API server process and denies service to all connected clients and agents. Under favorable timing conditions the same token may be accepted by multiple goroutines before deletion, bypassing the single-use enforcement and allowing repeated authentication with a token that should have been invalidated after first use.

  • GO-2026-5228Juju: In-Memory Token Store for Discharge Tokens Lacks Concurrency Safety and Persistence in github.com/juju/juju2026-06-25vendor · osvUS

    Juju: In-Memory Token Store for Discharge Tokens Lacks Concurrency Safety and Persistence in github.com/juju/juju

06

also known as (5)

Other names and identifiers for this entity.

07

sources

Which sources assert this record, and when.

published 2026-04-10modified 2026-06-17
08

references (10)

External citations — patches, advisories, analysis.

scry

Attackers weaponise vulnerabilities like this against internet-exposed services. See what is exposed on your perimeter with a free passive scan.

Free scan