CVE-2026-107811: Github.com/0xJacky/Nginx UI 0xJacky/nginx-ui /api/nodes Leaks Cluster Node Vulnerability

HIGH
Advisory Identifier: GHSA-32gc-wf3m-78w9
CVSS 8.8
CWE-862 CWE-200
Published
Advisory Summary

CVE-2026-107811 is a HIGH (CVSS 8.8) 0xjacky/nginx-ui /api/nodes leaks cluster node vulnerability (CWE-862: Missing Authorization) affecting Github.com/0xJacky/Nginx UI libraries in the Go ecosystem. The issue involves 0xjacky/nginx-ui /api/nodes leaks cluster node tokens and allows cross-node impersonation as inituser. Remediation is available by upgrading affected packages to version 1.9.10-0.20260728091109-0ecbd106c37b.

CVE-2026-107811 at a Glance

CVE Identifier CVE-2026-107811
GHSA Identifier GHSA-32gc-wf3m-78w9
Severity HIGH
CVSS v3.1 Base Score 8.8
CWE Classification CWE-862: Missing Authorization
Affected Product Github.com/0xJacky/Nginx UI
Package Ecosystem Go
Published Date
Last Updated

Security Impact

CVSS: 8.8

The security impact metrics below are parsed directly from the CVSS v3.1 vector string (CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H).

Attack Vector Network (AV:N)
Attack Complexity Low (AC:L)
Privileges Required Low (PR:L)
User Interaction None (UI:N)
Scope Unchanged (S:U)
Confidentiality High (C:H)
Integrity High (I:H)
Availability High (A:H)

How to Fix CVE-2026-107811

To remediate this vulnerability, upgrade all affected Github.com/0xJacky/Nginx UI dependencies to a patched release. Both direct and transitive dependencies should be checked, as frameworks or security libraries may pull in vulnerable versions transitively.

github.com/0xJacky/Nginx-UI fixed: 1.9.10-0.20260728091109-0ecbd106c37b
Upgrade github.com/0xJacky/Nginx-UI to 1.9.10-0.20260728091109-0ecbd106c37b
Verify Direct and Transitive Dependencies

Run the following command in your project directory to verify that all resolved dependencies use the patched release:

inspect dependencies for github.com/0xJacky/Nginx-UI

How to Check if You Are Affected

To determine whether your application is affected by CVE-2026-107811, inspect your project dependencies for Github.com/0xJacky/Nginx UI:

inspect dependencies for github.com/0xJacky/Nginx-UI

Analyze the terminal output to locate any version of Github.com/0xJacky/Nginx UI in your dependency tree. If any resolved version matches the vulnerable ranges listed in the table below (for example, versions earlier than 1.9.10-0.20260728091109-0ecbd106c37b), your application is affected.

Note: Verify declared build manifests and deployed runtime container environments.

Technical Details

Vulnerability Mechanism & Technical Analysis

This vulnerability is classified under CWE-862: Missing Authorization, where the product does not perform an authorization check when an actor attempts to access a resource or perform an action. In Github.com/0xJacky/Nginx UI, software state validation or input boundaries are circumvented during processing. Review the official source advisory statement below for specific affected components, classes, and reproduction details.

Source Advisory Statement

Summary 0xJacky/nginx-ui contains a high-severity trust-boundary failure between ordinary users and cluster node credentials. The source code shows that cluster node list and detail endpoints are reachable by ordinary authenticated users and return node objects containing the token field. That same token is also used as the X-Node-Secret shared credential for node-to-node authentication. When the middleware receives a correct node secret, it upgrades the request to initUser and bypasses the normal user-authentication path. As a result, any low-privileged authenticated user can first read a node token from /api/nodes and then impersonate a trusted node against a remote node's management API, achieving cross-node administrative authentication bypass. Details The root cause is a combination of sensitive credential exposure and improper trust elevation for node-to-node authentication. First, router/routers.go:87-105 mounts cluster.InitRouter(g) inside the shared /api authenticated route group, so any successfully authenticated user can access node list and detail endpoints. Next, api/cluster/node.go:19-48 implements GetNode and GetNodeList by directly returning analytic.GetNode(node). Meanwhile, model/node.go:8-13 defines Token with the JSON tag json:"token", meaning the node secret is serialized into API responses. The surrounding code path does not redact that field. Therefore, a low-privileged user can call /api/nodes or /api/nodes/:id and retrieve both the target node URL and the token value used for trusted node authentication. The second half of the exploit chain is in internal/middleware/middleware.go:73-103. The middleware reads a node secret from the X-Node-Secret header or node_secret query parameter. If that supplied value matches settings.NodeSettings.Secret, the request is immediately associated with user.GetInitUser(c), stored in the context as user, and allowed to continue. In other words, possession of the node secret is treated as sufficient to become initUser and bypass the normal JWT-based user-authentication flow. This makes the disclosed token directly reusable for privilege escalation. A low-privileged user logs in to the primary instance, retrieves the cluster node token through /api/nodes, then sends a request to the remote node with X-Node-Secret set to the leaked token. Because the remote node upgrades the request to initUser, the attacker can invoke sensitive management handlers. The verified evidence identifies api/system/router.go and api/system/restart.go as examples of reachable high-risk operations, including POST /api/system/restart. Core vulnerable code path: go // router/routers.go:87-105 g := root.Group("/", middleware.AuthRequired(), middleware.Proxy()) { debug.InitRouter(g) user.InitUserRouter(g) analytic.InitRouter(g) user.InitManageUserRouter(g) nginx.InitRouter(g) sites.InitRouter(g) streams.InitRouter(g) config.InitRouter(g) template.InitRouter(g) certificate.InitCertificateRouter(g) certificate.InitDNSCredentialRouter(g) certificate.InitAcmeUserRouter(g) dnsapi.InitRouter(g) system.InitPrivateRouter(g) settings.InitRouter(g) llm.InitRouter(g) cluster.InitRouter(g) notification.InitRouter(g) external_notify.InitRouter(g) backup.InitAutoBackupRouter(g) nginxLog.InitRouter(g) upstream.InitHTTPRouter(g) g.GET("/geolite/status", geolite.GetStatus) } This route block shows that cluster endpoints are mounted in the shared authenticated route group. Any user with a valid JWT can reach cluster management APIs; there is no administrator-only authorization gate here. go // api/cluster/node.go:19-48 func GetNode(c *gin.Context) { id := cast.ToUint64(c.Param("id")) nodeQuery := query.Node node, err := nodeQuery.FirstByID(id) if err != nil { cosy.ErrHandler(c, err) return } c.JSON(http.StatusOK, analytic.GetNode(node)) } func GetNodeList(c *gin.Context) { core := cosy.Core[model.Node](c). SetFussy("name") // fix for sqlite if c.Query("enabled") != "" { core.GormScope(func(tx *gorm.DB) *gorm.DB { return tx.Where("enabled = ?", cast.ToInt(cast.ToBool(c.Query("enabled")))) }) } core.SetTransformer(func(m *model.Node) any { return analytic.GetNode(m) }) core.List() } These handlers return node information directly to authenticated users. Because the returned object ultimately embeds the raw model.Node and that model contains a JSON token field, the API leaks the remote node shared secret. go // model/node.go:8-13 type Node struct { Model Name string `json:"name"` URL string `json:"url"` Token string `json:"token"` Enabled bool `json:"enabled" gorm:"default:false"` } The model definition confirms that Token is JSON-serializable. This is a core part of the sensitive-information exposure because the field is not restricted to internal-only use. go // internal/middleware/middleware.go:73-103 // 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") } // AuthRequired is a middleware that checks if the user is authenticated func AuthRequired() gin.HandlerFunc { return func(c *gin.Context) { abortWithAuthFailure := func() { c.AbortWithStatusJSON(http.StatusForbidden, gin.H{ "message": "Authorization failed", }) } xNodeID := getXNodeID(c) if xNodeID != "" { c.Set("ProxyNodeID", xNodeID) } // 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 } This authentication logic converts knowledge of the leaked node secret into an authenticated request as initUser. That makes the disclosed token immediately reusable for cross-node privilege escalation. POC Prerequisites: (1) the attacker has a valid low-privileged user account, (2) at least one cluster node is configured, and (3) the target node management address is reachable from the current deployment, which is typical in clustered setups. Reproduction steps: Log in as a low-privileged user with POST /api/login using a request body containing name and password. Capture the returned JWT token. Request GET /api/nodes or GET /api/nodes/:id with the low-privileged user's Authorization token. Inspect the JSON response and extract the target node's url and token fields. The token is the shared secret accepted by the remote node as X-Node-Secret. Send a sensitive management request directly to the target node, such as POST /api/system/restart, with the leaked token in the X-Node-Secret header. If the target node returns 200 or an equivalent success response, the request has been accepted as trusted node traffic. Expected result: the attacker performs administrative actions on the remote node without possessing a legitimate high-privileged user session on that node, demonstrating cross-node authentication bypass and privilege escalation to initUser-level access. Impact Any ordinary authenticated user can extract cluster node shared secrets and convert them into direct authentication bypass on remote nodes. The attacker can then execute high-risk administrative actions such as system restart, Nginx reload/restart, and configuration synchronization, enabling lateral movement across managed nodes and ultimately full compromise of the cluster management plane. The issue combines sensitive information disclosure with privilege escalation. Remediation Do not return cluster node tokens in normal API responses. Use dedicated output DTOs for node APIs and fully redact or omit the token field. Require administrator-level authorization for node-management endpoints instead of exposing them to every authenticated user. X-Node-Secret should not be shared with the normal HTTP management plane; it should be restricted to controlled network paths or stronger node-to-node trust channels such as mutually authenticated connections. Even when node-secret authentication succeeds, its capabilities should be minimized rather than mapping directly to a general-purpose initUser identity. Disclosure Notes The affected version is identified from the report-generation context as v2.4.2. No fixing commit, patched release, or vendor advisory was verified during this reporting stage, so patched_versions is marked as to be confirmed. The narrative below is based only on verified source-code evidence and the managed-vulnerability metadata. Supplemental Information Affected products Ecosystem: self-hosted Package name: 0xJacky/nginx-ui Affected versions: v2.4.2 Patched versions: to be confirmed

CVE-2026-107811 Affected Github.com/0xJacky/Nginx UI Versions

1 component(s)
Fixed Versions:
1.9.10-0.20260728091109-0ecbd106c37b
Product / Package Ecosystem Affected Versions Fixed Version
github.com/0xJacky/Nginx-UI
Go
≥ 1.9.10-0.20250517140552-daee3ac7ade1
< 1.9.10-0.20260728091109-0ecbd106c37b
1.9.10-0.20260728091109-0ecbd106c37b

References

Frequently Asked Questions

What is CVE-2026-107811?
CVE-2026-107811 is a security vulnerability in Github.com/0xJacky/Nginx UI involving 0xJacky/nginx-ui /api/nodes Leaks Cluster Node Tokens and Allows Cross-Node Impersonation as initUser under CWE-862: Missing Authorization.
Which Github.com/0xJacky/Nginx UI versions are affected?
Affected versions include releases prior to 1.9.10-0.20260728091109-0ecbd106c37b across affected packages: github.com/0xJacky/Nginx-UI.
What version fixes CVE-2026-107811?
Upgrading to 1.9.10-0.20260728091109-0ecbd106c37b (or the latest patched release for your respective branch) resolves the vulnerability.
Is github.com/0xJacky/Nginx-UI affected?
Yes, github.com/0xJacky/Nginx-UI is affected in releases prior to 1.9.10-0.20260728091109-0ecbd106c37b. Upgrade your dependency to 1.9.10-0.20260728091109-0ecbd106c37b or later.
What is the CVSS score of CVE-2026-107811?
CVE-2026-107811 has a CVSS v3.1 base score of 8.8 (HIGH) with vector string CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H.
What CWE is associated with CVE-2026-107811?
CVE-2026-107811 is classified under CWE-862: Missing Authorization (The product does not perform an authorization check when an actor attempts to access a resource or perform an action.).
How can I check Go dependencies for CVE-2026-107811?
Run the dependency tree command: 'inspect dependencies for github.com/0xJacky/Nginx-UI'. This command lists direct and transitive dependencies in your build configuration so you can verify if a vulnerable version is resolved.
Machine-readable OSV JSON OSV v1.5 Schema
Normalized schema output
{
  "schema_version" : "1.4.0",
  "id" : "GHSA-32gc-wf3m-78w9",
  "modified" : "2026-10-09T17:07:23Z",
  "published" : "2026-10-09T17:07:23Z",
  "aliases" : [ "CVE-2026-107811" ],
  "summary" : "0xJacky/nginx-ui /api/nodes Leaks Cluster Node Tokens and Allows Cross-Node Impersonation as initUser",
  "details" : "Summary\n0xJacky/nginx-ui contains a high-severity trust-boundary failure between ordinary users and cluster node credentials. The source code shows that cluster node list and detail endpoints are reachable by ordinary authenticated users and return node objects containing the token field.\n\nThat same token is also used as the X-Node-Secret shared credential for node-to-node authentication. When the middleware receives a correct node secret, it upgrades the request to initUser and bypasses the normal user-authentication path. As a result, any low-privileged authenticated user can first read a node token from /api/nodes and then impersonate a trusted node against a remote node's management API, achieving cross-node administrative authentication bypass.\n\nDetails\nThe root cause is a combination of sensitive credential exposure and improper trust elevation for node-to-node authentication. First, router/routers.go:87-105 mounts cluster.InitRouter(g) inside the shared /api authenticated route group, so any successfully authenticated user can access node list and detail endpoints.\n\nNext, api/cluster/node.go:19-48 implements GetNode and GetNodeList by directly returning analytic.GetNode(node). Meanwhile, model/node.go:8-13 defines Token with the JSON tag json:\"token\", meaning the node secret is serialized into API responses. The surrounding code path does not redact that field. Therefore, a low-privileged user can call /api/nodes or /api/nodes/:id and retrieve both the target node URL and the token value used for trusted node authentication.\n\nThe second half of the exploit chain is in internal/middleware/middleware.go:73-103. The middleware reads a node secret from the X-Node-Secret header or node_secret query parameter. If that supplied value matches settings.NodeSettings.Secret, the request is immediately associated with user.GetInitUser(c), stored in the context as user, and allowed to continue. In other words, possession of the node secret is treated as sufficient to become initUser and bypass the normal JWT-based user-authentication flow.\n\nThis makes the disclosed token directly reusable for privilege escalation. A low-privileged user logs in to the primary instance, retrieves the cluster node token through /api/nodes, then sends a request to the remote node with X-Node-Secret set to the leaked token. Because the remote node upgrades the request to initUser, the attacker can invoke sensitive management handlers. The verified evidence identifies api/system/router.go and api/system/restart.go as examples of reachable high-risk operations, including POST /api/system/restart.\n\nCore vulnerable code path:\n\ngo\n// router/routers.go:87-105\ng := root.Group(\"/\", middleware.AuthRequired(), middleware.Proxy())\n{\n\tdebug.InitRouter(g)\n\tuser.InitUserRouter(g)\n\tanalytic.InitRouter(g)\n\tuser.InitManageUserRouter(g)\n\tnginx.InitRouter(g)\n\tsites.InitRouter(g)\n\tstreams.InitRouter(g)\n\tconfig.InitRouter(g)\n\ttemplate.InitRouter(g)\n\tcertificate.InitCertificateRouter(g)\n\tcertificate.InitDNSCredentialRouter(g)\n\tcertificate.InitAcmeUserRouter(g)\n\tdnsapi.InitRouter(g)\n\tsystem.InitPrivateRouter(g)\n\tsettings.InitRouter(g)\n\tllm.InitRouter(g)\n\tcluster.InitRouter(g)\n\tnotification.InitRouter(g)\n\texternal_notify.InitRouter(g)\n\tbackup.InitAutoBackupRouter(g)\n\tnginxLog.InitRouter(g)\n\tupstream.InitHTTPRouter(g)\n\tg.GET(\"/geolite/status\", geolite.GetStatus)\n}\nThis route block shows that cluster endpoints are mounted in the shared authenticated route group. Any user with a valid JWT can reach cluster management APIs; there is no administrator-only authorization gate here.\n\ngo\n// api/cluster/node.go:19-48\nfunc GetNode(c *gin.Context) {\n\tid := cast.ToUint64(c.Param(\"id\"))\n\n\tnodeQuery := query.Node\n\n\tnode, err := nodeQuery.FirstByID(id)\n\tif err != nil {\n\t\tcosy.ErrHandler(c, err)\n\t\treturn\n\t}\n\n\tc.JSON(http.StatusOK, analytic.GetNode(node))\n}\n\nfunc GetNodeList(c *gin.Context) {\n\tcore := cosy.Core[model.Node](c).\n\t\tSetFussy(\"name\")\n\n\t// fix for sqlite\n\tif c.Query(\"enabled\") != \"\" {\n\t\tcore.GormScope(func(tx *gorm.DB) *gorm.DB {\n\t\t\treturn tx.Where(\"enabled = ?\", cast.ToInt(cast.ToBool(c.Query(\"enabled\"))))\n\t\t})\n\t}\n\n\tcore.SetTransformer(func(m *model.Node) any {\n\t\treturn analytic.GetNode(m)\n\t})\n\n\tcore.List()\n}\nThese handlers return node information directly to authenticated users. Because the returned object ultimately embeds the raw model.Node and that model contains a JSON token field, the API leaks the remote node shared secret.\n\ngo\n// model/node.go:8-13\ntype Node struct {\n\tModel\n\tName    string `json:\"name\"`\n\tURL     string `json:\"url\"`\n\tToken   string `json:\"token\"`\n\tEnabled bool   `json:\"enabled\" gorm:\"default:false\"`\n}\nThe model definition confirms that Token is JSON-serializable. This is a core part of the sensitive-information exposure because the field is not restricted to internal-only use.\n\ngo\n// internal/middleware/middleware.go:73-103\n// getNodeSecret from header or query\nfunc getNodeSecret(c *gin.Context) (secret string) {\n\tif secret = c.GetHeader(\"X-Node-Secret\"); secret != \"\" {\n\t\treturn secret\n\t}\n\n\treturn c.Query(\"node_secret\")\n}\n\n// AuthRequired is a middleware that checks if the user is authenticated\nfunc AuthRequired() gin.HandlerFunc {\n\treturn func(c *gin.Context) {\n\t\tabortWithAuthFailure := func() {\n\t\t\tc.AbortWithStatusJSON(http.StatusForbidden, gin.H{\n\t\t\t\t\"message\": \"Authorization failed\",\n\t\t\t})\n\t\t}\n\n\t\txNodeID := getXNodeID(c)\n\t\tif xNodeID != \"\" {\n\t\t\tc.Set(\"ProxyNodeID\", xNodeID)\n\t\t}\n\n\t\t// Check node secret authentication\n\t\tif nodeSecret := getNodeSecret(c); nodeSecret != \"\" && nodeSecret == settings.NodeSettings.Secret {\n\t\t\tinitUser := user.GetInitUser(c)\n\t\t\tc.Set(\"Secret\", nodeSecret)\n\t\t\tc.Set(\"user\", initUser)\n\t\t\tc.Next()\n\t\t\treturn\n\t\t}\nThis authentication logic converts knowledge of the leaked node secret into an authenticated request as initUser. That makes the disclosed token immediately reusable for cross-node privilege escalation.\n\nPOC\nPrerequisites: (1) the attacker has a valid low-privileged user account, (2) at least one cluster node is configured, and (3) the target node management address is reachable from the current deployment, which is typical in clustered setups.\n\nReproduction steps:\n\nLog in as a low-privileged user with POST /api/login using a request body containing name and password. Capture the returned JWT token.\nRequest GET /api/nodes or GET /api/nodes/:id with the low-privileged user's Authorization token.\nInspect the JSON response and extract the target node's url and token fields. The token is the shared secret accepted by the remote node as X-Node-Secret.\nSend a sensitive management request directly to the target node, such as POST /api/system/restart, with the leaked token in the X-Node-Secret header.\nIf the target node returns 200 or an equivalent success response, the request has been accepted as trusted node traffic.\nExpected result: the attacker performs administrative actions on the remote node without possessing a legitimate high-privileged user session on that node, demonstrating cross-node authentication bypass and privilege escalation to initUser-level access.\n\nImpact\nAny ordinary authenticated user can extract cluster node shared secrets and convert them into direct authentication bypass on remote nodes. The attacker can then execute high-risk administrative actions such as system restart, Nginx reload/restart, and configuration synchronization, enabling lateral movement across managed nodes and ultimately full compromise of the cluster management plane. The issue combines sensitive information disclosure with privilege escalation.\n\nRemediation\nDo not return cluster node tokens in normal API responses. Use dedicated output DTOs for node APIs and fully redact or omit the token field. Require administrator-level authorization for node-management endpoints instead of exposing them to every authenticated user. X-Node-Secret should not be shared with the normal HTTP management plane; it should be restricted to controlled network paths or stronger node-to-node trust channels such as mutually authenticated connections. Even when node-secret authentication succeeds, its capabilities should be minimized rather than mapping directly to a general-purpose initUser identity.\n\nDisclosure Notes\nThe affected version is identified from the report-generation context as v2.4.2. No fixing commit, patched release, or vendor advisory was verified during this reporting stage, so patched_versions is marked as to be confirmed. The narrative below is based only on verified source-code evidence and the managed-vulnerability metadata.\n\nSupplemental Information\nAffected products\nEcosystem: self-hosted\nPackage name: 0xJacky/nginx-ui\nAffected versions: v2.4.2\nPatched versions: to be confirmed",
  "severity" : [ {
    "type" : "CVSS_V3",
    "score" : "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H"
  } ],
  "affected" : [ {
    "package" : {
      "ecosystem" : "Go",
      "name" : "github.com/0xJacky/Nginx-UI"
    },
    "ranges" : [ {
      "type" : "ECOSYSTEM",
      "events" : [ {
        "introduced" : "1.9.10-0.20250517140552-daee3ac7ade1"
      }, {
        "fixed" : "1.9.10-0.20260728091109-0ecbd106c37b"
      } ]
    } ]
  } ],
  "references" : [ {
    "type" : "WEB",
    "url" : "https://github.com/0xJacky/nginx-ui/security/advisories/GHSA-32gc-wf3m-78w9"
  }, {
    "type" : "WEB",
    "url" : "https://github.com/0xJacky/nginx-ui/commit/0ecbd106c37b5143be14880c9447a66135151512"
  }, {
    "type" : "PACKAGE",
    "url" : "https://github.com/0xJacky/nginx-ui"
  }, {
    "type" : "WEB",
    "url" : "https://github.com/0xJacky/nginx-ui/releases/tag/v2.5.0"
  } ],
  "database_specific" : {
    "cwe_ids" : [ "CWE-200", "CWE-862" ],
    "severity" : "HIGH",
    "github_reviewed" : true,
    "github_reviewed_at" : "2026-10-09T17:07:23Z",
    "nvd_published_at" : null
  }
}