CWE-312
AllowedCleartext Storage of Sensitive Information
Abstraction: Base · Status: Draft
The product stores sensitive information in cleartext within a resource that might be accessible to another control sphere.
1141 vulnerabilities reference this CWE, most recent first.
GHSA-PQW6-WHQX-5MV6
Vulnerability from github – Published: 2022-11-29 00:30 – Updated: 2022-12-02 00:30The /device/signin end-point for the Ourphoto App version 1.4.1 discloses clear-text password information for functionality within the picture frame devices. The deviceVideoCallPassword and mqttPassword are returned in clear-text. The lack of sessions management and presence of insecure direct object references allows to return password information for other end-users devices. Many of the picture frame devices offer video calling, and it is likely this information can be used to abuse that functionality.
{
"affected": [],
"aliases": [
"CVE-2022-24188"
],
"database_specific": {
"cwe_ids": [
"CWE-312"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2022-11-28T22:15:00Z",
"severity": "HIGH"
},
"details": "The /device/signin end-point for the Ourphoto App version 1.4.1 discloses clear-text password information for functionality within the picture frame devices. The deviceVideoCallPassword and mqttPassword are returned in clear-text. The lack of sessions management and presence of insecure direct object references allows to return password information for other end-users devices. Many of the picture frame devices offer video calling, and it is likely this information can be used to abuse that functionality.",
"id": "GHSA-pqw6-whqx-5mv6",
"modified": "2022-12-02T00:30:25Z",
"published": "2022-11-29T00:30:19Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2022-24188"
},
{
"type": "WEB",
"url": "https://www.scrawledsecurityblog.com/2022/11/automating-unsolicited-richard-pics.html"
}
],
"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-PRH4-VHFH-24MJ
Vulnerability from github – Published: 2026-03-26 22:25 – Updated: 2026-03-26 22:25Impact
Harbor write configuration payload to audit log when configuration change, the ldap_search_password and oidc_client_secret will be logged in the audit log without redacted
Patches
Harbor v2.15.0, v2.14.3, v2.13.5
Workarounds
Disable audit log configure event in Harbor Web Console: Go to Administration -> Configuration -> Enable Audit Log Event Type -> Uncheck "Update Configuration" and click "Save" Button.
{
"affected": [
{
"package": {
"ecosystem": "Go",
"name": "github.com/goharbor/harbor"
},
"ranges": [
{
"events": [
{
"introduced": "2.13.0"
},
{
"fixed": "2.13.5"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "Go",
"name": "github.com/goharbor/harbor"
},
"ranges": [
{
"events": [
{
"introduced": "2.14.0"
},
{
"fixed": "2.14.3"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [],
"database_specific": {
"cwe_ids": [
"CWE-312",
"CWE-532"
],
"github_reviewed": true,
"github_reviewed_at": "2026-03-26T22:25:26Z",
"nvd_published_at": null,
"severity": "MODERATE"
},
"details": "### Impact\nHarbor write configuration payload to audit log when configuration change, the ldap_search_password and oidc_client_secret will be logged in the audit log without redacted\n\n### Patches\nHarbor v2.15.0, v2.14.3, v2.13.5\n\n### Workarounds\nDisable audit log configure event in Harbor Web Console: Go to Administration -\u003e Configuration -\u003e Enable Audit Log Event Type -\u003e Uncheck \"Update Configuration\" and click \"Save\" Button.",
"id": "GHSA-prh4-vhfh-24mj",
"modified": "2026-03-26T22:25:26Z",
"published": "2026-03-26T22:25:26Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/goharbor/harbor/security/advisories/GHSA-prh4-vhfh-24mj"
},
{
"type": "WEB",
"url": "https://github.com/goharbor/harbor/commit/85e756486fc19333c5c300d7ac273e1580dc9350"
},
{
"type": "PACKAGE",
"url": "https://github.com/goharbor/harbor"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:H/UI:N/VC:H/VI:N/VA:N/SC:N/SI:N/SA:N",
"type": "CVSS_V4"
}
],
"summary": "Harbor: LDAP password and OIDC secret are not redacted in the audit log"
}
GHSA-PV69-PH5F-43VX
Vulnerability from github – Published: 2022-05-24 19:20 – Updated: 2022-05-24 19:20A password mismanagement situation exists in XoruX LPAR2RRD and STOR2RRD before 7.30 because cleartext information is present in HTML password input fields in the device properties. (Viewing the passwords requires configuring a web browser to display HTML password input fields.)
{
"affected": [],
"aliases": [
"CVE-2021-42370"
],
"database_specific": {
"cwe_ids": [
"CWE-312"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2021-11-08T05:15:00Z",
"severity": "HIGH"
},
"details": "A password mismanagement situation exists in XoruX LPAR2RRD and STOR2RRD before 7.30 because cleartext information is present in HTML password input fields in the device properties. (Viewing the passwords requires configuring a web browser to display HTML password input fields.)",
"id": "GHSA-pv69-ph5f-43vx",
"modified": "2022-05-24T19:20:03Z",
"published": "2022-05-24T19:20:03Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/orangecertcc/security-research/security/advisories/GHSA-f3qp-4xqq-2wjx"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2021-42370"
},
{
"type": "WEB",
"url": "https://lpar2rrd.com/note730.php"
},
{
"type": "WEB",
"url": "https://stor2rrd.com/note730.php"
}
],
"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-PVGV-GCP7-V38G
Vulnerability from github – Published: 2026-10-09 17:07 – Updated: 2026-10-09 17:071. 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)
}
}
{
"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-PVV9-MC25-J2PR
Vulnerability from github – Published: 2024-02-10 18:30 – Updated: 2024-02-10 18:30IBM Storage Defender - Resiliency Service 2.0 could allow a privileged user to perform unauthorized actions after obtaining encrypted data from clear text key storage. IBM X-Force ID: 275783.
{
"affected": [],
"aliases": [
"CVE-2023-50957"
],
"database_specific": {
"cwe_ids": [
"CWE-269",
"CWE-312"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2024-02-10T16:15:07Z",
"severity": "HIGH"
},
"details": "IBM Storage Defender - Resiliency Service 2.0 could allow a privileged user to perform unauthorized actions after obtaining encrypted data from clear text key storage. IBM X-Force ID: 275783.",
"id": "GHSA-pvv9-mc25-j2pr",
"modified": "2024-02-10T18:30:34Z",
"published": "2024-02-10T18:30:34Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-50957"
},
{
"type": "WEB",
"url": "https://exchange.xforce.ibmcloud.com/vulnerabilities/275783"
},
{
"type": "WEB",
"url": "https://www.ibm.com/support/pages/node/7115261"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:H/PR:H/UI:N/S:C/C:H/I:H/A:H",
"type": "CVSS_V3"
}
]
}
GHSA-PXRF-M294-JQFF
Vulnerability from github – Published: 2022-05-24 19:02 – Updated: 2022-05-24 19:02An issue was discovered in Couchbase Server 5.x and 6.x through 6.6.1 and 7.0.0 Beta. Incorrect commands to the REST API can result in leaked authentication information being stored in cleartext in the debug.log and info.log files, and is also shown in the UI visible to administrators.
{
"affected": [],
"aliases": [
"CVE-2021-25644"
],
"database_specific": {
"cwe_ids": [
"CWE-312"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2021-05-19T19:15:00Z",
"severity": "HIGH"
},
"details": "An issue was discovered in Couchbase Server 5.x and 6.x through 6.6.1 and 7.0.0 Beta. Incorrect commands to the REST API can result in leaked authentication information being stored in cleartext in the debug.log and info.log files, and is also shown in the UI visible to administrators.",
"id": "GHSA-pxrf-m294-jqff",
"modified": "2022-05-24T19:02:47Z",
"published": "2022-05-24T19:02:47Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2021-25644"
},
{
"type": "WEB",
"url": "https://www.couchbase.com/downloads"
},
{
"type": "WEB",
"url": "https://www.couchbase.com/resources/security#SecurityAlerts"
}
],
"schema_version": "1.4.0",
"severity": []
}
GHSA-PXXP-9P24-326H
Vulnerability from github – Published: 2022-05-13 01:34 – Updated: 2022-05-13 01:34389-ds-base before versions 1.3.8.5, 1.4.0.12 is vulnerable to a Cleartext Storage of Sensitive Information. By default, when the Replica and/or retroChangeLog plugins are enabled, 389-ds-base stores passwords in plaintext format in their respective changelog files. An attacker with sufficiently high privileges, such as root or Directory Manager, can query these files in order to retrieve plaintext passwords.
{
"affected": [],
"aliases": [
"CVE-2018-10871"
],
"database_specific": {
"cwe_ids": [
"CWE-312"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2018-07-18T13:29:00Z",
"severity": "HIGH"
},
"details": "389-ds-base before versions 1.3.8.5, 1.4.0.12 is vulnerable to a Cleartext Storage of Sensitive Information. By default, when the Replica and/or retroChangeLog plugins are enabled, 389-ds-base stores passwords in plaintext format in their respective changelog files. An attacker with sufficiently high privileges, such as root or Directory Manager, can query these files in order to retrieve plaintext passwords.",
"id": "GHSA-pxxp-9p24-326h",
"modified": "2022-05-13T01:34:56Z",
"published": "2022-05-13T01:34:56Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2018-10871"
},
{
"type": "WEB",
"url": "https://access.redhat.com/errata/RHSA-2019:3401"
},
{
"type": "WEB",
"url": "https://bugzilla.redhat.com/show_bug.cgi?id=CVE-2018-10871"
},
{
"type": "WEB",
"url": "https://lists.debian.org/debian-lts-announce/2018/08/msg00032.html"
},
{
"type": "WEB",
"url": "https://pagure.io/389-ds-base/issue/49789"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.0/AV:N/AC:L/PR:H/UI:N/S:U/C:H/I:H/A:H",
"type": "CVSS_V3"
}
]
}
GHSA-Q2HM-2H45-V5G3
Vulnerability from github – Published: 2022-11-21 22:37 – Updated: 2022-12-03 04:09Impact
We discovered that when the reset a forgotten password feature of XWiki was used, the password was then stored in plain text in database. This only concerns XWiki 13.1RC1 and next versions. Note that it only concerns the reset password feature available from the "Forgot your password" link in the login view: the features allowing a user to change their password, or for an admin to change a user password are not impacted.
This vulnerability is particularly dangerous in combination with other vulnerabilities allowing to perform data leak of personal data from users, such as https://github.com/xwiki/xwiki-platform/security/advisories/GHSA-599v-w48h-rjrm.
Note that this vulnerability only concerns the users of the main wiki: in case of farms, the users registered on subwiki are not impacted thanks to a bug we discovered when investigating this.
Patches
The problem has been patched in version 14.6RC1, 14.4.3 and 13.10.8.
The patch involves a migration of the impacted users as well as the history of the page, to ensure no password remains in plain text in the database. This migration also involves to inform the users about the possible disclosure of their passwords: by default, two emails are automatically sent to the impacted users. A first email to inform about the possibility that their password have been leaked, and a second email using the reset password feature to ask them to set a new password. See below for the configuration options to disable the mail sending.
The first email contains by default the following text (could be translated depending on the wiki language settings):
Subject: Important security issue
Dear user,
due to a bug your password was stored in plain text in our wiki. We cannot exclude that your plain text password was exposed in a data leak. Therefore, you might receive a second email to choose a new password.
Please contact the administrator in case of problem or for further questions.
It's possible to specify another text by creating a file at the root of the permanent directory named 140600000XWIKI19869-mail.txt, this file should have same structure as used above:
Subject: [your custom subject]
[your custom mail content]
This mail is sent plain text and cannot contain any variable. Note that the second mail for the reset password is using the standard feature, so you can find information about the email templates there. Also note that if the users doesn't have any registered email address obviously no mail will be sent, so it's the administrators responsibility to find a way to contact the user (through comment on the user profile, or any other channel used for that wiki). The administrator should be particularly careful on the presence of logs such as:
WARN WIKI19869DataMigrationListener - Reset email cannot be sent for user [reference = [xwiki:XWiki.Foo]] as no email address is provided
It's also possible for administrators to set some properties for the migration: it's possible to decide if the user password should be reset (default) or if the passwords should be kept but only hashed. Note that in the first option, the users won't be able to login anymore until they set a new password if they were impacted. Note that in both options, mails will be sent to users to inform them and encourage them to change their passwords.
Two other properties are available to chose the behaviour regarding the mails to be sent: it's possible to chose to only send the first security email, or to only send the reset password email. It's important to note that those emails are sent after the migration during the initialization of the wiki, by reading a file creating by the migration in the permanent directory (the file is named 140600000XWIKI19869DataMigration-users.txt): then it's possible for an administrator to chose to not sent any email when the migration is performed (by setting the properties to false), and to send them later in a future restart by then setting back the properties to true before the restart of the wiki. Also note that the file is deleted after the mails are sent.
The mentioned properties can be found in xwiki.properties in the [Security] section:
#-# [Since 14.6RC1]
#-# [Since 14.4.3]
#-# [Since 13.10.8]
#-# This option is only used when performing a migration from a wiki before the versions mentioning above.
#-# This parameter defines if as part of the migration R140600000XWIKI19869 the passwords of impacted user should be
#-# reset or not. It's advised to keep this value as true, now for some usecases advertised administrators might want
#-# their users to keep their passwords nevertheless, then enable the configuration and set it to false before the
#-# migration is executed.
# security.migration.R140600000XWIKI19869.resetPassword = true
#-# [Since 14.6RC1]
#-# [Since 14.4.3]
#-# [Since 13.10.8]
#-# This option is only used when performing a migration from a wiki before the versions mentioned above.
#-# This parameter defines if reset password emails should be sent as part of the migration R140600000XWIKI19869.
#-# By default this value is set to true, so emails will be automatically produced. Now it's possible for admin to set
#-# this option to false: note that in such case a file containing the list of users for whom a reset password email
#-# should be sent will still be created in the permanent directory (named 140600000XWIKI19869DataMigration-users.txt).
#-# If this file exists and this property is set back to true after the migration, the file will still be consumed to
#-# send the emails, so it's possible to perform the migration and send the emails only later if needed.
# security.migration.R140600000XWIKI19869.sendResetPasswordEmail = true
#-# [Since 14.6RC1]
#-# [Since 14.4.3]
#-# [Since 13.10.8]
#-# This option is only used when performing a migration from a wiki before the versions mentioned above.
#-#
#-# This parameter defines if a security email information should be sent as part of the migration R140600000XWIKI19869.
#-# By default this value is set to true, so emails will be automatically produced. Now it's possible for admin to set
#-# this option to false: note that in such case a file containing the list of users for whom a reset password email
#-# should be sent will still be created in the permanent directory (named 140600000XWIKI19869DataMigration-users.txt).
#-# If this file exists and this property is set back to true after the migration, the file will still be consumed to
#-# send the emails, so it's possible to perform the migration and send the emails only later if needed.
# security.migration.R140600000XWIKI19869.sendSecurityEmail = true
Workarounds
There is actually 2 parts of the vulnerability:
1. users who might have use the reset feature should get their password protected. We provide some instructions how to identify and fix those.
2. the next usage of the reset password feature shouldn't lead to plain text password: sadly there is no easy workaround for that, except by recompiling xwiki-platform-security-authentication-default with that change: https://github.com/xwiki/xwiki-platform/commit/443e8398b75a1295067d74afb5898370782d863a#diff-f8a8f8ba80dfc55f044e2e60b521ce379176430ca6921b0f87b79cf682531f79L322
It's possible to identify all impacted users and to manually reset their passwords with an Admin account. For identifying the impacted users, a query such as the following is possible:
{{velocity}}
## The statement is put on multiple lines for readability of the snippet
#set ($statement = "select distinct doc.fullName from Document doc, doc.object(XWiki.XWikiUsers) objUser
where objUser.password not like 'hash:%' and objUser.password <> ''
order by doc.fullName")
$services.query.xwql($statement).execute()
{{/velocity}}
Once impacted users are identified at least 2 options are possible: 1. Set a new password (manually by going to the user profile, or automatically with a groovy script for example) 4. rollback to a previous version of the user document: in such case the password will be automatically processed properly
Be aware that those workarounds won't remove the clear password entry that might remain in database due to history.
References
- Jira ticket: https://jira.xwiki.org/browse/XWIKI-19869
- Advisory of a data leak vulnerability that increases the criticality of this vulnerability: https://github.com/xwiki/xwiki-platform/security/advisories/GHSA-599v-w48h-rjrm
- Bug discovered "protecting" subwiki from this vulnerability: https://jira.xwiki.org/browse/XWIKI-19945
For more information
If you have any questions or comments about this advisory: * Open an issue in Jira * Email us at security ML
{
"affected": [
{
"package": {
"ecosystem": "Maven",
"name": "org.xwiki.platform:xwiki-platform-security-authentication-default"
},
"ranges": [
{
"events": [
{
"introduced": "13.1RC1"
},
{
"fixed": "13.10.8"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "Maven",
"name": "org.xwiki.platform:xwiki-platform-security-authentication-default"
},
"ranges": [
{
"events": [
{
"introduced": "14.0.0"
},
{
"fixed": "14.4.3"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2022-41933"
],
"database_specific": {
"cwe_ids": [
"CWE-312",
"CWE-522"
],
"github_reviewed": true,
"github_reviewed_at": "2022-11-21T22:37:11Z",
"nvd_published_at": "2022-11-23T21:15:00Z",
"severity": "MODERATE"
},
"details": "### Impact\n\nWe discovered that when the reset a forgotten password feature of XWiki was used, the password was then stored in plain text in database. This only concerns XWiki 13.1RC1 and next versions.\nNote that it only concerns the reset password feature available from the \"Forgot your password\" link in the login view: the features allowing a user to change their password, or for an admin to change a user password are not impacted.\n\nThis vulnerability is particularly dangerous in combination with other vulnerabilities allowing to perform data leak of personal data from users, such as https://github.com/xwiki/xwiki-platform/security/advisories/GHSA-599v-w48h-rjrm. \n\nNote that this vulnerability only concerns the users of the main wiki: in case of farms, the users registered on subwiki are not impacted thanks to a bug we discovered when investigating this.\n\n### Patches\n\nThe problem has been patched in version 14.6RC1, 14.4.3 and 13.10.8.\n\nThe patch involves a migration of the impacted users as well as the history of the page, to ensure no password remains in plain text in the database. This migration also involves to inform the users about the possible disclosure of their passwords: by default, two emails are automatically sent to the impacted users. A first email to inform about the possibility that their password have been leaked, and a second email using the reset password feature to ask them to set a new password. See below for the configuration options to disable the mail sending.\n\nThe first email contains by default the following text (could be translated depending on the wiki language settings):\n```\nSubject: Important security issue\nDear user,\n\ndue to a bug your password was stored in plain text in our wiki. We cannot exclude that your plain text password was exposed in a data leak. Therefore, you might receive a second email to choose a new password. \nPlease contact the administrator in case of problem or for further questions.\n```\nIt\u0027s possible to specify another text by creating a file at the root of the permanent directory named `140600000XWIKI19869-mail.txt`, this file should have same structure as used above:\n```\nSubject: [your custom subject]\n[your custom mail content]\n```\nThis mail is sent plain text and cannot contain any variable. \nNote that the second mail for the reset password is using the standard feature, so you can find information about the email templates [there](https://www.xwiki.org/xwiki/bin/view/Documentation/AdminGuide/Authentication/#HMailTemplates).\nAlso note that if the users doesn\u0027t have any registered email address obviously no mail will be sent, so it\u0027s the administrators responsibility to find a way to contact the user (through comment on the user profile, or any other channel used for that wiki). The administrator should be particularly careful on the presence of logs such as: \n```\nWARN WIKI19869DataMigrationListener - Reset email cannot be sent for user [reference = [xwiki:XWiki.Foo]] as no email address is provided\n```\n\nIt\u0027s also possible for administrators to set some properties for the migration: it\u0027s possible to decide if the user password should be reset (default) or if the passwords should be kept but only hashed. Note that in the first option, the users won\u0027t be able to login anymore until they set a new password if they were impacted. Note that in both options, mails will be sent to users to inform them and encourage them to change their passwords.\n\nTwo other properties are available to chose the behaviour regarding the mails to be sent: it\u0027s possible to chose to only send the first security email, or to only send the reset password email. It\u0027s important to note that those emails are sent after the migration during the initialization of the wiki, by reading a file creating by the migration in the permanent directory (the file is named `140600000XWIKI19869DataMigration-users.txt`): then it\u0027s possible for an administrator to chose to not sent any email when the migration is performed (by setting the properties to false), and to send them later in a future restart by then setting back the properties to true before the restart of the wiki. Also note that the file is deleted after the mails are sent. \n\nThe mentioned properties can be found in `xwiki.properties` in the `[Security]` section:\n```\n#-# [Since 14.6RC1]\n#-# [Since 14.4.3]\n#-# [Since 13.10.8]\n#-# This option is only used when performing a migration from a wiki before the versions mentioning above.\n#-# This parameter defines if as part of the migration R140600000XWIKI19869 the passwords of impacted user should be\n#-# reset or not. It\u0027s advised to keep this value as true, now for some usecases advertised administrators might want\n#-# their users to keep their passwords nevertheless, then enable the configuration and set it to false before the\n#-# migration is executed.\n# security.migration.R140600000XWIKI19869.resetPassword = true\n\n#-# [Since 14.6RC1]\n#-# [Since 14.4.3]\n#-# [Since 13.10.8]\n#-# This option is only used when performing a migration from a wiki before the versions mentioned above.\n\n#-# This parameter defines if reset password emails should be sent as part of the migration R140600000XWIKI19869.\n#-# By default this value is set to true, so emails will be automatically produced. Now it\u0027s possible for admin to set\n#-# this option to false: note that in such case a file containing the list of users for whom a reset password email\n#-# should be sent will still be created in the permanent directory (named 140600000XWIKI19869DataMigration-users.txt).\n#-# If this file exists and this property is set back to true after the migration, the file will still be consumed to\n#-# send the emails, so it\u0027s possible to perform the migration and send the emails only later if needed.\n# security.migration.R140600000XWIKI19869.sendResetPasswordEmail = true\n\n#-# [Since 14.6RC1]\n#-# [Since 14.4.3]\n#-# [Since 13.10.8]\n#-# This option is only used when performing a migration from a wiki before the versions mentioned above.\n#-#\n#-# This parameter defines if a security email information should be sent as part of the migration R140600000XWIKI19869.\n#-# By default this value is set to true, so emails will be automatically produced. Now it\u0027s possible for admin to set\n#-# this option to false: note that in such case a file containing the list of users for whom a reset password email\n#-# should be sent will still be created in the permanent directory (named 140600000XWIKI19869DataMigration-users.txt).\n#-# If this file exists and this property is set back to true after the migration, the file will still be consumed to\n#-# send the emails, so it\u0027s possible to perform the migration and send the emails only later if needed.\n# security.migration.R140600000XWIKI19869.sendSecurityEmail = true\n```\n\n\n### Workarounds\n\nThere is actually 2 parts of the vulnerability:\n 1. users who might have use the reset feature should get their password protected. We provide some instructions how to identify and fix those. \n 2. the next usage of the reset password feature shouldn\u0027t lead to plain text password: sadly there is no easy workaround for that, except by recompiling `xwiki-platform-security-authentication-default` with that change: https://github.com/xwiki/xwiki-platform/commit/443e8398b75a1295067d74afb5898370782d863a#diff-f8a8f8ba80dfc55f044e2e60b521ce379176430ca6921b0f87b79cf682531f79L322\n \nIt\u0027s possible to identify all impacted users and to manually reset their passwords with an Admin account. For identifying the impacted users, a query such as the following is possible:\n\n```\n{{velocity}}\n## The statement is put on multiple lines for readability of the snippet\n#set ($statement = \"select distinct doc.fullName from Document doc, doc.object(XWiki.XWikiUsers) objUser \nwhere objUser.password not like \u0027hash:%\u0027 and objUser.password \u003c\u003e \u0027\u0027 \norder by doc.fullName\")\n$services.query.xwql($statement).execute()\n{{/velocity}}\n```\nOnce impacted users are identified at least 2 options are possible:\n 1. Set a new password (manually by going to the user profile, or automatically with a groovy script for example)\n 4. rollback to a previous version of the user document: in such case the password will be automatically processed properly\n\nBe aware that those workarounds won\u0027t remove the clear password entry that might remain in database due to history.\n\n### References\n\n * Jira ticket: https://jira.xwiki.org/browse/XWIKI-19869\n * Advisory of a data leak vulnerability that increases the criticality of this vulnerability: https://github.com/xwiki/xwiki-platform/security/advisories/GHSA-599v-w48h-rjrm\n * Bug discovered \"protecting\" subwiki from this vulnerability: https://jira.xwiki.org/browse/XWIKI-19945\n\n### For more information\nIf you have any questions or comments about this advisory:\n* Open an issue in [Jira](https://jira.xwiki.org)\n* Email us at [security ML](mailto:security@xwiki.org)\n",
"id": "GHSA-q2hm-2h45-v5g3",
"modified": "2022-12-03T04:09:18Z",
"published": "2022-11-21T22:37:11Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/xwiki/xwiki-platform/security/advisories/GHSA-599v-w48h-rjrm"
},
{
"type": "WEB",
"url": "https://github.com/xwiki/xwiki-platform/security/advisories/GHSA-q2hm-2h45-v5g3"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2022-41933"
},
{
"type": "WEB",
"url": "https://github.com/xwiki/xwiki-platform/commit/443e8398b75a1295067d74afb5898370782d863a#diff-f8a8f8ba80dfc55f044e2e60b521ce379176430ca6921b0f87b79cf682531f79L322"
},
{
"type": "PACKAGE",
"url": "https://github.com/xwiki/xwiki-platform"
},
{
"type": "WEB",
"url": "https://jira.xwiki.org/browse/XWIKI-19869"
},
{
"type": "WEB",
"url": "https://jira.xwiki.org/browse/XWIKI-19945"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:H/UI:R/S:C/C:H/I:N/A:N",
"type": "CVSS_V3"
}
],
"summary": "Plaintext storage of password after a reset in org.xwiki.platform:xwiki-platform-security-authentication-default"
}
GHSA-Q2Q3-G3X6-PFHJ
Vulnerability from github – Published: 2025-12-04 21:31 – Updated: 2025-12-04 21:31R Radio Network FM Transmitter 1.07 allows unauthenticated attackers to access the admin user's password through the system.cgi endpoint, enabling authentication bypass and FM station setup access.
{
"affected": [],
"aliases": [
"CVE-2024-58277"
],
"database_specific": {
"cwe_ids": [
"CWE-312"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2025-12-04T21:16:07Z",
"severity": "HIGH"
},
"details": "R Radio Network FM Transmitter 1.07 allows unauthenticated attackers to access the admin user\u0027s password through the system.cgi endpoint, enabling authentication bypass and FM station setup access.",
"id": "GHSA-q2q3-g3x6-pfhj",
"modified": "2025-12-04T21:31:06Z",
"published": "2025-12-04T21:31:06Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-58277"
},
{
"type": "WEB",
"url": "https://www.exploit-db.com/exploits/51855"
},
{
"type": "WEB",
"url": "https://www.vulncheck.com/advisories/r-radio-network-fm-transmitter-107-system-settings-disclosure"
},
{
"type": "WEB",
"url": "https://www.zeroscience.mk/en/vulnerabilities/ZSL-2023-5802.php"
}
],
"schema_version": "1.4.0",
"severity": [
{
"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-Q47V-W7JJ-MHCF
Vulnerability from github – Published: 2025-05-25 21:30 – Updated: 2026-10-07 09:31A vulnerability, which was classified as problematic, was found in PhonePe App 25.03.21.0 on Android. Affected is an unknown function of the file /data/data/com.phonepe.app/databases/ of the component SQLite Database. The manipulation leads to cleartext storage in a file or on disk. Local access is required to approach this attack. The exploit has been disclosed to the public and may be used.
{
"affected": [],
"aliases": [
"CVE-2025-5154"
],
"database_specific": {
"cwe_ids": [
"CWE-312"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2025-05-25T19:15:19Z",
"severity": "MODERATE"
},
"details": "A vulnerability, which was classified as problematic, was found in PhonePe App 25.03.21.0 on Android. Affected is an unknown function of the file /data/data/com.phonepe.app/databases/ of the component SQLite Database. The manipulation leads to cleartext storage in a file or on disk. Local access is required to approach this attack. The exploit has been disclosed to the public and may be used.",
"id": "GHSA-q47v-w7jj-mhcf",
"modified": "2026-10-07T09:31:25Z",
"published": "2025-05-25T21:30:27Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-5154"
},
{
"type": "WEB",
"url": "https://drive.google.com/drive/folders/1Xj9y2w3E98IZu8PUeGGI0nQPNsvVm87I?usp=sharing"
},
{
"type": "WEB",
"url": "https://github.com/honestcorrupt/-Insecure-Local-Storage-of-Sensitive-User-Data-in-PhonePe-Android-App-Unpatched-"
},
{
"type": "WEB",
"url": "https://vuldb.com/?ctiid.310242"
},
{
"type": "WEB",
"url": "https://vuldb.com/?id.310242"
},
{
"type": "WEB",
"url": "https://vuldb.com/?submit.576245"
},
{
"type": "WEB",
"url": "https://vuldb.com/cve/CVE-2025-5154"
},
{
"type": "WEB",
"url": "https://vuldb.com/submit/576245"
},
{
"type": "WEB",
"url": "https://vuldb.com/vuln/310242"
},
{
"type": "WEB",
"url": "https://vuldb.com/vuln/310242/cti"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:L/AC:L/PR:H/UI:N/S:U/C:L/I:N/A:N",
"type": "CVSS_V3"
},
{
"score": "CVSS:4.0/AV:L/AC:L/AT:N/PR:H/UI:N/VC:L/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"
}
]
}
Mitigation
When storing data in the cloud (e.g., S3 buckets, Azure blobs, Google Cloud Storage, etc.), use the provider's controls to encrypt the data at rest. [REF-1297] [REF-1299] [REF-1301]
Mitigation
In some systems/environments such as cloud, the use of "double encryption" (at both the software and hardware layer) might be required, and the developer might be solely responsible for both layers, instead of shared responsibility with the administrator of the broader system/environment.
CAPEC-37: Retrieve Embedded Sensitive Data
An attacker examines a target system to find sensitive data that has been embedded within it. This information can reveal confidential contents, such as account numbers or individual keys/credentials that can be used as an intermediate step in a larger attack.