CVE-2026-53603

nebula-mesh: Operator session tokens stored in plaintext in the database

Workarounds

Restrict and encrypt database backups; rotate the operator database. These mitigate exposure but do not fix the underlying storage of plaintext tokens.

Resources

• internal/models/operator.go:58-66
• internal/store/sqlite_operators.go:577-698
• Migration 005_operators.up.sql:27
• Prior related advisory: GHSA-ghmh-jhmj-wcmf

Operator session tokens are stored in plaintext in the operator_sessions table (the token column is the PRIMARY KEY). The session token is a 32-byte random hex value sent directly in a cookie and valid for 24 hours.

• internal/models/operator.go:61, OperatorSession.Token holds the plaintext token.
• internal/store/sqlite_operators.go:590, CreateOperatorSession inserts sess.Token verbatim.
• internal/store/sqlite_operators.go:603,642,681,698, lookups/updates/deletes use WHERE token = ? against the plaintext value.

Anyone who can read the database (backup, snapshot, file copy, or SQL-level disclosure) obtains every active session token and can hijack operator sessions directly, with no further authentication.

This is functionally identical to the plaintext enrollment-token issue fixed in GHSA-ghmh-jhmj-wcmf. API keys (OperatorAPIKey.KeyHash) and enrollment tokens (EnrollmentToken.TokenHash) already store only a SHA256 hash; session tokens were missed.

Kodem intelligence

Already deployed Kodem?

Store only a SHA256 hash of the session token, mirroring API keys and enrollment tokens:

1. Add a HashSessionToken helper (alongside the existing token-hash helpers).
2. Migration to add a token_hash column.
3. Update CreateOperatorSession, PromoteOperatorSession, and GetOperatorBySession to write/look up by hash.
4. Drop the plaintext token column in a follow-up migration.

Sessions are ephemeral (24h TTL), so all active sessions can be invalidated on deployment, no backward compatibility needed.

1. What is CVE-2026-53603? CVE-2026-53603 is a high-severity security vulnerability in github.com/forgekeep/nebula-mesh (go), affecting versions <= 0.3.7. It is fixed in 0.3.8.
2. Which versions of github.com/forgekeep/nebula-mesh are affected by CVE-2026-53603? github.com/forgekeep/nebula-mesh (go) versions <= 0.3.7 is affected.
3. Is there a fix for CVE-2026-53603? Yes. CVE-2026-53603 is fixed in 0.3.8. Upgrade to this version or later.
4. Is CVE-2026-53603 exploitable, and should I be worried? Whether CVE-2026-53603 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
5. What actually determines whether CVE-2026-53603 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.
6. How do I fix CVE-2026-53603? Upgrade github.com/forgekeep/nebula-mesh to 0.3.8 or later.

Other vulnerabilities in github.com/forgekeep/nebula-mesh