Common Weakness Enumeration

CWE-598

Allowed

Use of HTTP Request With Sensitive Query String

Abstraction: Variant · Status: Draft

API response cwe.mitre.org

The web application uses an HTTP method to process a request, but the request includes sensitive information in the query string.

169 vulnerabilities reference this CWE, most recent first.

GHSA-M2H3-RP3M-P73R

Vulnerability from github – Published: 2026-03-13 21:31 – Updated: 2026-03-13 21:31
VLAI
Details

IBM Sterling Partner Engagement Manager 6.2.3.0 through 6.2.3.5 and 6.2.4.0 through 6.2.4.2 could allow an attacker to obtain sensitive information from the query string of an HTTP GET method to process a request which could be obtained using man in the middle techniques.

Severity
3.1 (Low)
CVSS:3.1/AV:N/AC:H/PR:L/UI:N/S:U/C:L/I:N/A:N
Show details on source website
To clipboard 

{
  "affected": [],
  "aliases": [
    "CVE-2025-14811"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-598"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-03-13T19:53:50Z",
    "severity": "LOW"
  },
  "details": "IBM Sterling Partner Engagement Manager 6.2.3.0 through 6.2.3.5 and 6.2.4.0 through 6.2.4.2 could allow an attacker to obtain sensitive information from the query string of an HTTP GET method to process a request which could be obtained using man in the middle techniques.",
  "id": "GHSA-m2h3-rp3m-p73r",
  "modified": "2026-03-13T21:31:45Z",
  "published": "2026-03-13T21:31:45Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-14811"
    },
    {
      "type": "WEB",
      "url": "https://www.ibm.com/support/pages/node/7263391"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:H/PR:L/UI:N/S:U/C:L/I:N/A:N",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-M67M-3P5G-CW9J

Vulnerability from github – Published: 2025-04-15 14:20 – Updated: 2025-04-15 21:42
VLAI
Summary
VCS credentials included in URL parameters are potentially logged and saved into browser history as plaintext
Details

Summary

When creating a new component from an existing component that has a source code repository URL specified in settings, this URL is included in the client's URL parameters during the creation process. If, for example, the source code repository URL contains GitHub credentials, the confidential PAT and username are shown in plaintext and get saved into browser history. Moreover, if the request URL is logged, the credentials are written to the logs in plaintext.

The problematic URL in question is of this form:

https://<HOST>/create/component/vcs/?repo=https%3A%2F%2F<GITHUB USERNAME>%3A<GITHUB PAT>%40github.com%2F<REPOSITORY OWNER>%2F<REPOSITORY NAME>.git&project=1&category=&name=<REDACTED>&slug=<REDACTED>&is_glossary=False&vcs=github&source_language=228&license=&source_component=1#existing

If using Weblate official Docker image, nginx logs the URL and the token in plaintext:

nginx stdout | 127.0.0.1 - - [04/Apr/2025:10:46:54 +0000] "GET /create/component/vcs/?repo=https%3A%2F%2F<GITHUB USERNAME>%3A<GITHUB PAT>%40github.com%2F<REPOSITORY OWNER>%2F<REPOSITORY NAME>.git&project=1&category=&name=<REDACTED>&slug=<REDACTED>&is_glossary=False&vcs=github&source_language=228&license=&source_component=1 HTTP/1.1" 200 17625 "<REDACTED>" "Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:136.0) Gecko/20100101 Firefox/136.0"

Reproduction

  1. In a project, create a component which has the Repository push URL setting configured with, for example, a GitHub repository URL including a username and a PAT.
  2. In the same project, create another component using the From existing component option and selecting the previous component as the source. Click Continue.
  3. Observe that the URL parameter repo includes the secret PAT configured in the original components settings. The URL with the token is potentially saved as plaintext in browser history and server logs.
  4. Select a translation file to import and click Continue.
  5. Observe again the same repo parameter in the URL.

Impact

  • If server logs are compromised, the attacker may be able to gain access to private repositories potentially containing sensitive source code.
  • Under common browser settings, the URL containing VCS credentials is saved into browser history. Browser extensions, for example, are often able to read the history and thus offer a realistic attack vector to gain access to the credentials.
Severity
2.2 (Low)
CVSS:3.1/AV:N/AC:H/PR:H/UI:N/S:U/C:L/I:N/A:N
Show details on source website
To clipboard 

{
  "affected": [
    {
      "package": {
        "ecosystem": "PyPI",
        "name": "weblate"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "5.11"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2025-32021"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-598"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2025-04-15T14:20:38Z",
    "nvd_published_at": "2025-04-15T21:16:04Z",
    "severity": "LOW"
  },
  "details": "### Summary\n\nWhen creating a new component from an existing component that has a source code repository URL specified in settings, this URL is included in the client\u0027s URL parameters during the creation process. If, for example, the source code repository URL contains GitHub credentials, the confidential PAT and username are shown in plaintext and get saved into browser history. Moreover, if the request URL is logged, the credentials are written to the logs in plaintext.\n\nThe problematic URL in question is of this form:\n\n```\nhttps://\u003cHOST\u003e/create/component/vcs/?repo=https%3A%2F%2F\u003cGITHUB USERNAME\u003e%3A\u003cGITHUB PAT\u003e%40github.com%2F\u003cREPOSITORY OWNER\u003e%2F\u003cREPOSITORY NAME\u003e.git\u0026project=1\u0026category=\u0026name=\u003cREDACTED\u003e\u0026slug=\u003cREDACTED\u003e\u0026is_glossary=False\u0026vcs=github\u0026source_language=228\u0026license=\u0026source_component=1#existing\n```\n\nIf using Weblate official Docker image, nginx logs the URL and the token in plaintext:\n\n```\nnginx stdout | 127.0.0.1 - - [04/Apr/2025:10:46:54 +0000] \"GET /create/component/vcs/?repo=https%3A%2F%2F\u003cGITHUB USERNAME\u003e%3A\u003cGITHUB PAT\u003e%40github.com%2F\u003cREPOSITORY OWNER\u003e%2F\u003cREPOSITORY NAME\u003e.git\u0026project=1\u0026category=\u0026name=\u003cREDACTED\u003e\u0026slug=\u003cREDACTED\u003e\u0026is_glossary=False\u0026vcs=github\u0026source_language=228\u0026license=\u0026source_component=1 HTTP/1.1\" 200 17625 \"\u003cREDACTED\u003e\" \"Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:136.0) Gecko/20100101 Firefox/136.0\"\n```\n\n### Reproduction\n\n1. In a project, create a component which has the _Repository push URL_ setting configured with, for example, a GitHub repository URL including a username and a PAT.\n2. In the same project, create another component using the _From existing component_ option and selecting the previous component as the source. Click _Continue_.\n3. Observe that the URL parameter `repo` includes the secret PAT configured in the original components settings. The URL with the token is potentially saved as plaintext in browser history and server logs.\n4. Select a translation file to import and click _Continue_.\n5. Observe again the same `repo` parameter in the URL.\n\n### Impact\n\n- If server logs are compromised, the attacker may be able to gain access to private repositories potentially containing sensitive source code.\n- Under common browser settings, the URL containing VCS credentials is saved into browser history. Browser extensions, for example, are often able to read the history and thus offer a realistic attack vector to gain access to the credentials.",
  "id": "GHSA-m67m-3p5g-cw9j",
  "modified": "2025-04-15T21:42:20Z",
  "published": "2025-04-15T14:20:38Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/WeblateOrg/weblate/security/advisories/GHSA-m67m-3p5g-cw9j"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-32021"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/WeblateOrg/weblate"
    },
    {
      "type": "WEB",
      "url": "https://github.com/WeblateOrg/weblate/releases/tag/weblate-5.11"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:H/PR:H/UI:N/S:U/C:L/I:N/A:N",
      "type": "CVSS_V3"
    }
  ],
  "summary": "VCS credentials included in URL parameters are potentially logged and saved into browser history as plaintext"
}

GHSA-MRQC-3276-74F8

Vulnerability from github – Published: 2026-03-24 19:33 – Updated: 2026-03-27 21:18
VLAI
Summary
PinchTab: API Bearer Token Exposed in URL Query Parameter via Server Logs and Intermediary Systems
Details

Summary

PinchTab v0.7.8 through v0.8.3 accepted the API token from a token URL query parameter in addition to the Authorization header. When a valid API credential is sent in the URL, it can be exposed through request URIs recorded by intermediaries or client-side tooling, such as reverse proxy access logs, browser history, shell history, clipboard history, and tracing systems that capture full URLs.

This issue is an unsafe credential transport pattern rather than a direct authentication bypass. It only affects deployments where a token is configured and a client actually uses the query-parameter form. PinchTab's security guidance already recommended Authorization: Bearer <token>, but v0.8.3 still accepted ?token= and included first-party flows that generated and consumed URLs containing the token.

This was addressed in v0.8.4 by removing query-string token authentication and requiring safer header- or session-based authentication flows.

Details

Issue 1 — Query-string token accepted in v0.7.8 through v0.8.3 (internal/handlers/middleware.go): The v0.8.3 authentication middleware accepted credentials from the URL query string:

// internal/handlers/middleware.go — v0.8.3
auth := r.Header.Get("Authorization")
qToken := r.URL.Query().Get("token")

if auth == "" && qToken == "" {
    web.ErrorCode(w, 401, "missing_token", "unauthorized", false, nil)
    return
}

provided := strings.TrimPrefix(auth, "Bearer ")
if provided == auth {
    if qToken != "" {
        provided = qToken
    } else {
        provided = auth
    }
}

if subtle.ConstantTimeCompare([]byte(provided), []byte(cfg.Token)) != 1 {
    web.ErrorCode(w, 401, "bad_token", "unauthorized", false, nil)
    return
}

This means any client sending GET /health?token=<secret> in v0.8.3 would authenticate successfully without using the Authorization header. I verified the same query-token auth pattern is present in the historical tag range starting at v0.7.8, and it is removed in v0.8.4.

Issue 2 — First-party setup and dashboard flows in v0.8.3 generated and consumed ?token= URLs: The v0.8.3 setup flow generated dashboard URLs containing the token in the query string:

// cmd/pinchtab/cmd_wizard.go — v0.8.3
func dashboardURL(cfg *config.FileConfig, path string) string {
    host := orDefault(cfg.Server.Bind, "127.0.0.1")
    port := orDefault(cfg.Server.Port, "9867")
    url := fmt.Sprintf("http://%s:%s%s", host, port, path)
    if cfg.Server.Token != "" {
        url += "?token=" + cfg.Server.Token
    }
    return url
}

The v0.8.3 dashboard frontend also supported one-click login from that same query-string token:

// dashboard/src/App.tsx — v0.8.3
const params = new URLSearchParams(window.location.search);
const urlToken = params.get("token");
if (urlToken) {
    setStoredAuthToken(urlToken);
    clean.searchParams.delete("token");
    window.history.replaceState({}, "", clean.pathname + clean.hash);
    window.location.reload();
}

That combination materially increased the chance that users would open, copy, paste, bookmark, or log URLs containing live credentials before the token was scrubbed from the visible address bar.

Issue 3 — Exposure depends on surrounding systems recording the URL: PinchTab's own request logger records r.URL.Path, not the full raw query string, so the leak is not primarily through PinchTab's structured application log. The risk comes from surrounding systems or client tooling that record the full request URI, such as:

  1. reverse proxies and load balancers
  2. browser history or bookmarks
  3. shell history containing full curl commands
  4. clipboard or terminal history when the wizard prints and copies a tokenized URL
  5. tracing or monitoring systems that capture full request URLs

PoC

Step 1 — Confirm auth is required

curl -i http://localhost:9867/health

Expected in token-protected affected deployments:

HTTP/1.1 401 Unauthorized

Step 2 — Authenticate using the vulnerable query-parameter pattern

curl -i "http://localhost:9867/health?token=supersecrettoken"

Expected:

HTTP/1.1 200 OK

This demonstrates that the token is accepted from the URL.

Step 3 — Observe the exposure vector If the request traverses a system that records the full URI, the token may appear in logs or local history, for example:

GET /health?token=supersecrettoken HTTP/1.1

In v0.8.3, a first-party reproduction path also exists without any external proxy: run the setup wizard, copy the printed dashboard URL containing ?token=..., and note that the live credential is now present in clipboard history and any place that URL is pasted.

Impact

  1. Exposure of a valid API token through unsafe URL-based transport when a client uses the ?token= authentication form.
  2. Lower barrier for credential compromise where reverse proxies, browser history, shell history, clipboard history, or tracing systems retain full request URIs.
  3. The v0.8.3 wizard/dashboard flow increased the practical likelihood of this exposure by generating and consuming tokenized URLs as a first-party login pattern.
  4. Practical risk depends on actual use of the query-token pattern; deployments that use only Authorization: Bearer <token> are not affected by this issue in practice.
  5. This is not a direct authentication bypass. An attacker still needs access to a secondary source that captured the URL containing the token.

Suggested Remediation

  1. Reject query-string token authentication and accept credentials only through the Authorization header or controlled session mechanisms.
  2. Avoid generating user-facing URLs that contain live credentials.
  3. Document header-based auth as the only supported non-browser API authentication pattern.
  4. Recommend token rotation for users who may previously have used query-parameter authentication.

Screenshot Capture ภาพถ่ายหน้าจอ 2569-03-18 เวลา 12 46 08

Severity
4.3 (Medium)
CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:L/I:N/A:N
Show details on source website
To clipboard 

{
  "affected": [
    {
      "package": {
        "ecosystem": "Go",
        "name": "github.com/pinchtab/pinchtab"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0.7.8"
            },
            {
              "fixed": "0.8.4"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-33620"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-598"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-03-24T19:33:23Z",
    "nvd_published_at": "2026-03-26T21:17:06Z",
    "severity": "MODERATE"
  },
  "details": "### Summary\nPinchTab `v0.7.8` through `v0.8.3` accepted the API token from a `token` URL query parameter in addition to the `Authorization` header. When a valid API credential is sent in the URL, it can be exposed through request URIs recorded by intermediaries or client-side tooling, such as reverse proxy access logs, browser history, shell history, clipboard history, and tracing systems that capture full URLs.\n\nThis issue is an unsafe credential transport pattern rather than a direct authentication bypass. It only affects deployments where a token is configured and a client actually uses the query-parameter form. PinchTab\u0027s security guidance already recommended `Authorization: Bearer \u003ctoken\u003e`, but `v0.8.3` still accepted `?token=` and included first-party flows that generated and consumed URLs containing the token.\n\nThis was addressed in v0.8.4 by removing query-string token authentication and requiring safer header- or session-based authentication flows.\n\n### Details\n**Issue 1 \u2014 Query-string token accepted in `v0.7.8` through `v0.8.3` (`internal/handlers/middleware.go`):**\nThe `v0.8.3` authentication middleware accepted credentials from the URL query string:\n\n```\n// internal/handlers/middleware.go \u2014 v0.8.3\nauth := r.Header.Get(\"Authorization\")\nqToken := r.URL.Query().Get(\"token\")\n\nif auth == \"\" \u0026\u0026 qToken == \"\" {\n    web.ErrorCode(w, 401, \"missing_token\", \"unauthorized\", false, nil)\n    return\n}\n\nprovided := strings.TrimPrefix(auth, \"Bearer \")\nif provided == auth {\n    if qToken != \"\" {\n        provided = qToken\n    } else {\n        provided = auth\n    }\n}\n\nif subtle.ConstantTimeCompare([]byte(provided), []byte(cfg.Token)) != 1 {\n    web.ErrorCode(w, 401, \"bad_token\", \"unauthorized\", false, nil)\n    return\n}\n```\n\nThis means any client sending `GET /health?token=\u003csecret\u003e` in `v0.8.3` would authenticate successfully without using the `Authorization` header. I verified the same query-token auth pattern is present in the historical tag range starting at `v0.7.8`, and it is removed in `v0.8.4`.\n\n**Issue 2 \u2014 First-party setup and dashboard flows in `v0.8.3` generated and consumed `?token=` URLs:**\nThe `v0.8.3` setup flow generated dashboard URLs containing the token in the query string:\n\n```\n// cmd/pinchtab/cmd_wizard.go \u2014 v0.8.3\nfunc dashboardURL(cfg *config.FileConfig, path string) string {\n    host := orDefault(cfg.Server.Bind, \"127.0.0.1\")\n    port := orDefault(cfg.Server.Port, \"9867\")\n    url := fmt.Sprintf(\"http://%s:%s%s\", host, port, path)\n    if cfg.Server.Token != \"\" {\n        url += \"?token=\" + cfg.Server.Token\n    }\n    return url\n}\n```\n\nThe `v0.8.3` dashboard frontend also supported one-click login from that same query-string token:\n\n```\n// dashboard/src/App.tsx \u2014 v0.8.3\nconst params = new URLSearchParams(window.location.search);\nconst urlToken = params.get(\"token\");\nif (urlToken) {\n    setStoredAuthToken(urlToken);\n    clean.searchParams.delete(\"token\");\n    window.history.replaceState({}, \"\", clean.pathname + clean.hash);\n    window.location.reload();\n}\n```\n\nThat combination materially increased the chance that users would open, copy, paste, bookmark, or log URLs containing live credentials before the token was scrubbed from the visible address bar.\n\n**Issue 3 \u2014 Exposure depends on surrounding systems recording the URL:**\nPinchTab\u0027s own request logger records `r.URL.Path`, not the full raw query string, so the leak is not primarily through PinchTab\u0027s structured application log. The risk comes from surrounding systems or client tooling that record the full request URI, such as:\n\n1. reverse proxies and load balancers\n2. browser history or bookmarks\n3. shell history containing full `curl` commands\n4. clipboard or terminal history when the wizard prints and copies a tokenized URL\n5. tracing or monitoring systems that capture full request URLs\n\n### PoC\n**Step 1 \u2014 Confirm auth is required**\n\n```bash\ncurl -i http://localhost:9867/health\n```\n\nExpected in token-protected affected deployments:\n\n```http\nHTTP/1.1 401 Unauthorized\n```\n\n**Step 2 \u2014 Authenticate using the vulnerable query-parameter pattern**\n\n```bash\ncurl -i \"http://localhost:9867/health?token=supersecrettoken\"\n```\n\nExpected:\n\n```http\nHTTP/1.1 200 OK\n```\n\nThis demonstrates that the token is accepted from the URL.\n\n**Step 3 \u2014 Observe the exposure vector**\nIf the request traverses a system that records the full URI, the token may appear in logs or local history, for example:\n\n```text\nGET /health?token=supersecrettoken HTTP/1.1\n```\n\nIn `v0.8.3`, a first-party reproduction path also exists without any external proxy: run the setup wizard, copy the printed dashboard URL containing `?token=...`, and note that the live credential is now present in clipboard history and any place that URL is pasted.\n\n### Impact\n1. Exposure of a valid API token through unsafe URL-based transport when a client uses the `?token=` authentication form.\n2. Lower barrier for credential compromise where reverse proxies, browser history, shell history, clipboard history, or tracing systems retain full request URIs.\n3. The `v0.8.3` wizard/dashboard flow increased the practical likelihood of this exposure by generating and consuming tokenized URLs as a first-party login pattern.\n4. Practical risk depends on actual use of the query-token pattern; deployments that use only `Authorization: Bearer \u003ctoken\u003e` are not affected by this issue in practice.\n5. This is not a direct authentication bypass. An attacker still needs access to a secondary source that captured the URL containing the token.\n\n### Suggested Remediation\n1. Reject query-string token authentication and accept credentials only through the `Authorization` header or controlled session mechanisms.\n2. Avoid generating user-facing URLs that contain live credentials.\n3. Document header-based auth as the only supported non-browser API authentication pattern.\n4. Recommend token rotation for users who may previously have used query-parameter authentication.\n\n**Screenshot Capture**\n\u003cimg width=\"1162\" height=\"164\" alt=\"\u0e20\u0e32\u0e1e\u0e16\u0e48\u0e32\u0e22\u0e2b\u0e19\u0e49\u0e32\u0e08\u0e2d 2569-03-18 \u0e40\u0e27\u0e25\u0e32 12 46 08\" src=\"https://github.com/user-attachments/assets/e68b4469-dafd-400d-a6e1-f74d368cc8ac\" /\u003e",
  "id": "GHSA-mrqc-3276-74f8",
  "modified": "2026-03-27T21:18:50Z",
  "published": "2026-03-24T19:33:23Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/pinchtab/pinchtab/security/advisories/GHSA-mrqc-3276-74f8"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-33620"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/pinchtab/pinchtab"
    },
    {
      "type": "WEB",
      "url": "https://github.com/pinchtab/pinchtab/releases/tag/v0.8.4"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:L/I:N/A:N",
      "type": "CVSS_V3"
    }
  ],
  "summary": "PinchTab: API Bearer Token Exposed in URL Query Parameter via Server Logs and Intermediary Systems"
}

GHSA-MXW5-PQ7X-P39X

Vulnerability from github – Published: 2025-02-14 00:30 – Updated: 2025-02-14 00:30
VLAI
Details

The Mojave Inverter uses the GET method for sensitive information.

Severity
7.5 (High)
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N
8.7 (High)
CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:H/VI:N/VA:N/SC:N/SI:N/SA:N
Show details on source website
To clipboard 

{
  "affected": [],
  "aliases": [
    "CVE-2025-26473"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-598"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2025-02-13T22:15:13Z",
    "severity": "HIGH"
  },
  "details": "The Mojave Inverter uses the GET method for sensitive information.",
  "id": "GHSA-mxw5-pq7x-p39x",
  "modified": "2025-02-14T00:30:44Z",
  "published": "2025-02-14T00:30:44Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-26473"
    },
    {
      "type": "WEB",
      "url": "https://old.outbackpower.com/about-outback/contact/contact-us"
    },
    {
      "type": "WEB",
      "url": "https://www.cisa.gov/news-events/ics-advisories/icsa-25-044-17"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N",
      "type": "CVSS_V3"
    },
    {
      "score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:H/VI:N/VA:N/SC:N/SI:N/SA:N/E:X/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:X",
      "type": "CVSS_V4"
    }
  ]
}

GHSA-P626-9V99-XC4X

Vulnerability from github – Published: 2025-01-04 03:33 – Updated: 2025-01-06 18:31
VLAI
Details

An issue was discovered in Optimizely Configured Commerce before 5.2.2408. A medium-severity issue exists in requests for resources where the session token is submitted as a URL parameter. This exposes information about the authenticated session, which can be leveraged for session hijacking.

Severity
7.5 (High)
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N
Show details on source website
To clipboard 

{
  "affected": [],
  "aliases": [
    "CVE-2025-22387"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-598"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2025-01-04T02:15:07Z",
    "severity": "HIGH"
  },
  "details": "An issue was discovered in Optimizely Configured Commerce before 5.2.2408. A medium-severity issue exists in requests for resources where the session token is submitted as a URL parameter. This exposes information about the authenticated session, which can be leveraged for session hijacking.",
  "id": "GHSA-p626-9v99-xc4x",
  "modified": "2025-01-06T18:31:02Z",
  "published": "2025-01-04T03:33:08Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-22387"
    },
    {
      "type": "WEB",
      "url": "https://support.optimizely.com/hc/en-us/articles/32695551034893-Configured-Commerce-Security-Advisory-COM-2024-06"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-PF27-23G4-7WJJ

Vulnerability from github – Published: 2025-03-04 21:30 – Updated: 2025-03-21 18:31
VLAI
Details

Maharashtra State Electricity Distribution Company Limited Mahavitran IOS Application 16.1 application till version 16.1 communicates using the GET method to process requests that contain sensitive information such as user account name and password, which can expose that information through the browser's history, referrers, web logs, and other sources.

Severity
7.5 (High)
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N
Show details on source website
To clipboard 

{
  "affected": [],
  "aliases": [
    "CVE-2021-41719"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-598"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2025-03-04T21:15:11Z",
    "severity": "HIGH"
  },
  "details": "Maharashtra State Electricity Distribution Company Limited Mahavitran IOS Application 16.1 application till version 16.1 communicates using the GET method to process requests that contain sensitive information such as user account name and password, which can expose that information through the browser\u0027s history, referrers, web logs, and other sources.",
  "id": "GHSA-pf27-23g4-7wjj",
  "modified": "2025-03-21T18:31:34Z",
  "published": "2025-03-04T21:30:57Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2021-41719"
    },
    {
      "type": "WEB",
      "url": "https://cvewalkthrough.com/cve-2021-41719-mseb-ios-application-sensitive-information-exposure"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-PR6F-5C62-PJ5R

Vulnerability from github – Published: 2025-10-09 15:31 – Updated: 2025-12-04 21:31
VLAI
Details

Potential use of sensitive information in GET requests in Checkmk GmbH's Checkmk versions <2.4.0p13, <2.3.0p38, <2.2.0p46, and 2.1.0 (EOL) may cause sensitive form data to be included in URL query parameters, which may be logged in various places such as browser history or web server logs.

Severity
4.3 (Medium)
CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:L/I:N/A:N
1.0 (Low)
CVSS:4.0/AV:L/AC:L/AT:P/PR:H/UI:P/VC:L/VI:N/VA:N/SC:L/SI:N/SA:N
Show details on source website
To clipboard 

{
  "affected": [],
  "aliases": [
    "CVE-2025-32916"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-598"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2025-10-09T15:16:05Z",
    "severity": "LOW"
  },
  "details": "Potential use of sensitive information in GET requests in Checkmk GmbH\u0027s Checkmk versions \u003c2.4.0p13, \u003c2.3.0p38, \u003c2.2.0p46, and 2.1.0 (EOL) may cause sensitive form data to be included in URL query parameters, which may be logged in various places such as browser history or web server logs.",
  "id": "GHSA-pr6f-5c62-pj5r",
  "modified": "2025-12-04T21:31:01Z",
  "published": "2025-10-09T15:31:03Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-32916"
    },
    {
      "type": "WEB",
      "url": "https://checkmk.com/werk/17105"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:L/I:N/A:N",
      "type": "CVSS_V3"
    },
    {
      "score": "CVSS:4.0/AV:L/AC:L/AT:P/PR:H/UI:P/VC:L/VI:N/VA:N/SC:L/SI:N/SA:N/E:X/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:X",
      "type": "CVSS_V4"
    }
  ]
}

GHSA-PVGV-GCP7-V38G

Vulnerability from github – Published: 2026-10-09 17:07 – Updated: 2026-10-09 17:07
VLAI
Summary
Nginx UI: Node Secret Credential Exposure via URL Query Parameter
Details

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:

Vector How It Happens Who Can See It
HTTP access logs GET /api/settings?node_secret=xxx logged by nginx/caddy/apache Log readers, SIEM operators
Application logs Gin debug mode logs full request URLs Server operators, log aggregators
Browser history Admin uses ?node_secret= URL directly Anyone with browser access
HTTP Referer header Page with ?node_secret= in URL links to external resource Third-party servers
WebSocket URL logs ws://host/api/ws?node_secret=xxx logged by proxies Proxy log readers
app.ini on disk Cluster node URLs contain node_secret= Filesystem readers
Environment variables NGINX_UI_CLUSTER_NODE=...&node_secret=... ps aux, Docker inspect, K8s pod specs
CI/CD pipeline logs Env vars printed during deployment CI/CD log viewers
Database nodes.token column stored in plaintext SQLite DB 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

Date Event
2026-04-21 Vulnerability 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)
    }
}
Severity
8.8 (High)
CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
Show details on source website
To clipboard 

{
  "affected": [
    {
      "package": {
        "ecosystem": "Go",
        "name": "github.com/0xJacky/Nginx-UI"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "1.9.10-0.20250517140552-daee3ac7ade1"
            },
            {
              "fixed": "1.9.10-0.20260728074433-a3999bd78a3b"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-107807"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-312",
      "CWE-598"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-10-09T17:07:09Z",
    "nvd_published_at": null,
    "severity": "HIGH"
  },
  "details": "## 1. Vulnerability Summary\n\nnginx-ui\u0027s `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.\n\nAn 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 \u2014 including reading TLS private keys, modifying nginx configurations, and (when chained with Bug #1) achieving OS-level code execution.\n\n---\n\n## 2. Root Cause Analysis\n\n### 2.1 Node Secret Accepted as URL Query Parameter\n\nThe `getNodeSecret` function reads the credential from the URL query string as a fallback when the `X-Node-Secret` header is absent: [1](#3-0) \n\nThis function is called in both `AuthRequired()` and `AuthRequiredWS()` middleware, meaning the query parameter bypass works for **all authenticated HTTP and WebSocket endpoints**: [2](#3-1) [3](#3-2) \n\nThe same pattern is repeated in the WebSocket origin checker, which also reads `node_secret` from the URL: [4](#3-3) \n\n### 2.2 Node Secret Is a Full Authentication Bypass\n\nThe documentation explicitly states this is by design: [5](#3-4) \n\nWhen the secret matches, the middleware sets the request context to an admin-level init user and calls `c.Next()` \u2014 bypassing all JWT validation, session checks, and 2FA: [2](#3-1) \n\n### 2.3 Cluster Configuration Embeds Node Secrets in URLs\n\nThe official cluster configuration format, documented and used in `app.example.ini`, stores node secrets as URL query parameters: [6](#3-5) \n\nThe `parseNodeUrl` function extracts the secret from the URL\u0027s query string and stores it in the database as the node\u0027s `Token` field: [7](#3-6) \n\nThis means node secrets are embedded in:\n- `app.ini` on disk (readable by any process with filesystem access)\n- The `NGINX_UI_CLUSTER_NODE` environment variable (visible in `ps aux`, Docker inspect, Kubernetes pod specs, CI/CD logs)\n- The SQLite database `nodes` table as the `token` column in plaintext\n\n### 2.4 Node Secret Generation Uses UUID\n\nThe secret is auto-generated as a UUID v4 if not set: [8](#3-7) \n\nUUID v4 has 122 bits of entropy, which is adequate. However, the exposure surface described in this report makes entropy irrelevant \u2014 the secret is leaked through operational channels, not brute-forced.\n\n---\n\n## 3. Exposure Surface\n\nThe following table maps each exposure vector to its source in the codebase:\n\n| Vector | How It Happens | Who Can See It |\n|---|---|---|\n| **HTTP access logs** | `GET /api/settings?node_secret=xxx` logged by nginx/caddy/apache | Log readers, SIEM operators |\n| **Application logs** | Gin debug mode logs full request URLs | Server operators, log aggregators |\n| **Browser history** | Admin uses `?node_secret=` URL directly | Anyone with browser access |\n| **HTTP Referer header** | Page with `?node_secret=` in URL links to external resource | Third-party servers |\n| **WebSocket URL logs** | `ws://host/api/ws?node_secret=xxx` logged by proxies | Proxy log readers |\n| **`app.ini` on disk** | Cluster node URLs contain `node_secret=` | Filesystem readers |\n| **Environment variables** | `NGINX_UI_CLUSTER_NODE=...\u0026node_secret=...` | `ps aux`, Docker inspect, K8s pod specs |\n| **CI/CD pipeline logs** | Env vars printed during deployment | CI/CD log viewers |\n| **Database** | `nodes.token` column stored in plaintext SQLite | DB file readers |\n\n---\n\n## 4. Proof of Concept\n\n### Scenario A: Log-Based Secret Extraction\n\n**Step 1 \u2014 Attacker gains read access to nginx access logs** (e.g., via a misconfigured log aggregator, a compromised monitoring account, or a separate vulnerability).\n\n**Step 2 \u2014 Search logs for the pattern:**\n\n```bash\ngrep -oP \u0027node_secret=[^\u0026\\s\"]+\u0027 /var/log/nginx/access.log\n# Output: node_secret=a1b2c3d4-e5f6-7890-abcd-ef1234567890\n```\n\n**Step 3 \u2014 Use the extracted secret for full API access:**\n\n```http\nGET /api/settings HTTP/1.1\nHost: target:9000\nX-Node-Secret: a1b2c3d4-e5f6-7890-abcd-ef1234567890\n```\n\nResponse: Full settings JSON including `JwtSecret`, `NodeSecret`, all nginx paths, and all configured credentials.\n\n```http\nGET /api/nginx/config?filepath=/etc/nginx/nginx.conf HTTP/1.1\nHost: target:9000\nX-Node-Secret: a1b2c3d4-e5f6-7890-abcd-ef1234567890\n```\n\nResponse: Full nginx configuration including any embedded credentials.\n\n### Scenario B: Environment Variable Exposure in Docker/Kubernetes\n\n**Step 1 \u2014 Attacker reads a Kubernetes pod spec or Docker Compose file:**\n\n```yaml\nenvironment:\n  - NGINX_UI_CLUSTER_NODE=http://10.0.0.1:9000?name=node1\u0026node_secret=my-node-secret\u0026enabled=true\n```\n\n**Step 2 \u2014 Extract the secret from the URL query string.**\n\n**Step 3 \u2014 Authenticate to the target node:**\n\n```http\nPOST /api/nginx/test HTTP/1.1\nHost: 10.0.0.1:9000\nX-Node-Secret: my-node-secret\n```\n\nThe attacker now has full admin access to the cluster node.\n\n### Scenario C: Referer Header Leak to Third-Party\n\n**Step 1 \u2014 Admin navigates to a page with `?node_secret=` in the URL.**\n\n**Step 2 \u2014 That page contains a resource (image, script, analytics) from a third-party domain.**\n\n**Step 3 \u2014 Browser sends:**\n\n```http\nGET /analytics.js HTTP/1.1\nHost: analytics.third-party.com\nReferer: https://nginx-ui.internal/api/settings?node_secret=a1b2c3d4-...\n```\n\nThe third-party server receives the node secret in the `Referer` header.\n\n\n\n---\n\n## 5. Impact\n\n- **Confidentiality:** Full read access to all nginx configurations, TLS private keys, ACME account credentials, database contents, and all settings stored in `app.ini`.\n- **Integrity:** Full write access to all nginx configurations across all cluster nodes. An attacker can deploy malicious nginx configs, disable TLS, or redirect traffic.\n- **Availability:** An attacker can reload or restart nginx with a broken configuration, causing a denial of service.\n- **Persistence:** The node secret does not expire and has no revocation mechanism. Once leaked, it provides permanent access until manually rotated.\n- **Cluster-wide blast radius:** A single leaked node secret from one cluster member\u0027s logs can be used to authenticate to any other node that shares the same secret.\n\n---\n\n## 6. Affected Versions\n\nAll 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`.\n\n---\n\n## 7. Recommended Fixes\n\n**Fix 1 (Primary) \u2014 Remove query parameter support for `node_secret`:**\n\n```go\n// internal/middleware/middleware.go\nfunc getNodeSecret(c *gin.Context) (secret string) {\n    // Only accept via header, never via query parameter\n    return c.GetHeader(\"X-Node-Secret\")\n}\n```\n\nApply the same change to `isTrustedNodeRequest` in `websocket_origin.go`.\n\n**Fix 2 \u2014 Redesign cluster node configuration format:**\n\nThe cluster node URL format must not embed secrets in query parameters. Use a separate configuration key:\n\n```ini\n[cluster]\nNode     = http://10.0.0.1:9000?name=node1\u0026enabled=true\nNodeKey1 = \u003csecret-for-node1\u003e\n```\n\nOr store secrets in a separate secrets file with restricted permissions.\n\n**Fix 3 \u2014 Encrypt node tokens at rest:**\n\nThe `nodes.token` column in the SQLite database stores secrets in plaintext. Encrypt using the `CryptoSettings.Secret` key before storage.\n\n**Fix 4 \u2014 Add secret rotation support:**\n\nProvide an API endpoint to rotate the `Node.Secret` and invalidate all existing sessions authenticated via the old secret.\n\n---\n\n## 8. Timeline\n\n| Date | Event |\n|---|---|\n| 2026-04-21 | Vulnerability identified via source code review |\n| \u2014 | Vendor notification (pending) |\n| \u2014 | CVE assignment (pending) |\n\n### Citations\n\n**File:** internal/middleware/middleware.go (L73-80)\n```go\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\n**File:** internal/middleware/middleware.go (L96-103)\n```go\n\t\t// Check node secret authentication\n\t\tif nodeSecret := getNodeSecret(c); nodeSecret != \"\" \u0026\u0026 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}\n```\n\n**File:** internal/middleware/middleware.go (L152-158)\n```go\n\t\tif nodeSecret := getNodeSecret(c); nodeSecret != \"\" \u0026\u0026 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}\n```\n\n**File:** internal/middleware/websocket_origin.go (L39-46)\n```go\nfunc isTrustedNodeRequest(r *http.Request) bool {\n\tsecret := strings.TrimSpace(r.Header.Get(\"X-Node-Secret\"))\n\tif secret == \"\" {\n\t\tsecret = strings.TrimSpace(r.URL.Query().Get(\"node_secret\"))\n\t}\n\n\treturn secret != \"\" \u0026\u0026 secret == settings.NodeSettings.Secret\n}\n```\n\n**File:** docs/guide/config-server.md (L109-111)\n```markdown\nThis secret is used to authenticate the communication between the Nginx UI servers.\nAlso, you can use this secret to access the Nginx UI API without a password.\n\n```\n\n**File:** app.example.ini (L45-48)\n```text\n[cluster]\nNode = http://10.0.0.1:9000?name=node1\u0026node_secret=my-node-secret\u0026enabled=true\nNode = http://10.0.0.2:9000?name=node2\u0026node_secret=my-node-secret\u0026enabled=true\nNode = http://10.0.0.3?name=node3\u0026node_secret=my-node-secret\u0026enabled=true\n```\n\n**File:** internal/cluster/cluster.go (L55-73)\n```go\nfunc parseNodeUrl(nodeUrl string) (node *model.Node, err error) {\n\tu, err := url.Parse(nodeUrl)\n\tif err != nil {\n\t\treturn\n\t}\n\tvar sb strings.Builder\n\tsb.WriteString(u.Scheme)\n\tsb.WriteString(\"://\")\n\tsb.WriteString(u.Host)\n\tsb.WriteString(u.Path)\n\n\tnode = \u0026model.Node{\n\t\tName:    u.Query().Get(\"name\"),\n\t\tURL:     sb.String(),\n\t\tToken:   u.Query().Get(\"node_secret\"),\n\t\tEnabled: u.Query().Get(\"enabled\") == \"true\",\n\t}\n\n\treturn\n```\n\n**File:** internal/kernel/boot.go (L132-144)\n```go\nfunc InitNodeSecret() {\n\tif settings.NodeSettings.Secret == \"\" {\n\t\tlogger.Info(\"Secret is empty, generating...\")\n\t\tuuidStr := uuid.New().String()\n\t\terr := settings.Update(func() {\n\t\t\tsettings.NodeSettings.Secret = uuidStr\n\t\t})\n\t\tif err != nil {\n\t\t\tlogger.Error(\"Error save settings\", err)\n\t\t}\n\t\tlogger.Info(\"Generated Secret: \", uuidStr)\n\t}\n}\n```",
  "id": "GHSA-pvgv-gcp7-v38g",
  "modified": "2026-10-09T17:07:09Z",
  "published": "2026-10-09T17:07:09Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/0xJacky/nginx-ui/security/advisories/GHSA-pvgv-gcp7-v38g"
    },
    {
      "type": "WEB",
      "url": "https://github.com/0xJacky/nginx-ui/commit/a3999bd78a3b97ab22e6b5e9fd478ac57598a954"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/0xJacky/nginx-ui"
    },
    {
      "type": "WEB",
      "url": "https://github.com/0xJacky/nginx-ui/releases/tag/v2.5.0"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H",
      "type": "CVSS_V3"
    }
  ],
  "summary": "Nginx UI: Node Secret Credential Exposure via URL Query Parameter"
}

GHSA-PWP3-PPXM-VG9C

Vulnerability from github – Published: 2026-09-10 15:33 – Updated: 2026-09-10 15:33
VLAI
Details

Flextype CMS through 1.0.0-alpha.3 accepts API authentication credentials through URL query string parameters in REST API routes. Attackers with access to web server, proxy, or monitoring logs can recover valid API token pairs that grant full API access.

Severity
5.9 (Medium)
CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:N/A:N
8.2 (High)
CVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:N/VC:H/VI:N/VA:N/SC:N/SI:N/SA:N
Show details on source website
To clipboard 

{
  "affected": [],
  "aliases": [
    "CVE-2026-88897"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-598"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-09-10T15:17:58Z",
    "severity": "HIGH"
  },
  "details": "Flextype CMS through 1.0.0-alpha.3 accepts API authentication credentials through URL query string parameters in REST API routes. Attackers with access to web server, proxy, or monitoring logs can recover valid API token pairs that grant full API access.",
  "id": "GHSA-pwp3-ppxm-vg9c",
  "modified": "2026-09-10T15:33:21Z",
  "published": "2026-09-10T15:33:21Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-88897"
    },
    {
      "type": "WEB",
      "url": "https://github.com/flextype/flextype/issues/598"
    },
    {
      "type": "WEB",
      "url": "https://github.com/flextype/flextype"
    },
    {
      "type": "WEB",
      "url": "https://github.com/flextype/flextype/blob/v1.0.0-alpha.3/src/flextype/core/Endpoints/Api.php"
    },
    {
      "type": "WEB",
      "url": "https://www.vulncheck.com/advisories/flextype-cms-through-1.0.0-alpha.3-api-token-exposure-via-query-string"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:N/A:N",
      "type": "CVSS_V3"
    },
    {
      "score": "CVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:N/VC:H/VI:N/VA:N/SC:N/SI:N/SA:N/E:X/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:X",
      "type": "CVSS_V4"
    }
  ]
}

GHSA-PX37-V4HM-7F6Q

Vulnerability from github – Published: 2024-02-02 03:30 – Updated: 2024-02-02 03:30
VLAI
Details

IBM PowerSC 1.3, 2.0, and 2.1 may allow a remote attacker to view session identifiers passed via URL query strings. IBM X-Force ID: 275110.

Severity
3.7 (Low)
CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:L/I:N/A:N
Show details on source website
To clipboard 

{
  "affected": [],
  "aliases": [
    "CVE-2023-50328"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-598",
      "CWE-668"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2024-02-02T02:15:16Z",
    "severity": "LOW"
  },
  "details": "IBM PowerSC 1.3, 2.0, and 2.1 may allow a remote attacker to view session identifiers passed via URL query strings.  IBM X-Force ID:  275110.\n\n",
  "id": "GHSA-px37-v4hm-7f6q",
  "modified": "2024-02-02T03:30:32Z",
  "published": "2024-02-02T03:30:32Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-50328"
    },
    {
      "type": "WEB",
      "url": "https://exchange.xforce.ibmcloud.com/vulnerabilities/275110"
    },
    {
      "type": "WEB",
      "url": "https://www.ibm.com/support/pages/node/7113759"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:L/I:N/A:N",
      "type": "CVSS_V3"
    }
  ]
}
Mitigation
Implementation

When sending sensitive information, only include it in the request body or request headers instead of the query string. This may require avoiding use of GET requests.

No CAPEC attack patterns related to this CWE.

← Back to the CWE list