Quick Take
- What: CVE-2026-126393, a server-side request forgery (SSRF) vulnerability in SiYuan’s skill-install download path that allows attackers to reach internal services
- Who is affected: Users of SiYuan versions before 3.8.10 who install skills via MCP tool actions
- What to do: Upgrade to SiYuan version 3.8.10 or later
- Attack vector: Attackers supply a malicious skill URL that redirects or DNS-rebinds to loopback addresses (127.0.0.1)
- Severity: Medium (CVSS 6.1), requires user interaction or pre-approved settings
In plain English
SiYuan is a note-taking application that can install skills (extensions) from URLs. A security flaw in versions before 3.8.10 lets attackers trick the app into connecting to internal services on your computer. When you install a skill from a malicious URL, that URL can redirect to your computer’s internal addresses (like 127.0.0.1), letting the attacker reach services that should be private, such as cloud metadata endpoints. This requires either clicking a confirmation prompt or having pre-approved settings enabled.
What you should do: If you use SiYuan, update to version 3.8.10. If you don’t use this software, you can ignore this issue.
What happened
SiYuan before version 3.8.10 contains a server-side request forgery vulnerability in the skill-install download path. The flaw exists because the fetchBytes function performs only a parse-time hostname check instead of using the ssrfSafeClient that was introduced in a previous security fix (GHSA-x8gv-g2g3-65fj).
On version 3.8.8, the skill-install path performs a hostname check at parse time (skill.go:681), then downloads with httpclient.NewBrowserRequest() (skill.go:706), a plain HTTP client that resolves the hostname again at connect time. This creates a time-of-check to time-of-use vulnerability.
The vulnerability can be exploited in two ways:
1. HTTP redirect: A public URL that returns a 302 redirect to http://127.0.0.1/... passes the initial CheckHostSSRF validation (which only examines the first hostname), but fetchBytes follows the redirect without re-checking the target.
2. DNS rebinding: An attacker-controlled domain can resolve to a public IP during validation, then resolve to a loopback address during the actual connection.
The entry point is the MCP tool skill with action=install and a malicious url parameter (mcp/tools/skill.go:275). The install action is declared LocalWrite, requiring either user confirmation or a pre-approved setting.
Testing in the same process against the same loopback target showed the asymmetry:
ssrfSafeClient.Get(http://127.0.0.1:P)returned error: “access to private/internal IP is prohibited”httpclient.NewBrowserRequest().Get(http://127.0.0.1:P)returned 200 “INTERNAL-SERVICE”
The vulnerability was reported by Figo5 and assigned CVE-2026-126393 with a CVSS score of 6.1 (Medium severity). The CVSS vector is CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:C/C:L/I:L/A:N, indicating network attack vector, low complexity, no privileges required, user interaction required, changed scope, and low confidentiality and integrity impact.
What you should do
Upgrade to SiYuan version 3.8.10 or later. Version 3.8.10 patches this vulnerability.
The fix routes fetchBytes through ssrfSafeClient (or sets a DialContext with the same control hook) and re-validates each redirect hop or installs a CheckRedirect that re-applies CheckHostSSRF to every Location header.
What it means
This vulnerability represents a residual SSRF risk that remained after a previous high-severity SSRF-by-DNS-rebinding issue (GHSA-x8gv-g2g3-65fj) was fixed. While that earlier fix introduced ssrfSafeClient to pin validated IPs at dial time for agent paths, the skill-install download path was not migrated to use the safe client.
The medium severity rating (rather than high) reflects the requirement for user interaction: either a confirmation click or pre-approved settings must be in place for the MCP skill install action to execute. This matches the UI:R (User Interaction Required) component in the CVSS score.
Successful exploitation allows attackers to reach internal services and cloud metadata endpoints (such as AWS EC2 metadata at 169.254.169.254 or similar services), potentially exposing sensitive information or enabling further attacks against internal infrastructure.
The redirect vector is considered a separate bug from DNS rebinding and represents a cheaper attack path, as it requires only a single malicious HTTP redirect rather than coordinated DNS timing attacks.
