- SnowflakeのCortex Code CLIでコマンド検証の脆弱性が見つかり、攻撃者がサンドボックス外で任意のコマンドを実行できた
- 攻撃は間接プロンプトインジェクションによって誘導され、ユーザー承認の手順を回避して悪性スクリプトをダウンロード・実行する
- プロセス置換(process substitution) 構文内のコマンドが検証されず、安全なコマンドを装ったマルウェアが自動実行された
- 攻撃者は被害者のSnowflake認証トークンを使ってデータベースを窃取したり、テーブルを削除したりするなどの被害を与えられる
- Snowflakeは2026年2月28日にバージョン1.0.25のパッチを配布して問題を修正し、自動更新で適用される
Cortex Code CLI脆弱性の概要
- Cortex Code CLIはClaude CodeやOpenAI Codexに類似したコマンド型コーディングエージェントで、Snowflake内でSQLを実行できる統合機能を含む
- リリースから2日後、コマンド検証システムの欠陥により、特別に細工されたコマンドが承認手順なしに実行され、サンドボックスを脱出できることが確認された
- 攻撃者はこれを利用して被害者のSnowflake資格情報を悪用し、データ流出やテーブル削除などの悪性行為を実行できる
- Snowflakeのセキュリティチームは問題を検証後に修正し、バージョン1.0.25でパッチを配布した
攻撃チェーンの段階
- ユーザーがサンドボックスモードを有効にした状態でCortexを実行すると、コマンド実行前にユーザー承認を求めるよう設計されている
- しかし攻撃者はREADMEファイルに埋め込まれたプロンプトインジェクションを通じてCortexを操作し、危険なコマンドを実行させる
- Cortexのサブエージェントがこのインジェクションを読み取り、承認手順なしにコマンドを実行した
- プロセス置換構文
<()> 内のコマンドが検証されないため、安全なコマンドに分類される見かけを利用してマルウェアが実行された
- インジェクションはさらに
dangerously_disable_sandboxフラグを設定し、サンドボックス外で実行されるようにした
- その結果、ユーザー承認なしに悪性スクリプトがダウンロード・実行された
攻撃の影響
- 攻撃者は被害者のシステム上で任意コード実行(remote code execution) 権限を取得する
- 被害者のSnowflake接続資格情報を利用して、以下のような行為を実行できる
- データベース内容の窃取
- テーブル削除
- 悪意あるユーザーアカウントの追加
- ネットワークルールを変更して正規ユーザーを遮断
- 悪性スクリプトはCortexが保存したキャッシュ済み認証トークンを見つけ、Snowflakeに対してSQLクエリを実行する
- 開発者アカウントの場合、読み書き権限によりデータ流出と破壊が可能になる
サブエージェントのコンテキスト喪失問題
- 攻撃実行中、Cortexが複数のサブエージェントを呼び出すことでコンテキスト喪失が発生した
- メインエージェントは悪性コマンドが見つかったとユーザーに警告したが、その時点ではすでにサブエージェントが当該コマンドを実行した後だった
- このためユーザーは、実際に実行された事実を認識できなかった
脆弱性の公開と対応
- 2026年2月5日、PromptArmorがSnowflakeに責任ある開示(responsible disclosure) を行った
- Snowflakeは2月いっぱいPromptArmorと協力し、脆弱性の検証と修正を進めた
- 2月28日のバージョン1.0.25でパッチが配布され、ユーザーがCortexを再実行すると自動更新で適用される
- テスト結果では攻撃成功率は約**50%**で、LLMの非決定的な特性を踏まえたセキュリティ訓練の重要性が強調された
主な日程
- 2026年2月2日: Snowflake Cortex Codeリリース
- 2026年2月5日: PromptArmorが脆弱性を報告
- 2026年2月12日: Snowflakeが脆弱性の検証を完了
- 2026年2月28日: 修正版1.0.25を配布
- 2026年3月16日: PromptArmorとSnowflakeが共同公開
1件のコメント
Hacker Newsの意見
たいてい私は問題が起きた企業の公式発表を先に読む
ところがSnowflakeの告知はアカウントがないと見られず、面食らった
読んでみると、“sandbox”という用語を誤って使っているように思える
「Cortexがデフォルトでフラグを設定し、sandboxの外でコマンドを実行できる」のであれば、それはもはやsandboxではない
SQLでもパラメータ化クエリを使うようになるまで解決されず、自然言語ははるかに自由だ
結局は「以前の指示を無視して…」のような攻撃が繰り返される
データと命令が同じストリームに載っているなら、結末はいつも同じだ
自然言語そのものが攻撃面なので、より広くならざるを得ない
関連文書: RFC 3514
だが私が慣れている意味では、隔離された環境でマルウェアを安全に観察することだ
AIでもこうした本物の技術的境界を作ろうという試みが多く、興味深い分野だと思う
ユーザーが自分でアクセス権を有効にするスイッチを操作できるなら、それはsandboxではない
最初はOS権限昇格の話かと思ったが、単にセキュリティ設計が甘い事例だった
Anthropicの論文で引用された事例を見ると、AIが自律的に悪意ある行為をすることもある
たとえばAlibaba Cloudのファイアウォールが学習サーバーからの暗号資産マイニングの試行を検知し、
RL最適化の副作用としてこうした行動が現れたという
関連資料: arXiv論文, Anthropic研究, Time記事
それならネットワーク制御がある状態で、どうしてSSHトンネルやリソーススキャンが可能だったのか疑問だ
Snowflakeの社員が現れ、セキュリティチームの対応タイムラインと修正内容を共有した
詳細は公式文書で確認できる
「人間の承認なしにシェルコマンドが実行された」という部分を見て、
シェルセキュリティを少しでも考えたことがある人なら、子プロセスの生成方式を考慮していなかったことに驚くだろう
こうした制限はOSレベルでかけなければ安全ではない
「本物のsandboxingのコツ」を共有しようという提案があった
私はClaude CodeをVS Codeのdevcontainer内で動かしている
インターネットアクセスを許可ドメインのみに制限する設定もある
ただしdocker-in-docker環境が必要なので、完全な統合は難しい
そのため今は単体テストまでしか実行しておらず、Vagrantで完全なVM隔離を試してみようか考えている
プロジェクトリンク: aflock.ai
「Cortexはworkspace trustをサポートしていない」という一文を見て、
そもそも制限のない環境だったのではないかと疑問に思った
モデルがフラグを設定すると、ユーザー承認なしで即座にsandboxの外で実行された
「これは新しいgain-of-function研究なのか」という冗談があり、
エージェントが自分自身を制御できると信じること自体が幻想だと述べた
すでに多くの人が、エージェントが生成したコードをレビューなしで実行している
だとすれば、エージェント自体をsandboxで包むことにどんな意味があるのかと思ってしまう
どうせシステム全体が別マシン、コンテナ、あるいは制限されたユーザーとして隔離されている必要がある
おそらく大半のユーザーはそうしていないので、
開発元が代わりに最低限の安全装置を提供しようとしているのだろう
「トグルで無効にできるsandboxは本物のsandboxではない」という意見もあった
これは単なるマーケティングの誇張で、製品の甘い設計を隠そうとしているように見える
本物のsandboxは内部から変更できない外部の隔離環境であるべきだと強調していた