Security

概要 GitHubはCI/CDで広く使われる公式アクションactions/checkoutに、サプライチェーン攻撃「Pwn Request」を防ぐ安全なデフォルト動作を追加し、既存の主要バージョン全体へバックポートした。対象となるのはpull_request_targetやworkflow_runイベントで動作するワークフローで、フォークリポジトリの未レビューなプルリクエストのコードをチェックアウトしようとすると、ワークフローを失敗させる仕様に変わった。この変更はactions/checkout@v4のようにfloatingタグ（メジャーバージョンのみを指定するタグ）を使っているワークフローには自動的に適用される。当初は7月16日の適用開始が予定されていたが、実際の全面適用は7月20日にずれ込んだ形となった。 Pwn Requestとは何か pull_request_targetイベントは、通常のpull_requestイベントとは異なり、ベースリポジトリのGITHUB_TOKENや各種シークレット、デフォルトブランチのキャッシュへのアクセス権を持った状態でワークフローが実行される。ここで従来のactions/checkoutは、指定さえすればフォークPRのヘッドコミットも無条件にチェックアウトしていたため、悪意ある投稿者がPRを送るだけで、レビューされていない攻撃者制御下のコードが昇格した権限で実行されてしまう危険があった。GitHub自身も「未レビューのフォークPRのヘッドをこうしたワークフロー内でチェックアウトすると、通常は攻撃者制御のコードがワークフローの全権限で実行されてしまう」と説明しており、この攻撃パターンは近年、Nx、PostHog、TanStack、Emacsパッケージなどを巻き込んだ複数の実際のサプライチェーン侵害の原因となっていた。 技術的な仕組みと対象範囲 新しいデフォルト動作は、pull_request_targetまたはworkflow_run（後者はworkflow_run.eventがpull_request系イベントの場合に限る）のワークフロー内で、以下の条件が同時に満たされる場合にチェックアウトを拒否する。 repository:がフォークリポジトリを指し示している ref:がrefs/pull/<番号>/headなど、PRのヘッドやマージ参照に該当する 実際に解決される参照がフォークのヘッドまたはマージコミットSHAである 同一リポジトリ内のPRや通常のpull_requestイベントは影響を受けない。GitHubは6月18日にactions/checkout v7としてこの保護機能を一般公開した後、v1を除く既存の主要バージョン（v2〜v6系統など）にも同等の安全策をバックポートし、フォーク由来の危険なコードチェックアウトを塞いだ。 開発者への影響と対応方法 昇格権限が本当に必要な特殊なワークフロー（例えば、レビュー済みのラベルが付いたPRのみを対象とするデプロイパイプラインなど）のために、GitHubはallow-unsafe-pr-checkoutという入力パラメータを用意しており、これを明示的に指定すればこれまで通りの動作に戻せる。あえて警告的な名前を付けることで、コードレビュー時にこのオプトアウトが目立ち、レビュアーが気づきやすいよう配慮されている。一方で、actions/checkoutを特定のSHAやマイナー・パッチバージョンにピン留めしているワークフローは自動的には保護を受けないため、Dependabotなどの仕組みを使って明示的にアップグレードする必要がある。今回の変更はCI/CDのデフォルト設定をより安全な方向に倒す取り組みの一環であり、他のGitHub Actions関連ツールでも同様の「secure by default」の流れが今後広がることが予想される。

概要 セキュリティ企業Arctic Wolf Labsは、ランサムウェアグループ「Qilin」が Palo Alto Networks の PAN-OS GlobalProtect に存在する認証バイパスの脆弱性 CVE-2026-0257(CVSSスコア7.8)を悪用し、複数の企業ネットワークへ初期侵入を行っていると報告した。同社が2026年6月に調査した複数の侵入事例では、攻撃者がこの脆弱性を突いて有効な認証情報なしでVPNセッションを確立し、その後横展開やデータ窃取、ランサムウェア配置へと進んでいたことが確認されている。 脆弱性の技術的詳細 CVE-2026-0257は、PAN-OSのポータルおよびゲートウェイコンポーネントに存在する認証バイパスの脆弱性である。認証オーバーライド用のクッキーが有効化されており、かつ特定の証明書設定が組み合わさっている環境では、認証されていないリモートの攻撃者が認証プロセスを回避し、正規の認証情報を持たないまま VPN セッションを確立できてしまう。この脆弱性はすでに修正されているとされるが、記事内では具体的な修正パッチのバージョン番号や適用手順、緩和策についての詳細は明らかにされていない。 侵入後の攻撃手法 Arctic Wolfの分析によると、攻撃者は認証バイパスによってVPNセッションを確立した後、PsExecや管理共有を利用して社内ネットワーク内を横展開し、管理者アカウントを悪用していた。ランサムウェア本体の展開に際しては C:\PerfLogs\ ディレクトリにファイルをステージングする手口が確認されており、さらにイベントログの削除やWindows Defenderのリアルタイム保護の無効化といった防御回避の手法も併用されていた。 侵入後の行動パターンは事例によって幅があり、データ持ち出しを伴わない全社的な暗号化のみで終わるケースから、大規模な資格情報窃取を経てダブルエクストーション(二重恐喝)に至るケースまで多様であったという。データ持ち出しにはRclone、Proton Drive、FileZillaといったツールが、リモートアクセスの確保にはAnyDesk、Ngrok、LogMeInといったツールがそれぞれ使用されていたことも確認されている。 背景と今後の展望 Arctic Wolfは、こうした戦術のばらつきについて、Qilinがランサムウェア・アズ・ア・サービス(RaaS)の運用モデルを採っており、複数のアフィリエイトが共通の初期アクセス基盤とランサムウェアツールを共有しつつ、それぞれ独自に好むポストエクスプロイト手法を適用している可能性があると指摘している。これはRaaS型のランサムウェア集団に共通する特徴であり、単一の脆弱性の悪用であっても侵入後の挙動から画一的な攻撃者像を描くことが難しいことを示している。PAN-OS GlobalProtectを利用する組織においては、該当する認証オーバーライド設定の見直しや最新の修正状況の確認など、早急な対応が求められる。

概要 オンプレミス版Microsoft SharePoint Serverに存在する重大なリモートコード実行(RCE)脆弱性「CVE-2026-50522」(CVSSスコア9.8)が、公開された概念実証(PoC)コードの登場直後から実際に悪用されていることが、セキュリティ企業watchTowrの調査で明らかになった。攻撃者は本脆弱性を突いてSharePointサーバーからIISマシンキーを窃取し、正規の認証トークンを偽造することで、脆弱性そのものにパッチを適用した後も長期的にシステムへアクセスし続ける手口を確立している。影響を受けるのはSharePoint Subscription Edition、2019、2016の自己管理(セルフホスト)環境で、インターネットに公開された対象インスタンスは世界で約1,500件、その多くが米国に所在するとみられる。 技術的な詳細 この脆弱性は、信頼できないデータのデシリアライズに起因する欠陥で、SharePointのサインインエンドポイント(/_trust/default.aspx)を狙い、WS-Federationのサインイン応答内に偽造したSecurityContextTokenとしてCookie形式で悪意ある.NET BinaryFormatterペイロードを送り込むことで成立する。Microsoft側は本来Site Owner権限での認証を前提とした脆弱性として分類していたが、セキュリティ企業Defused Cyberの分析によれば、実際に観測された攻撃リクエストには認証情報が一切含まれておらず、攻撃者が何らかの手法で認証要件を回避し、事実上「認証不要」の形で悪用していることが示唆されている。Microsoftは本脆弱性を攻撃複雑度「低(AC:L)」、悪用可能性「Exploitation More Likely」と評価しており、攻撃者が高度な事前知識を持たずとも再現性高く攻撃を成功させられる状態にあるとしている。 攻撃はSharePointからマシンキーを1回のリクエストで窃取する手口が確認されており、盗まれたマシンキーがあれば攻撃者はパッチ適用後も正規の認証トークンを偽造してシステムへの侵入を継続できてしまう点が最大の脅威となっている。 発覚の経緯 セキュリティ企業Defused Cyberは7月17日、SharePoint内の未文書化のデシリアライズ経路を検知し、早期の警告を発していた。7月20日にはwatchTowrがPoCコードの存在を確認し、同社のグローバルハニーポットネットワーク「Attacker Eye」が、PoC公開からわずか数時間のうちに実際の悪用試行を捕捉したという。公開PoCは研究者Janggggg氏がGitHub上でPowerShellによるデモンストレーション用エクスプロイトとして公開したものとされる。なお本件は、2026年7月にオンプレミスSharePoint Serverで実悪用が確認された脆弱性としては、CVE-2026-56164、CVE-2026-58644に続く3件目となる。 推奨される対策 watchTowrやCISAなど複数の専門家・機関は、パッチ適用だけでは不十分であると強く警告している。CISAは「侵害の痕跡を捜索・修復してからIISマシンキーをローテーションすべき」と助言しており、単に脆弱性を修正するだけでなく、既に侵害を受けている可能性を前提とした対応が求められる。具体的な推奨事項としては、(1) Microsoftが7月に公開したセキュリティ更新プログラムを直ちに適用すること、(2) 侵害の兆候がないか事前に調査すること、(3) その上でIISマシンキーをローテーションすること、(4) SharePoint Webアプリケーションに対してAMSI(アンチマルウェア スキャン インターフェース)連携を有効化すること、が挙げられている。パッチ適用のみでは既に窃取されたマシンキーによる不正アクセスを防げないため、資格情報のローテーションを含めた包括的な対応が急務となっている。

概要 ServiceNow AI Platformに存在する未認証のサンドボックスエスケープ脆弱性CVE-2026-6875(CVSS 9.5)が、実際の攻撃キャンペーンで悪用されていることが明らかになった。この脆弱性は、認証されていない攻撃者がネットワークアクセスのみでスクリプトサンドボックスを脱出し、対象インスタンス上で任意のコードを実行できるというもので、脅威インテリジェンス企業Defusedによれば、パッチ公開からわずか数日後の週末には実悪用が確認されたという。ServiceNow AI Platformは年間1000億件を超えるワークフローを処理し、フォーチュン500企業の85%で10万を超えるエンタープライズAIアプリケーションを支える基盤であり、影響範囲の大きさから業界全体で警戒が高まっている。 脆弱性の発見と開示の経緯 この脆弱性はセキュリティ企業Searchlight Cyberの研究チームが2026年4月上旬に発見し、ServiceNowに報告した。ServiceNowは報告を受けて速やかに対応し、翌日にはホスト型(ServiceNowが運用するクラウド)インスタンス向けの更新を配布、自社ホスト型(オンプレミス・セルフホスト)顧客向けにも順次パッチを提供してきた。脆弱性の技術詳細は7月13日に公開され、Searchlight Cyberも概念実証(PoC)コードを合わせて公表した。この開示から間もなく、悪用の試みが観測され始めている。 悪用の手口と影響範囲 Defusedのセキュリティ研究者チームによると、最初の悪用の試みは公開直後の金曜日に現れ、週末にかけて実際の悪用行為へと発展した。注目すべきは、同じ未認証エンドポイント(/assessment_thanks.do)を標的としており、当初Defusedは攻撃者が使用したペイロードが公開PoCとは異なるルートでコード実行プリミティブに到達していると報告していたが、後の分析により実際にはSearchlight Cyberが公開したPoCと同一のペイロードであったことが判明した。影響を受けるのは主に自社ホスト型インスタンスであり、ServiceNowは「自社がホストするインスタンスにおいて、この活動に関連する証拠は観察されていない」としている。 対応策と今後の展望 ServiceNowは、まだパッチを適用していない自社ホスト型インスタンスの顧客に対し、7月に提供された更新プログラムを至急適用するよう強く呼びかけている。同社は必要に応じて顧客の対応を支援する姿勢も示した。さらに、将来的な同種のサンドボックスエスケープのリスクを低減する新機能「Guarded Script」の導入も進めている。今回のケースは、脆弱性の技術詳細やPoCの公開が、パッチ未適用の環境に対する攻撃の引き金となり得ることを改めて示すものであり、企業には開示から悪用までのタイムラインの短縮を前提とした迅速なパッチ運用が求められている。

概要 Oracleは2026年7月21日、四半期ごとの定例パッチ(Critical Patch Update、CPU)を公開した。今回のCPUは同社の企業向けオンプレミス製品全体で1,455件という過去最大級の脆弱性を一括修正するもので、その中には犯罪グループShinyHuntersが実際に悪用し、100以上の組織から約300台のサーバーを侵害するために使われたPeopleSoft PeopleToolsの認証前リモートコード実行(RCE)脆弱性が含まれる。CPU全体ではWebLogic Server、PeopleSoft、Identity Manager、WebCenter、WebCenter Capture、VirtualBoxにまたがり5件の緊急(CVSS 9.0以上)、12件以上の重要(High)脆弱性が対処された。 ShinyHuntersによる悪用の経緯 Mandiant(Googleの脅威インテリジェンス部門)が追跡するUNC6240ことShinyHuntersは、2026年5月27日からPeopleSoft PeopleTools 8.61/8.62のUpdates Environment Managementコンポーネントに存在するCVE-2026-35273(CVSS 9.8)を未パッチのゼロデイとして悪用を開始した。この脆弱性は/PSEMHUB/エンドポイントに対する単一のHTTPリクエストのみで認証なしにサーバーを完全に乗っ取れるというもので、攻撃者はMeshCentralの改造版をMicrosoft Azureのサービスに偽装させて展開し、盗んだ認証情報をシェルスクリプトでSSH経由に展開、WebLogicディレクトリにJSP webshellを設置してデータを段階的に圧縮・窃取するという手口を用いた。 悪用は6月9日まで約2週間続き、Oracleが緊急のセキュリティ警告を発表したのは6月10日で、その間パッチは存在しなかった。この攻撃により100以上の組織、約300台の脆弱なインスタンスが侵害され、被害組織の68%が高等教育機関、特に米国の大学が中心だった。最も早く被害が確認されたノッティンガム大学では約40GB・45万5,000人分の学生・卒業生の個人情報や請求記録が流出し、Moody Bible Instituteでは230万件の個人記録が流出したと報告されている。Mandiant Consultingの最高技術責任者Charles Carmakalは、キャンペーンが依然として活動中であり、恐喝メッセージの送付が続いていることを確認したと述べている。 7月定例パッチの内容 今回のCPUで修正されたPeopleSoft関連の脆弱性はCVE-2026-35278(CVSS 9.8)で、これは認証不要・HTTPアクセスのみでPeopleSoftアプリケーションサーバーと基盤ホストを完全に侵害できるリモートコード実行の欠陥である。CPU全体としては、WebLogic Serverの認証不要T3/IIOP経由RCEであるCVE-2026-35263(CVSS 9.9)、Identity ManagerのHTTP経由RCEであるCVE-2026-35268(CVSS 9.9)、WebCenter SitesのCVE-2026-35270(CVSS 9.1)、WebCenter CaptureのCVE-2026-35280およびCVE-2026-35281(いずれもCVSS 9.9)が緊急レベルの脆弱性として修正された。重要度の高い脆弱性としては、認証済みRCEのCVE-2026-35259(WebLogic、CVSS 8.8)、権限昇格・RCEにつながるCVE-2026-35271(PeopleSoft+WebLogic、CVSS 8.7)、ゲスト・ツー・ホスト脱出のCVE-2026-35275(VirtualBox、CVSS 7.5)などが含まれる。 推奨される対応 セキュリティ専門家は、PeopleSoftおよびWebLogic環境へのパッチを72時間以内に適用することを強く推奨している。あわせて、Oracleミドルウェアをインターネットに直接公開しないネットワーク隔離、全Oracleアプリケーションサーバーでの詳細なアクセス・エラーログの有効化、パッチ適用後の管理者認証情報のリセット、PeopleSoftサーバーにおける不審なプロセスや設定変更の侵害調査が求められる。Oracleはパッチが存在しなかった期間の緩和策として、複数サーバー環境ではEnvironment Management Hubサービスの無効化、単一サーバー環境では/PSEMHUB/*と/PSIGW/HttpListeningConnectorへの外部アクセス遮断を案内していたが、今回のCPUで恒久的な修正が提供されたことになる。ShinyHuntersによる恐喝キャンペーンは本稿執筆時点でも継続しているとされ、被害組織や関連組織は侵害の有無を改めて確認する必要がある。

概要 50,000以上の組織が利用し、4万5000を超えるモデルをホストする世界最大のAIモデルリポジトリHugging Faceは、自律型AIエージェントによるサイバー攻撃を受け、内部データセットとサービス認証情報が窃取されたことを公表した。攻撃者はプラットフォームにアップロードされたデータセットに仕込んだ脆弱性を悪用してサーバー上で悪質なコードを実行し、権限を昇格させて社内クラスタへの広範なアクセスを獲得した。公開モデルやユーザー向けデータセット、Spaces、ソフトウェアサプライチェーンの改ざんは確認されていないが、業界がかねて懸念してきた「エージェント型攻撃者」による実際の侵害事例として大きな注目を集めている。 侵入経路と攻撃手法 侵害の起点は、Hugging Faceのデータ処理パイプラインそのものだった。攻撃者は「リモートコードデータセットローダーにおけるコード実行経路」と「データセット設定内のテンプレートインジェクション」という2つの脆弱性を組み合わせ、悪意あるデータセットを介して処理ワーカー上で任意コードを実行させた。ここからノードレベルのアクセスへとエスカレーションし、認証情報を収集しながら週末をまたいで内部クラスタを横方向に移動していったという。 自律型AIエージェントの役割 今回の侵害で特に注目されているのが、攻撃の実行主体が人間ではなく自律型AIエージェントのフレームワークだった点だ。Hugging Faceの説明によれば、外部の自律エージェントは「短命のサンドボックス群を横断して数千件もの個別アクションを実行」し、さらに「公開サービス上に段階的に構築された自己移動型のコマンド・アンド・コントロール(C2)」を展開した。人手による操作を介さず、AIエージェントが探索・権限昇格・水平移動・データ収集までを自律的に連続実行した点で、これまで理論上の脅威とされてきた「エージェント型攻撃者」シナリオが現実の攻撃として観測された初期の事例といえる。 被害範囲とHugging Faceの対応 流出が確認されたのは限定的な内部データセットと複数のサービス認証情報で、顧客やパートナーのデータに影響が及んだかどうかは調査が続いている。一方で、公開されているモデルやデータセット、Spaces自体の改ざんは確認されていない。Hugging Faceは侵害の発覚後、悪用された脆弱なコードパスを修正し、攻撃者の足がかりを排除した上で侵害されたノードを再構築、影響を受けた認証情報とトークンをすべて失効・ローテーションした。さらにクラスタへのアクセス制御を厳格化し、24時間体制の検知システムを強化するとともに、法執行機関への報告と外部のサイバーフォレンジック専門家の起用も行った。ユーザーに対しては、プラットフォーム上に保存しているAPIキーの再発行と、アカウントでの不審な活動の確認を呼びかけている。 フォレンジック分析における技術的な教訓 侵害対応の過程でHugging Faceが直面したのは、攻撃者が残した実際の攻撃コマンドやエクスプロイトのペイロード、C2の痕跡を分析しようとした際、欧米の主要な商用フロンティアモデルがガードレールによって分析リクエストを拒否してしまうという問題だった。同社はこれを回避するため、Z.aiのGLM 5.2モデルを自社インフラ上で運用してログのフォレンジック分析に活用したという。Hugging Faceはこの経験から、「インシデントが起きる前に、自社インフラ上で検証済みのモデルを用意しておくことが重要だ」と指摘している。ガードレールによる分析拒否を避けられるだけでなく、攻撃者関連の機密データや認証情報を外部のAI企業のサーバーに送信せずに済むためだ。この教訓は、AIを活用したセキュリティ運用を進める組織にとって、フォレンジック用モデルの選定と運用体制のあり方に一石を投じるものとなっている。

概要 RubyGemsのパッケージエコシステムを標的とした新たなサプライチェーン攻撃「SleeperGem」が発覚した。攻撃者は6〜7年間ログインのなかった休眠中のメンテナーアカウントを乗っ取り、git_credential_manager、Dendreo、fastlane-plugin-run_tests_firebase_testlabという3つのgemパッケージを悪用してマルウェアを配布した。特にfastlane-plugin-run_tests_firebase_testlabは累計57万4661件のダウンロード実績を持つ既存の信頼されたパッケージであり、攻撃者は新規に怪しいパッケージを公開するのではなく、実績のあるアカウントとパッケージを乗っ取ることで検知を回避した。RubyGemsエコシステムにおける大規模なサプライチェーン攻撃事例として注目されている。 攻撃の手口 攻撃は段階的かつ慎重に実行された。新規作成されたgit_credential_managerでは、わずか数時間のうちに4つのバージョン（v2.8.0〜v2.8.3）が連続して公開されている。最初のv2.8.0は完全に機能するドロッパーとして配布されたが、24分後に公開されたv2.8.1では出力をサイレント化して痕跡を隠蔽し、その後8時間の沈黙期間を置いて翌朝公開されたv2.8.2でgemのロードパスに悪意あるコードを統合、requireされるだけで実行される状態にした上で、その17分後に公開されたv2.8.3で最終的にペイロード取得機能を有効化するという慎重な展開を行っている。 各gemはローダーとして機能し、攻撃者が管理するForgejoインスタンス（git.disroot.org）から第2段階のペイロードを取得する。この通信ではSSL証明書検証を明示的に無効化した上でペイロードを取得し、シェルまたはPowerShellに直接渡して実行する実装になっていた。さらに、GitHub Actions、GitLab CI、CircleCI、Jenkinsなど約30種類のCI/CD環境変数をスキャンし、CI環境下では実行を控える仕組みを組み込んでいた。これにより自動化されたビルドパイプラインでの検知を回避し、開発者個人のマシンを直接狙う点が本攻撃の大きな特徴となっている。 永続化と被害の範囲 侵入に成功した端末では、~/.local/share/gcm/にネイティブバイナリのデーモンをステージングし、cronエントリとsystemdのユーザーサービスを用いて再起動後も動作し続けるよう永続化される。さらに、sudoがパスワードなしで実行できる環境ではroot権限で処理を再実行し、/usr/local/sbin/ping6にsetuid rootのシェルを設置するなど、より深い権限奪取も試みる。Windows環境ではPowerShell経由でdeploy.shスクリプトが実行される仕組みも確認されている。 また、git_credential_managerはDendreoやfastlane-plugin-run_tests_firebase_testlabのほか、slackHtmlToMarkdown、seo_optimizer、array_fast_methodsといった別のパッケージからも依存関係として追加されており、被害が芋づる式に拡大する構造になっていた。Dendreoは「LR-DEV」、git_credential_managerは「pinkroom」と、異なるアカウントが使われていたことから、単一アカウントの侵害ではなく、複数の休眠アカウントが並行して乗っ取られていたとみられている。 対策への示唆 セキュリティ企業のStepSecurityなどは、該当パッケージをインストールした形跡がある端末について、関連する認証情報がすべて漏えいした前提で対応するよう推奨している。具体的には、~/.local/share/gcm/に設置されたデーモンプロセスの削除、/usr/local/sbin/ping6に仕込まれたsetuidシェルの有無の確認、影響を受けた可能性のある全認証情報のローテーションが挙げられる。今回の事例は、長期間放置された正規のメンテナーアカウントが、地道な監視なしには気づかれないまま攻撃インフラとして悪用され得ることを示しており、パッケージレジストリ運営者やメンテナー自身による休眠アカウントの定期的な棚卸しと多要素認証の徹底が改めて課題として浮かび上がっている。

概要 WordPressコア自体に、未認証の攻撃者が任意コードを実行できる深刻な脆弱性チェーン「wp2shell」が発見され、世界のウェブサイトの相当数を占める約5億サイトに影響する可能性があることが明らかになった。プラグインを一切使わないデフォルト環境でも悪用可能な点が特に深刻で、WordPressは7月18日以降、6.9.5・7.0.2・6.8.6の緊急アップデートを自動更新の形で強制配信する異例の対応を取った。すでにGitHub上には実際に動作するプルーフオブコンセプト(PoC)が複数公開されており、パスワードハッシュの抽出から悪意あるプラグインの実行まで可能なことが確認されている。 技術的な詳細 wp2shellは単一の脆弱性ではなく、2つの問題が連鎖することで「匿名リクエストからコード実行まで」を実現する複合的な攻撃チェーンである。 1つ目は、REST APIのバッチ処理エンドポイント/wp-json/batch/v1に存在する「バッチルート混同」の脆弱性(CVE-2026-63030、CVSS 9.8)。バッチ処理エンドポイント自体は2020年公開のWordPress 5.6から存在するが、WordPress 6.9で新たに生じたこの脆弱性は、複数のサブリクエストをまとめて処理する際にエラーが発生すると、内部で管理している2つの並列配列がずれてしまい、本来とは異なるハンドラーの下でリクエストが処理されてしまうというルート検証の不同期化バグである。これにより、本来アクセスできないはずの機能へのアクセス制限がバイパスされる。 2つ目は、WordPressコアのSQLインジェクション脆弱性(CVE-2026-60137)。WP_Queryのauthor__not_inパラメータに配列ではなく文字列を渡すと、本来行われるはずの配列チェックがスキップされ、未フィルタリングの値がそのままSQLクエリに挿入されてしまう。 この2つを組み合わせることで、未認証の攻撃者がSQLインジェクションを起点にサイトを制御下に置き、最終的に任意コードの実行(RCE)にまで到達できてしまう。影響範囲はバージョンによって異なり、WordPress 6.8.0〜6.8.5ではSQLインジェクションのみが存在する(6.8.6で修正)のに対し、バッチルート機能を含む6.9.0〜6.9.4および7.0.0〜7.0.1では完全なRCEチェーンが成立する(それぞれ6.9.5、7.0.2で修正)。 対応状況と推奨される対策 WordPressは7月18日以降、影響を受ける全バージョン向けに緊急パッチを自動更新機能を通じて強制的に配信した。開発版である7.1のベータ2にも両方の修正が反映されている。サイト管理者は自動更新が正常に完了しているかを確認するとともに、手動での即時アップデートが強く推奨される。 即座にアップデートできない場合の一時的な緩和策としては、REST APIへの匿名アクセスをブロックする、あるいはWAF(Web Application Firewall)で/wp-json/batch/v1エンドポイントへのアクセスをフィルタリングする方法が挙げられている。Cloudflareはすでに全プランでこの脆弱性に対するWAF保護を展開済みとしている。また、パッチ適用が遅れたサイトについては、バックドアの設置など侵害の痕跡がないか確認することも推奨されている。 なお、悪用状況については情報源によって温度差がある。BleepingComputerやCyberInsiderは実際の悪用(in-the-wild exploitation)が既に確認されていると報じる一方、The Hacker Newsは本記事時点でCISAの既知悪用脆弱性(KEV)カタログには掲載されておらず、確認された悪用報告はないとしている。いずれにせよ、攻撃チェーンの詳細と動作するPoCが既に公開されている以上、悪用の拡大は時間の問題とみられ、未パッチのサイトは早急な対応が求められる。

概要 医療機器大手のアボット・ラボラトリーズは7月17日、社内システムへの不正アクセスを伴う2件の別々のサイバー攻撃について調査していることを明らかにした。1件はがん診断事業(Cancer Diagnostics)の内部システムを狙ったもので、恐喝グループShinyHuntersが関与を主張している。もう1件はLabCentralという顧客向けポータルを狙ったもので、攻撃者ShadowByt3$が犯行を名乗り出ている。アボットはいずれの事案についても「事業運営、製品、製品供給には影響がない」としており、他の事業部門やサイト、システムへの波及もないと説明している。 がん診断事業への攻撃 ShinyHuntersは、6月中旬にアボット従業員を狙ったビッシング(音声フィッシング)攻撃によってMicrosoft Entraのシングルサインオン(SSO)アカウントを侵害し、がん診断事業内のExact Sciences由来のレガシーシステムに侵入したと主張している。アボットは今回の買収からわずか数ヶ月というタイミングで、210億ドル規模で買収したExact Sciencesの旧システムが標的となった形だ。ShinyHuntersは、3000万件を超える顧客の個人識別情報、100万件以上の社会保障番号、医師と患者の会話を含む2200万件超のクライアントノート、2000万件を超える医療オーダー、さらに内部文書や契約書を窃取したと主張しているが、アボットはどのような情報にアクセスされたかについて具体的な開示をしておらず、これらの主張の裏付けは取れていない。両者ともこれまでのところ盗み出したとするデータを公開していない。 LabCentralポータルへの侵害 もう1件の事案は、アボットの臨床検査診断事業が使用する外部の顧客向けポータル「LabCentral」に関するものだ。攻撃者ShadowByt3$は、7月4日に顧客の認証情報を悪用してポータルの「脆弱な部分」を突いて侵入したと主張し、製造証明書、操作マニュアル、技術仕様書、規制関連文書を窃取したとしている。これに対しアボットは、同環境に保存されているデータはすべて公開情報であり機微なものではないと反論しており、LabCentralは操作マニュアルやトラブルシューティングのチェックリストなど、一般に公開されている技術製品参考資料のみを保管していると説明している。 対応状況と業界動向 アボットは両事案の発覚後、外部のサイバーセキュリティ専門家と法執行機関に連絡し、インシデント対応手続きを開始した。同社は現時点で、機微な顧客情報や事業情報の流出は確認されておらず、財務結果への重大な影響も見込んでいないとしている。製造や検査業務についても継続中であることを強調した。今回の一件は、2026年上半期にStryker、Intuitive Surgical、Medtronic、iRhythm、AdaptHealth、Novo Nordiskなど複数の医療機器・ヘルスケア関連企業がサイバー攻撃の被害を公表している流れの中に位置づけられ、医療セクターを狙った攻撃が引き続き増加傾向にあることを示している。

概要 コカ・コーラの完全子会社で、シカゴを拠点とする乳製品ブランドFairlifeが7月16日、ランサムウェア攻撃を受けたことを米証券取引委員会(SEC)への開示文書で明らかにした。生産関連システムを含む一部システムへの不正アクセスが確認されたことを受け、米国内のFairlife生産拠点は操業を一時停止している。一方、カナダでの生産活動は現時点で影響を受けていないという。同社は「製品の品質と安全性には影響がない」としているが、システムの復旧時期については明確な見通しを示していない。 被害の詳細と事業への影響 Fairlifeは、通常より高いタンパク質含有量が特徴の超ろ過(ウルトラフィルタリング)牛乳を主力製品とし、チョコレート、無脂肪、低脂肪、イチゴ、全脂肪乳の5種類の味で展開している。年間売上高は約40億ドル規模とされ、コカ・コーラの乳製品事業の中核を担うブランドだ。今回の攻撃では生産システムへの不正アクセスが確認されているものの、データが実際に窃取されたかどうか、また攻撃者から身代金要求があったかどうかは本稿執筆時点で明らかになっていない。既知のランサムウェアグループが犯行声明を出した形跡もなく、攻撃者の身元は特定されていない。 コカ・コーラの対応 コカ・コーラおよびFairlifeは、インシデント対応と事業継続のプロトコルを発動し、外部の顧問やサイバーセキュリティ専門家の支援を受けながら調査を進めている。あわせて法執行機関にも通報済みとしている。ただし、両社は報道機関に対しSEC開示文書に記載された内容以上の詳細な情報提供を控えており、被害の全容や復旧の見込み時期については依然として不透明な状態が続いている。 食品製造業を狙うランサムウェアの脅威 今回の事例は、食品・飲料製造業を標的とするランサムウェア被害の深刻さを改めて浮き彫りにした。過去にも2019年のアリゾナ・ビバレッジや、2025年に食品流通大手UNFIが受けた攻撃では、生産ラインの混乱や小売店での品切れが数週間にわたって続いた前例がある。生産システムがIT環境と密接に連携する製造業では、サイバー攻撃が単なる情報漏えいにとどまらず、物理的な供給網の停止に直結しやすい。今回のFairlifeの事例も、消費財サプライチェーン全体に及ぶ影響が今後注視される展開となりそうだ。