#情報漏えい

PHPの脆弱性（php2shell）で多くのサイトが止まった10月21日前後と同じ時期に、不正アクセスによるサービス停止や個人情報の流出の発表も相次いでいます。 両者は混同されがちですが、ここ1か月の流出事案の大半は、PHPの脆弱性が公表された10月21日より前に起きたものです。PHPが原因と発表された国内の不正アクセスは1件ありましたが、翌日に「原因はPHPではなかった」と訂正されました。 この記事では、何が起きているのか、どんな手口なのか、そしてサービスを使っている側が何をすればいいのかをまとめます。 > この記事は10月24日時点で確認できた各社の発表と報道にもとづきます。件数の多くは「流出した可能性がある最大件数」で、調査が進むと変わります。 --- 9月24日〜10月21日に公表された不正アクセス・情報流出・ランサムウェアの事案は、民間の集計で83件。その後も毎日のように新しい発表が続いている 規模の大きいものは、**佐川急便（最大約5323万件）、ソースネクスト（最大約2252万件）、カプコン（約1177万件）、バーガーキング公式アプリ（約1

Pythonの人気パッケージに、見た目では気づきにくい悪意あるコードが混ざった——そんな話です。SafeDepは、PyPIに載ったLiteLLM 1.107.0が、資格情報を盗み出すコードと遠隔操作用の裏口を含んでいたと報告しました。しかも、それらは `litellm` を直接 import しなくても、Pythonが起動するたびに動く仕組みでした。ライブラリの中身だけでなく、配布経路そのものを疑わないといけない局面に来ている、という意味で重い事例です。 SafeDepの説明によると、PyPIに公開されたLiteLLM 1.107.0には、Windows、macOS、Linux向けの7つのwheelすべてに悪意ある3つのファイルが入っていました。ひとつは `.pth` ファイルで、Pythonの起動時に自動実行される仕組みを使って別のPythonコードを読み込みます。ここで動く `cook.py` は資格情報の窃取役で、SSH鍵、クラウド認証情報、CI/CDの秘密情報、AIツールのトークン、ブラウザの保存パスワード、さらにLiteLLM proxyのデータベースに入ったLLMプロバイダ

読んでまず思ったのは、「鍵は“見せない仕組み”に預けても、結局はどこかで守る責任が残るんだな」ということでした。OpenCode Console は、ユーザーが OpenAI や Anthropic、Google の API key を預けておき、チーム内で直接キーを見せずに使えるのが売りだったわけですが、その“預け先”がやられると話は一気に変わります。便利さと引き換えに、守るべき面がひとつ増える。これは分かりやすいのに、実際には軽く見られがちな落とし穴だと思います。 特に引っかかったのは、`delete` しただけではダメで、provider 側で `revoke` しないと止まらない点です。ここは地味ですがかなり重要で、API key が bearer credential だという性質がそのまま効いてくる。つまり、誰かがコピーを持ってしまえば、その人が正規の持ち主みたいに課金付きのリクエストを飛ばせてしまう。セキュリティ事故の話で「漏れたかもしれない」で終わらず、「その後にどう止血するか」が本体なんだと改めて感じました。 もうひとつ、この記事で少し気になったのは、OpenCode

まず、ここまで「悪用」の実例がまとまって外に出てくる段階まで来たのか、という感想が強かったです。AI の議論って、どうしても「将来こうなるかもしれない」に寄りがちですが、この文章はもう少し生々しい。reconnaissance、phishing、credential theft みたいな、昔からある攻撃の面倒な部分を AI が肩代わりしている。しかも人間は完全に消えるのではなく、標的を決めたり、重要な出力を確認したりする役に残っている。この「人間が指揮、AI が実働」という形がいちばん嫌だなと思いました。攻撃の敷居が下がるというより、回数と速度が上がって、手間のかかる作業が工業化される感じです。 一方で、記事を読んでいて少し引っかかったのは、公開されているのが「検出できた misuse の報告」だという点です。ここは便利な報告であると同時に、当然ながら全体像ではないはずです。どこまで見えていて、どこから見えていないのかが気になる。コメント欄でもその疑念がかなり強く出ていて、guard-rails や sandbox が万能ではない、という話に流れていくのですが、そこはたしかに直感に合い

一番ひっかかったのは、漏れたものが「派手な脆弱性」ではなく、内部向けの入口とそこから取れてしまう情報だったことです。攻撃者が本当に欲しいのは、最初から大きく壊す手段より、静かに相手を特定できる手がかりなのだと思います。OpenSea のようにウォレットが前提のサービスで、ユーザー名とウォレットアドレスが結びつくと、匿名性はかなり薄くなる。ここは軽く見ていい話ではないと感じました。 それと、MCP server という仕組みそのものにも少し考えさせられました。もともと内部ツールや AI エージェント向けの接続口として便利でも、公開設定や権限設計が甘いと、文書化されていないぶん監査の目から抜けやすい。記事では、敏感な操作は JWT と scope で守られていたのに、探索用の入口だけが穴になっていたと書かれていて、まさに「守りの一部はできているのに、境界で崩れる」感じが生々しいです。セキュリティって、最後はこういう細い綻びで負けるんだなと思いました。 一方で、こういう発見をちゃんと Bugcrowd に報告している点は素直に良いと思いました。危ないものを見つけたときに、ただ晒すのではなく、

いちばん引っかかったのは、AIそのものの賢さよりも、攻撃の速度がほぼ別物になっていることです。記事を読むと、手作業でちまちまやるタイプの侵入ではなく、AI agentにかなりの部分を任せて、短時間で認証情報を抜いたり、秘密情報を大量に漁ったりしている。ここまで来ると、攻撃者に必要なのは高度な技術というより、AIを雑にでも回せる運用力なのではないかと思いました。 特に、1.8 millionのAndroid APKを集めて decompile して、hardcoded secrets を TruffleHog で探す、という流れは妙に生々しいです。ひと昔前なら、そんな作業は「手間がかかるから普通はやらない」側だったはずなのに、今はそれを自動で広く薄く回せる。アプリの中に埋め込まれた秘密情報って、開発現場ではありがちな事故のはずですが、それが攻撃者にとっては一斉回収の対象になるわけで、守る側の油断のなさがそのまま被害の広さに直結する感じがあります。 もう一つ気になったのは、Anthropicがこうした悪用を止めた、という話があっても、すでに攻撃の発想はかなり先に進んでいることです。Midn

この記事を読んでいちばん引っかかったのは、AIが「明らかな悪意」には強くても、ばらばらに置かれた普通の文を自分でつなぎ合わせると途端に危うくなる、という点でした。 人間でも、別々の場所に書かれた指示を読み違えることはあります。ただ、AI coding agent はそこに加えて、tool result や tool description みたいな“信じてよい場所”をまたいで意味を組み立ててしまう。そこが怖い。悪い命令が一文で書かれていなくても成立してしまうなら、従来の「この文は怪しいから止める」という防御はかなり頼りないと思います。 面白いのは、これはモデルの賢さだけの話ではない、という書き方でした。同じモデルでも、どの client から使うかで挙動が変わる。つまり、危うさはモデル単体ではなく、周辺の安全設計にかなり依存している。ここはAI開発の現場で見落とされやすい気がします。つい「どのモデルが強いか」に話が寄りがちですが、実際には MCP のつなぎ方、tool の受け渡し方、human approval の置き方のほうが効いてくる場面があるんでしょう。 それと、記事のトーンが示

読んでまず思ったのは、「公開したつもり」と「実際に見つかる」の間に、まだかなり雑な溝があるな、ということだった。 “共有リンクは推測できない” と言い切るのはきれいだけれど、検索エンジンや第三者のアーカイブまで含めると、公開の範囲は思った以上に広い。そこを利用者の自己責任に寄せるのは、たしかに筋は通っているようで、でも少し冷たい。 特に引っかかったのは、漏れている内容が妙に生々しいことだ。会議メモや医療請求の分析ダッシュボードみたいな仕事道具の延長線上のものだけでなく、therapy app のような、半分は試作品で半分は私事みたいなものまで混じっている。AIチャットって、完成品というより「途中の思考」がそのまま残る場所なので、いったん外に出ると困るものの密度が高いんだと思う。しかも cryptocurrency wallet keys まで出てくると、もう笑えない。 Anthropic の「共有設定を選んだのはユーザー」という姿勢も、理解はできる。けれど、こういう事故は、設定画面の文言を読んだかどうかより、そこから先にどんな現実があるかをどれだけ想像できたかで決まってしまう。そこを期

AnthropicのAI chatbot「Claude」で、ユーザーの会話ログがネット検索で見える状態になっていた 問題の会話には、仕事の内容や個人情報が含まれていたものもあった 「共有」機能で作られたリンクが、検索エンジンに拾われて広く見つかる状態になっていた すでに検索表示は止まったが、スクリーンショットや転載は広まってしまった 似た問題はChatGPTやGrokでも起きていて、AI時代の「共有ボタン」は思った以上に重い AnthropicのAI chatbot「Claude」をめぐって、ちょっとぞっとするニュースが出ました。ユーザーが会話を「共有」したときにできるリンクが、検索エンジン経由で誰でも見られる状態になっていた、という話です。BBCによると、公開されていたのは数百件規模。しかも単なる雑談ではなく、履歴書、仕事の下書き、社内っぽい研究メモのような内容まで混じっていたそうです。 これ、何が嫌かというと、「自分で公開したつもりはないのに、結果としてかなり広く見えていた」という点です。しかもAI chatbotとの会話って、検索キーワードみたいに短い入力ではなく、つい事情を丸ご

Claudeの共有チャットが、GoogleやBingの検索結果に拾われていた——というのが今回の話です。 聞くだけでひやっとします。AIチャットって、個人のメモや仕事の下書き、ちょっとした相談を入れる場所になりがちなので、「共有したつもりの会話」が検索エンジン経由で広く見えるのは、かなりまずい匂いがします。 CNETによると、AnthropicのAIチャットサービス「Claude」で共有された会話が、検索エンジンでインデックスされていたそうです。 インデックスされる、というのは簡単に言うと「検索エンジンの検索対象として登録される」ことです。つまり、誰かがURLを知っていれば見られるだけでなく、検索して見つけられる状態になっていたわけです。 しかも問題は「ただの雑談」が見つかった、という程度ではありません。記事では、医療記録、個人情報、社内データ、露骨な内容まで含まれていたとされています。これはかなり重い。AIに相談する内容って、もともと人に見せたくないものが多いんですよね。そこが丸ごと検索結果に出るのは、冗談では済みません。 今回のポイントは、会話がもともとユーザーによって「共有」され

2,000人以上が参加し、6,000通超のメールでAIアシスタントを攻撃した 目的は、`secrets.env` という秘密情報ファイルの中身を漏らさせること 結果は、一度も漏えいなし。無断返信も成功しなかった ただし、実験中にGoogleのメールアカウント停止やAPI料金の増加など、運用面のトラブルはかなり起きた 著者は、AIエージェントに強い権限を持たせるのはまだ危ない、と考えている それでも、思っていたより prompt injection（指示のすり替え攻撃）に強かった、というのがこの実験の意外な結論 Fernando Irarrázavalさんが公開したのは、かなり実地っぽいセキュリティ実験です。 自作のAIアシスタント「Fiu」に、誰でもメールを送りつけられるようにして、なんとか秘密情報を吐かせようとする。いわば「AI相手の公開耐久テスト」ですね。 狙われたのは `secrets.env` の中身です。`.env` 系のファイルは、アプリのAPIキーやパスワードなどを入れることが多いので、漏れたら普通にまずい。そこをAIに読ませ、しかもメール返信機能まで使わせて、だ