この記事のポイント
- 脆弱性
- CVE-2026-115718
- 深刻度
MEDIUM5.3
- 対象
- Frappe Builder 1.33.0以上1.36.0未満：improve_promptの認可不備
- 悪用状況
- 不明
- 推奨対応
- Frappe本体の互換条件を確認してBuilder 1.36.0へ更新し、bench migrateとプロセス再起動を行います。低権限アカウントで呼び出しが拒否されること、OpenRouterの過去利用に異常がないことを確認してください。
- 公表日
目次
Frappe BuilderのAI改善機能に、認証済み利用者がサイト所有者のOpenRouter利用枠を消費できる不備「-2026-115718」が公表されました。対象はBuilder 1.33.0以上1.36.0未満です。未認証の外部者が直接使える問題ではありませんが、ポータル利用者を含むログイン済みアカウントが、Builder Pageを編集できない状態でも呼び出しを実行できました。
Frappe Builderを社内外の利用者へ提供し、Builder SettingsにOpenRouterのを保存している運用では、Builder 1.36.0への更新と権限試験を優先してください。更新だけで過去の利用状況は確認できないため、OpenRouter側の使用量、Frappeのアクセス記録、不要アカウントも併せて点検します。本稿は2026年10月26日に公開されたCVE情報と、Frappeの修正コミット、10月21日のv1.36.0リリースを基に、影響条件と実務対応を整理します。
スポンサーリンク
何が問題だったのか
問題のあるimprove_promptは、利用者が入力した下書きをLLMで整えるサーバー側の機能です。Frappeの修正コミットによると、この関数はリモートから呼び出せるようホワイトリスト登録されていましたが、Builder Pageへの書き込み権限を確認していませんでした。そのため、通常のページ編集者だけでなく、ログインできるポータル利用者もサイトに設定されたキーでLLM呼び出しを行えました。
修正は@has_page_write()を追加し、他のAIと同じページ書き込み権限を要求するものです。回帰テストでは、ページを編集できないポータル利用者による呼び出しがValidationErrorになり、LLM処理自体が実行されないことを確認しています。一方、編集権限を持つ利用者にはプロンプト改善結果を返す正常系も維持されています。
ここで守る対象はAPIキーの文字列だけではありません。確認した一次資料は、攻撃者がキーそのものを読み取れるとは説明していません。問題は、サーバーが保管する資格情報を使って攻撃者の要求を代理実行し、所有者に課金やの消費を負わせられる点です。秘密値をレスポンスへ返していなくても、資格情報が許可している有償処理を第三者が起動できれば、認可の境界は破られています。
影響を受ける条件を切り分ける
CVE情報が示す影響版はFrappe Builder 1.33.0以上1.36.0未満です。ただし、版番号だけで実際の危険度は決まりません。少なくとも、対象版が稼働し、OpenRouterへ到達できる設定があり、攻撃者が何らかのFrappeアカウントでログインできる場合に、問題の経路が成立します。インターネット公開の有無、ポータルユーザーの発行範囲、利用者が自分で登録できるかによって、攻撃者が条件を満たす難しさは変わります。
| 確認項目 | 判断する内容 |
|---|---|
| Builderの版 | 1.33.0以上1.36.0未満が残っていないか |
| AI設定 | Builder SettingsでOpenRouterを利用できる状態か |
| アカウント | ページ編集権限のないポータル利用者や低権限利用者がログインできるか |
| 外向き通信 | アプリケーションからOpenRouterへのLLM要求が許可されているか |
| 利用記録 | 想定外のモデル、時間帯、件数、費用の増加がないか |
Guestユーザーだけを許可し、認証済みアカウントが存在しないサイトは、今回説明された攻撃条件とは一致しません。反対に、会員サイト、顧客ポータル、検証用アカウントを含め、ページ編集を許可していない利用者でもログインできるサイトは優先して確認します。退職者、委託先、試用利用者など、現在の業務では不要でも有効なセッションを作れるアカウントも対象です。
スポンサーリンク
v1.36.0への更新前にFrappe本体の条件を見る
はBuilder 1.36.0です。公式リリースは、この版がFrappe 16.36.1を必要とし、更新後にbench migrateを実行するよう案内しています。権限定義の変更が含まれるため、コードを取得しただけで完了とは扱わず、対象サイトのマイグレーション、ワーカーやWebプロセスの再起動、実行版の再確認まで行います。
注意が必要なのはFrappe v15の運用です。v1.36.0のリリースノートは、Frappe v15のサイトがBuilder v1.35に留まると記しています。v1.35はCVEの影響範囲と重なるため、互換性を無視して1.36.0だけを強制導入してはいけません。v15を使う場合は、Frappe v16へ移行できるかを評価し、直ちに移行できない間はAI機能への到達を制限し、ポータルアカウントを絞り、保守元へv15向け修正の有無を確認します。
- 本番、、検証環境ごとにFrappeとBuilderの実行版を記録する。
- と条件を決め、対応するFrappe 16系とBuilder 1.36.0へ更新する。
bench migrateを実行し、失敗や未適用パッチがないことを確認する。- Web、ワーカー、スケジューラーを更新済みコードで再起動し、古いプロセスが残っていないか確かめる。
- 低権限アカウントと正規編集者の両方で、拒否と正常系を試験する。
更新後は「拒否されたこと」を試験する
管理者アカウントでAI機能が動くだけでは修正確認になりません。ページ編集権限を持たない専用テストユーザーを作り、認証済みセッションからプロンプト改善処理を呼び出したときに拒否され、OpenRouterの使用量が増えないことを確認します。次に、Builder Pageを書き込める編集者では必要な機能が動くことを確認します。この二つを同じ環境で試すことで、機能停止と認可修正を区別できます。
ステータスだけで合否を決めると、アプリケーションがエラーを200応答に包む場合を見落とします。応答内容、Frappeの例外記録、外部プロバイダーへの要求、使用量の変化を組み合わせて判定してください。テスト用プロンプトと時刻を記録しておけば、アプリケーションログとOpenRouter側の記録を突き合わせやすくなります。
独自のやでエンドポイントを塞いでいた場合も、製品側の認可を直す更新は必要です。経路名やルーティングが変われば周辺制御を迂回する可能性があり、内部ネットワークや別ホスト名から到達できることもあります。WAFは更新までの一時的な低減策として使い、最終的な合格条件はアプリケーションの権限判定に置きます。
スポンサーリンク
過去の不正利用を点検する
修正版を入れても、修正前に消費されたクレジットやレート制限は戻りません。OpenRouterの利用履歴で、通常の編集作業と合わない時間帯、急な要求数の増加、使っていないモデル、想定外の費用を確認します。複数サイトで同じOpenRouterキーを共有している場合は、サイト単位で原因を特定しにくいため、Frappe側のアクセス時刻とアカウント情報を照合します。
確認した資料だけでは、特定のログフィールドや完全な検知クエリまでは示されていません。そのため、存在を確認していない固定パスやイベント名へ依存せず、各環境でimprove_promptの呼び出し、関連するユーザー、外部LLM要求を追える記録を探します。ログ保持期間が短い場合は、請求・利用履歴を先に保存してから更新やキー変更を行います。
APIキーの漏えいが一次資料で確認されたわけではないため、全環境で一律に侵害済みと断定する必要はありません。ただし、利用量を説明できない、共有キーの利用元を分離できない、長期間にわたり低権限アカウントが利用可能だった場合は、キーを再発行し、旧キーを失効させる判断が妥当です。再発行後は新しいキーを必要なサイトだけへ配布し、サイトや環境ごとに利用上限と監視を分けます。
AI機能では秘密値と実行権限を別々に守る
このは、APIキーをして保存するだけでは防げません。サーバーが復号して外部を呼べる以上、「誰の要求を代理実行するか」を各AI機能で確認する必要があります。特に文章改善、要約、翻訳、画像生成のような補助機能は、主要なエージェント機能より軽く見られやすい一方、同じ有償資格情報と外向き通信を使います。
- と認可を分ける：ログイン済みであることに加え、対象ページや機能を実行できる権限をサーバー側で判定する。
- 資格情報の用途を限定する：キーを利用する機能、プロバイダー、環境を分け、不要なや共有を避ける。
- 費用の境界を設ける：利用上限、アラート、モデル制限を設定し、一つの機能やサイトが全体の枠を使い切らないようにする。
- 拒否系を回帰試験にする：低権限利用者、失効済み利用者、別など、実行してはいけない主体のテストを残す。
- 主体を監査記録へ残す：外部AI要求と、起点になったサイト、ユーザー、機能、時刻を関連付ける。
構造化出力やツール呼び出しをWeb機能へ組み込む場合も、モデルが返す値の検証と、外部処理を実行できる主体の認可は別の層です。設計の分け方は構造化出力とツール呼び出しの違いを扱った解説で整理しています。また、AI基盤の資格情報が実際に窃取された場合の初動は、LiteLLMの侵害と鍵のローテーション手順を参照してください。今回のFrappe Builderでは、漏えいを前提にせず、利用記録からの要否を判断する点が異なります。
対応の優先順位
最初に、1.33.0以上1.36.0未満のBuilderと、OpenRouterを使うサイトを特定します。次に、外部や多数のポータル利用者がログインできる環境からAI機能を制限し、対応可能なサイトを1.36.0へ更新します。更新後は低権限利用者の拒否を確認し、その後で修正前の使用量とアクセスを調査します。異常が見つかった場合や利用元を説明できない場合は、APIキーの再発行、不要アカウントとセッションの失効、上限・アラートの再設定まで進めます。
本件を単なる「AIの費用増加」として終わらせないことが重要です。サーバー保管の資格情報で外部サービスを呼ぶ機能では、秘密値が画面へ出なくても、認可されていない代理実行が起き得ます。修正版の権限確認を導入し、誰の操作として外部AIを使ったかを追跡できる状態にしてから、利用者へプロンプト改善機能を再開してください。
関連記事
出典・一次情報
本記事は以下の公開情報をもとに作成しています。最新の状況は各リンク先で確認してください。
