社内向けにノーコードのAIワークフロー基盤を自前で運用している組織に向けた内容です。LangflowというAIパイプライン構築ツールに、低権限アカウントでもサーバー上で任意コマンドを実行できる脆弱性が見つかりました。CVSSスコアは9.9とほぼ最高値で、業務システムの一部としてLangflowを組み込んでいる場合は影響範囲の確認が必要です。
Langflow（AIワークフローをドラッグ&ドロップで構築できるオープンソースツール）は、社内の問い合わせ自動応答やデータ整形パイプラインなど、業務システムの裏側に組み込まれるケースが増えています。管理画面から誰でもワークフローを編集できる手軽さが魅力ですが、今回の脆弱性はその「編集のしやすさ」そのものが攻撃経路になっています。
何が起きるか
該当するのはCVE-2026-105740、対象はLangflowのバージョン1.9.0より前のすべてです。低権限アカウント（管理者権限を持たない一般ユーザー）でログインできれば、サーバー上で任意のOSコマンドを実行できてしまいます。
観測情報によると、2026年9月19日から10月17日時点までに2,023件の攻撃試行が確認されています。送信元は28のIPアドレス、16か国にまたがっており、日本も含まれています。単一のセンサーでの観測とはいえ、継続的に試行が繰り返されている状況です。
攻撃が成功すると、Langflowプロセスの権限でOSコマンドが実行されます。その結果、接続先コネクタの認証情報、AIモデルのAPIキー、ワークフローのデータなどが窃取される可能性があります。社内ネットワークの他ホストへの横展開の足がかりにもなり得ます。
なぜ起きるか
原因はMCP（Model Context Protocol、AIモデルが外部ツールと連携するための標準プロトコル）のStdioトランスポート（標準入出力経由でコマンドを起動する接続方式）の実装にあります。
LangflowではMCPサーバーをStdio方式で追加する際、実行コマンドと環境変数（env）をユーザーが自由に設定して保存できます。本来この設定は管理者のみが扱うべき強い権限を伴う操作です。
ところが、低権限ユーザーでもこの設定を保存できてしまう権限制御の甘さが1つ目の原因です。さらに、保存されたコマンドは検証なしにそのままbash -c経由で実行される仕組みになっていました。
実行のトリガーも見落とされがちなポイントです。GET /api/v2/mcp/servers?action_count=trueというMCPサーバー一覧をアクション数付きで取得するAPIを呼ぶと、保存済みのコマンドが実行されます。クエリパラメータなしの通常の一覧取得では発火しないため、ログを見ても一見「ただの一覧表示」に紛れてしまう点が厄介です。
言い換えると、入力検証の欠如（保存時にコマンド内容をチェックしない）と権限分離の欠如（誰でも危険な設定を保存できる）という2つの設計上の穴が重なって、低権限アカウントからのRCE（Remote Code Execution、リモートからの任意コード実行）が成立しています。
自分のプロジェクトが該当するか確認する
まず、運用中のLangflowのバージョンを確認します。
pip show langflow | grep VersionあるいはDockerで動かしている場合は、コンテナ内のパッケージ情報を確認するか、docker imagesで使用中のタグを確認します。
docker exec <container_name> pip show langflow | grep Versionバージョンが1.9.0より前であれば対象です。次に、MCPのStdio機能を実際に使っているかどうかを確認します。管理画面のMCPサーバー設定一覧を開き、Stdioトランスポートで登録されたサーバーが存在するかを見てください。
社内で低権限アカウントを発行して外部委託先やパートチームに使わせている場合、特に注意が必要です。Langflowが社内ネットワークに閉じているか、インターネットから到達可能になっているかも合わせて確認します。
ログが残っている環境では、以下の痕跡を探すことができます。
- プロキシ・DNSログで
GET /api/v2/mcp/servers?action_count=trueの呼び出し履歴 - 同リクエスト直後に発生したbashやshの子プロセス起動記録（EDR等）
LD_PRELOADやPATHなど環境変数の不審な変更履歴- 身に覚えのない低権限アカウントの新規作成やログイン元IP
- ワークフロー・MCPサーバー・シークレットの変更履歴
ログが残っていなくても、侵害がなかったことの証明にはならない点は留意してください。
対策の手順
最優先の対策は、Langflowを1.9.0以降にアップデートすることです。公式のセキュリティアドバイザリ（GHSA-7w94-79vh-5mr2）でパッチ内容が公開されているため、アップデート後にMCP関連エンドポイントへの検証ロジックが追加されているかをリリースノートで確認してください。
アップデートがすぐにできない場合の緩和策は以下の通りです。
- MCP Stdioの利用を必要最小限の管理者アカウントのみに制限する（RBAC設定の見直し）
- Langflowへのインターネットからの直接アクセスを遮断し、社内VPN経由に限定する
- 共有アカウントの廃止と、長期間有効なAPIキーの棚卸し・失効
- Langflowプロセス自体をコンテナなど低権限のサンドボックス環境で実行し、ホストへの影響範囲を限定する
業務システムの一部としてLangflowを組み込んでいる場合、アップデートによる既存ワークフローへの影響も確認が必要です。特にMCP連携部分の設定フォーマットに変更が入っていないか、ステージング環境での動作確認を挟んでから本番反映することをおすすめします。
まとめ
Langflowを低権限アカウント運用で社内公開している場合、CVE-2026-105740は見過ごせない穴です。確認すべきことを整理します。
pip show langflowやDockerイメージタグでバージョンが1.9.0未満かを確認する- MCP Stdioサーバーの登録有無と、低権限アカウントの発行状況を棚卸しする
action_count=true付きのAPI呼び出しログやbash子プロセスの起動履歴を調査する- アップデートが難しい場合はMCP Stdioの利用制限とネットワーク遮断で当面しのぐ
AIワークフロー基盤は便利さゆえに権限管理が緩くなりがちです。今回のケースを機に、MCP連携まわりの権限設計を一度見直してみてください。