SiYuan 脆弱性 CVE-2026-66012 が公開されました。対象はオープンソースのナレッジ管理アプリ SiYuan（GitHubスター 45,612・2026-08-04時点実測）で、深刻度はCVSS 10.0（最高値）です。SiYuanが実装するMCP（Model Context Protocol）エンドポイント POST /mcp に認可チェックが欠落しており、AIエージェント連携用に用意された31個のMCPツールすべてに未認証で到達し、管理者権限を奪取できる状態だったというものです。この記事では、公式GitHub Security Advisory（GHSA-hp8g-g2qj-wgpj）を一次ソースに、事実関係と、読者自身の環境が影響を受けるかを判定する手順を整理します。攻撃の再現手順やPoCそのものは扱いません。

SiYuan MCP脆弱性の時系列図。2026-06-03に2件のXSS→RCE脆弱性が公開、2026-07-13に関連する先行advisory、2026-07-21にv3.7.3リリース、2026-07-25にCVSS10.0のCVE-2026-66012が公開される流れを示す。
SiYuanで2026年6〜7月に公開された関連advisoryの時系列。CVE-2026-66012（CVSS10.0）は、同時期に噴出した143件のadvisoryの中でも最高深刻度にあたる。

30秒でわかる｜この記事のポイント

・正体：POST /mcp エンドポイントの認可チェック欠落。SiYuanが実装するMCPツール31個すべてに未認証到達でき、管理者権限を奪取できる（GHSA-hp8g-g2qj-wgpj）
・深刻度：CVSS 10.0（最高値）。海外DBでは「SiYuan CVSS 10」の表記でも言及される。認証・事前権限とも不要
・成立条件：Publish（公開）サーバーを匿名モードで有効にしている環境のみ。使っていない・認証を有効にしている環境は対象外
・影響範囲：v3.7.2未満。v3.7.2以降は /mcp 側にも認可チェックが入る
・実体：★45,612・25,000超のコミットの割に、開発は実質2名（上位2名で全コミットの96%超）に集中。日本語の詳細解説は本記事執筆時点で確認できず、完全な空白

なお、認可漏れや権限昇格など「境界のどちら側で権限チェックが抜けたか」を体系的に押さえたい場合は、サプライチェーンセキュリティ2026｜攻撃手法・防御ツール・実践チェックリストを合わせて読んでください。本記事はそのうち「セルフホストのAIエージェント連携（MCP）エンドポイントで、認可チェック自体が1か所抜けていた」という実例に絞った解説です。

SiYuanとは：MCPサーバー機能を持つノートアプリ

SiYuan（中国語圏では「思源笔记」の名でも知られ、「思源笔记 脆弱性」の呼称で言及されることもある）は、Go製カーネルとTypeScript/Electron製のデスクトップ・Web UIで構成される、ブロック単位でノートを管理するオープンソースのナレッジ管理アプリです。ライセンスはAGPL-3.0（README・LICENSE双方の表記が一致）。GitHub API実測で★45,612・フォーク2,931、直近のpushは2026-08-03と現役で開発が続いています。リリースは928件を数え、最新版はv3.7.3（2026-07-21公開）です。

本記事の主題はSiYuan自体がAIノートアプリという意味ではなく、SiYuanが実装するMCPサーバー機能です。MCP（Model Context Protocol）は、AIエージェントやLLMクライアントが外部アプリの機能をツールとして呼び出すためのプロトコルで、SiYuanは自身のノート操作（ノートの作成・編集・検索・システム管理など）をMCPツール群として公開しています。ChatGPTやClaudeのようなLLMクライアント、あるいは自作のAIエージェントが、このMCPエンドポイントに接続することでSiYuan上のノートを直接操作できるようになる仕組みです。今回のCVE-2026-66012は、このMCPエンドポイントの認可チェックが抜けていたという、AIエージェント連携機能そのものが攻撃の入口になった実例です。

CVE-2026-66012の核心は「バージョンが古いから危険」ではなく「Publishサーバーを匿名モードで有効にしている場合に限り、MCPエンドポイントが外部から未認証で到達できる」という条件付きの脆弱性である点です。

開発体制にも触れておきます。GitHub contributors API実測では、Vanessa219が12,127コミット、88250が11,952コミットと、上位2名で合計約24,079コミット（総コミット数約25,033の大半）を占め、3位のTCOTCは537コミットと桁が2つ落ちます。★4.5万・コミット2.5万超という規模の見た目に対し、開発の実権は実質2名に集中しているというのが実体です。企業スポンサーの有無は本リサーチでは裏取りできておらず「未確認」とします。

順位 contributor コミット数 総コミットに占める割合（概算）
1位 Vanessa219 12,127 約48%
2位 88250 11,952 約48%
3位 TCOTC 537 約2%

バス係数（プロジェクトの継続性が特定の少数の開発者にどれだけ依存しているかを示す指標）の観点では、上位2名が離脱した場合の影響は極めて大きいと言えます。★数やコミット数だけでプロジェクトの成熟度を判断せず、こうした実体まで見た上で採用・依存の判断をすることが重要です。

SiYuan 脆弱性 CVE-2026-66012 の時系列

日付はGitHub Security Advisories・Releasesの実測値です。SiYuanは同時期に143件（2026-08-04時点実測）のadvisoryを公開しており、通常のOSSの脆弱性報告ペースとしては異常な密度です。なぜこれほど多いかは断定できる材料がなく、本記事では事実の列挙にとどめます。

日付 出来事
2026-06-03 CVE-2026-54067（GHSA-mvjr-vv3c-w4qv）公開。renderSnippet() のCSSスニペット <style> ブレイクアウトによるStored XSS→RCE
2026-06-03 CVE-2026-50551（GHSA-56mp-4f3v-fgj2）公開。属性ビューのアセットセル未サニタイズによるStored XSS→RCE
2026-07-13 GHSA-cvhv-7xhj-xjp8 公開。MCP経由の未認証管理者テイクオーバーに関する関連・先行のadvisory
2026-07-21 v3.7.3 リリース（本記事執筆時点の最新版）
2026-07-25 CVE-2026-66012（GHSA-hp8g-g2qj-wgpj）公開。CVSS 10.0
2026-08-03 直近のpush（現役で開発継続中）
2026-08-04 本記事のリサーチ時点（★45,612・advisory 143件を実測）

GHSA-hp8g-g2qj-wgpjの本文は、7月13日公開のGHSA-cvhv-7xhj-xjp8を関連advisoryとして明示的に参照しています。両者が同一の根本原因の再発なのか、別の切り口による指摘なのかはGHSA原文からは断定できないため、本記事では「関連するadvisoryが先行して存在する」という事実のみを記載します。

v3.7.2でMCPエンドポイントに認可チェックが追加され、その後にv3.7.3（2026-07-21）がリリースされています。CVE番号が公になったのは7月25日ですが、修正自体はそれ以前のv3.7.2で既に取り込まれていたことになります。日常的に最新版へ追従していた運用であれば、CVE番号を知る前に既に守られていた可能性が高いという点は、押さえておく価値があります。

何が起きたのか：/mcp の認可チェック欠落

GHSA-hp8g-g2qj-wgpjが指摘するのは、SiYuanが実装するMCPサーバー機能の POST /mcp エンドポイントで、認可チェックそのものが欠落していたことです。SiYuanは31個のMCPツール（ノートの作成・編集・検索・システム操作などをAIエージェントから呼び出すためのインターフェース）を用意していますが、このエンドポイントには本来必要な権限確認が実装されていませんでした。結果として、到達可能な状態にある攻撃者は、認証情報を一切持たずにこれら31個のMCPツールをすべて呼び出せ、管理者権限を奪取できる状態になっていました。

ここで重要なのが「到達可能な状態」の定義です。Publishサーバーを匿名モードで有効にしている環境では、外部からの到達性が生まれます。Publish機能はノートを外部に公開共有するための仕組みで、Auth.Enable=false（匿名モード）にすると認証なしでアクセス可能になります。この設定と、/mcp の認可チェック欠落が組み合わさることで、外部の第三者が認証なしで管理者権限のMCPツールを叩けるようになっていた、というのが今回の構図です。Publish機能を使っていない、または匿名モードを有効にしていない環境では、この到達経路自体が存在しません。

flowchart TD A["攻撃者が到達"] --> B{"Publishサーバーは
匿名モードで有効か？"} B -- いいえ --> Z["到達経路なし
影響を受けない"] B -- はい --> C{"バージョンは
v3.7.2未満か？"} C -- いいえ v3.7.2以降 --> Y["/mcp側に認可チェックあり
拒否される"] C -- はい v3.7.2未満 --> D["POST /mcp へ未認証到達"] D --> E["31個のMCPツールを
認可チェックなしで呼び出し"] E --> F["管理者権限を奪取
CVE-2026-66012 CVSS 10.0"] style F fill:#ffe3e3,stroke:#c92a2a,stroke-width:2px style Z fill:#d9f5ec,stroke:#0b7a63,stroke-width:2px style Y fill:#d9f5ec,stroke:#0b7a63,stroke-width:2px
読者の3つの問いへの答え
① 何が起きた：MCPエンドポイント `POST /mcp` の認可チェック欠落で、31個のMCPツールに未認証到達できCVSS10.0の管理者権限奪取が成立した。② 何が原因：Publishサーバーを匿名モードで有効にしている環境という、特定設定との組み合わせで露出条件が成立する。③ 何をすればよいか：まずPublish設定を確認し、匿名モードが有効ならv3.7.2以降へ更新するか、匿名モードを無効化する。

関連する SiYuan 脆弱性 の一覧

同時期に公開されたcritical級のadvisoryのうち、本記事が扱うCVE-2026-66012を含む主要なものを整理します。すべてSiYuan公式のGitHub Security Advisoryが一次ソースです。

CVE / GHSA CVSS 概要 公開日
CVE-2026-66012（GHSA-hp8g-g2qj-wgpj） 10.0（critical） POST /mcp の認可欠落。31個のMCPツールに未認証到達→管理者権限奪取 2026-07-25
GHSA-cvhv-7xhj-xjp8 critical MCP経由の未認証管理者テイクオーバー（関連・先行のadvisory） 2026-07-13
CVE-2026-54067（GHSA-mvjr-vv3c-w4qv） critical renderSnippet() のCSSスニペット <style> ブレイクアウトによるStored XSS→RCE 2026-06-03
CVE-2026-50551（GHSA-56mp-4f3v-fgj2） critical 属性ビューのアセットセル未サニタイズによるStored XSS→RCE 2026-06-03

severityは4件ともcriticalですが、CVSS数値そのものはCVE-2026-66012の10.0のみが確認できている値です。同時期に公開された143件のadvisory全体を「すべてCVSS10」と読むのは誤りで、実際にはcritical/high/medium/lowが混在します。

4件を並べると、6月の2件（CVE-2026-54067・CVE-2026-50551）はいずれもStored XSSを起点にRCEへつながる系統である一方、7月の2件（GHSA-cvhv-7xhj-xjp8・CVE-2026-66012）はいずれもMCP経由の未認証管理者テイクオーバーという系統に分類できます。前者はコンテンツのサニタイズ、後者は認可チェックという、異なるレイヤーの不備が同じ時期に相次いで公開されたという点は事実として押さえておく価値があります。GHSA-hp8g-g2qj-wgpjの本文がGHSA-cvhv-7xhj-xjp8を関連advisoryとして参照していることから、7月の2件には何らかのつながりがあると推測できますが、同一の根本原因の再発なのか、別の切り口での指摘なのかはGHSA原文からは断定できません。

自分の環境が影響を受けるか判定する

判定は設定→バージョンの順で行います。v3.7.2以降であれば設定に関わらず安全とみなせますが、多くの利用者にとってはPublish機能自体を使っていないケースが大半です。先にPublish設定を確認すれば、その時点で「対象外」と判定でき、バージョン確認の手間を省けます。逆にバージョン確認を先にすると、Publishを使っていない利用者もいったんバージョンを調べる必要が生じ、判定の手数が増えます。

手順1：Publishサーバーが匿名モードで有効になっていないか確認する

# conf.json のPublish設定を確認（Auth.Enable=false なら匿名モード）
grep -A3 '"publish"' ~/.config/siyuan/conf/conf.json 2>/dev/null

Publish機能自体を使っていない、または Auth.Enable=true（認証あり）になっている場合、この脆弱性の到達経路そのものが存在しません。以降のバージョン確認は緊急性を持ちません（それでも更新は推奨されます）。

手順2：稼働中のバージョンを確認する

# Dockerで動かしている場合
docker exec <container> cat /opt/siyuan/app.json 2>/dev/null | grep -i version

# 起動中のカーネルAPIから確認する場合
curl -s http://127.0.0.1:6806/api/system/version

v3.7.2未満であればCVE-2026-66012の影響範囲です。v3.7.2以降であれば、/mcp 側にも認可チェックが入るため、Publish設定に関わらず安全とみなせます。

手順3：/mcp エンドポイントへの到達性を確認する

# 自分の環境のみに対して実行する（第三者ホストへは絶対に実行しない）
curl -s -o /dev/null -w "%{http_code}\n" http://127.0.0.1:6806/mcp

このコマンドはあくまで自環境の疎通確認用です。外部から到達可能かどうかは、リバースプロキシやファイアウォールの設定と合わせて確認してください。

「Publish匿名モード」がなぜMCPエンドポイントの露出条件になるのかについて、GHSA本文からはこれ以上の技術的な内部構造までは確認できていません。確認できているのは、①Publishサーバーが匿名モードで有効になっていること、②/mcp に認可チェックが欠落していること、の2つが揃った場合に外部からの未認証到達が成立するという事実です。Publish機能を使っていない環境がそもそも対象外になるのは、この経路自体が有効化されないためです。

判定項目 条件 影響
Publish匿名モード 無効 or 未使用 対象外（到達経路なし）
Publish匿名モード 有効 かつ v3.7.2以降 対象外（/mcp 側で拒否）
Publish匿名モード 有効 かつ v3.7.2未満 CVE-2026-66012の影響範囲

対策：優先度別の手順

最優先はv3.7.2以降への更新です。本記事執筆時点の最新はv3.7.3（2026-07-21リリース）で、CVE-2026-66012を含む修正済みの系列に入ります。

# 公式Dockerイメージを使っている場合
docker pull b3log/siyuan:latest
docker compose up -d

# 更新後は必ずバージョンを実測で確認する
curl -s http://127.0.0.1:6806/api/system/version

すぐに更新できない場合の緩和策は、成立条件そのものを外す方向で検討します。

・Publish匿名モードを無効化する。Auth.Enableを有効にし、Publishサーバーに認証を必須にする
・Publishサーバーを外部から到達不能な配置にする。ネットワーク的に隔離し、必要な相手にのみ経路を開く
・リバースプロキシで /mcp 経路を絞る。外部公開が必要な場合も、MCPエンドポイントだけは内部ネットワークに限定する

対応の順序としては、まず設定（Publish匿名モードの無効化）で露出条件を外し、その上でバージョン更新を進めるのが実践的です。バージョンさえ新しければ設定に関わらず安全という理解で問題ありませんが、更新に時間がかかる場合は設定変更のほうが即効性があります。

更新後は、バージョン確認だけで終わらせず、次の点も合わせて見ておくと安心です。

・更新前のアクセスログを確認する。Publishサーバーを外部公開した状態で稼働していた期間があるなら、/mcp への不審なリクエストが記録されていないか、リバースプロキシやファイアウォールのログを遡って確認しておく
・Publish匿名モードを引き続き使う場合は、必要最小限の範囲に絞る。公開する必要のあるノートだけを対象にし、SiYuanインスタンス全体を無条件に公開しない
・バックアップを最新化しておく。管理者権限奪取が成立していた場合の被害範囲はノート全体に及びうるため、更新作業とあわせてバックアップの世代を確認する

自分でMCPサーバーを実装・運用している場合は、今回の事案を自分のコードベースの棚卸しにも活用できます。確認するとよい観点は次の3つです。①新しく追加したエンドポイントに、既存の認可ミドルウェアが本当に適用されているか（ルーティングの追加時にミドルウェアの適用漏れが起きやすい）、②「外部公開用の機能」と「内部向けの管理用エンドポイント」が同じネットワーク境界を共有していないか、③MCPツールの一覧に、読み取り専用であるべきものと管理者権限が必要なものが混在していないか。SiYuanの事案は、これら3点のうち①と②が重なって成立した例として読むことができます。

まとめ：AIエージェント連携機能が認可漏れの入口になる典型例

CVE-2026-66012は、SiYuanがAIエージェント連携のために実装したMCPエンドポイントで、認可チェックそのものが1か所抜けていたという事案です。CVSS10.0という最高深刻度でありながら、Publishサーバーを匿名モードで有効にしている環境という特定の条件でのみ成立する点が、この脆弱性を理解するうえでの核心です。

MCPのようなAIエージェント連携プロトコルは、機能を追加するたびに新しいエンドポイントを生みます。既存の認可レイヤーがそこまでカバーしきれていないケースは、SiYuan以外でも起こり得る構造です。同種の「MCPエンドポイントで認可・アクセス制御が想定通りに効いていない」事案としては、AWS MCPサーバーのfail-open脆弱性CVE-2026-16584｜deny設定が黙って無効化や、MCP脆弱性！STDIOトランスポートの設計欠陥で20万台のサーバーがRCEの危険に——OX Securityが警告も参考になります。自作・導入しているMCPサーバーがあるなら、「新しく追加したエンドポイントに、既存の認可チェックが本当に及んでいるか」を棚卸しする価値があります。

公開されたMCPサーバーそのものが攻撃対象として狙われている実態は、公開 MCP サーバが標的に｜AI 開発者を狙い撃つ走査を SANS ISC が観測で扱っています。設定不備が残ったMCPエンドポイントは、能動的にスキャンされる対象になり得るという点でも、今回の事案と地続きです。

注意：本記事執筆時点でSiYuanリポジトリには143件のGitHub Security Advisoryが確認できます（2026-08-04実測）。数が多い理由は本リサーチでは断定できないため記載していません。同時期に公開された他のadvisoryも合わせて棚卸しすることをおすすめします。

参照ソース

・GHSA-hp8g-g2qj-wgpj｜CVE-2026-66012（siyuan-note/siyuan 公式 GitHub Security Advisory・一次ソース） — CVSS 10.0・脆弱性の技術詳細・影響条件
・GHSA-mvjr-vv3c-w4qv｜CVE-2026-54067（renderSnippet CSSスニペット breakout・一次ソース） — 6月に公開された関連XSS→RCE
・GHSA-56mp-4f3v-fgj2｜CVE-2026-50551（属性ビューアセットセル未サニタイズ・一次ソース） — 同時期のもう1件のXSS→RCE
・SiYuan v3.7.2 Release（GitHub Releases・修正版） — 修正版のリリース確認
・siyuan-note/siyuan（公式リポジトリ） — star/fork/コミット等の実測値