LLM アプリケーションやエージェントワークフローをノーコード・ローコードで構築できる Langflow OSS を、社内の検証環境や本番のパイプラインに組み込んでいるインフラ担当者に向けた内容です。2026年8月に公開された CVE-2026-17633 は、認証済みユーザーであれば誰でもリモートでコードを実行できてしまう脆弱性です。可用性設計やセキュリティ運用の観点から、何を確認しどう塞ぐべきかを整理します。
何が起きるか
Langflow は、AI ワークフローの各処理単位を「コンポーネント」としてつなぐ低コード基盤です。そのなかの Custom Components という機能は、コンポーネントの振る舞いを Python コードで直接書ける便利な仕組みです。
この機能を有効化していると、POST /api/v1/custom_component というエンドポイントに投げた Python コードが、サーバー側でそのまま実行されてしまいます。CVSS スコアは 8.5（HIGH）で、CWE-94（コード生成の不適切な制御）に分類されています。
影響範囲は Langflow OSS 1.0.0 から 1.10.3 までです。前提条件は「認証済みユーザーであること」と「環境変数 LANGFLOW_ALLOW_CUSTOM_COMPONENTS=true が設定されていること」の2つだけです。管理者権限がなくても、ログインさえできれば任意のシェルコマンドをサーバー上で実行できます。
影響は単一プロセスの侵害にとどまりません。Langflow がコンテナ内で動いていても、マウントされたシークレットや同一ネットワーク内の他サービスへの横展開の起点になり得ます。RCE（Remote Code Execution、リモートからの任意コード実行）はインシデント対応上、最優先で塞ぐべきクラスの脆弱性です。
なぜ起きるか
原因は一段階ではなく、2つのチェック漏れが重なっています。
1つ目は、入力検証の「対象の取り違え」です。エンドポイントの実装では settings.allow_custom_components というフラグだけを見て処理を通すかどうかを決めています。このフラグが答えているのは「このユーザーはカスタムコンポーネントを作ってよいか」であって、「送られてきたコードの中身が安全か」ではありません。Langflow には scan_code_security() という AST（抽象構文木、コードを構文単位に分解した木構造）ベースのスキャナーが別途用意されていますが、このエンドポイントの実行経路ではそもそも呼び出されていません。
2つ目は、より根深い実装バグです。コードは prepare_global_scope() という関数を経由して exec()（文字列やコンパイル済みコードをその場で実行する Python の組み込み関数）に渡されます。この関数は送信されたコードの AST を走査し、import 文と class / def / 代入だけを「安全な定義」として収集します。
ここに落とし穴があります。トップレベルに書いた os.system(...) のような命令文は AST 上 ast.Expr というノードになり、収集対象の判定リストに含まれていないため黙って捨てられます。ところがクラスの本体（メソッドの外、クラス定義の直下）に同じ命令を書くと、それは ClassDef ノードの一部として扱われ、クラスが定義される瞬間（つまり exec() が走る瞬間）にそのまま実行されてしまいます。
つまり攻撃者にとって必要な工夫は、難読化でも文字コードのすり抜けでもなく「ペイロードをクラス本体の直下に書く」というだけです。設計上の判定ロジックの穴を突く、非常にシンプルな攻撃です。
自分の環境が該当するか確認する
最初に確認すべきは Langflow のバージョンです。管理 UI の設定画面か、以下のようにパッケージ情報から確認できます。
pip show langflow | grep Version1.0.0 から 1.10.3 の範囲に入っていれば対象です。1.10.4 以降であれば、修正が取り込まれているか変更履歴（CHANGELOG）を確認してください。
次に確認するのは環境変数です。デプロイに使っている .env ファイルや Docker Compose、Kubernetes の ConfigMap / Secret で以下を探します。
grep -r "LANGFLOW_ALLOW_CUSTOM_COMPONENTS" . --include="*.env" --include="*.yaml" --include="*.yml"true になっていれば前提条件の2つ目が満たされています。IaC（Infrastructure as Code）で環境を管理している場合は、Terraform の aws_ecs_task_definition や Kubernetes マニフェストの env ブロックに直書きされているケースが典型です。コードレビューの差分だけでは見落としやすいので、terraform plan の出力や kubectl get deployment -o yaml で実際に反映されている値を確認してください。
さらに、認証がどこまで開かれているかも重要な判断材料です。Langflow をイントラネット限定で運用しているのか、外部公開のリバースプロキシ経由でアクセスできる状態なのかによって、実際に到達可能な攻撃者の範囲が変わります。ロードバランサーやリバースプロキシの ACL（アクセス制御リスト）設定、認証基盤（SSO や API キー）の対象範囲も併せて棚卸ししておくと判断がぶれません。
対策の手順
恒久対応はバージョンアップですが、即座に実行できる暫定策から順に整理します。
- 緊急対応:
LANGFLOW_ALLOW_CUSTOM_COMPONENTSをfalseに変更し、対象プロセス・コンテナを再起動する。Custom Components 機能を業務で使っていないなら、この設定変更だけで攻撃経路を閉じられる - ネットワーク制御:
/api/v1/custom_componentへのアクセスを、リバースプロキシ（Nginx や Envoy）の設定で管理者 IP のみに制限する。機能自体は残しつつ露出面を絞る折衷案になる - バージョン更新: 修正版がリリースされていれば速やかに更新する。更新前にステージング環境で既存ワークフローの互換性を確認する
- 監視の強化: Langflow プロセスから予期しない子プロセス（
sh,bash,curlなど）が起動していないか、eBPF ベースのランタイム監視ツール（Falco など）や監査ログでアラートを設定する
環境変数の変更は IaC で管理している場合、リポジトリの該当行を修正して terraform apply や kubectl apply を実行する流れになります。手動で本番環境の変数だけを書き換えると、次回のデプロイで設定が巻き戻る事故につながるので、必ずコードとして変更を残してください。
監視面では、Custom Components のリクエストボディをログに残しておくと、事後調査（フォレンジック）の初動が大きく変わります。オブザーバビリティの基本方針として、認証済みユーザーの操作ログと、その操作が実際に何を exec() したかのトレースは別々に保存しておくと、侵害範囲の切り分けがしやすくなります。
まとめ
CVE-2026-17633 は、認証済みユーザーという比較的低いハードルで、サーバー上のコード実行に到達できる脆弱性です。原因は「機能フラグ」と「コード安全性」の判定を取り違えたことと、AST 解析でトップレベルの命令文だけを見落としていたことの2点です。
手始めに、pip show langflow でバージョンを確認し、LANGFLOW_ALLOW_CUSTOM_COMPONENTS の設定値を IaC の実体で確認してください。該当する場合は、機能を使っていないなら無効化、使っているならエンドポイントへのアクセス制限とバージョン更新を優先度順に進めることをおすすめします。
あわせて、自社でノーコード・ローコード型のツールを運用しているなら、「有効化フラグ」と「入力内容の検証」が別物として実装されているかどうかを、他のプラグイン機構にも当てはめて点検しておくと安心です。