Apex Centralの脆弱性対応：PHPのCVE-2026-109618とCVE-2025-69258、最新Build 7328の確認と暫定手順【2026年11月】

Trend Micro Apex Central（オンプレミス版）では、2026年に入って対応が必要な脆弱性が2系統出ています。1つは1月に公表された製品自体の欠陥CVE-2025-69258（CVSS 9.8）で、Critical Patch Build 7190以降で直ります。もう1つは、Apex Centralが内部で使っているPHPの脆弱性「php2shell」（CVE-2026-109618・109619）です。こちらは2026年10月26日にCISAの悪用確認済み脆弱性カタログ（KEV）に載り、最新のBuild 7328でも影響を受けます。本記事では2026年11月11日時点の一次情報をもとに、影響範囲、確かめ方、暫定対応、パッチの適用と切り戻しを整理します。

まとめ：Build 7328への更新とPHPの暫定対応・正式パッチの適用

• 最優先はPHPの件：php2shell（CVE-2026-109618・109619）は認証不要のRCEで、KEV掲載済みです。トレンドマイクロはApex Centralを「影響あり」とし、11月4日時点で正式なCritical Patchの提供予定を11月11日としています。
• 正式パッチまで：Build 7328を当てたうえで、PHPとWebUIのファイルを公式配布のパッケージで置き換える暫定手順（KA-0024805）を実施します。
• CVE-2025-69258：MsgReceiver.exe（既定でTCP 20001）への細工したメッセージで、SYSTEM権限のコード実行を許します。Build 7190未満が対象で、7328を当てれば直っています。
• 最新ビルド：ダウンロードセンターの最新はCritical Patch Build 7328（日本語版は2026年10月16日公開、サポート終了は2028年4月30日）です。
• 確認方法：管理コンソールの［ヘルプ］→［バージョン情報］で「Hot Fix:」の番号を見ます。バージョンの横のBuild番号は初期インストール時のままで、パッチを当てても変わりません。
• すぐ当てられない場合：管理コンソールとTCP 20001への接続を、管理対象のサーバー群と管理者の端末だけに絞ります。

Apex Centralは社内のウイルス対策やEDRを束ねる管理サーバーです。乗っ取られると配下の端末の保護設定まで書き換えられるおそれがあるため、通常の業務サーバーより優先度を上げて扱います。

PHPの脆弱性php2shell（CVE-2026-109618・109619）とApex Centralへの影響

Apex Centralの管理コンソールは、IIS上のPHPで動いています。製品に同梱されたPHPに欠陥があれば、Apex Central本体のコードに問題がなくても管理サーバーが攻撃を受けます。2026年10月の件がまさにこの形です。

認証不要のRCEとKEV掲載・PHP側の修正版

PHP開発チームは2026年10月21日に、Webリクエストを処理するPHPで認証なしにリモートからコードを実行される2件の脆弱性を公表し、PHP 8.5.12・8.4.27・8.3.36・8.2.35で修正しました。CISAのアラートによると、影響はWebリクエストを処理するすべてのPHP（mod_php・PHP-FPM・php-cgiなど）に及び、10月26日にKEVへ追加されました。KEVでの名称はCVE-2026-109618が「PHP Memory Corruption Vulnerability」、CVE-2026-109619が「PHP Stale Internal Request-State Vulnerability」です。

トレンドマイクロのKA-0024802（11月4日更新）は、2件をCVSS v4で9.2と紹介し、製品ごとの影響を一覧にしています。Apex CentralとApex One（オンプレミス版）はどちらも「Impacted」で、Critical Patchの提供予定は11月11日です。一方、Deep SecurityやTrend Vision Oneのプラットフォームは「Not Impacted」、Apex One as a Serviceは10月23日の緊急メンテナンスで対処済みとされています。自社の製品で悪用を確認した事例は、11月4日時点では無いとしています。

最新のCritical Patch Build 7328のReadmeが同梱PHPとして挙げているのは8.2.33で、修正版の8.2.35に届いていません。7328を当てていても、PHPの件は残ったままです。

正式パッチまでの暫定対応（KA-0024805の手順）

日本語のKA-0024805（11月10日更新）が、正式パッチまでの暫定手順を示しています。前提はCritical Patch 7328の適用で、それより古いビルドでは検証されていません。作業前にスナップショットかOSレベルのバックアップを取るよう求めています。

1. Build 7328を当てる（未適用なら先に適用する）。Apex Centralサーバーにセキュリティエージェントが同居している場合は、アンロードしておく。
2. 管理者権限のコマンドプロンプトで、NET STOP TMCM、NET STOP "TrendMicro Infrastructure"、NET STOP W3SVCの順にサービスを止める。
3. <インストールフォルダ>\Control Manager\PHPフォルダと、WebUI\cgi-bin\zlibwapi.dllを、サーバーの外へコピーして控える。
4. KA-0024805のリンクから「Control Manager.zip」を入手し、記事に載っているSHA256と一致することを確かめ、パスワード「trend」で展開し、PHPフォルダとWebUIフォルダを\Control Managerに上書きで配置する。
5. NET START "TrendMicro Infrastructure"、NET START TMCM、NET START W3SVCの順にサービスを起動する。

ハッシュの照合と、置き換え後のPHPのバージョン確認は、PowerShellで次のように行えます。インストールフォルダは自社の環境に合わせて書き換えてください。

# 入手したパッケージのSHA256を表示し、KA-0024805に載っている値と目で照合する
Get-FileHash -Algorithm SHA256 '.\Control Manager.zip'

# Apex Centralのインストールフォルダ（環境に合わせて書き換える）
$acDir = 'D:\Trend Micro\Control Manager'

# 同梱PHPの実行ファイルとバージョンを表示する（置き換え前後で比べる）
Get-ChildItem (Join-Path $acDir 'PHP') -Filter 'php*.exe' |
  Select-Object Name, @{ Name = 'Version'; Expression = { $_.VersionInfo.ProductVersion } }

英語版のKA-0024815は、Apex Oneの手順の中で、退避したPHPフォルダをサーバー上に残さないよう注意しています。古いPHPのファイルが残っていると、脆弱性スキャナーがそれを検出し続けるためです。Apex Centralで控えたPHPフォルダも、同じ理由でサーバーの外に置いてください。暫定手順は正式パッチの代わりではないので、パッチが出たら適用します。

CVE-2025-69258の仕組みとSYSTEM権限でDLLを読み込ませる攻撃経路

2026年1月に公表されたCVE-2025-69258は、Apex Central自体の欠陥です。原因は、Windows APIのLoadLibraryExに、外部から受け取ったDLLのパスをそのまま渡している点にあります。発見者であるTenableのアドバイザリTRA-2026-01が、問題の処理を逆アセンブル結果つきで示しています。

MsgReceiver.exeのメッセージ0x0a8dがDLL名をそのまま読み込む欠陥

MsgReceiver.exeは既定でTCP 20001を待ち受け、独自形式のメッセージを処理します。そのうち「SC_INSTALL_HANDLER_REQUEST」（メッセージID 0x0a8d）には、読み込むハンドラーDLLの名前が入っています。Tenableによると、この名前が検証されないままLoadLibraryExAに渡されるため、攻撃者は自分の共有フォルダーにあるDLL（例：\\攻撃者のホスト\share\evil.dll）を指定できます。DLLは読み込まれた時点でコードが動くので、MsgReceiver.exeの権限であるSYSTEMで任意のコードが実行されます。

TenableのPoCは、32ビットのDLLと、認証なしで読めるSamba共有を使います。成立には、TCP 20001に届くことに加え、対象サーバーから共有上のDLLを読み込めることも必要です。CVSS v3.1は9.8（AV:N/AC:L/PR:N/UI:N）で、NVDに登録されたトレンドマイクロの評価も同じ値です。CVE番号とCVSSの関係はCVEの番号の読み方とCVSS・NVDとの違いで解説しています。

CVE-2025-69259・69260のメッセージ0x1b5b処理不備によるサービス停止

残る2件は、同じMsgReceiver.exeでメッセージ0x1b5bを処理する部分の不具合で、どちらも認証不要、CVSS 7.5（可用性のみHigh）です。CVE-2025-69259は、strstrが改行（CRLF）を見つけられずNULLを返したとき、その戻り値を確かめずに使ってしまう欠陥です。CVE-2025-69260は、メッセージ中の文字列の長さを検証しないまま読み進め、バッファの外を読み取ってしまう欠陥です。管理サーバーが落ちている間は、ポリシー配信や配下製品のログ集約が止まります。

2026年2月25日にアドバイザリへ追記された過去修正分の5件

日本語版アドバイザリKA-0022081は2026年2月25日に更新され、以前のCritical Patchで修正済みだったものの公表されていなかった5件が加わりました。いずれもBuild 7190に修正が含まれており、悪用には認証が必要です。

CVE-2025-71205〜71207は、脅威インテリジェンス・スケジュール更新・手動更新の各コンポーネントで、サーバーから任意のHTTPリクエストを送らせられるブラインドSSRFです。CVE-2025-71208と71209は互いに似ているものの別の不具合とされています。この5件は7190より前のパッチで直っているため、7190未満のサーバーでも当てているパッチによっては該当しません。1月公表の3件は、7190未満なら必ず該当します。

2025年以降のApex Centralのパッチと脆弱性の履歴

どのパッチまで当てているかで、残っている脆弱性とサポートの状態が変わります。

脆弱性を公表したアドバイザリ

2025年4月のKA-0019355では、ウィジェットのローカルファイルインクルード（CVE-2025-47867）が「任意のファイルをPHPコードとして実行させられる」と説明されています。表のCVE-2025-30680はSaaS版だけの脆弱性です。2025年6月のKA-0019926の2件は、認証前に信頼できないデータを逆シリアル化するRCEで、アドバイザリは実際の悪用は確認されていないと明記しています。

CVE番号が付かない修正もあります。Build 7258のReadmeは、同梱PHPを8.2.30へ更新し、SQLiteモジュールの潜在的な脆弱性にも対処したと記載しています。7328のReadmeのリリース履歴には、英語版Critical Patch 7309で直したウィジェットのクロスサイトスクリプティングも載っています。CVEの一覧だけを見て「7190で十分」と判断しないでください。

ビルドごとの公開日とサポート終了日

日本向けのサポート期間の一覧（KA-0009810）によると、Apex Centralはビルドごとに、公開した月から18か月がサポート期間です。2025年以降のビルドは次のとおりです。

英語版のダウンロードセンターでは、7258が2026年4月23日、7309が7月31日、7328が10月8日に公開されています。7309は日本の一覧に載っておらず、修正内容は7328に引き継がれています。7007以前のまま運用しているサーバーは、脆弱性とは別に、すでにサポートが終わっている点にも注意が必要です。

Apex Centralのパッチ適用状況とTCP 20001の到達性確認

管理コンソールの「Hot Fix」番号で確かめるパッチの適用状況

Apex CentralのWeb管理コンソールにログインし、［ヘルプ］→［バージョン情報］を開きます。KA-0000665によると、パッチの適用状況はここに表示される「Hot Fix:」の番号で判断します。「Hot Fix:」の表示が無ければ、修正プログラムが1つも当たっていない状態です。

注意したいのは、バージョン番号の右に出るBuild番号です。これは初期インストール時のビルドを示しており、パッチを当てても変わりません。「Buildが7190未満だから未適用」と判断すると、7328まで当て終えたサーバーまで未適用に数えてしまいます。適用後に確かめるのも「Hot Fix:」の番号です。

PowerShellでTCP 20001の待ち受けと接続元を確認するコマンド

管理サーバー上の管理者権限のPowerShellで次を実行すると、20001番を待ち受けているプロセスと、その通信に当たりうる有効な受信規則が分かります。規則は、GPOで配られたものも含む実効のポリシー（ActiveStore）から取り、ローカルポートを20001と明示した規則に加えて、Anyやポート範囲で20001を含む規則も拾います。

# 20001番を待ち受けているプロセス（MsgReceiver.exe であることを確かめる）
Get-NetTCPConnection -LocalPort 20001 -State Listen |
  ForEach-Object { Get-Process -Id $_.OwningProcess } |
  Select-Object Id, ProcessName, Path

# 20001番に当たりうる有効な受信規則（20001・Any・範囲指定）と、その動作・接続元・配布元
Get-NetFirewallPortFilter -PolicyStore ActiveStore |
  Where-Object { $_.Protocol -in 'TCP', 'Any' -and ($_.LocalPort | Where-Object {
      $_ -in '20001', 'Any' -or ($_ -match '^(\d+)-(\d+)$' -and [int]$Matches[1] -le 20001 -and [int]$Matches[2] -ge 20001) }) } |
  Get-NetFirewallRule |
  Where-Object { $_.Direction -eq 'Inbound' -and $_.Enabled -eq 'True' } |
  ForEach-Object { [pscustomobject]@{
      Name    = $_.DisplayName
      Action  = $_.Action
      Profile = $_.Profile
      Source  = $_.PolicyStoreSourceType
      Remote  = ($_ | Get-NetFirewallAddressFilter).RemoteAddress } }

# 社外や別セグメントの端末から到達できるかの確認（宛先は自社の管理サーバー名に置き換える）
Test-NetConnection -ComputerName apexcentral.example.local -Port 20001

RemoteがAnyの許可規則は、接続元を絞っていない規則です。ただしWindowsファイアウォールでは明示的なブロック規則が許可規則より優先され、プロファイルやプログラムの条件もかかるため、この一覧だけで外部から届くかは決まりません。SourceがGroupPolicyの規則はサーバー上では書き換えられないので、GPO側で直します。最後のコマンドは、本来届かないはずのネットワーク（VPN接続した外部端末や来客用のセグメントなど）から実行し、TcpTestSucceededがFalseになることを確かめます。PHPの件は管理コンソールのHTTPS（IIS）経由なので、同じコマンドの-Portを443に変えて、管理コンソールに届く範囲も確かめておきます。

パッチを当てるまでの緩和策と管理対象のサーバー群に接続元を絞る設定例

KA-0022081が示す軽減要素は「信頼されたネットワークからのみアクセスを許可する」ことです。回避策の具体的な設定値は示されていないため、ここではWindowsファイアウォールでTCP 20001を絞る例を示します。

# ローカル（PersistentStore）の有効な受信許可規則のうち、ローカルポートの一覧に20001を含むものを対象にする
$rules = Get-NetFirewallPortFilter -PolicyStore PersistentStore -Protocol TCP |
  Where-Object { $_.LocalPort -contains '20001' } |
  Get-NetFirewallRule |
  Where-Object { $_.Direction -eq 'Inbound' -and $_.Enabled -eq 'True' -and $_.Action -eq 'Allow' }

# 変更前の接続元を控えてから、管理対象のサーバー群のセグメントだけにする（例：10.0.20.0/24）
$rules | ForEach-Object { [pscustomobject]@{ Name = $_.Name; Remote = ($_ | Get-NetFirewallAddressFilter).RemoteAddress -join ',' } } |
  Export-Csv .\fw20001_before.csv -NoTypeInformation -Encoding UTF8
$rules | Set-NetFirewallRule -RemoteAddress 10.0.20.0/24

# 変更後の接続元を確認する
$rules | Get-NetFirewallAddressFilter | Select-Object InstanceID, RemoteAddress

このコードは、ローカルポートの一覧に20001を含む許可規則を書き換えます。複数ポートを指定した規則では他のポートの接続元も変わるため、実行前に対象規則を確認してください。確認用のコマンドでAnyやポート範囲の許可規則が見つかった場合は、その規則も個別に見直してください。20001番は管理対象の製品との通信にも使われるため、絞る前に、どのサーバーがApex Centralへ接続しているかを洗い出します。範囲から漏れたサーバーは、ログやステータスを送れなくなります。管理コンソールのHTTPSも配下製品との通信に使われることがあるので、管理者の端末と管理対象のサーバー群を合わせた範囲に絞ります。経路上のファイアウォールでも同じ制限をかけておけば、サーバー側の規則を誤って戻しても外からは届きません。境界での制御の考え方はファイアウォールの仕組みと種類、侵入検知との組み合わせはIDS・IPSの違いと使い分けで整理しています。

TenableのPoCは、攻撃者の共有フォルダーからDLLを読み込ませる手順でした。管理サーバーから外部へのSMB（TCP 445）通信を止めておくと、外部に置いたDLLを読ませる経路は使いにくくなります。ただし社内の別端末を踏み台にされると防げないため、補助的な対策にとどまります。

Critical Patchの適用手順と適用に失敗したときの切り戻し

Critical Patchは、トレンドマイクロの最新版ダウンロードページでApex Central 2019を選んで入手します。最新版ダウンロードページには最新のパッチだけが載ります。Readmeのリリース履歴に過去のHotfixやCritical Patchが並んでいるとおり、修正は累積して含まれます。日本語版7328のReadmeによると、適用できるのはApex Central ビルド3945（日本語版の初期リリース）以降で、サーバーにファイルをコピーして実行すればインストールが完了します（英語版はBuild 3752以降）。注意したいのは、7328はアンインストールできないと明記されている点です。

1. Readmeで、システム要件と既知の制限事項を確認する。
2. Apex Centralのデータベースと設定をバックアップする。仮想サーバーならスナップショットも取る。
3. Readmeに従ってCritical Patchをインストールする。
4. 管理コンソールの［ヘルプ］→［バージョン情報］で「Hot Fix:」の番号が変わったこと、配下の製品からステータスとログが届いていることを確かめる。
5. PHPの暫定対応を当てていた場合は、正式パッチの案内に従って扱いを確かめる。

同じReadmeは既知の制限事項として、Windows Server 2025ではActive Directory同期にメール形式（[email protected]）のアカウントが必要で、domain\username形式では失敗すると記載しています。理由はWindows Server 2025でNTLMが初期設定で無効になっているためとされています。Windows Server 2025で動かしている場合は、適用前に同期用アカウントの形式を確かめてください。

インストールが完了しない、適用後に配下の製品の情報が同期されない、といった失敗では、7328はアンインストールで戻せないため、手順2で取ったバックアップかスナップショットから適用前の状態へ戻すことになります。同じトレンドマイクロの管理サーバーでは、2026年4月にApex OneのCritical Patch（ビルド17079）が一部環境でインストールを完了できず公開停止になりました（KA-0023004）。このときもトレンドマイクロが最初に挙げた戻し方は、フルバックアップからのリストアとスナップショットへの切り戻しでした。戻したあとは接続元の制限で守りを固め、エラーの内容を添えてサポートへ問い合わせます。パッチの優先度をKEVで決めて運用に組み込む方法はパッチ管理の手順で解説しています。

Apex Centralの脆弱性を優先して扱うべき理由と悪用状況

2026年11月10日版のCISA KEVで、Apex Centralという製品名での登録は2022年3月のCVE-2022-26871（任意ファイルアップロード）の1件だけで、CVE-2025-69258などの1月公表分は載っていません。ただし、PHPの2件はPHP Groupの製品として10月26日に登録され、連邦機関への対応期限は10月29日でした。KEVをApex Centralの名前で検索しても出てこないため、製品名で載っていないことを理由に通常の月例パッチと同じ扱いにしないでください。同じ管理サーバー型のApex One（オンプレミス版）では、CVE-2026-34926が2026年5月21日にKEVへ追加されています。PoCが公開された脆弱性の悪用状況の調べ方はexploitとPoCの違いと悪用状況の確認手順で整理しています。同じトレンドマイクロのサーバー保護製品の脆弱性はDeep Security Agentの脆弱性CVE-2024-51503で扱っています。

管理サーバーへの不審な接続を後から追えるよう、Apex Centralと周辺のファイアウォール、IISのログをSOCとSIEMの監視対象に入れておくと、侵害の有無を判断しやすくなります。管理サーバーの公開範囲や設定を第三者に確かめてもらいたい場合は、脆弱性診断・セキュリティ診断で外部から到達できる面を洗い出せます。

よくある質問

Apex CentralはPHPの脆弱性CVE-2026-109618の影響を受けますか？

受けます。トレンドマイクロのKA-0024802は、オンプレミス版のApex Centralを「Impacted」としています。最新のBuild 7328に同梱されたPHPは8.2.33で、修正版の8.2.35より古いためです。正式なCritical Patchが出るまでは、7328を当てたうえでKA-0024805の暫定手順を実施してください。

Apex Centralの最新バージョンはいくつですか？

製品のバージョンはApex Central 2019で、2026年11月11日時点でダウンロードセンターに載っている最新の修正はCritical Patch Build 7328です（日本語版は2026年10月16日公開）。トレンドマイクロはPHPの件を直すCritical Patchを11月11日に提供予定としているため、適用の直前にダウンロードページで最新の番号を確かめてください。

CVE-2025-69258は実際に悪用されていますか？

2026年11月10日版のCISA KEVには載っておらず、トレンドマイクロのアドバイザリにも悪用の記載はありません。ただしTenableがPoCの使い方を公開しており、認証も不要なため、攻撃を試みる手間は小さい脆弱性です。Build 7190未満のサーバーは、PHPの件とあわせて最新のパッチへ上げてください。

SaaS版のApex Centralも対応が必要ですか？

1月のアドバイザリの対象表に載っているのはオンプレミス版だけです。PHPの件のKA-0024802でも、SaaS版のApex Centralは個別に挙がっておらず、Trend Vision Oneのプラットフォームは「Not Impacted」、Apex One as a Serviceは10月23日に対処済みとされています。SaaSでは利用者がパッチを当てる手順がないため、気になる場合はサポートに確認してください。

すぐにパッチを当てられない場合は何をすればよいですか？

管理コンソールとTCP 20001への接続を、管理対象のサーバー群と管理者の端末だけに絞ります。Windowsファイアウォールと経路上のファイアウォールの両方で制限すると確実です。あわせて管理サーバーから外部へのSMB通信を止めると、外部に置いたDLLを読ませる手口を使いにくくできます。どれも暫定策なので、適用日程を同時に決めてください。

関連記事

• Deep Security Agentの脆弱性CVE-2024-51503とは？後続CVE一覧と影響ビルドの確認・更新手順【2026年11月】
• パッチ管理とは：KEVで優先度を決め、Patch Managerとapt・dnfで自動適用する手順
• exploit（エクスプロイト）とは？意味とPoC・マルウェアとの違い、悪用状況の確認手順
• CVE（共通脆弱性識別子）とは？番号の読み方・CVSS/CWE/NVDとの違いと調べ方
• CTEMとは？脆弱性管理との違い・5つの段階と企業の導入判断を解説