Langflowの auto_login が既定で有効 — 未認証でsuperuserトークンが取れる CVE-2026-9103

2026年7月17日に Langflow の脆弱性が複数公開された。中でも運用上いちばん重いのが CVE-2026-9103（CVSS 9.8）だ。

Langflow OSS 1.0.0 through 1.10.0 could allow a remote attacker to gain unauthorized access due to improper authentication in the /api/v1/login/auto_login endpoint.

要点は3つ。

1. /api/v1/login/auto_login は認証を要求せずに superuser 権限の bearer トークンを発行する
2. そのトークンは長期有効（long-lived）
3. これが動く条件である AUTO_LOGIN は既定で有効

つまり「デフォルト設定のまま外に出したら終わり」という形をしている。加えて CORS 設定が緩く、取得したトークンが意図しないオリジンへ漏れる経路も指摘されている。

単体では終わらない

同日、CVSS 9.9 の CVE-2026-8635 も公開されている。こちらは「認証済みユーザーがDBを直接操作して superuser へ昇格し、任意のシステムコマンドを実行できる」というもので、Scope が Changed（S:C）で評価されている。

この2つは噛み合う。

CVE-2026-9103  未認証の攻撃者が superuser トークンを取得
      ↓
CVE-2026-8635  そのトークンでホスト上の任意コマンド実行

9103 単体では「管理画面を触られる」で、8635 単体では PR:L（低権限の認証が必要）だ。並べると、公開状態のインスタンスに対して未認証からホスト上のコード実行までが通る。8635 の説明にある「full system compromise with Langflow service permissions」がそのまま成立する。

Langflow は今年に入ってから、CVE-2026-33017（未認証RCE）、CVE-2026-55255（他ユーザーのフローを実行できるIDOR・CISA KEV登録済み）と、公開インスタンスを狙う脆弱性が続いている。系統としては同じ「そもそも外に出す前提で作られていない」問題だ。

自分の環境を確認する

まずバージョン。NVD の影響範囲は 1.0.0 から 1.10.0 で、公開済みの最新は 2026-07-07 の v1.10.2 だ。

# pip 導入
pip show langflow | grep -i version

# コンテナ
docker inspect --format '{{index .Config.Image}}' <container>

次に AUTO_LOGIN の状態。未設定なら有効である点に注意する。

# 環境変数に明示されているか（無ければ既定＝有効）
docker exec <container> env | grep -i LANGFLOW_AUTO_LOGIN || echo "未設定 → 既定で有効"

そして露出。ここがいちばん重要で、バージョンより先に確認したほうがいい。

# 外から 7860 が開いていないか
ss -tlnp | grep 7860
# 0.0.0.0:7860 で LISTEN していたら、前段のFW/SGを確認する

エンドポイントの応答を見るなら、自分が管理しているインスタンスに対してのみ行うこと。

curl -s -o /dev/null -w '%{http_code}\n' http://<自分のホスト>:7860/api/v1/login/auto_login

対処

更新だけを対策にしないほうがいい。Langflow は過去に「修正版とされたバージョンがまだ攻撃可能だった」事例（CVE-2026-33017）があり、露出の遮断と併用するのが現実的だ。

1. バージョンを上げる

pip install -U langflow
# または docker pull langflowai/langflow:<1.10.0 より新しいタグ>

2. AUTO_LOGIN を明示的に切る

LANGFLOW_AUTO_LOGIN=false
LANGFLOW_SUPERUSER=<admin>
LANGFLOW_SUPERUSER_PASSWORD=<強いパスワード>

false にすると superuser 資格情報の設定が必須になるので、更新と同時に認証設計を決めることになる。

3. そもそも直接公開しない

• AWS: セキュリティグループで 7860 を社内CIDRに限定。ALB の OIDC 認証や Verified Access を前段に置く
• GCP: Cloud Run の ingress を internal にし、IAP で前段認証
• Azure: Container Apps の ingress を internal、App Service なら Easy Auth
• 自前: nginx 等で Basic 認証・IP制限

4. 公開運用していたなら、後始末をする

発行済みトークンの失効と、フロー内に保存した API キー・認証情報のローテーション。管理画面を取られていた場合、フローに埋めた外部サービスの鍵はすべて読まれた前提で動くべきだ。

5. コード実行された場合の被害を絞る

8635 の影響範囲は、Langflow プロセスに紐づけた権限で決まる。ECSタスクロール／GKEのWorkload Identity／AzureのマネージドIDから不要な権限を外しておくと、侵害が横に広がらない。非root実行・read-onlyルートFSも効く。

まとめ

この件の教訓は「既定値が安全でないソフトウェアがある」という一点に尽きる。AUTO_LOGIN が既定で有効というのは、開発時の利便性としては理解できるが、そのまま本番に出ると認証が無いのと同じになる。LLM系のツールは開発体験を優先した設計が多く、社内向けだから大丈夫という判断が最も危ないカテゴリだと思っておいたほうがいい。

各CVEのクラウド別（AWS/GCP/Azure/Linux）の対応状況は 脆弱性対応ウォッチ に整理してある。CVE-2026-9103・CVE-2026-8635 も掲載済みで、一次情報へのリンクも付けてある。

参考: CVE-2026-9103 - NVD / CVE-2026-8635 - NVD