CVE-2026-55513

MEDIUMPre-NVD 5.45.4
EchelonGraph scoreLOW confidence

This medium-severity CVE scores 5.4 under the CNA's CVSS (NVD's own analysis pending). EPSS exploit-prediction score not yet available (the EPSS model rescores nightly; freshly-published CVEs typically appear within 48 hours). GitHub Security Advisory data not yet ingested — confidence will rise once GHSA publishes (typical lag: hours to days for open-source ecosystem CVEs; never for infrastructure-only CVEs).

Triggered by: NVD CVSS baseline
Sources: cna:github_m
5.4
EchelonGraph verdictMonitorLow exploitation likelihood right now — keep watching.
  • Lower severity and no public exploit yet
CISA-KEV: Not listedEPSS: CVSS: 5.4Exploit: NoneExposed: 0

No vendor fix yet — apply a workaround or compensating control (WAF / firewall / segmentation) and watch for a patch.

nebula-mesh: Web UI host creation ignores configured enrollment token TTL and mints 24-hour bearer enrollment tokens

Summary

The nebula-mgmt Web UI host-creation path ignores both the server-wide enrollment_token_ttl security setting and per-network network_config.enrollment_token_ttl overrides. API host creation and token-regeneration paths use the configured TTL resolver, but POST /ui/hosts hardcodes now.Add(24 * time.Hour) for newly minted agent enrollment tokens. In deployments that intentionally reduce enrollment-token lifetime, any authenticated operator who can create a host through the Web UI can still mint a bearer enrollment token valid for about 24 hours.

Details

Enrollment tokens are bearer credentials for the public POST /api/v1/enroll endpoint: possession of a valid token allows enrolling the pending host and receiving a signed Nebula certificate/config for that host. The server configuration documents a security knob for their default lifetime and per-network overrides:
  • internal/config/server.go:82 defines EnrollmentTokenTTL as the default lifetime for freshly minted enrollment tokens.
  • internal/config/server.go:83 documents per-network overrides in network_config under enrollment_token_ttl.

The API server implements and consistently uses this resolver:

  • internal/api/server.go:77 defines tokenTTLFor, with precedence of per-network enrollment_token_ttl, then server default, then 24h fallback.
  • internal/api/server.go:82 reads network_config.enrollment_token_ttl.
  • internal/api/server.go:89 falls back to the configured server default.
  • internal/api/hosts.go:190 through internal/api/hosts.go:196 use now.Add(s.tokenTTLFor(r.Context(), host.NetworkID)) for API host creation.

The Web UI sibling path does not call the resolver and instead always sets a 24-hour expiry:

  • internal/web/handlers.go:874 mints the raw token for POST /ui/hosts.
  • internal/web/handlers.go:879 sets ExpiresAt: now.Add(24 * time.Hour).

This creates inconsistent behavior between API and Web UI host creation and bypasses an operator-configured token lifetime policy. The issue is reachable by an authenticated Web UI operator who can create hosts. Admins can create hosts in any network; non-admin operators can create hosts in networks whose CA they own.

Affected version evidence: the configurable enrollment-token TTL feature was introduced by commit 6c344a6 (feat(api): configurable enrollment-token TTL + regenerate endpoint (#75) (#79)), and git tag --contains 6c344a6 --sort=version:refname returns v0.3.0 through v0.3.8. Pattern checks across all release tags showed the TTL config/API resolver and the Web UI 24-hour hardcode are present in every v0.3.x release from v0.3.0 to v0.3.8, and are not meaningfully applicable to v0.1.x/v0.2.0 because the TTL policy knob was not present there. The current checkout at commit d92dd9a60de291e2bc1caf73b4e9a99567b31ec0 (git describe: v0.3.8-1-gd92dd9a) remains affected.

PoC

Safe local PoC run from a clean checkout at commit d92dd9a60de291e2bc1caf73b4e9a99567b31ec0 on 2026-06-12. The PoC is a temporary Go test that uses only in-memory SQLite and httptest; it does not start a real server and does not contact external services.
  • Create a temporary test file internal/web/security_audit_poc_test.go in package web.
  • In the test, create an in-memory Web UI with newTestWeb(t), create a network audit-poc-net with CIDR 10.77.0.0/24, and set network_config.enrollment_token_ttl to 30m.
  • Log in as the seeded test admin through the normal Web UI helper and obtain a CSRF token from GET /ui/hosts/new.
  • Submit POST /ui/hosts with network_id=audit-poc-net, name=audit-poc-host, nebula_ips=10.77.0.10, role=host, and kind=agent.
  • Parse the one-shot enrollment token from the returned host-detail page and read the token row with GetEnrollmentToken.
  • Compare the observed expiry to the configured 30-minute network override.

Command run:

go test ./internal/web -run 'TestSecurityAuditPOC' -count=1 -v

Observed vulnerable output from this environment:

=== RUN   TestSecurityAuditPOC_UIHostCreateIgnoresNetworkEnrollmentTokenTTL
POC_UI_TTL_BYPASS observed_token_ttl=24h0m0s configured_network_ttl=30m expires_at=2026-06-13T14:51:45Z
--- PASS: TestSecurityAuditPOC_UIHostCreateIgnoresNetworkEnrollmentTokenTTL (0.05s)

The meaningful control is the API sibling: internal/api/hosts.go:190 through internal/api/hosts.go:196 uses s.tokenTTLFor(...), and existing tests in internal/api/hosts_token_ttl_test.go verify API-created/regenerated enrollment tokens honor server-default and per-network TTLs. Variant review also found API regenerate-token, API re-enroll, and signed-poll rekey token minting use the resolver rather than a hardcoded 24h value. After recording the output, the temporary test file was removed and git status --short returned clean. The PoC was re-run after drafting this report and produced the output shown above.

Impact

An authenticated Web UI operator can bypass a configured enrollment-token lifetime policy and obtain a token valid for approximately 24 hours even when the deployment or network is configured for a much shorter lifetime such as 30 minutes. Because enrollment tokens are bearer credentials for the public enrollment endpoint, longer-than-intended validity increases the window in which a copied, logged, shared, or otherwise exposed token can be used to enroll the pending host and obtain its Nebula certificate/config. This weakens confidentiality and integrity for deployments relying on short token lifetimes to reduce enrollment-token exposure.

Suggested remediation: refactor the Web UI host-creation path to use the same TTL resolution as the API path, or move the resolver into a shared package/service used by both API and Web UI. Add a regression test under internal/web that sets network_config.enrollment_token_ttl = "30m", creates an agent host through POST /ui/hosts, and asserts the persisted enrollment token expires within the configured 30-minute window rather than 24 hours.

CVSS v3
5.4
EG Score
5.4(low)
EPSS
KEV
Not listed

Published

July 14, 2026

Last Modified

July 14, 2026

Vendor Advisories for CVE-2026-55513(1)

These vendors published their own advisory mentioning this CVE — often with vendor-specific remediation steps + affected product lists not in NVD.

Data Freshness Timeline

(refreshed 2× in last 7d / 2× in last 30d)

Each row is a source pipeline that fetched or updated this CVE on that date, with what changed. For example, "NVD update" means NVD published or revised its analysis for this CVE; "MITRE cvelistV5" means we ingested or refreshed it from the CNA feed. Most recent first.

  1. 2026-07-15 22:05 UTCEG score recompute
  2. 2026-07-14 20:56 UTCEG score recompute

Frequently asked(4)

What is CVE-2026-55513?
CVE-2026-55513 is a medium vulnerability published on July 14, 2026. nebula-mesh: Web UI host creation ignores configured enrollment token TTL and mints 24-hour bearer enrollment tokens Summary The nebula-mgmt Web UI host-creation path ignores both the server-wide enrollmenttokenttl security setting and per-network networkconfig.enrollmenttoken_ttl overrides. API…
When was CVE-2026-55513 disclosed?
CVE-2026-55513 was first published in the National Vulnerability Database on July 14, 2026. EchelonGraph re-ingests CVE updates from NVD on a 2-hour cycle, so this page reflects the latest published state.
What is the CVSS score of CVE-2026-55513?
CVE-2026-55513 has a CVSS v4.0 base score of 5.4 (CNA self-assessment; NVD's own analysis pending). The EG score is currently aggregating — additional source signals are being incorporated as they become available..
How do I remediate CVE-2026-55513?
Patch to the fixed version published by the affected vendor. Where vendor advisories exist for CVE-2026-55513, EchelonGraph cross-links them in the Vendor Advisories panel below — those typically contain the canonical remediation steps, fixed version numbers, and any vendor-specific mitigations.

Dependency Blast Radius

Explore the affected products and dependency analysis for CVE-2026-55513

Explore →

Is Your Infrastructure Affected by CVE-2026-55513?

EchelonGraph automatically scans your cloud infrastructure and maps CVE exposure using blast radius analysis.