Langflow CVE-2026-33017 Exploited to Steal AWS Keys, Deploy NATS Worker
2026/05/14 gbhackers — Langflow の脆弱性 CVE-2026-33017 に対する、パッチを適用していないインスタンスが積極的に悪用されている。一連の攻撃は、単なるリモート・コード実行や AWS キーの窃取に留まらず、”KeyHunter” と呼ばれる NATS ベースのボットネット型ワーカー・プールへの参加基盤としての悪用も展開されている。
この脆弱性は、CISA の Known Exploited Vulnerabilities (KEV) カタログに登録されている。この脆弱性は、公開されている Langflow のフロー構築エンドポイントに影響を及ぼす。それを悪用する未認証の脅威アクターは、任意の Python コードの実行が可能となり、環境変数／アプリケーション・シークレットへの完全なアクセスを達成する。
この攻撃を仕掛けた脅威アクターは、約 10時間にわたり LMDeploy インスタンスと LiteLLM 上の攻撃対象領域を探索した後に、Langflow を悪用することで、認証情報の収集および再利用サイクルを成立させた。2026年5月5日 09:12 UTC の時点で、攻撃者は Langflow の公開 Flow API に対する CVE-2026-33017 の悪用を成功させ、プロセス環境をダンプした上で、AWS_ACCESS_KEY_ID および AWS_SECRET_ACCESS_KEY をメモリから直接抽出した。
Sysdig Threat Research Team (TRT) が観測したのは、Langflow の認証不要 RCE を悪用して AI パイプラインを掌握した攻撃者が、被害者の AWS 環境へと pivot する挙動である。攻撃者は、窃取した認証情報を悪用して sts:GetCallerIdentity を呼び出して有効性を確認した後に、AWS Bedrock／S3／EC2／Lambda／IAM など複数サービスに対する偵察を実施した。これは、典型的なスコープ制限付きキーを悪用する偵察スキャンである。
さらに Bedrock:InvokeModel および Bedrock:ListModelInvocationJobs の呼び出しから、Claude や Llama 3 などの高額な基盤モデルを第三者に課金させて悪用する LLMjacking の試行も確認されている。これは他者のクラウド請求を悪用し、高コストな推論ワークロードを実行する行為である。
Langflow CVE-2026-33017 の悪用
このキャンペーンの特徴は、AWS 偵察パターン自体にあるのではなく、攻撃者が採用した C2 インフラにある。そこでは、攻撃者によりハードニングされた NATS サーバが、隠蔽 C2 インフラとして運用されていた。
従来の HTTP パネルや Discord／Telegram のようなチャット・アプリケーションではなく、認証および subject レベル ACL を備えた “45.192.109.25:14222” の NATS エンドポイントを悪用することで、この攻撃者は KeyHunter プロジェクト内のワーカー・ノードを制御していた。
単一のワーカーにより、CodePen／JSFiddle／StackBlitz／CodeSandbox などから共有されたコード・スニペットがスクレイピングされ、漏洩 API キーの収集の後に、AWS および商用 LLM のキーが検証され、その結果がオペレーターに送信されていた。
Sysdig のテレメトリによると、”159.89.205.184″ から Python ワーカーおよび Go ベースのワーカー・バイナリがダウンロードされていた。いずれも NATS に接続され、KeyHunter という名称が付与されていたが、この名称はオープンソースのキー検出ツールから借用されたものである。
Python ワーカーは scan_cde／scan_web／validate_aws／validate_ai の 4 機能を提供していた。これらは NATS subject である task.scan_cde／task.scan_web／task.validate_aws／task.validate_ai として定義され、クラウド開発環境および AI API プロバイダーを対象とする収益化チャネルに対応していた。その一方で、NATS サーバ自体は subject 単位で厳格なアクセス制御を適用し、侵害済みワーカーが publish または subscribe できる範囲を制限していた。
Python ワーカーが heartbeat.worker へ heartbeat を送信しようとした際に、サーバは “permissions violation for publish” エラーを返して送信を拒否した。それに対し攻撃者は、エクスプロイト・チャネル経由でエニュメレーション・スクリプトを投入し、ワーカー・ロールから利用できる subject に対して総当たり攻撃を実施した。
その結果として、heartbeat.worker／worker.hb／worker.heartbeat／result.*／workers.heartbeat のみが悪用可能となった。これらのロールは、heartbeat および結果送信の publish に限定されていることが判明しており、制御 subject への subscribe や他ワーカー通信の盗聴は不可能であった。
この設計は、C2 レイヤーにおける最小権限 (least privilege) の適用の事例でもある。それにより、仮に防御側がワーカー・ノードを掌握した場合でも、NATS バス全体への容易な侵入や、コントローラーに対する成りすましは困難となる。
Go ワーカーは、明示的 ACK を伴う NATS JetStream pull consumer を使用しており、ノード障害やオフライン状態が発生した場合でも、タスクが耐久キューへ保持され再配信される仕組みとなっている。さらに systemd ベースのインストーラー “deploy.sh” により Restart=always を設定し、ファイル・ディスクリプタ上限を 65,535 へ引き上げることで、高並列スクレイピングおよび長期持続性に最適化している。
KeyHunter バイナリの静的解析では、GitHub のようなコード・リポジトリではなく、オンライン・コード・サンドボックスに特化していることが確認されている。それぞれのプラットフォームごとに複数の抽出戦略を備えることで、UI や API の変更に対する耐性を持つに至っている。
Go ワーカーは uTLS を統合し、実ブラウザの TLS フィンガープリントを模倣する一方で、JavaScript を多用するページではヘッドレス・ブラウザの併用により、CodeSandbox や StackBlitz における bot 検知回避を試みていた。さらに、正規表現パターンおよび gitleaks 連携により、AWS／OpenAI／Anthropic／Stripe／Slack／秘密鍵／データベース URL などの、広範な認証情報を収集対象としていた。
運用面における攻撃者の OPSEC (Operations Security) は限定的であり、ログ削除／履歴無効化／systemd ユニット名偽装などの対策は確認されていない。また、クラッシュした Go バイナリからは、Windows ビルド・パスの漏洩も確認された。
それであっても、Langflow RCE／自動 AWS 偵察／NATS ベース C2 を組み合わせた攻撃は、小規模ながら高い技術力を持つグループの存在を示している。この攻撃者は、高度に強化されたインプラントよりも、低コスト VPS ノード／マルチ・アーキテクチャ・ワーカー／耐障害メッセージングを活用することで、ステルス性よりも規模拡大を優先していた。
防御側にとって重要なのは、Langflow への迅速なパッチ適用である。それに加えて、AI サービスおよび Bedrock 利用状況の異常監視、そして NATS のようなメッセージ・ブローカーを単なるバックエンド基盤ではなく、潜在的 C2 チャネルとして検知対象へ含めることである。
侵害指標 (IOC)
| Indicator | Type |
| 45.192.109.25:14222 | NATS C2 |
| 159.89.205.184:8888 | Staging HTTP |
| File | SHA-256 | Size |
| worker-linux-amd64 | dbee863ad2a39f939be2c7ed76f7d5a8fe000aad2d2b2d32b3e8ec3ee42f1c25 | 9,453,752 |
| keyhunter_worker.py | 323bbf3064d4b83df7920d752636b1acb36f462e58609a815bd8084d1e6b004c | 10,979 |
| deploy.sh | 16b279aa018c64294d58280636e538f86e3dd9bdcb5734c203373394b72d101a | 1,424 |
注: IP およびドメインは defang 表記であり、制御環境でのみ復元すること。
訳者後書：今回のインシデントについて、内容を整理していきましょう。この問題の大きな原因は、Langflow の公開エンドポイントに存在した CVE-2026-33017 という脆弱性です。この脆弱性があることで、本来は必要なはずの認証を通さずに、誰でも任意の Python コードを実行できてしまう状態になっていました。このギャップを突く攻撃者は、アプリケーションのシークレット情報や AWS の認証情報を盗み出し、さらに別のクラウド・サービスへと攻撃の手を広げていきました。便利なツールであっても、パッチが適用されていない古いバージョンを公開した状態で放置すると、大切な情報が外部から丸見えになってしまうリスクがあります。ご利用のチームは、ご注意ください。よろしければ、2026/03/26 の「CISA KEV 警告 26/03/25：Langflow のコード・インジェクションの脆弱性 CVE-2026-33017 を登録」も、ご参照ください。
IoT OT Security News 
You must be logged in to post a comment.