セキュリティ・AI・テクノロジー 週次ニュースまとめ（2026年7月13日）

はじめに

2026年7月第2週は、開発者が日常的に使うツールそのものを狙う攻撃が相次いで報告されました。npm パッケージへの汚染、AI コードレビューへのプロンプトインジェクション、エンタープライズ向けファイル共有製品の重大脆弱性と、「安全なはずの作業環境」を揺さぶるニュースが重なった週でした。今週の3つの注目ポイントは以下のとおりです。

• jscrambler npm パッケージ 8.14.0 の汚染：サプライチェーン攻撃によりインフォスティーラーが仕込まれ、npm install 実行時点でマルウェアが走る状態に
• Ghostcommit によるプロンプトインジェクション：PNG 画像に隠した命令で AI コードレビューツールを騙し、リポジトリ内の秘密情報を窃取できることが実証
• Progress ShareFile の緊急シャットダウン指示：Storage Zone Controller の重大脆弱性を受け、ベンダーが顧客に対してシステムの即時停止を要請する異例の対応

今週の注目ニュース3選

npmパッケージ「jscrambler」に悪意のあるコードが混入、インストールするだけで情報窃取マルウェアが実行される（原題: Compromised jscrambler 8.14.0 npm Release Drops Rust Infostealer During Install）

概要 2026年7月11日、JavaScriptの難読化ツールとして広く利用されているnpmパッケージ「jscrambler」のバージョン8.14.0が攻撃者によって改ざんされ、悪意のあるコードが混入した状態で公開されました。この版にはpreinstallフックが仕込まれており、npm installを実行するだけでWindows・macOS・Linux向けにそれぞれビルドされたネイティブバイナリが自動的にドロップ・実行されます。このバイナリはRust製のInfostealer（情報窃取マルウェア）であり、開発者が意図せず自分のマシン上でマルウェアを走らせる状態に陥ります。

注目ポイント セキュリティ企業のSocketは、この悪意あるバージョンが公開されてからわずか6分後に検出・フラグを立てています。この速さ自体は評価できますが、npm registryでは公開から削除までの間に不特定多数のユーザーがnpm installを実行し得るため、6分間の露出でも実害が発生するリスクがあります。また、preinstallフックを悪用する手口はサプライチェーン攻撃の典型パターンですが、今回は正規の人気パッケージそのものが侵害された点が深刻です。開発ツールへの信頼を利用して検出を回避しやすく、CI/CDパイプラインに組み込まれている場合はサーバー環境にまで被害が及びます。

押さえておきたい理由 jscrambler はフロントエンド開発で利用頻度の高いパッケージです。該当バージョン（8.14.0）をnpm installした開発者は、自身の端末上でマルウェアがすでに実行済みである可能性を前提に対応する必要があります。具体的には、①該当バージョンのインストール履歴をpackage-lock.jsonおよびnpm lsで確認する、②感染端末の認証情報・APIキー・SSHキーを直ちにローテーションする、③CI/CDパイプラインで使用している場合はビルド環境全体のシークレットを無効化する、という手順が求められます。また、組織としての対策として、npm auditや依存関係スキャン（Socket・Snykなど）をパイプラインに組み込み、preinstall/postinstallスクリプトを自動的に検査する仕組みを整えることが、今後同種の攻撃への有効な防御になります。

参照 The Hacker News

AIコードレビューツールを騙して機密情報を盗み出す攻撃手法「Ghostcommit」が実証される（原題: ‘Ghostcommit’ hides prompt injection in images to fool AI agents, steal secrets）

概要 セキュリティ研究者がPNGファイルにプロンプトインジェクション命令を埋め込み、AIコーディングエージェントに.envファイルの機密情報を読み取らせてコードに書き出させる攻撃手法「Ghostcommit」を実証しました。この手法は、AIコードレビューツールであるCodeRabbitとBugbotによるレビューをすり抜けました。これら2つのツールが画像ファイルの内容を解析しないという仕様上の盲点を突いた攻撃です。

注目ポイント この攻撃の核心は、「AIがレビューしない領域」を悪用している点にあります。CodeRabbitやBugbotといったAIコードレビューツールは画像ファイルを開かないため、PNG内に隠された命令を検出できません。一方、コーディングエージェントはその画像を処理できるため、悪意ある命令だけを実行してしまいます。つまり、「検出するAI」と「実行するAI」の能力差そのものが攻撃経路になっています。AIセキュリティツールの守備範囲に穴がある限り、ツールを信頼すること自体がリスクになります。

押さえておきたい理由 AIコードレビューを「承認ゲート」として運用しているチームは、レビュー済み＝安全という前提を今すぐ見直す必要があります。具体的には、①画像ファイルを含むPRに対してAIエージェントが自律的にコード変更を行うワークフローを制限すること、②.envなどの機密ファイルへのアクセスをエージェントの実行権限から外すこと、③AIレビューツールが「何を見ていないか」をあらかじめ把握した上でレビュープロセスを設計することが求められます。AIを開発フローに組み込む速度が上がるほど、こうした「AIの死角」を突いた攻撃の被害範囲も広がります。

参照 Bleeping Computer

Progress SoftwareがShareFile顧客にStorage Zone Controllerの即時停止を要請（原題: URGENT - Progress Tells ShareFile Customers to Shut Down Storage Zone Controllers Over Security Threat）

概要 Progress Softwareは、ShareFileのオンプレミス構成要素であるStorage Zone Controller（Windows Server上で動作）を利用している顧客に対し、サーバーの即時シャットダウンを要請しました。同社はThe Hacker Newsに対し、「信頼性の高い外部からのセキュリティ脅威」に対応中であることを認めています。Progress Softwareは対象アカウントへのアクセスを一時的に無効化しており、社内外のセキュリティチームと連携して調査を進めています。

注目ポイント 通常、ベンダーがセキュリティ対応としてとる手順は「パッチの適用」や「設定変更の推奨」です。今回Progress Softwareがサーバーの完全停止とアカウントアクセスの無効化という踏み込んだ措置をとったことは、脆弱性の深刻度が高く、かつ既に悪用が試みられているか、その可能性が極めて高いと同社が判断していることを示しています。「credible external security threat（信頼性の高い外部の脅威）」という表現は、脆弱性の理論的なリスクではなく、具体的な攻撃の兆候を把握していることを示唆する言い回しです。Progress Softwareは過去にMOVEitの脆弱性（CVE-2023-34362）がCl0pランサムウェアグループに悪用された実績があり、同社製品は標的になりやすい傾向があります。

押さえておきたい理由 ShareFileのStorage Zone Controllerをオンプレミスで運用している場合、現時点でサーバーが稼働していれば攻撃対象になり得ます。Progress Softwareの公式指示に従い、対象サーバーを即時停止することが最優先の対応です。また、サーバーが稼働していた期間中のログを保全し、不審なアクセスや外部通信がなかったかを確認する必要があります。MOVEitの事例では、パッチ適用前にデータが窃取されていたケースが多数確認されており、「停止＝安全」ではなく、侵害済みである前提での調査が不可欠です。社内にShareFileを導入している場合は、ベンダーからの続報を継続的に確認してください。

参照 The Hacker News

カテゴリ別まとめ

セキュリティ

Androidマルウェア「RedHook」がワイヤレスADBを悪用してPCなしでシェル権限を取得（原題: RedHook Android malware now uses Wireless ADB for shell access）

概要 Androidマルウェア「RedHook」の新バージョンが、Android標準のワイヤレスデバッグ機能（Wireless ADB）を悪用する手法を採用し、PCとの有線接続なしにシェルレベルの権限を取得できるようになりました。これまでADB経由の攻撃はUSB接続や開発者向け設定の手動有効化が前提でしたが、RedHookはこの制約を回避する新たな経路を確立しています。

実務的な示唆 この手法の最大の危険点は、攻撃の物理的障壁がほぼ消滅したことにあります。従来のADB悪用型攻撃は「PCを被害端末に接続する」という物理的操作が必要でしたが、ワイヤレスADBを経由することで同一Wi-Fiネットワーク上からリモートでシェル操作が可能になります。これは、社内Wi-Fiに接続した業務用Androidデバイスが、ネットワーク内の別の感染端末や攻撃者から横断的に狙われるリスクを意味します。

現場での対策として、まず開発者向けオプションおよびワイヤレスデバッグ設定が業務端末で無効化されているかを確認してください。MDM（Mobile Device Management）を導入している組織は、これらの設定をポリシーで強制無効化することで攻撃面を削減できます。また、業務端末を接続するWi-Fiネットワークをゲストネットワークや個人端末と分離するセグメンテーションも、横展開リスクの低減に直結します。エンドポイントセキュリティ製品のAndroid対応状況と、RedHookに関する検出シグネチャの更新有無も合わせて確認することを推奨します。

参照 Bleeping Computer

Zimbraの深刻なXSS脆弱性、細工したメールでユーザーセッション上の任意コード実行が可能に（原題: Critical Zimbra Flaw Could Let Crafted Emails Run Malicious Code in User Sessions）

概要 Zimbraは、Classic Web Clientに影響するストアド型XSS（クロスサイトスクリプティング）の脆弱性を公表し、ユーザーに対してただちにアップデートを適用するよう呼びかけました。この脆弱性を悪用されると、攻撃者が細工したメールを送付するだけで、受信者のブラウザセッション上で任意の悪意あるスクリプトが実行されます。なお、本脆弱性にはまだCVE識別子が割り当てられていません。

実務的な示唆 攻撃のトリガーが「メールを受信して開く」という通常業務の操作である点が特に深刻です。ストアド型XSSはメールの本文や添付データに悪意あるスクリプトを埋め込む手法のため、フィッシングのような「リンクを踏ませる」誘導が不要で、受信者が気づかないまま認証情報の窃取やセッションハイジャックが行われるリスクがあります。Zimbraを業務メールやグループウェアとして利用している組織は、Classic Web Clientを使用しているかどうかにかかわらず、まずZimbraが提供する最新アップデートの有無を確認し、適用を優先してください。CVEが未採番の段階では社内の脆弱性管理ツールによる自動検知が機能しないため、ベンダーのセキュリティアドバイザリを直接ウォッチする運用体制を整えることが必要です。

参照 The Hacker News

AI

提供された本文抜粋には「過去48時間で需要が急増したため、OpenAIが一時的に利用制限を緩和した」という事実のみが含まれており、モデルの具体的な性能詳細・制限の数値・緩和の期間・対象プランなどの情報が不足しています。

不確かな情報を補完して記事を執筆することは、読者への誤情報提供につながるリスクがあるため、現時点では記事化を保留することをお勧めします。

記事を執筆するにあたり、以下の情報が追加で確認できると正確な解説が可能になります。

1. 緩和の具体的な内容 — どのプラン（Free / Plus / Pro / API）が対象か、何のレート制限（1日あたりのリクエスト数、トークン数など）がどの程度変更されたか
2. 緩和の期間 — 「一時的」とある場合、終了予定日または条件
3. GPT-5.6 Sol の位置づけ — 既存モデル（GPT-4o等）との性能・用途の違い
4. 需要急増の背景 — リリースのタイミング、競合との関係など

元記事のURLにアクセスして全文を確認いただき、上記情報を補足していただければ、執筆ルールに沿った正確な解説記事をお届けします。

テクノロジー / 開発

Injective Labs のGitHubリポジトリが侵害され、npm経由でウォレット秘密鍵を窃取するパッケージが配布（原題: Injective Labs GitHub Compromise Pushes Wallet-Key-Stealing npm Packages）

概要 不明な攻撃者がブロックチェーン開発向けSDKを提供するInjective LabsのGitHubリポジトリを侵害し、公式npmパッケージ @injectivelabs/sdk-ts のバージョン1.20.21に偽のテレメトリ機能を埋め込んだ悪意あるコードを混入させました。このパッケージをインストールした開発者の環境から、暗号通貨ウォレットの秘密鍵とニーモニックシードフレーズが外部に送信される状態になっていました。

開発者・技術者への示唆 今回の攻撃は、信頼済みの公式リポジトリとパッケージレジストリそのものが侵害の起点になっている点が深刻です。「公式リポジトリからインストールしているから安全」という前提が成立しないことを示しています。

技術的な対策として、以下の3点を優先度が高い順に整理します。

1. パッケージバージョンのピン留めと差分確認: package-lock.json でバージョンを固定するだけでなく、CIパイプライン上で npm audit や socket.dev、Snyk などのサプライチェーン監視ツールを導入し、既知の安全なバージョンとのコード差分を自動検出する仕組みを設けることで、今回のような「1マイナーバージョン上のみに含まれる悪意あるコード」を検知できます。

2. GitHub Actions / CI権限の最小化: リポジトリへの書き込み権限を持つCI/CDトークンがnpmへの公開権限も持っていた場合、リポジトリ侵害が即座にパッケージ配布につながります。npmの公開トークンをリポジトリシークレットとは分離し、リリース専用のワークフローにのみ付与する構成が有効です。

3. ウォレット秘密鍵をメモリに展開するタイミングの見直し: SDKレイヤーで秘密鍵やシードフレーズをそのまま扱う実装は、テレメトリや外部通信コードが混入した際の被害を最大化します。署名処理をハードウェアウォレットや専用の署名サービスに分離し、SDK側には鍵そのものを渡さない設計に移行することで、たとえSDKが侵害されても鍵の漏洩を防げます。

参照 The Hacker News

今週の総括

今週もっとも際立ったのは、攻撃対象が「開発行為そのもの」に移行しつつあるという点です。jscrambler パッケージの汚染は、npm レジストリという信頼の基盤を直接突いたものであり、被害を受けるのはエンドユーザーではなく開発者本人です。npm install を実行した瞬間にインフォスティーラーが起動するという手口は、CI/CD パイプライン上でも同様のリスクを生むため、被害の連鎖が読みにくいのが厄介なところです。GitHub リポジトリ侵害も含め、サプライチェーン攻撃が単発の事故ではなくトレンドとして定着しつつあることを、今週の複数件の報告が改めて示しました。

Ghostcommit が実証した AI コードレビューへのプロンプトインジェクションは、「AI を使えばセキュリティレビューが楽になる」という前提を崩す事例です。PNG に埋め込んだ不可視の命令でレビューツールの判断を歪め、秘密情報を外部に漏洩させられるとなれば、AI をレビュープロセスに組み込んでいるチームは検討し直す必要があります。AI が「賢いから安全」ではなく、「賢いから巧みに騙せる」という逆説が、実装レベルで証明された週でした。

Progress ShareFile の件は、ベンダー自身が緊急シャットダウンを顧客に指示したという対応の異例さが目を引きます。今後確認すべき具体的な観点は2つです。①自社の開発環境・CI で利用している npm パッケージのバージョンとインスト