Your RSA-2048 keys break in 2030. Find every one of them before attackers do.
🐹
🐹 Go
Not in CISA KEV
HIGH severity

CVE-2026-107807 — Nginx-UI

HIGHFix: 0xJacky/nginx-ui@a3999bd

CVE-2026-107807 is a high-severity (CVSS 8.8) CWE-312 vulnerability in github.com/0xJacky/Nginx-UI. A fix is available for github.com/0xJacky/Nginx-UI — see the affected versions and patch details below.

Nginx UI: Node Secret Credential Exposure via URL Query Parameter

Also known asGHSA-pvgv-gcp7-v38gGO-2026-6708
Published
Updated
Affected
1 pkg
Patched
1 / 1
Exploits
None indexed
Exploitation data as of Oct 24, 2026 · OSV.dev, NVD, FIRST.org (EPSS)

Exploitation Status

Proof-of-concept exploit code exists

  • CISA’s SSVC triage found public proof-of-concept exploit code for this CVE, though no confirmed active exploitation.
  • A successful exploit gives an attacker total control of the affected component, not partial access.

Exploitation and automatability from CISA’s SSVC triage for CVE-2026-107807.

EPSS Exploitation Probability

via FIRST.org ↗
0.3%probability of exploitation in next 30 days
Lower Risk0.00%
Lower risk than most CVEs21th percentile — riskier than 21% of all scored CVEsHighest risk

Probability of exploitation in the next 30 days, from FIRST.org EPSS.

How urgent is this, really

CVE-2026-107807 by exploitation likelihood (EPSS) against impact (CVSS). Outside the shaded patch-first corner.

Where this sits among everything scored

Of 394,803 CVEs with a current EPSS score, this one falls in the < 10% band (highlighted). Counts from FIRST.org, log-scaled.

Real-World Exposure

1 pkg affected
🐹github.com/0xJacky/Nginx-UI

Real-time download stats are indexed for npm and PyPI packages. This vulnerability affects Go packages — download data is not available via public APIs for these ecosystems.

Description

1. Vulnerability Summary

nginx-ui's Node.Secret is a master credential that bypasses all JWT/password authentication for the entire API. The application accepts this credential via a URL query parameter (?node_secret=), causing it to be recorded in plaintext in HTTP access logs, reverse proxy logs, browser history, and HTTP Referer headers. Additionally, the official cluster configuration format embeds node secrets directly into URL query strings stored in app.ini and environment variables, creating a systemic credential exposure pattern across the entire cluster deployment model.

An attacker who gains read access to any log aggregation system, proxy log, or configuration file can extract the node secret and obtain full, persistent, unauthenticated administrative access to the nginx-ui API — including reading TLS private keys, modifying nginx configurations, and (when chained with Bug #1) achieving OS-level code execution.


2. Root Cause Analysis

2.1 Node Secret Accepted as URL Query Parameter

The getNodeSecret function reads the credential from the URL query string as a fallback when the X-Node-Secret header is absent: 1

This function is called in both AuthRequired() and AuthRequiredWS() middleware, meaning the query parameter bypass works for all authenticated HTTP and WebSocket endpoints: 2 3

The same pattern is repeated in the WebSocket origin checker, which also reads node_secret from the URL: 4

2.2 Node Secret Is a Full Authentication Bypass

The documentation explicitly states this is by design: 5

When the secret matches, the middleware sets the request context to an admin-level init user and calls c.Next() — bypassing all JWT validation, session checks, and 2FA: 2

2.3 Cluster Configuration Embeds Node Secrets in URLs

The official cluster configuration format, documented and used in app.example.ini, stores node secrets as URL query parameters: 6

The parseNodeUrl function extracts the secret from the URL's query string and stores it in the database as the node's Token field: 7

This means node secrets are embedded in:

  • app.ini on disk (readable by any process with filesystem access)
  • The NGINX_UI_CLUSTER_NODE environment variable (visible in ps aux, Docker inspect, Kubernetes pod specs, CI/CD logs)
  • The SQLite database nodes table as the token column in plaintext

2.4 Node Secret Generation Uses UUID

The secret is auto-generated as a UUID v4 if not set: 8

UUID v4 has 122 bits of entropy, which is adequate. However, the exposure surface described in this report makes entropy irrelevant — the secret is leaked through operational channels, not brute-forced.


3. Exposure Surface

The following table maps each exposure vector to its source in the codebase:

VectorHow It HappensWho Can See It
HTTP access logsGET /api/settings?node_secret=xxx logged by nginx/caddy/apacheLog readers, SIEM operators
Application logsGin debug mode logs full request URLsServer operators, log aggregators
Browser historyAdmin uses ?node_secret= URL directlyAnyone with browser access
HTTP Referer headerPage with ?node_secret= in URL links to external resourceThird-party servers
WebSocket URL logsws://host/api/ws?node_secret=xxx logged by proxiesProxy log readers
app.ini on diskCluster node URLs contain node_secret=Filesystem readers
Environment variablesNGINX_UI_CLUSTER_NODE=...&node_secret=...ps aux, Docker inspect, K8s pod specs
CI/CD pipeline logsEnv vars printed during deploymentCI/CD log viewers
Databasenodes.token column stored in plaintext SQLiteDB file readers

4. Proof of Concept

Scenario A: Log-Based Secret Extraction

Step 1 — Attacker gains read access to nginx access logs (e.g., via a misconfigured log aggregator, a compromised monitoring account, or a separate vulnerability).

Step 2 — Search logs for the pattern:

grep -oP 'node_secret=[^&\s"]+' /var/log/nginx/access.log
# Output: node_secret=a1b2c3d4-e5f6-7890-abcd-ef1234567890

Step 3 — Use the extracted secret for full API access:

GET /api/settings HTTP/1.1
Host: target:9000
X-Node-Secret: a1b2c3d4-e5f6-7890-abcd-ef1234567890

Response: Full settings JSON including JwtSecret, NodeSecret, all nginx paths, and all configured credentials.

GET /api/nginx/config?filepath=/etc/nginx/nginx.conf HTTP/1.1
Host: target:9000
X-Node-Secret: a1b2c3d4-e5f6-7890-abcd-ef1234567890

Response: Full nginx configuration including any embedded credentials.

Scenario B: Environment Variable Exposure in Docker/Kubernetes

Step 1 — Attacker reads a Kubernetes pod spec or Docker Compose file:

environment:
  - NGINX_UI_CLUSTER_NODE=http://10.0.0.1:9000?name=node1&node_secret=my-node-secret&enabled=true

Step 2 — Extract the secret from the URL query string.

Step 3 — Authenticate to the target node:

POST /api/nginx/test HTTP/1.1
Host: 10.0.0.1:9000
X-Node-Secret: my-node-secret

The attacker now has full admin access to the cluster node.

Scenario C: Referer Header Leak to Third-Party

Step 1 — Admin navigates to a page with ?node_secret= in the URL.

Step 2 — That page contains a resource (image, script, analytics) from a third-party domain.

Step 3 — Browser sends:

GET /analytics.js HTTP/1.1
Host: analytics.third-party.com
Referer: https://nginx-ui.internal/api/settings?node_secret=a1b2c3d4-...

The third-party server receives the node secret in the Referer header.


5. Impact

  • Confidentiality: Full read access to all nginx configurations, TLS private keys, ACME account credentials, database contents, and all settings stored in app.ini.
  • Integrity: Full write access to all nginx configurations across all cluster nodes. An attacker can deploy malicious nginx configs, disable TLS, or redirect traffic.
  • Availability: An attacker can reload or restart nginx with a broken configuration, causing a denial of service.
  • Persistence: The node secret does not expire and has no revocation mechanism. Once leaked, it provides permanent access until manually rotated.
  • Cluster-wide blast radius: A single leaked node secret from one cluster member's logs can be used to authenticate to any other node that shares the same secret.

6. Affected Versions

All versions of nginx-ui where getNodeSecret reads from c.Query("node_secret"). Present in the current dev branch. The cluster URL format with embedded node_secret has been present since v2.0.0-beta.23.


7. Recommended Fixes

Fix 1 (Primary) — Remove query parameter support for node_secret:

// internal/middleware/middleware.go
func getNodeSecret(c *gin.Context) (secret string) {
    // Only accept via header, never via query parameter
    return c.GetHeader("X-Node-Secret")
}

Apply the same change to isTrustedNodeRequest in websocket_origin.go.

Fix 2 — Redesign cluster node configuration format:

The cluster node URL format must not embed secrets in query parameters. Use a separate configuration key:

[cluster]
Node     = http://10.0.0.1:9000?name=node1&enabled=true
NodeKey1 = <secret-for-node1>

Or store secrets in a separate secrets file with restricted permissions.

Fix 3 — Encrypt node tokens at rest:

The nodes.token column in the SQLite database stores secrets in plaintext. Encrypt using the CryptoSettings.Secret key before storage.

Fix 4 — Add secret rotation support:

Provide an API endpoint to rotate the Node.Secret and invalidate all existing sessions authenticated via the old secret.


8. Timeline

DateEvent
2026-04-21Vulnerability identified via source code review
—Vendor notification (pending)
—CVE assignment (pending)

Citations

File: internal/middleware/middleware.go (L73-80)

// getNodeSecret from header or query
func getNodeSecret(c *gin.Context) (secret string) {
	if secret = c.GetHeader("X-Node-Secret"); secret != "" {
		return secret
	}

	return c.Query("node_secret")
}

File: internal/middleware/middleware.go (L96-103)

		// Check node secret authentication
		if nodeSecret := getNodeSecret(c); nodeSecret != "" && nodeSecret == settings.NodeSettings.Secret {
			initUser := user.GetInitUser(c)
			c.Set("Secret", nodeSecret)
			c.Set("user", initUser)
			c.Next()
			return
		}

File: internal/middleware/middleware.go (L152-158)

		if nodeSecret := getNodeSecret(c); nodeSecret != "" && nodeSecret == settings.NodeSettings.Secret {
			initUser := user.GetInitUser(c)
			c.Set("Secret", nodeSecret)
			c.Set("user", initUser)
			c.Next()
			return
		}

File: internal/middleware/websocket_origin.go (L39-46)

func isTrustedNodeRequest(r *http.Request) bool {
	secret := strings.TrimSpace(r.Header.Get("X-Node-Secret"))
	if secret == "" {
		secret = strings.TrimSpace(r.URL.Query().Get("node_secret"))
	}

	return secret != "" && secret == settings.NodeSettings.Secret
}

File: docs/guide/config-server.md (L109-111)

This secret is used to authenticate the communication between the Nginx UI servers.
Also, you can use this secret to access the Nginx UI API without a password.

File: app.example.ini (L45-48)

[cluster]
Node = http://10.0.0.1:9000?name=node1&node_secret=my-node-secret&enabled=true
Node = http://10.0.0.2:9000?name=node2&node_secret=my-node-secret&enabled=true
Node = http://10.0.0.3?name=node3&node_secret=my-node-secret&enabled=true

File: internal/cluster/cluster.go (L55-73)

func parseNodeUrl(nodeUrl string) (node *model.Node, err error) {
	u, err := url.Parse(nodeUrl)
	if err != nil {
		return
	}
	var sb strings.Builder
	sb.WriteString(u.Scheme)
	sb.WriteString("://")
	sb.WriteString(u.Host)
	sb.WriteString(u.Path)

	node = &model.Node{
		Name:    u.Query().Get("name"),
		URL:     sb.String(),
		Token:   u.Query().Get("node_secret"),
		Enabled: u.Query().Get("enabled") == "true",
	}

	return

File: internal/kernel/boot.go (L132-144)

func InitNodeSecret() {
	if settings.NodeSettings.Secret == "" {
		logger.Info("Secret is empty, generating...")
		uuidStr := uuid.New().String()
		err := settings.Update(func() {
			settings.NodeSettings.Secret = uuidStr
		})
		if err != nil {
			logger.Error("Error save settings", err)
		}
		logger.Info("Generated Secret: ", uuidStr)
	}
}

Affected Packages

1 total 1 fixed
EcosystemPackageVulnerable rangeFix
🐹Gogithub.com/0xJacky/Nginx-UI≥ 1.9.10-0.20250517140552-daee3ac7ade1&&< 1.9.10-0.20260728074433-a3999bd78a3b1.9.10-0.20260728074433-a3999bd78a3bgo get github.com/0xJacky/Nginx-UI@v1.9.10-0.20260728074433-a3999bd78a3b

Affected Products

1 product · 1 configurations
Application
nginx uinginxui
≥ 2.0.0 && < 2.5.0
range

Detection & mitigation playbook

Open-source dependency
  1. Detect

    Scan your dependency tree (package-lock.json, pnpm-lock.yaml, requirements.txt, go.sum, etc.) for github.com/0xJacky/Nginx-UI, including transitive dependencies — a direct dependency you never call can still pull in a vulnerable version.

  2. Fix

    Update github.com/0xJacky/Nginx-UI to 1.9.10-0.20260728074433-a3999bd78a3b or later, then make sure no transitive (indirect) dependency still pins the vulnerable range — O3 confirms CVE-2026-107807 is resolved across your whole dependency graph.

  3. Workarounds

    Put an independent control in front of the weakness: restrict the affected endpoint or interface to trusted networks, require an additional authentication factor or proxy-level check, and invalidate existing sessions and credentials in case the flaw has already been used.

Frequently Asked Questions

## 1. Vulnerability Summary nginx-ui's `Node.Secret` is a master credential that bypasses all JWT/password authentication for the entire API. The application accepts this credential via a **URL query parameter** (`?node_secret=`), causing it to be recorded in plaintext in HTTP access logs, reverse proxy logs, browser history, and HTTP `Referer` headers. Additionally, the official cluster configuration format embeds node secrets directly into URL query strings stored in `app.ini` and environment variables, creating a systemic credential exposure pattern across the entire cluster deployment mod
O3 Security · Impact-Aware SCA

Is CVE-2026-107807 in your dependencies?

Find it across Go, including transitive dependencies.

CVE-2026-107807: Nginx-UI Auth Bypass — Fix Available