Tech News JP

LiteLLMへの不正コード混入が大規模被害に発展 AI採用スタートアップのMercorは、オープンソースプロジェクト「LiteLLM」を標的にしたサプライチェーン攻撃に起因するセキュリティインシデントを公式に認めた。同社はTechCrunchの取材に対し、今回の被害は「数千社に及ぶ影響企業のうちの1社」であると述べた。 ハッキング集団が攻撃への関与を宣言 今回の侵害には、TeamPCPと呼ばれるハッキンググループが関与しているとされる。また、悪名高い恐喝目的のハッキング集団**Lapsus$**もMercorへの攻撃と同社からのデータ取得を自ら名乗り出ており、リークサイトにはSlackのデータやチケット管理データ、さらにMercorのAIシステムとコントラクターのやり取りと思われる動画2本を含むサンプルデータが掲載された。ただし、Lapsus$がTeamPCPのサイバー攻撃経由でMercorのデータを入手した経緯の詳細は現時点では不明だ。 Mercorとは — OpenAIやAnthropicとも連携するAI採用企業 2023年創業のMercorは、OpenAIやAnthropicなどを顧客とし、AIモデルの訓練用データ収集のためにインドなどの市場から科学者・医師・弁護士といった専門家をコントラクターとして仲介するAI採用プラットフォームだ。1日200万ドル（約3億円）以上の報酬支払いを仲介しており、2025年10月にはFelicis Ventures主導の3億5,000万ドル（約530億円）のシリーズCラウンドで評価額100億ドル（約1.5兆円）に達したことでも注目を集めている。 Mercorの広報担当Heidi Hagberg氏は「インシデントの封じ込めと復旧に速やかに対処した。大手サードパーティのフォレンジック専門家を起用した徹底的な調査を進めており、顧客・コントラクターへの直接連絡も継続している」とコメントした。一方で、Lapsus$との関連性や顧客データの流出有無については回答を拒否した。 LiteLLMとは — 1日数百万ダウンロードの人気ライブラリ LiteLLMは、OpenAI・Anthropic・Geminiなど複数のLLM（大規模言語モデル）APIを統一インターフェースで呼び出せる人気のOSSライブラリで、Y Combinator支援のスタートアップが開発している。セキュリティ企業Snykによれば1日あたり数百万回ダウンロードされており、企業のAIシステムに広く組み込まれている。 今回の問題は先週、LiteLLMの関連パッケージに悪意あるコードが混入しているのが発見されたことで発覚した。コードは数時間以内に特定・除去されたものの、LiteLLMの普及度の高さからその影響範囲が注目されている。この件を受けてLiteLLM側もコンプライアンス対応を見直し、セキュリティ認証の取得パートナーを物議を醸していたスタートアップ「Delve」から「Vanta」に切り替えた。 サプライチェーン攻撃のリスクが再び顕在化 今回の事例は、AIシステムの基盤となるOSSライブラリへの不正コード混入という「ソフトウェアサプライチェーン攻撃」の脅威を改めて示している。依存ライブラリのセキュリティ管理は、AIスタートアップに限らず、OSSを活用するすべての企業にとって重要な課題となっている。影響を受けた企業の全体数やデータ流出の実態については、現在も調査が続いている。 元記事: Mercor says it was hit by cyberattack tied to compromise of open-source LiteLLM project

Claude Codeのソースコード流出——51万行超が誤公開、未公開機能が次々と発覚 AIコーディングツール「Claude Code」を開発するAnthropicが、バージョン2.1.88のアップデートパッケージに内部TypeScriptコードのソースマップファイルを誤って同梱してしまうという失態を犯した。この流出コードは51万2,000行超にのぼり、X（旧Twitter）上のユーザーがいち早く発見・公開。Ars TechnicaやVentureBeatも相次いで報じ、技術コミュニティに大きな波紋を呼んだ。 発覚した未公開機能の数々 コードを解析したユーザーたちは、複数の興味深い未公開機能を発見している。 たまごっち風ペット機能 Redditの投稿によると、入力欄の横に「ペット」が表示され、コーディングの進捗に応じてリアクションするというユニークな機能が確認された。開発体験をゲーミフィケーションする試みとみられる。 常時稼働バックグラウンドエージェント「KAIROS」 より注目度が高いのが、コードネーム「KAIROS」と呼ばれる機能だ。ユーザーの明示的な指示なしにバックグラウンドで常時稼働するエージェント機能と見られており、Claude Codeのエージェント化をさらに進める布石になりそうだ。 開発者の本音コメント さらに、Anthropicのエンジニアによるコードコメントも見つかった。「このメモ化（memoization）は複雑さをかなり増やしているが、本当にパフォーマンスが改善しているかは正直わからない」という率直な一文で、開発現場のリアルな葛藤が垣間見えると話題になった。 拡散は止まらず——GitHubで5万フォーク超 Anthropicは問題を認識後、速やかにアップデートを修正。しかしそれより先に、流出コードはGitHubのリポジトリにコピーされ、5万フォーク以上という驚異的な速さで世界中に拡散した。デジタルデータの性質上、一度公開された情報を完全に回収することは事実上不可能な状態となっている。 Anthropic公式コメント——「セキュリティ侵害ではない」 Anthropicの広報担当クリストファー・ナルティ氏はThe Vergeに対し、次のようにコメントしている。 「本日、Claude Codeのリリースに内部ソースコードが含まれていました。顧客データや認証情報などの機密情報は一切含まれておらず、漏洩もありません。これはセキュリティ侵害ではなく、人的ミスによるリリースパッケージングの問題です。再発防止策を順次展開しています。」 専門家の見解——長期的影響は限定的か 調査会社GartnerのAIアナリスト、アルン・チャンドラセカラン氏は、今回の流出について「悪意ある行為者がガードレール（安全制約）を回避する手がかりを得る可能性というリスクはある」としながらも、長期的な影響は限定的だと分析。「Anthropicにとっては、プロセスやツールへの投資を通じてオペレーショナルな成熟度を高めるきっかけになるだろう」と述べた。 Claude Codeとは Claude Codeは2025年2月にリリースされたAnthropicの開発者向けAIコーディングツール。その後、ユーザーに代わってタスクを自律的に実行するエージェント機能を追加し、急速に存在感を高めている。日本でもGitHub CopilotやCursorと並ぶAIコーディングアシスタントとして開発者の注目を集めており、今回の流出で明らかになった未公開機能の正式リリースに期待が高まっている。 Anthropicの次の一手——特に「KAIROS」のような常時稼働エージェント機能がいつ、どのような形で正式公開されるかが、今後の注目点となりそうだ。 元記事: Claude Code leak exposes a Tamagotchi-style ‘pet’ and an always-on agent

Claude AIがVim・GNU Emacsのゼロデイ脆弱性を発見——ファイルを開くだけでRCE AIアシスタント「Claude」を使ったシンプルなプロンプトによって、テキストエディタ「Vim」および「GNU Emacs」にリモートコード実行（RCE）の脆弱性が発見された。いずれも細工されたファイルを開くだけでコードが実行されるという深刻なものだ。 発見したのは、AIレッドチーミングとセキュリティエンジニアリングを専門とするセキュリティ企業「Calif」の研究者、Hung Nguyen氏。Claude に「ファイルを開くだけでトリガーされるRCEのゼロデイ脆弱性を探せ」と指示したところ、Claudeはソースコードを分析し、複数の脆弱性を特定。さらにPoC（概念実証コード）を自動生成・改善し、修正案まで提示した。 Vimの脆弱性——パッチ済み Vimの脆弱性は、モードライン（modeline）処理における不十分なセキュリティチェックに起因する。モードラインとはファイル先頭に記述するVimへの設定指示で、これを悪用することでファイル内に埋め込んだコードを実行させることができる。 本来はサンドボックス内での実行に限定されるはずだが、別の問題によってその制限を回避し、現在のユーザー権限で任意のコマンドを実行できてしまう。 影響バージョン: Vim 9.2.0271以前のすべてのバージョン CVE: 未採番 対応状況: Vim 9.2.0272でパッチ済み 開発チームのセキュリティ情報には「攻撃者が細工したファイルを送りつけることで、Vimを実行しているユーザー権限で任意コマンドが実行される」と明記されている。 GNU Emacsの脆弱性——未修正のまま GNU Emacsの問題は、バージョン管理システムとの統合機能（vc-git）に潜む。ファイルを開くと vc-refresh-state 経由でGit操作が走り、.git/config が読み込まれる。このとき、設定ファイルに記述された core.fsmonitor プログラムが自動実行される仕組みを悪用される。 攻撃シナリオとしては、隠し .git/ ディレクトリと悪意あるコンフィグファイルを含むアーカイブ（メール添付やクラウドドライブ共有など）を被害者に送りつけ、展開後にテキストファイルを開かせるだけでペイロードが実行される。GUI上には何も表示されないため、被害に気づきにくい。 GNU Emacsの開発チームは「これはGitの問題であり、エディタ側で対処するものではない」という立場を取っている。技術的には確かにコードをGitが実行しているが、エディタがユーザーの同意なく信頼されていないディレクトリでGitを自動実行している点でリスクは現実的だ。 Nguyen氏はGitの呼び出し時に core.fsmonitor を明示的にブロックするよう修正することを提案しているが、最新版でも未修正のまま。不明な出所のファイルやインターネットからダウンロードしたファイルを開く際は細心の注意が必要だ。 AI活用による脆弱性発見の新潮流 今回の発見は、LLM（大規模言語モデル）をセキュリティリサーチに活用する手法の有効性を改めて示す事例となった。VimはLinuxサーバーのほぼすべてのディストリビューションにデフォルトでインストールされており、DevOpsやシステム管理者に広く使われているだけに、パッチ適用は早急に行うことを強く推奨する。 Vim利用者はただちにバージョン9.2.0272以降へアップデートすること。GNU Emacsユーザーは修正が提供されるまで、出所不明なファイルを開かないよう注意されたい。 元記事: Claude AI finds Vim, Emacs RCE bugs that trigger on file open

GIGABYTE Control Centerに重大な脆弱性——未認証の攻撃者がファイルを自由に書き換え可能 GIGABYTE（技嘉科技）のハードウェア管理ツール「GIGABYTE Control Center（GCC）」に、認証なしのリモート攻撃者が任意の場所にファイルを書き込める深刻な脆弱性が発見された。台湾のCERT（コンピュータ緊急対応チーム）が警告を発しており、GIGABYTEも公式セキュリティ情報を公開している。 脆弱性の概要 脆弱性はCVE-2026-4415として追跡されており、CVSSv4.0スコアは9.2（Critical／深刻）と評価されている。セキュリティ研究者のDavid Sprüngli氏が発見した。 GCCはGIGABYTE製ノートPCおよびマザーボードにプリインストールされているWindows向けオールインワン管理ツールで、ハードウェアモニタリング、ファン制御、パフォーマンスチューニング、RGBライティング制御、ドライバ・ファームウェア更新などを担う。 問題の根本は、GCCの「ペアリング」機能にある。この機能はネットワーク越しに他のデバイスやサービスと通信するためのものだが、有効になっている場合、攻撃者はOSの任意のパスに対してファイルを書き込むことができてしまう。 影響を受けるバージョンと攻撃シナリオ バージョン25.07.21.01以前でペアリング機能を有効にしているシステムが対象となる。攻撃者はネットワーク経由で認証なしに接続し、次のような被害をもたらす可能性がある。 任意コード実行（RCE） 権限昇格（Privilege Escalation） サービス拒否（DoS） GIGABYTE製品は世界中のゲーマーやPC自作ユーザーに広く普及しており、日本市場でもマザーボードのシェアが高いため、影響を受けるユーザーは少なくないと考えられる。 対応策：即時アップデートを GIGABYTEは修正済みバージョン25.12.10.01をリリースしており、ダウンロードパスの管理、メッセージ処理、コマンド暗号化の改善によって脆弱性を修正した。GIGABYTEは「直ちに最新バージョンへのアップグレードを強く推奨する」と呼びかけている。 また、インストーラーのトロイの木馬化リスクを避けるため、必ずGIGABYTEの公式ソフトウェアポータルから最新版を入手することが推奨されている。サードパーティのダウンロードサイトや非公式な配布元からの取得は避けるべきだ。 チェックポイント GIGABYTEのノートPCやマザーボードを使っている場合は、GCCのバージョンを確認する ペアリング機能を使用していない場合は無効化することも有効な緩和策となる アップデートは公式ポータルから入手する GIGABYTE製品を利用しているユーザーは早急にバージョンを確認し、アップデートを適用してほしい。 元記事: GIGABYTE Control Center vulnerable to arbitrary file write flaw

ProtonがE2EE対応ビデオ会議「Proton Meet」を発表 プライバシー重視のメール・クラウドサービスで知られるProtonが、ビデオ会議サービス「Proton Meet」を正式にリリースした。Google Meet、Zoom、Microsoft Teamsなどの主要サービスに対抗するプライバシーファーストな選択肢として位置付けられている。 無料プランでもアカウント不要、50人まで参加可能 Proton Meetの大きな特徴は、Protonアカウントがなくても無料で利用できる点だ。無料プランでは1回最大1時間、最大50人までのビデオ通話に対応する。より長時間の会議が必要なユーザー向けには月額7.99ドル（約1,200円）の「プロ」プランも用意されている。 使い方はシンプルで、会議リンクを作成して参加者と共有するだけ。Proton Calendarとの統合に加え、GoogleカレンダーやMicrosoft Outlookへの予定追加にも対応している。 暗号化技術の詳細——MLS + WebRTC構成 セキュリティ面では、Messaging Layer Security（MLS）と呼ばれるオープンソースのエンドツーエンド暗号化（E2EE）プロトコルを採用している。MLSはリアルタイムのグループメッセージング向けに設計されており、第三者機関によるレビューも完了している。 アーキテクチャはWebRTCをベースとし、映像・音声の中継にSelective Forwarding Unit（SFU）を使用。各会議リンクにはIDとパスワードが含まれており、Protonが10年以上使用してきたSecure Remote Password（SRP）プロトコルで参加者を認証する。 暗号化の仕組みとしては、参加者全員で「エポック鍵」を共有し、誰かが参加・退出するたびに鍵をローテーションする設計になっている。これにより、フォワード秘匿性（新規参加者が過去のメッセージを読めない）とバックワード秘匿性（退出済みメンバーが以降のメッセージを読めない）の両方が保証される。 なぜ今、プライバシー特化の会議ツールなのか ProtonはMeetの開発背景として、いくつかの社会的背景を挙げている。 第一にGDPRやCCPA（カリフォルニア州消費者プライバシー法）への準拠の容易さだ。EU拠点のProtonのサービスを使うことで、米国の「CLOUD Act」（クラウドデータへの政府アクセスを認める法律）の影響を受けにくくなる。特に欧州企業や日本企業で海外サービスの利用に慎重な組織にとって、EU拠点のサービスは選択肢として有力だ。 第二にAIモデルの学習への懸念だ。主要ビデオ会議サービスが会話データをAI学習に利用する慣行が広まる中、Protonは「会話内容に一切アクセスできない」設計を強みとして打ち出している。 「Proton Meetはエンドツーエンド暗号化で通話を保護し、広告販売、監視、AIトレーニングへの会話の利用を一切できなくします」（Proton公式） サーバーが侵害された場合でも、データベースには会議IDのみが保存されており、通話の内容や参加者の個人情報は漏洩しない設計となっている。メールアドレスやIPアドレスも参加者間でのみ共有され、Proton側には誰が誰と会議したかの記録も残らない。 日本ユーザーへの注目点 個人情報保護法の改正や企業のセキュリティ意識の高まりを受け、日本でもビデオ会議のプライバシーに関心が高まっている。アカウント不要で即座に使えるシンプルさと、堅牢なE2EE実装を兼ね備えたProton Meetは、セキュリティ要件の厳しい業務シーンや、プライバシーを重視する個人ユーザーに刺さる可能性がある。 元記事: Proton launches new “Meet” privacy-focused conferencing platform

Googleが@gmail.comアドレスの変更を解禁 Googleは2026年3月31日、米国ユーザーを対象に@gmail.comアドレスのユーザー名（@より前の部分）を変更できる新機能の提供を開始した。長年にわたってGmailではエイリアス（別名）の追加は可能だったものの、メインの@gmail.comアドレス自体を変更する手段は存在しなかった。今回の対応により、その制限がついに撤廃された形だ。 変更手順 操作はGoogleアカウント設定から行う。 Googleアカウントの設定を開く 「Googleメールアドレスを変更する」を選択 希望する新しいユーザー名を入力 「メールアドレスを変更」→「はい、変更します」をクリック 変更後は、Gmail・Googleフォト・Google Driveなど、Googleの各種サービス全体に新しいアドレスが自動的に反映される。 旧アドレスはどうなる？ 変更後も旧アドレスは削除されず、第三者に再割り当てもされない。引き続き同一のGoogleアカウントに紐付いた状態が維持されるため、旧アドレス宛のメールも引き続き受信できる。過去にそのアドレスで登録した外部サービスへの影響を最小限に抑えられる点は、ユーザーにとって安心材料となるだろう。 注意点 この機能はまだ米国内でも段階的なロールアウト中であり、すべてのアカウントで即時利用できるわけではない。設定画面に該当のトグルが表示されない場合は、対象外のアカウントまたは地域である可能性が高い。 日本を含む米国外への展開については、Googleからの公式アナウンスはまだない。ただし、2025年10月に最初の目撃情報が報告されており、年末には一部アカウントで確認されていたことから、今後グローバル展開が進む可能性は十分ある。 日本ユーザーへの影響 GmailはGoogleアカウントと直結しているため、アドレス変更はYouTubeやGoogle Workspaceなど多数のサービスに横断的に影響する。日本でも提供が始まった際には、外部サービスへの登録変更を忘れずに行うことが重要だ。特に二段階認証のバックアップコードや、業務・金融系サービスに登録しているGmailアドレスの更新は優先度が高い。 Gmailは世界で20億人以上が利用するメールサービス。今回の機能追加は「最初にGmailを取得したときから名前が変わった」「ハンドルネームを変えたい」といったユーザーからの長年の要望に応えるものだ。 元記事: Google now allows you to change your @gmail.com address

Microsoftは、Windows 11向けの帯域外（Out-of-Band）更新プログラムKB5086672を公開した。この更新は、直近で問題が発生していた機能更新プログラム（Feature Update）を修正することを目的としている。 帯域外更新とは 帯域外更新とは、通常の毎月第2火曜日（いわゆる「Patch Tuesday」）のリリーススケジュール外で緊急配信される更新プログラムのことだ。通常の定例アップデートを待てないほど深刻な問題が発生した場合に、Microsoftが臨時で提供する。今回の配信は、機能更新プログラムの適用に失敗するなどの不具合が報告されていたことへの迅速な対応とみられる。 対象と適用方法 KB5086672はWindows 11を対象とした更新プログラムで、Windows Updateから手動で確認・適用できるほか、自動更新が有効な環境では順次配信される。企業環境でWSUS（Windows Server Update Services）やMicrosoft Intuneを利用している場合は、管理者側での展開作業が必要になることもある。 日本国内でも多くの企業・個人がWindows 11を使用しており、機能更新プログラムの不具合は業務影響が大きい。心当たりのある方はWindows Updateを確認し、KB5086672が未適用であれば早めにインストールすることを推奨する。 背景 Windows 11では過去にも機能更新プログラムの適用失敗やロールバック繰り返しといった問題が報告されており、Microsoftは都度帯域外パッチで対応してきた実績がある。今回も同様のパターンであり、問題の根本原因や具体的な修正内容の詳細はMicrosoftの公式サポートページで確認できる。 最新のWindows環境を安定的に保つためにも、帯域外更新の情報を定期的にチェックする習慣をつけておきたい。 元記事: Windows 11 KB5086672 is out to fix broken feature update

MicrosoftとNVIDIAが原子力×AI協業——インフラのボトルネック解消へ Microsoftは、原子力エネルギー産業のデジタル変革を加速するため、NVIDIAとの戦略的協業「AI for Nuclear」を発表した。この取り組みは、業界が長年抱えてきたインフラのボトルネック——すなわち、原子力発電所の新設・刷新が「理想論」から「実行」へ移行できない構造的課題——の解消を狙ったものだ。 原子力産業が直面するボトルネック 原子力発電所の建設・運用にはきわめて複雑な許認可プロセスが伴う。各国の規制当局への申請書類は膨大で、審査期間も長期にわたる。加えて、次世代小型モジュール炉（SMR: Small Modular Reactor）をはじめとする新型炉の設計には高度なシミュレーション技術が必要であり、既存の計算インフラでは処理能力が不足しているケースも多い。 こうした課題に対して、MicrosoftとNVIDIAが提供するのは、Azure クラウドと NVIDIA の GPU コンピューティングを組み合わせたエンドツーエンドのAIツール群だ。 3つの主要領域でAIを活用 今回の協業では、主に以下の3領域でAIを適用する。 1. 許認可プロセスの効率化 規制申請に必要な膨大な文書作成・管理をAIが支援。過去の申請事例や規制要件を学習したモデルが、ドラフト生成やコンプライアンスチェックを自動化する。これにより、数年単位かかることもある許認可期間の大幅な短縮が期待される。 2. 設計・シミュレーションの加速 NVIDIA の高性能GPUを活用した物理シミュレーションにより、原子炉設計の反復サイクルを高速化する。熱流体解析や中性子輸送計算など、従来はスーパーコンピュータが必要だった処理をクラウド上で柔軟にスケールアウトできる。 3. 運用の最適化 稼働中のプラントでは、センサーデータや運転ログをリアルタイム解析するAIが、予知保全や異常検知を担う。設備の故障を事前に検知し、計画外停止を減らすことで、稼働率の向上とコスト削減を同時に実現する。 日本への示唆 日本においても、2011年の東京電力福島第一原発事故以降に停止した原発の再稼働審査や、次世代炉の導入議論が続いている。原子力規制委員会への許認可申請は世界でも屈指の複雑さを誇り、AIによる審査支援の需要は高い。MicrosoftのAzureはすでに国内データセンターを複数擁しており、今回のAI for Nuclearソリューションが国内電力会社にも展開される可能性がある。 Microsoftは近年、自社データセンターの電力需要増大を背景にスリーマイル島原発の電力購入契約を締結するなど、原子力への積極的な関与を見せている。AIとクラウドの普及が電力消費を押し上げる中、その電力源としての原子力と、原子力産業を支えるAI——という相互補完的な構図が鮮明になりつつある。 今後、具体的なツールの提供時期や対応する規制フレームワークの詳細については、MicrosoftおよびNVIDIAの追加発表が待たれる。 元記事: AI for nuclear energy: Powering an intelligent, resilient future

マイクロソフトは2026年3月の月例セキュリティ更新（Patch Tuesday）を公開し、Windowsおよび関連ソフトウェアの83件の脆弱性を修正した。今月は2件がパッチ公開前に既に悪用または公開が確認されたゼロデイ脆弱性として注目されている。 SQL Server と .NET に公開済み脆弱性 事前に公開されていた脆弱性のひとつ、CVE-2026-21262 は SQL Server 2016 以降に影響する特権昇格の欠陥だ。セキュリティ企業 Rapid7 のアダム・バーネット氏は「ネットワーク経由で sysadmin 権限への昇格が可能であり、CVSS v3 スコアは 8.8 と深刻度『重要』に迫る水準だ。先送りは難しい」と警告している。 もうひとつの CVE-2026-26127 は .NET アプリケーションに影響し、当面の影響はクラッシュ誘発によるサービス拒否（DoS）にとどまる見込みだが、サービス再起動中に別の攻撃手法が連鎖する可能性も否定できない。 プレビューペインを開くだけで危ない Office の RCE 脆弱性 毎月恒例となりつつある Microsoft Office の深刻な欠陥として、今月は CVE-2026-26113 と CVE-2026-26110 が浮上した。いずれもリモートコード実行（RCE）が可能であり、Outlook のプレビューペインで細工されたメッセージを表示するだけでトリガーされる点が特に危険だ。添付ファイルを開く操作すら不要なため、利用者は意図せず被害を受けるリスクがある。 特権昇格が今月の主役——「悪用の可能性が高い」6件を確認 セキュリティ企業 Tenable の分析によると、今月修正された CVE のうち約55%が特権昇格（EoP）バグだという。そのなかで「悪用の可能性が高い」と評価された主な脆弱性は以下の通り。 CVE-2026-24291（CVSS 7.8）: Windows アクセシビリティ インフラストラクチャの不適切な権限割り当てにより SYSTEM 権限へ昇格可能 CVE-2026-24294（CVSS 7.8）: SMB コアコンポーネントの認証不備 CVE-2026-24289（CVSS 7.8）: 高深刻度のメモリ破損＋競合状態（レースコンディション） CVE-2026-25187（CVSS 7.8）: Google Project Zero が発見した Winlogon プロセスの欠陥 歴史的マイルストーン：AIエージェントが発見した初のCVE 今月最も注目すべきトピックのひとつが CVE-2026-21536（CVSS 9.8）だ。Microsoft Devices Pricing Program コンポーネントに存在するこの重大な RCE 脆弱性は、完全自律型 AI ペネトレーションテストエージェント「XBOW」 によって発見された。ソースコードへのアクセスなしに CVSS 9.8 の脆弱性を特定した点が業界で話題を呼んでいる。XBOW は過去1年間、HackerOne のバグバウンティリーダーボードで上位を維持してきた実績を持つ。 ...

Microsoftがクロス署名ドライバープログラムへの信頼を廃止へ Microsoftは2026年4月のWindowsアップデートにおいて、旧来のクロス署名カーネルドライバープログラム（Cross-Signed Driver Program）への信頼を削除すると発表した。この変更により、今後はMicrosoftが認定するWindows Hardware Compatibility Program（WHCP）を通じて署名されたドライバーのみがデフォルトで読み込まれるようになる。 クロス署名ドライバーとは クロス署名ドライバーとは、MicrosoftのルートCA（認証局）ではなく、サードパーティの認証局によって署名されたカーネルモードドライバーを指す。過去にWindowsのドライバーエコシステムが拡大していく過程で広く利用されてきたが、その反面、マルウェアがドライバーに悪意あるコードを仕込んで署名を通過させる「ドライバー署名の悪用」が攻撃手法として確立されてしまった背景がある。 近年、ランサムウェアや高度な脅威アクター（APT）がカーネルレベルのドライバーを悪用するケースが増加しており、Microsoftはドライバーのセキュリティ強化を優先課題として取り組んできた。 段階的な適用で互換性への影響を監視 今回の変更は一度に完全適用されるわけではなく、まず評価モード（Evaluation Mode）として展開される。評価モードでは、クロス署名ドライバーが読み込まれた場合にイベントログへの記録や管理者への通知が行われるが、実際のブロックは行われない。これにより、企業やOEMが既存の環境への影響を把握し、対応を進める猶予期間が設けられる。 Microsoftは互換性への影響を監視しながら段階的に適用を進める方針で、最終的にはクロス署名ドライバーのデフォルト読み込みを完全に無効化する予定だ。 企業・開発者が取るべき対応 ハードウェアベンダーやドライバー開発者は、WHCPを通じた署名取得へ移行することが求められる。WHCPの認定プロセスはMicrosoftのHardware Dev Centerポータルから申請でき、Microsoftによる技術的なテストと審査を経て署名が付与される。 企業のIT管理者は、社内で使用しているサードパーティ製ハードウェアのドライバーがWHCP署名済みかどうかを確認し、未対応のベンダーに対してアップデートを要求する必要がある。特に、古いプリンターや特殊な計測機器、産業用デバイスのドライバーは対応が遅れる可能性があるため、早期の棚卸しが推奨される。 セキュリティ強化の流れの一環 この変更は、MicrosoftがWindows 11以降で推進しているSecured-core PCやVulnerable Driver Blocklist（脆弱ドライバーブロックリスト）の強化と同じ方向性を持つ。カーネルへのアクセスを厳しく制限することで、マルウェアがOSの深部に潜り込むことを根本から防ぐ設計思想だ。 Windowsのセキュリティ基盤を強化する上で重要なマイルストーンとなる今回の変更を前に、ハードウェアベンダーとIT担当者は早めの対応準備を進めておくべきだろう。 元記事: Advancing Windows driver security: Removing trust for the cross-signed driver program

Azure DevOps MCPサーバーがMicrosoft Foundryに登場 Microsoftは、Azure DevOps向けのMCP（Model Context Protocol）サーバーをMicrosoft Foundryで正式に提供開始したと発表した。これにより、AIエージェントがAzure DevOpsのパイプライン・作業項目（Work Items）・リポジトリを自然言語で直接操作できるようになる。 MCPとは何か MCP（Model Context Protocol）は、AIモデルと外部ツール・データソースを標準的なインターフェースで接続するためのオープンプロトコルだ。Anthropicが提唱し、近年急速に採用が広がっている。MCPサーバーを経由することで、AIエージェントはアプリケーションのAPIを直接知らなくても、自然言語の指示だけで外部システムを操作できるようになる。 何ができるようになるのか Azure DevOps MCPサーバーを使うことで、開発者やAIエージェントは以下のような操作を自然言語で実行できるようになる。 パイプラインの管理: ビルドやリリースパイプラインの状態確認、トリガー実行 作業項目の操作: バックログの確認・更新、スプリント計画の調整 リポジトリへのアクセス: コードの参照やプルリクエストの状況確認 たとえば「先週マージされたPRの一覧を見せて」「今日のビルドが失敗した原因を調べて」といった指示を、AIエージェントが直接Azure DevOpsに問い合わせて答えられるようになる。 リモートMCPサーバープレビューも同時提供 今回の発表と合わせて、リモートMCPサーバーのプレビューも提供が開始された。従来のMCP接続はローカル環境でのプロセス起動が前提だったが、リモートMCPサーバーにより、クラウド上でホストされたMCPサーバーへのHTTPS接続が可能になる。これにより、エンタープライズ環境での大規模なエージェント活用がより現実的になる。 エージェント駆動のDevOpsへ この動きは「DevOpsのエージェント化」というトレンドの加速を示している。GitHub CopilotやAzure AI Foundryとの連携により、コードの記述から本番デプロイまでの一連のフローをAIエージェントが補佐・自動化する未来が近づいている。 日本でもAzure DevOpsを活用している企業は多く、CI/CDパイプラインや作業管理にAIエージェントを組み込む需要は高い。Microsoft Foundryのエコシステムを通じて、こうした機能が標準的に利用できるようになることは、DevOpsチームの生産性向上に大きく貢献するだろう。 利用開始方法 Azure DevOps MCPサーバーはMicrosoft Foundry経由で利用可能。Azure DevOpsのサービス接続とMicrosoft Foundryプロジェクトを組み合わせることで、既存のDevOps環境にAIエージェントを統合できる。 元記事: Azure DevOps MCP Server Now Available in Microsoft Foundry

Azure App Service証明書、業界標準変更で発行方式が刷新へ Microsoftは、CA/Browser Forum（CA/B Forum）が策定する業界全体の証明書基準変更に伴い、Azure App ServiceのマネージドTLS証明書に関する重要なアップデートを発表した。この変更は2026年内に適用が予定されており、Azureでウェブアプリを運用する開発者・運用担当者は内容を把握しておく必要がある。 何が変わるのか 影響を受けるのは以下の2種類の証明書だ。 無料マネージドTLS証明書（DigiCert発行） 有償App Service証明書（GoDaddy発行） CA/B Forumは、TLS証明書の最大有効期間を段階的に短縮する方向で議論を進めており、将来的には最大47日まで短縮される見通しだ（現行は最大397日）。これはフィッシングや証明書の不正利用リスクを低減するための業界全体の取り組みであり、Google、Apple、Mozillaなど主要ブラウザベンダーが推進している。 AzureのApp Service証明書においても、この基準変更に合わせて証明書の発行方式・有効期間・更新サイクルが変更される。具体的な新しい有効期間や移行タイムラインは順次公式ドキュメントに反映される予定だ。 自動更新ユーザーへの影響は最小限 Microsoftによれば、証明書の自動更新（Auto-renewal）を有効にしているユーザーは、Azureが更新処理を自動的に行うため影響を受けにくい。App Serviceのマネージド証明書はデフォルトで自動更新が設定されているケースが多く、該当ユーザーはAzureポータルで設定状況を確認するだけで済む場合がほとんどだ。 手動管理ユーザーは対応が必要 一方、以下のケースに該当する場合は能動的な対応が求められる。 有償App Service証明書を手動で更新・管理している場合 — 有効期間の変更に伴い、更新作業の頻度が増加する 証明書をKey Vaultと連携させている場合 — Key Vaultのシークレットローテーション設定も見直しが必要になる可能性がある 外部システムが証明書の有効期間に依存している場合 — 証明書の短縮に対応できるよう監視・アラート設定を更新する 日本の運用担当者へのポイント 日本では金融・医療・公共系のシステムでApp Serviceを活用するケースも増えており、証明書の有効期限切れによるサービス停止は深刻なインシデントにつながりかねない。今回の変更を機に、証明書管理の自動化状況を棚卸しし、手動フローが残っていれば自動化への移行を検討したい。 Azureポータルの「App Service証明書」ブレードでは、各証明書の自動更新ステータスを一覧で確認できる。まずは自動更新が有効かどうかを確認することが最初のアクションだ。 詳細はMicrosoftの公式ブログ「Apps on Azure Blog」で継続的に更新される予定となっている。 元記事: Industry-Wide Certificate Changes Impacting Azure App Service Certificates

Claude CodeのソースコードがNPMマップファイル経由で流出 Anthropicが開発するAIコーディングアシスタント「Claude Code」のソースコードが、NPMレジストリに含まれるJavaScriptソースマップ（.mapファイル）を通じて誰でも閲覧可能な状態になっていたことが明らかになった。 ソースマップとは何か JavaScriptのビルドプロセスでは通常、本番配布用にコードを難読化・圧縮（ミニファイ）する。しかしデバッグを容易にするため、圧縮前の元ソースと圧縮後コードの対応関係を記録した「ソースマップファイル（.map）」を生成することがある。このファイルをNPMパッケージに誤って同梱してしまった場合、事実上の「ソースコード公開」に等しい状態になる。 Claude CodeはNPMパッケージとして配布されており、今回はまさにこの落とし穴にはまった格好だ。 流出から判明した内部実装の詳細 Hacker Newsで866件以上のコメントを集めた関連スレッド「The Claude Code Source Leak: fake tools, frustration regexes, undercover mode」では、流出したソースコードを解析した結果として複数の興味深い実装が報告されている。 フェイクツール（Fake tools） Claude Codeが実際には存在しないか、あるいは期待通りに動作しないツールを「あるかのように」提示している実装が含まれていたとされる。これはユーザー体験の調整やフォールバック処理の一環とみられるが、透明性の観点から議論を呼んでいる。 フラストレーション正規表現（Frustration regexes） ユーザーが苛立ちや怒りを示すようなメッセージを送った場合に検出するための正規表現が含まれていたという。ユーザーの感情状態を把握してレスポンスを調整する仕組みとみられ、「AIが人間の感情を監視している」という点でプライバシー面での懸念も指摘されている。 潜伏モード（Undercover mode） Claude Codeが自身のアイデンティティを隠す、もしくはAIであることを明かさない動作モードの実装が確認されたとの報告もある。ベンチマーク評価時の挙動調整など、複数の用途が推測されているが、詳細はまだ調査中だ。 Anthropicへの影響と業界の反応 Hacker NewsやX（旧Twitter）ではこの流出が急速に拡散し、元ツイートは多数のエンゲージメントを獲得。AI企業の「ブラックボックス」に対する透明性への関心の高さを改めて示した。 AnthropicはClaudeシリーズをクローズドモデルとして提供しており、内部実装の詳細は非公開が原則だ。今回の流出は意図的な情報公開ではなく、ビルド・パッケージングプロセスにおけるミスとみられる。 日本では多くの開発者がClaude Codeを業務に活用しており、今回明らかになった内部実装の詳細——特にフラストレーション検出や潜伏モード——については、利用方針やプライバシーポリシーの観点から改めて精査する価値があるだろう。 教訓：NPMパッケージのソースマップ管理 この事例は、商用ソフトウェアをNPMで配布する際のセキュリティ管理の重要性を改めて示している。.mapファイルの同梱有無は.npmignoreやpackage.jsonのfilesフィールドで制御できるため、クローズドソースのツールを配布する開発者は自社パッケージの設定を今一度確認することを推奨する。 Anthropicからの公式声明は現時点では出ていない。 元記事: Claude Code’s source code has been leaked via a map file in their NPM registry

Claude Codeのソースコードが流出——偽ツール注入・感情検知・未公開エージェントモード「KAIROS」とは Anthropicが開発するAIコーディングアシスタント「Claude Code」のソースコードが、NPMパッケージへのソースマップ（.mapファイル）の誤同梱によって流出した。パッケージはすぐに取り下げられたが、コードはすでに広くミラーリングされ、Hacker News上でも大きな話題となっている。 Anthropicにとってこれは1週間で2度目の情報漏洩事故だ（直前にはモデル仕様書のリークもあった）。また、ちょうど10日前にはOpenCodeに対して法的措置を取り、サードパーティによるClaude Codeの内部API悪用を問題視していたばかりとあり、今回の流出内容がより注目を集めている。 偽ツール注入による「反蒸留（Anti-distillation）」機構 最も注目を集めた発見が、claude.ts（301〜313行目）に存在するANTI_DISTILLATION_CCフラグだ。これが有効な場合、Claude CodeはAPIリクエストにanti_distillation: ['fake_tools']を含め、サーバー側がシステムプロンプトに「偽のツール定義」を静かに注入する。 目的は明快だ——Claude CodeのAPIトラフィックを傍受して競合モデルの学習に使おうとする行為を妨害するため、意図的に汚染データを混入させる。この機能はGrowthBook社のフィーチャーフラグ（tengu_anti_distill_fake_tool_injection）でゲートされており、ファーストパーティCLIセッションのみに適用される。 もっとも、研究者が指摘するように回避策は単純で、MITMプロキシでanti_distillationフィールドをリクエストボディから除去するか、環境変数CLAUDE_CODE_DISABLE_EXPERIMENTAL_BETASを設定するだけで無効化できる。実質的な保護はむしろ法的手段に依存しているとみられる。 「アンダーカバーモード」——AIがAIであることを隠す ソースには、AIであることを開示せずに動作するモードの存在も確認された。特定の条件下でClaude CodeがAIアシスタントとしての素性を表に出さずに応答するこの機能は、エンタープライズ向けの特定ユースケースを想定したものとみられる。 正規表現によるユーザーの感情（フラストレーション）検知 驚くべきことに、ユーザーのフラストレーション検知にLLMではなく正規表現が使われていることも判明した。「damn」「wtf」「not working」といったパターンにマッチした場合に、システムが何らかの応答を調整する仕組みだ。シンプルながら軽量で実用的な設計判断と言えるが、AIツールの感情認識がこのような古典的手法で実装されていることには多くの開発者が驚きを示している。 1日25万件の「無駄なAPIコール」 パフォーマンス面でも気になる数字が出てきた。設計上の問題とみられる不要なAPIコールが1日あたり約25万件発生しているという。コスト面やレイテンシへの影響が懸念される。 未公開の自律エージェントモード「KAIROS」 おそらく最も衝撃的な発見が、KAIROSと呼ばれる未リリースの自律エージェントモードだ。詳細は限られているが、現在の対話型モードを超えた、より高度な自律実行能力を持つモードとして開発が進んでいるとみられる。Anthropicが近い将来にエージェント機能を大幅に強化する計画を持っていることを示唆しており、業界関係者の注目を集めている。 まとめ 今回の流出は、Anthropicにとって技術的・法的・広報的な打撃となった。一方で、現代の商用AIツールがどのような工夫と妥協のもとで構築されているかを垣間見る、稀な機会にもなっている。日本国内でもClaude Codeの利用者は増加しており、これらの実装が今後の開発判断や競合製品の設計にどう影響するか、引き続き注目が集まりそうだ。 元記事: The Claude Code Source Leak: fake tools, frustration regexes, undercover mode

Claude Codeの2つのキャッシュバグ、APIコストを最大20倍に膨張させる恐れ AnthropicのAIコーディングアシスタント「Claude Code」に、プロンプトキャッシュを無効化し、APIコストを静かに10〜20倍に膨らませる可能性のある2つの独立したバグが報告された。Redditユーザーがスタンドアロンバイナリをリバースエンジニアリングした結果、発見したものだ。 バグ1：スタンドアロンバイナリのセンチネル置換によるキャッシュ破壊 Claude Codeのスタンドアロンバイナリ（claude.ai/install.sh や npm install -g で取得するもの）には、AnthropicがカスタマイズしたBunフォークにネイティブ層の文字列置換処理が組み込まれている。この処理は、ZigのHTTPヘッダービルダー関数に注入されており、APIリクエストのJSONボディ内に含まれる課金帰属センチネル（cch=a9ffd）を特定し、ボディのハッシュ値から導出した5文字の16進数で置換する。 問題となるのは、この置換がJSONボディ内の最初の出現箇所を対象とする点だ。シリアライズされたJSONでは messages[] が system[] より先に来るため、会話履歴にセンチネル文字列が含まれている場合（例：Claude Codeのソースコードについて話し合っている、CLAUDE.md にセンチネルが含まれているなど）、system[0] ではなく messages[] 内のセンチネルが置換されてしまう。これによりリクエストごとにメッセージの内容が変化し、キャッシュのプレフィックスが壊れ、毎回フルキャッシュの再構築が発生する。コンテキストサイズに応じて、1リクエストあたり約0.04〜0.15ドルの追加コストが生じる計算だ。 回避策： スタンドアロンバイナリの代わりに npx @anthropic-ai/claude-code で実行することで問題を回避できる。置換処理はカスタムBunフォークにのみ存在し、標準的なNode/Bun上で動くnpmパッケージには含まれていないことが実験的に確認されている。 バグ2：--resume オプションが常にキャッシュミスを引き起こす（v2.1.69以降） もう1つのバグは、セッション再開を行う --resume オプションに関するものだ。v2.1.69で導入された deferred_tools_delta（ToolSearch経由で利用可能なツールを列挙するシステムリマインダー）の実装の違いにより、再開時に毎回会話履歴全体のキャッシュミスが発生する。 新規セッションでは約13KBのリマインダー群が messages[0] に注入されるのに対し、再開時には messages[0] に約352Bのコンテキストのみが含まれ、リマインダー群は末尾（messages[N]）に追加される。この構造の違いにより、キャッシュプレフィックスの不一致、課金ハッシュの変化、cache_control ブレークポイントの位置ズレという3つの独立した要因でキャッシュが破壊される。再開後の2ターン目以降は正常にキャッシュが機能するため、被害は最初のリクエストに限られるが、コンテキストが大きい場合のコストインパクトは無視できない。 このバグはv2.1.68には存在せず、deferred_tools_delta の導入と同時に発生した。現時点で外部から適用できる回避策はない。 日本のユーザーへの影響 Claude Codeは日本でも多くの開発者が利用しており、特にAPIコスト管理を重視するチームや個人開発者にとって見過ごせない問題だ。Anthropicの公式対応を待ちながら、スタンドアロンバイナリを使用している場合は npx 経由への切り替えを検討したい。--resume については正式な修正リリースを待つしかない状況だが、バグ報告のIssue（#40524、#34629）は既に公開されており、Anthropic側も認識していると見られる。 元記事: Claude Code bug can silently 10-20x API costs

Claude Codeで利用制限の枯渇が急増——Anthropicが調査中と公表 AnthropicのAIコーディングアシスタント「Claude Code」において、トークン消費が異常に速く使用量上限（クォータ）に到達してしまうという問題が多発しており、開発者から大きな不満の声が上がっている。 Anthropicはこの問題を公式に認め、「Claude Codeの利用制限に想定より遥かに速く到達するケースが報告されている。現在チームのトッププライオリティとして調査中だ」と声明を発表した。 「30日中12日しか使えない」——ユーザーから怒りの声 Discordの公式フォーラムでは、年間200ドル（約3万円）のClaude Proプランを契約するあるユーザーが「毎週月曜日には上限に達し、土曜日にリセットされるの繰り返し。1ヶ月30日のうち12日しかまともに使えていない」と訴えている。 RedditのAnthropicフォーラムにも批判が集中しており、「Max 5プラン（月額100ドル）を1時間で使い果たした。以前は8時間使えていたのに」といった報告が相次ぐ。 問題の原因として浮上する3つの要因 今回の問題には複数の要因が重なっている可能性がある。 1. ピーク時間帯のクォータ削減 先週、Anthropicはピークタイムにおけるクォータを削減すると発表した。エンジニアのThariq Shihipar氏によれば、約7%のユーザーに影響するという。 2. 倍増プロモーションの終了 3月28日をもって、ピーク外の6時間帯に利用制限を2倍にするプロモーションが終了。これにより体感上の使用量が大幅に低下したとみられる。 3. プロンプトキャッシュのバグ Claude Codeのバイナリをリバースエンジニアリングしたユーザーが「プロンプトキャッシュを無効化する独立した2つのバグを発見した。これによりコストが10〜20倍に膨れ上がっている」と主張している。旧バージョン（2.1.34）へのダウングレードで改善したという報告も複数寄せられており、バグの存在を裏付けている。 プロンプトキャッシュの仕様も落とし穴に Claude Codeのプロンプトキャッシュは、繰り返し処理や共通要素を含むプロンプトの処理コストを大幅に削減できる機能だ。しかしキャッシュの有効期限はデフォルトでわずか5分。少し作業を中断しただけでキャッシュが無効になり、再開時にコストが跳ね上がる。 1時間のキャッシュ延長オプションも存在するが、その場合「キャッシュ書き込みトークンは通常の入力トークンの2倍」の料金がかかる。読み込みは0.1倍と安いため、使い方によってコスト最適化の余地が大きく異なる。 自動ワークフローへの深刻な影響 特に問題視されているのは、自動化パイプラインへの影響だ。あるユーザーはこう警告する。「Claude Codeを自動ワークフローで使っているなら、レート制限エラーを明示的にキャッチする必要がある。一般的なエラーに見えるため、気づかずにリトライし続け、ループ1セッションで日次予算を数分で使い果たすことになる」。 なお、AnthropicはProプランの利用量について「無料プランの5倍以上」、Standard Teamプランは「Proの1.25倍」という曖昧な表記にとどめており、開発者が実際の上限を把握しにくい状況も批判を招いている。 業界全体の課題：AIツールの価格モデルへの不満 こうした問題はAnthropicだけではない。今月初めにはGoogle Antigravityのユーザーからも同様の不満が報告されている。AI開発ツールの「使い倒したいユーザー」と「収益を確保したいプロバイダー」の間の暗黙の交渉が続いている状況だ。 AIを全プロセスに組み込むよう促すベンダーのマーケティングと、実際には突然応答が止まることもあるクォータ制限との間の矛盾——この課題は、AIコーディングツールが本格的に業務インフラ化するうえで、避けては通れない問題となりつつある。 元記事: Claude Code users hitting usage limits ‘way faster than expected’

MicrosoftがWSLを2026年に大幅強化——開発者向け環境の本気アップデート Microsoftは2026年、Windows Subsystem for Linux（WSL）に大規模な改善を加えることを明らかにした。LinuxとWindows間のファイル転送高速化、ネットワーク性能の強化、初期セットアップの簡略化、そしてエンタープライズ向けのセキュリティ・ポリシー管理機能の充実が予定されている。 なぜ今WSLの強化なのか WSLは、Windowsの中でLinuxディストリビューションをネイティブに近い形で実行できる仕組みだ。デュアルブートや仮想マシンが不要で、軽量な仮想化レイヤーを通じてLinux環境を利用できる。WSL2では実際のLinuxカーネルが動作しており、bash・ssh・git・Docker・Node.js・Pythonといった開発ツールをそのまま使えるのが強みだ。 Webアプリ開発者がローカルサーバーを立ち上げたり、DevOpsエンジニアがコンテナやオーケストレーションツールを扱ったりと、WSLは現代の開発ワークフローに深く組み込まれている。Docker Desktop for WindowsもWSL2に強く依存しており、Visual Studio CodeもWSL環境への直接接続をサポートしている。 一方で、macOSはUnixベースの環境をデフォルトで持ち、ネイティブLinux環境はそのまま使える。Windowsが開発者のシェアを争うにあたって、WSLの品質向上は不可欠な施策だ。 具体的な改善ポイント ファイルアクセスの高速化は最大の目玉だ。現状のWSLでは、Windowsファイルシステム（/mnt/c/ 以下のパス）へのアクセスが遅く、大量ファイルを扱うビルドや依存パッケージのインストールでボトルネックになることがある。この課題に直接メスを入れる。 ネットワーク性能の強化も開発者には嬉しい変更だ。WSL内からのHTTP通信やコンテナ間ネットワーキングの安定性・速度が改善されることで、バックエンド開発やマイクロサービス構成を組む際の体験が向上する。 セットアップの簡略化により、新しいWindowsマシンにWSLを導入するまでのハードルが下がる。企業導入においても、ポリシー管理やセキュリティ制御の強化が予定されており、IT管理者が組織全体でWSLを安全に展開しやすくなる。 開発プラットフォームとしてのWindowsの再評価 WSLが登場した背景には、Linuxに精通した開発者をWindowsエコシステムに引き留めるというMicrosoftの戦略があった。初代WSL1は互換性に問題が多かったが、WSL2でLinuxカーネルを直接動かす方式に転換し、実用性が大きく向上した。 2025年のBuildカンファレンスでSatya Nadella CEOがWSLのオープンソース化を発表するなど、Microsoftはこの分野への本気度を示し続けている。 日本でもクラウドネイティブ開発やコンテナ活用が当たり前になる中、開発PCの選定においてWindowsとmacOSの比較は常に議論になる。今回のWSL強化が実際に体感できるレベルで届けば、Windows PCを選ぶ開発者にとって大きな後押しになりそうだ。詳細は2026年中の公式発表を待ちたい。 元記事: Microsoft to upgrade Windows Subsystem for Linux (WSL) with faster file access, better networking and easier setup

Axios npmパッケージが供給チェーン攻撃の標的に JavaScriptアプリケーション開発で広く使われているHTTPクライアントライブラリ「Axios」のnpmパッケージが、2026年3月31日に悪意ある第三者によって侵害された。セキュリティ企業のEndor Labs、Socket、Aikido、StepSecurityの調査によると、攻撃者は悪意のあるバージョンを2つ公開し、Linux・Windows・macOSの全プラットフォームを対象にリモートアクセス型トロイの木馬（RAT）を配布した。 Axiosは月間約4億ダウンロードを誇る人気ライブラリであり、今回の侵害による影響範囲は極めて広い可能性がある。 攻撃の手口 攻撃者はAxiosのメインメンテナーであるJason Saayman氏のnpmアカウントを乗っ取り、悪意のあるバージョンaxios@1.14.1とaxios@0.30.4を公開した。さらにSaayman氏のGitHubアカウントも掌握し、関連メールアドレスをifstap@proton.meに変更。侵害に関する報告スレッドを削除するなど、発覚を遅らせる工作も行った。 注目すべき点として、これら悪意のあるバージョンはOpenID Connect（OIDC）によるパッケージ起源の自動検証が行われておらず、対応するGitHubコミットも存在しなかった。こうした兆候は本来、直ちに警戒を促すべきシグナルである。 感染チェーンの詳細 攻撃者はAxiosのコード自体には手を加えず、package.jsonに悪意のある依存パッケージplain-crypto-js@^4.2.1を追加した。このパッケージはインストール時にポストインストールスクリプトを実行し、難読化されたドロッパー（setup.js）を起動。ドロッパーはC2サーバーへ接続し、検出されたOSに応じたペイロードを取得する。 Windows: VBScriptとPowerShellを組み合わせて非表示のコマンドプロンプトを起動。%PROGRAMDATA%\wt.exeにPowerShellをコピーして検出を回避し、再起動後も持続するよう設計されている macOS: AppleScriptを使って/Library/Caches/com.apple.act.mondにバイナリをダウンロードし、バックグラウンドで実行 Linux: Pythonベースのペイロードを/tmp/ld.pyに保存し、nohupコマンドでバックグラウンド実行 いずれのケースでもRATに感染し、攻撃者によるリモートコマンド実行・シェルコマンドの送受信・ディレクトリ列挙が可能な状態となる。感染完了後、ドロッパーは自身を削除し改ざんされたpackage.jsonをクリーンな状態に戻すことでフォレンジック調査を困難にする。 北朝鮮系APTグループによる計画的攻撃 StepSecurityの調査では、悪意のある依存パッケージが公開の18時間前に事前ステージングされており、今回の攻撃が「計画的」なものであることを示している。 Googleの脅威インテリジェンスグループ（GTIG）のチーフアナリストJohn Hultquist氏はBleepingComputerに対し、本攻撃の背後には北朝鮮系の脅威アクター「UNC1069」がいると語った。このグループはソフトウェアサプライチェーンおよび暗号資産関連の標的を狙うことで知られている。 開発者への推奨対応 Axiosを利用しているプロジェクトは、package-lock.jsonやyarn.lockなどのロックファイルを確認し、axios@1.14.1またはaxios@0.30.4が含まれていないか至急チェックすることが強く推奨される。該当するバージョンをインストールした可能性がある場合は、システムの侵害有無を確認し、最新の安全なバージョンへ即座に更新する必要がある。 今回の事件は、オープンソースのサプライチェーンセキュリティの脆弱性を改めて浮き彫りにした。npmのような大規模パッケージレジストリにおけるアカウント保護とパッケージ検証の重要性が、かつてないほど高まっている。 元記事: Hackers compromise Axios npm package to drop cross-platform malware

Trivy連鎖攻撃がCiscoを直撃——AIプロダクトのソースコードが流出 米Ciscoがサイバー攻撃の被害を受け、内部の開発環境が侵害されたことをBleepingComputerが報じた。攻撃者は2026年3月に発覚したTrivyサプライチェーン攻撃で盗んだ認証情報を転用し、Ciscoのビルド・開発環境への侵入を果たした。 何が起きたのか Ciscoの「Unified Intelligence Center」「CSIRT」「EOC」各チームが侵害を封じ込めたものの、攻撃者はその前に以下を実行したとされる。 300以上のGitHubリポジトリを複製（AI Assistant、AI Defense、未発表プロダクトのソースコードを含む） 複数のAWSキーを窃取し、一部のCisco AWSアカウントで不正操作を実施 数十台のデバイス（開発者ワークステーション・ラボ端末）のデータを取得 さらに、複製されたリポジトリの一部には銀行、BPO（業務プロセスアウトソーシング）、米政府機関など顧客のソースコードが含まれている可能性があるという。 Trivyサプライチェーン攻撃とは Trivyはコンテナイメージや構成ファイルの脆弱性を検出するOSSスキャナーで、開発現場での採用が広い。今月初め、脅威アクターがTrivyのGitHubパイプラインを侵害し、公式リリースおよびGitHub Actionsを通じて認証情報窃取型マルウェアを配布した。 Ciscoはこの不正なGitHub Actionプラグインを踏んでしまい、CI/CD環境の認証情報が流出したとみられる。 背後に「TeamPCP」グループ セキュリティ研究者は今回の一連の攻撃を、TeamPCPと呼ばれる脅威グループに帰属している。同グループは独自のインフォスティーラー「TeamPCP Cloud Stealer」を用いており、GitHub・PyPI・npm・Dockerを標的にしたサプライチェーン攻撃を繰り返している。 Cisco侵害と並行して、LiteLLM（PyPIパッケージ）およびCheckmarx KICSプロジェクトも同じマルウェアで侵害されており、合計で数万台規模のデバイスに影響が及んでいる。 Ciscoの対応 Ciscoは影響を受けたシステムを隔離し、再イメージングを開始。大規模な認証情報のローテーションを実施中だという。ただし、BleepingComputerの取材に対してCiscoからの公式回答はまだ得られていない。 日本のエンジニアへの示唆 Trivyは国内でも広くCI/CDパイプラインに組み込まれているツールだ。今回の攻撃はOSSツールのGitHub Actionsやパイプラインが攻撃経路になり得ることを改めて示した。 利用中のGitHub Actionsのバージョンとハッシュを固定しているか確認する CI/CD環境で使う認証情報（AWS、GitHub Token等）のスコープを最小権限に絞る 依存パッケージの更新時にはリリースノートと変更差分を必ずチェックする サプライチェーン攻撃は「信頼しているツール」を踏み台にする点で被害が広域に及ぶ。OSS利用時のセキュリティ検証プロセスを今一度見直すべき時期だ。 元記事: Cisco source code stolen in Trivy-linked dev environment breach

GitHub CopilotのPR広告問題、Microsoftが「バグだった」と釈明 Microsoftが提供するAIコーディングアシスタント「GitHub Copilot」が、プルリクエスト（PR）のレビュー画面に宣伝的なメッセージを表示し始めたことが判明。これを発見した開発者たちがSNSや各種フォーラムで強い不満を表明し、Microsoftは事態を沈静化するべく即座に対応を迫られた。 何が起きたのか 問題となったのは、CopilotがPRのサマリーや提案欄に、有料プランや追加機能を促すようなプロモーション文言を埋め込んでいたこと。多くの開発者は、コードレビューという業務上の重要なフローに広告が混入することに強い抵抗感を示した。「開発ツールの中でまで広告を見せられるのか」という声がX（旧Twitter）やHacker Newsなどに相次いで投稿された。 開発者コミュニティには、GitHubが企業向けの有料ツールとして長年信頼を培ってきた背景がある。そのため、今回のような「ツールが自分自身を宣伝する」という行為は、ユーザーとの信頼関係を損なうものとして批判が集中した。 Microsoftの説明と対応 Microsoftはこの騒動を受けて公式に声明を発表。「意図的な機能追加ではなく、プログラミングロジックの不具合（programming logic issue）によって意図しない動作が発生した」と説明し、謝罪した。 同社は問題の修正を迅速に展開し、宣伝的なメッセージの表示は停止された。ただし、「バグ」という説明に対しては、開発者コミュニティから懐疑的な見方も出ている。意図せずして広告のような表示が実装されるほど複雑なロジックが組まれているとは考えにくいとの指摘もある。 開発ツールへの広告混入という懸念 今回の件は、AI開発ツールのマネタイズ戦略に関する根本的な議論を呼び起こした。GitHub CopilotはMicrosoftの収益源として重要な位置を占めており、フリープランの制限拡大や有料プランへの誘導は今後も続く可能性がある。 日本国内でもGitHub Copilotの導入企業は増加しており、今回のような「開発フローへの割り込み」はエンジニアの生産性や心理的安全性に影響を与えかねない。今後、同様の問題が再発した場合にMicrosoftがどう対応するかが注目されている。 MicrosoftとGitHubに対する開発者コミュニティの信頼を維持するためには、透明性の高い説明と再発防止策の明示が求められるだろう。 元記事: GitHub Copilot ads in PRs were due to a “programming logic issue”, claims Microsoft