Skip to content

Commit d04dba4

Browse files

File tree

5 files changed

+37
-11
lines changed

5 files changed

+37
-11
lines changed

advisories/github-reviewed/2026/03/GHSA-2h2p-mvfx-868w/GHSA-2h2p-mvfx-868w.json

Lines changed: 4 additions & 2 deletions
Original file line numberDiff line numberDiff line change
@@ -1,9 +1,11 @@
11
{
22
"schema_version": "1.4.0",
33
"id": "GHSA-2h2p-mvfx-868w",
4-
"modified": "2026-03-07T02:19:45Z",
4+
"modified": "2026-03-09T13:13:10Z",
55
"published": "2026-03-07T02:19:45Z",
6-
"aliases": [],
6+
"aliases": [
7+
"CVE-2026-30869"
8+
],
79
"summary": "SiYuan Vulnerable to Path Traversal in /export Endpoint Allows Arbitrary File Read and Secret Leakage",
810
"details": "### Summary\nA path traversal vulnerability in the `/export` endpoint allows an attacker to read arbitrary files from the server filesystem. By exploiting double‑encoded traversal sequences, an attacker can access sensitive files such as `conf/conf.json`, which contains secrets including the API token, cookie signing key, and workspace access authentication code.\n\nLeaking these secrets may enable administrative access to the SiYuan kernel API, and in certain deployment scenarios could potentially be chained into `remote code execution (RCE)`.\n\n### Details\nFile: [serve.go](app://-/index.html?hostId=local#), [session.go](app://-/index.html?hostId=local#)\nLines: serve.go 303, 315, 320, 340, 955-957; session.go 292-295\n\nVulnerable Code:\n```\n// session.go\nif localhost {\n if strings.HasPrefix(c.Request.RequestURI, \"/assets/\") || strings.HasPrefix(c.Request.RequestURI, \"/export/\") {\n c.Set(RoleContextKey, RoleAdministrator)\n c.Next()\n return\n }\n}\n\n// serve.go\nfilePath := strings.TrimPrefix(c.Request.URL.Path, \"/export/\")\ndecodedPath, err := url.PathUnescape(filePath)\nfullPath := filepath.Join(exportBaseDir, decodedPath)\nc.File(fullPath)\n\n// CORS\nc.Header(\"Access-Control-Allow-Origin\", \"*\")\n\n```\nPoints of Vulnerability:\n\n- `/export/*` trusts url.PathUnescape output and joins it without enforcing fullPath to stay under exportBaseDir.\n- Double-encoded traversal (`%252e%252e`) bypasses `ServeFile` dot-dot URL rejection but is decoded by app logic into ...\n- `CheckAuth` grants admin for localhost requests to `/export/*` when access auth code is set.\n- Global CORS `Access-Control-Allow-Origin: *` allows hostile web pages to read localhost responses.\n\n### PoC\n\nReproduction Steps:\n\n1. Send a GET request to `/export/%252e%252e/%252e%252e/conf/conf.json` or `export/%252e%252e/%252e%252e/%252e%252e/%252e%252e/%252e%252e/%252e%252e/%252e%252e/etc/passwd`\n\n2. If HTTP 200 is returned, inspect the response body for sensitive fields:\n```\napi.token\ncookieKey\naccessAuthCode\n```\nor\n```\n/etc/passwd\n```\n\n3. (Optional) If api.token is present, test admin API access:\n```\nPOST /api/system/getNetwork\nHeader: Authorization: Token <leaked token>\n```\n\n4. Confirm that the response indicates administrative privileges.\nAll steps can be performed with read-only HTTP requests; no Docker or local modifications are needed.\n### Impact\n\nThis vulnerability can lead to serious compromise of a SiYuan instance, including:\n\n**Arbitrary File Disclosure**\n- Attackers can read files anywhere on the server filesystem, including system files such as /etc/passwd.\n\n**Exposure of Sensitive Secrets**\n- Configuration files such as conf/conf.json contain sensitive information including:\n- API tokens\n- cookie signing keys\n- workspace authentication codes\n\n**Administrative API Access**\n- Leaked tokens can allow attackers to interact with privileged SiYuan kernel APIs.\n\n**Cross‑Origin Localhost Data Exfiltration**\n- Because the server sets `Access-Control-Allow-Origin: *`, a malicious website can exploit the vulnerability to read files from a victim's local SiYuan instance running on 127.0.0.1.\n\n**Potential Remote Code Execution (RCE)**\n- Disclosure of authentication secrets and internal configuration may enable attackers to chain this vulnerability with other application features or APIs to achieve remote code execution or full system compromise.",
911
"severity": [

advisories/github-reviewed/2026/03/GHSA-595m-wc8g-6qgc/GHSA-595m-wc8g-6qgc.json

Lines changed: 7 additions & 3 deletions
Original file line numberDiff line numberDiff line change
@@ -1,13 +1,13 @@
11
{
22
"schema_version": "1.4.0",
33
"id": "GHSA-595m-wc8g-6qgc",
4-
"modified": "2026-03-06T14:21:56Z",
4+
"modified": "2026-03-09T13:13:28Z",
55
"published": "2026-03-05T21:49:03Z",
66
"aliases": [
77
"CVE-2026-30247"
88
],
99
"summary": "WeKnora is Vulnerable to SSRF via Redirection",
10-
"details": "### Summary\n\nThe application's \"Import document via URL\" feature is vulnerable to Server-Side Request Forgery (SSRF) through HTTP redirects. While the backend implements comprehensive URL validation (blocking private IPs, loopback addresses, reserved hostnames, and cloud metadata endpoints), it **fails to validate redirect targets**. An attacker can bypass all protections by using a redirect chain, forcing the server to access internal services. Additionally, Docker-specific internal addresses like `host.docker.internal` are not blocked.\n\n### Details\n\nThe `/api/v1/knowledge-bases/{id}/knowledge/url` endpoint validates the initial URL but follows HTTP redirects without re-validating the destination. This allows attackers to:\n1. Submit a URL to an attacker-controlled domain (passes validation)\n2. Have that domain respond with a 307 redirect to an internal service\n3. The backend automatically follows the redirect without checking if the destination is restricted\n4. The internal service response is exposed to the attacker\n\n### Validation Gaps\n- The `IsSSRFSafeURL()` function (in `internal/utils/security.go`) validates the initial URL thoroughly, but there's no validation of HTTP redirect targets\n- `host.docker.internal` is not in the `restrictedHostnames` list\n- Docker-specific IP ranges (172.17.0.0/16 for bridge networks) are not explicitly blocked\n- The code validates `parsed.Hostname()` from the initial URL, but redirect Location headers bypass this check\n\n### Root Cause Analysis\nThe backend makes the security mistake of trusting the server's HTTP client library to be secure. In Go, when using http.Get() or similar functions, the standard library will automatically follow redirects up to 10 times by default. The SSRF validation only checks the URL passed to the endpoint, not intermediate redirects.\n\n### PoC\n\n**Step 1**: Set up an attacker-controlled server that responds with a redirect:\n\n```http\nHTTP/1.1 307 Temporary Redirect\nLocation: http://host.docker.internal:7777\nContent-Type: text/html\nAccess-Control-Allow-Origin: *\n```\n**Step 2**: Send the request with a clean URL:\n\n```http\nPOST /api/v1/knowledge-bases/dbadd153-9e60-4213-9553-9f78dbcba0dc/knowledge/url HTTP/1.1\nHost: localhost\nContent-Type: application/json\nAuthorization: Bearer <valid_token>\n\n{\"url\":\"https://attacker-domain.com\",\"tag_id\":\"\"}\n```\n\nThe URL `https://attacker-domain.com` passes all validation checks because:\n✓ Valid `https://` scheme\n✓ Not an IP address (it's a domain)\n✓ Not in restricted hostnames\n✓ Doesn't resolve to a private IP (assuming attacker controls a public domain)\n\n**Step 3**: The backend's HTTP client follows the redirect to `http://host.docker.internal:7777`, which:\n✗ Is not validated\n✗ `host.docker.internal` is not in the blocklist\n✗ Successfully accesses the internal service\n\n### Impact\n\nVulnerability Type: Server-Side Request Forgery (SSRF) via HTTP Redirect\n\n**Who is Impacted**:\n- The organization running the application\n- Internal services and databases accessible from the application container\n- Services in the Docker network (other containers, internal infrastructure)\n- Sensitive data stored in internal services\n\n**Potential Consequences**:\n- Access to internal databases (PostgreSQL, MongoDB, MySQL) running in Docker\n- Information disclosure from internal services (Redis cache, configuration servers)\n- Access to Docker container metadata and environment variables\n- Lateral movement to other containers in the same Docker network\n- Exfiltration of sensitive configuration, API keys, or database credentials\n- Potential RCE if internal services have exploitable vulnerabilities\n\n**CVSS Score**: 7.5 (High) - Could be higher depending on what's exposed\n\n- Vector: CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N\n- Reasoning: Network-accessible via public redirect, no privileges needed, high confidentiality impact",
10+
"details": "### Summary\n\nThe application's \"Import document via URL\" feature is vulnerable to Server-Side Request Forgery (SSRF) through HTTP redirects. While the backend implements comprehensive URL validation (blocking private IPs, loopback addresses, reserved hostnames, and cloud metadata endpoints), it **fails to validate redirect targets**. An attacker can bypass all protections by using a redirect chain, forcing the server to access internal services. Additionally, Docker-specific internal addresses like `host.docker.internal` are not blocked.\n\n### Details\n\nThe `/api/v1/knowledge-bases/{id}/knowledge/url` endpoint validates the initial URL but follows HTTP redirects without re-validating the destination. This allows attackers to:\n1. Submit a URL to an attacker-controlled domain (passes validation)\n2. Have that domain respond with a 307 redirect to an internal service\n3. The backend automatically follows the redirect without checking if the destination is restricted\n4. The internal service response is exposed to the attacker\n\n### Validation Gaps\n- The `IsSSRFSafeURL()` function (in `internal/utils/security.go`) validates the initial URL thoroughly, but there's no validation of HTTP redirect targets\n- `host.docker.internal` is not in the `restrictedHostnames` list\n- Docker-specific IP ranges (172.17.0.0/16 for bridge networks) are not explicitly blocked\n- The code validates `parsed.Hostname()` from the initial URL, but redirect Location headers bypass this check\n\n### Root Cause Analysis\nThe backend makes the security mistake of trusting the server's HTTP client library to be secure. In Go, when using http.Get() or similar functions, the standard library will automatically follow redirects up to 10 times by default. The SSRF validation only checks the URL passed to the endpoint, not intermediate redirects.\n\n### PoC\n\n**Step 1**: Set up an attacker-controlled server that responds with a redirect:\n\n```http\nHTTP/1.1 307 Temporary Redirect\nLocation: http://host.docker.internal:7777\nContent-Type: text/html\nAccess-Control-Allow-Origin: *\n```\n**Step 2**: Send the request with a clean URL:\n\n```http\nPOST /api/v1/knowledge-bases/dbadd153-9e60-4213-9553-9f78dbcba0dc/knowledge/url HTTP/1.1\nHost: localhost\nContent-Type: application/json\nAuthorization: Bearer <valid_token>\n\n{\"url\":\"https://attacker-domain.com\",\"tag_id\":\"\"}\n```\n\nThe URL `https://attacker-domain.com` passes all validation checks because:\n✓ Valid `https://` scheme\n✓ Not an IP address (it's a domain)\n✓ Not in restricted hostnames\n✓ Doesn't resolve to a private IP (assuming attacker controls a public domain)\n\n**Step 3**: The backend's HTTP client follows the redirect to `http://host.docker.internal:7777`, which:\n✗ Is not validated\n✗ `host.docker.internal` is not in the blocklist\n✗ Successfully accesses the internal service\n\n### Impact\n\nVulnerability Type: Server-Side Request Forgery (SSRF) via HTTP Redirect\n\n**Who is Impacted**:\n- The organization running the application\n- Internal services and databases accessible from the application container\n- Services in the Docker network (other containers, internal infrastructure)\n- Sensitive data stored in internal services\n\n**Potential Consequences**:\n- Access to internal databases (PostgreSQL, MongoDB, MySQL) running in Docker\n- Information disclosure from internal services (Redis cache, configuration servers)\n- Access to Docker container metadata and environment variables\n- Lateral movement to other containers in the same Docker network\n- Exfiltration of sensitive configuration, API keys, or database credentials\n- Potential RCE if internal services have exploitable vulnerabilities",
1111
"severity": [
1212
{
1313
"type": "CVSS_V3",
@@ -43,6 +43,10 @@
4343
"type": "WEB",
4444
"url": "https://github.com/Tencent/WeKnora/security/advisories/GHSA-595m-wc8g-6qgc"
4545
},
46+
{
47+
"type": "ADVISORY",
48+
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-30247"
49+
},
4650
{
4751
"type": "PACKAGE",
4852
"url": "https://github.com/Tencent/WeKnora"
@@ -55,6 +59,6 @@
5559
"severity": "MODERATE",
5660
"github_reviewed": true,
5761
"github_reviewed_at": "2026-03-05T21:49:03Z",
58-
"nvd_published_at": null
62+
"nvd_published_at": "2026-03-07T04:15:54Z"
5963
}
6064
}

advisories/github-reviewed/2026/03/GHSA-87x4-j8vh-p5qf/GHSA-87x4-j8vh-p5qf.json

Lines changed: 10 additions & 2 deletions
Original file line numberDiff line numberDiff line change
@@ -1,7 +1,7 @@
11
{
22
"schema_version": "1.4.0",
33
"id": "GHSA-87x4-j8vh-p5qf",
4-
"modified": "2026-03-05T21:48:11Z",
4+
"modified": "2026-03-09T13:12:16Z",
55
"published": "2026-03-05T21:48:11Z",
66
"aliases": [
77
"CVE-2026-30244"
@@ -40,9 +40,17 @@
4040
"type": "WEB",
4141
"url": "https://github.com/makeplane/plane/security/advisories/GHSA-87x4-j8vh-p5qf"
4242
},
43+
{
44+
"type": "ADVISORY",
45+
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-30244"
46+
},
4347
{
4448
"type": "PACKAGE",
4549
"url": "https://github.com/makeplane/plane"
50+
},
51+
{
52+
"type": "WEB",
53+
"url": "https://github.com/makeplane/plane/releases/tag/v1.2.2"
4654
}
4755
],
4856
"database_specific": {
@@ -53,6 +61,6 @@
5361
"severity": "HIGH",
5462
"github_reviewed": true,
5563
"github_reviewed_at": "2026-03-05T21:48:11Z",
56-
"nvd_published_at": null
64+
"nvd_published_at": "2026-03-06T22:16:01Z"
5765
}
5866
}

advisories/github-reviewed/2026/03/GHSA-fpx8-73gf-7x73/GHSA-fpx8-73gf-7x73.json

Lines changed: 10 additions & 2 deletions
Original file line numberDiff line numberDiff line change
@@ -1,7 +1,7 @@
11
{
22
"schema_version": "1.4.0",
33
"id": "GHSA-fpx8-73gf-7x73",
4-
"modified": "2026-03-05T21:43:15Z",
4+
"modified": "2026-03-09T13:12:11Z",
55
"published": "2026-03-05T21:43:15Z",
66
"aliases": [
77
"CVE-2026-30242"
@@ -43,9 +43,17 @@
4343
"type": "WEB",
4444
"url": "https://github.com/makeplane/plane/security/advisories/GHSA-fpx8-73gf-7x73"
4545
},
46+
{
47+
"type": "ADVISORY",
48+
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-30242"
49+
},
4650
{
4751
"type": "PACKAGE",
4852
"url": "https://github.com/makeplane/plane"
53+
},
54+
{
55+
"type": "WEB",
56+
"url": "https://github.com/makeplane/plane/releases/tag/v1.2.3"
4957
}
5058
],
5159
"database_specific": {
@@ -55,6 +63,6 @@
5563
"severity": "HIGH",
5664
"github_reviewed": true,
5765
"github_reviewed_at": "2026-03-05T21:43:15Z",
58-
"nvd_published_at": null
66+
"nvd_published_at": "2026-03-06T22:16:01Z"
5967
}
6068
}

advisories/github-reviewed/2026/03/GHSA-m4h2-mjfm-mp55/GHSA-m4h2-mjfm-mp55.json

Lines changed: 6 additions & 2 deletions
Original file line numberDiff line numberDiff line change
@@ -1,7 +1,7 @@
11
{
22
"schema_version": "1.4.0",
33
"id": "GHSA-m4h2-mjfm-mp55",
4-
"modified": "2026-03-06T18:47:52Z",
4+
"modified": "2026-03-09T13:12:23Z",
55
"published": "2026-03-06T18:47:52Z",
66
"aliases": [
77
"CVE-2026-30241"
@@ -40,6 +40,10 @@
4040
"type": "WEB",
4141
"url": "https://github.com/mercurius-js/mercurius/security/advisories/GHSA-m4h2-mjfm-mp55"
4242
},
43+
{
44+
"type": "ADVISORY",
45+
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-30241"
46+
},
4347
{
4448
"type": "WEB",
4549
"url": "https://github.com/mercurius-js/mercurius/commit/5b56f60f4b0d60780b0ff499a479bd830bdd6986"
@@ -56,6 +60,6 @@
5660
"severity": "LOW",
5761
"github_reviewed": true,
5862
"github_reviewed_at": "2026-03-06T18:47:52Z",
59-
"nvd_published_at": null
63+
"nvd_published_at": "2026-03-06T22:16:01Z"
6064
}
6165
}

0 commit comments

Comments
 (0)