Apex Oneにphp2shellの修正、Centralとの連携に注意

オンプレミスで動くApex Oneの管理サーバーも、ようやく修正パッチでPHPの脆弱性を閉じられるようになりました。トレンドマイクロは11月12日11時、Apex One 2019のクリティカルパッチ（CP、ビルド20113）と、Apex CentralのCP（ビルド7351）を公開しました。どちらにも、PHPの脆弱性php2shell（CVE-2026-109618、CVE-2026-109619）の修正が含まれます。

ただ、Apex Centralとつないでいる会社と、エージェントが多い会社は、当てる前に決めておくことがあります。連携が切れたときの手当てと、配信の量と順番です。

PHPの修正版から22日

PHPの開発チームは、10月21日に8.5.12などの修正版を出しました。米CISAは10月26日にこの2件をKEVに加え、米国の連邦機関に29日までの対応を求めました。Apex One as a Serviceは10月23日の臨時メンテナンスで先に直りましたが、オンプレミスの管理サーバーは、同社の暫定対応の手順でしのぐ日が続きました。

11月12日の国の情報ダイジェストを出した朝の時点では、CPは「11月中旬」の予定のままでした。その日の11時に出たわけです。PHPの修正版から数えて22日、KEVの期限からは14日あと。

製品に組み込まれたPHPは、OSの更新では直りません。正式なパッチで閉じられない期間が3週間あり、その間の頼りは、10月23日に載った暫定の手順でした。PHPのフォルダーを丸ごと入れ替える作業です。

暫定対応を済ませた会社には、うれしい知らせです。CPのお知らせによると、PHPのフォルダーを入れ替えた環境にもCPはそのまま当てられ、モジュールを戻す作業は要りません。当てられるのは、Apex One Service Pack 1（ビルド11092）以降のサーバーです。なお同社は、自社の製品やサービスでこの2件が悪用された例は、今のところ確認していないとしています。

Centralの証明書で登録していると、連携が切れる

CPのお知らせには、気になる特記事項が付きました。Apex OneのサーバーにCPを当てると、Apex Centralとの通信ができなくなる場合があるというのです。

同社のFAQで対象とされたのは、Apex Centralの証明書を使い、Apex OneのサーバーをApex Centralに登録している環境です。Apex Oneの管理コンソールで接続テストが失敗したり、Apex Centralの管理コンソールでApex Oneの最新の状況が見えなかったりします。原因はApex Centralが作る証明書とCPの互換性の問題で、修正はApex Centralの側で出す予定だそうです。

修正が出るまでの回避策は、短い手順で済みます。Apex CentralのWebサーバー証明書（WebServer_Cert.pem）を開き、Public-Key: (2048 bit)の記載があるかを見てから、Apex Oneのサーバーにコピーします。名前をTMCM_CA_Cert.pemに変えて置き換え、その前後でサービスを1つ止めて起動し直す。止めるのは、Apex One Apex Central Agent（OfficeScanCMAgent）だけです。

連携が切れたまま放っておくと、困るのは状況の表示だけではないかもしれません。登録の手引きによると、Apex Centralに登録したApex Oneのサーバーは自分の予約アップデートが止まり、Apex Centralが決めた配信計画でアップデートを受け取ります。FAQの例には出てきませんが、この構成ではパターンファイルの届き方にも響くおそれがあるとみています。CPを当てた日のうちに、接続テストまで済ませておきたいところです。

では、Apex Central側の修正を待ってから当てるべきでしょうか。管理サーバーの脆弱性はKEVに載った2件で、連携の問題には回避策があります。待つ理由は小さいと考えます。

エージェントへの配信は、64ビットで1台794MB

CPはサーバーだけでなく、エージェントも14.0.20113に上げます。インストールの手順によると、エージェントに配る量は64ビットで794MB、32ビットで395MBです。64ビットのPCが100台あれば、約79GBが社内を流れる計算になります。

もっとも、今回の脆弱性はサーバーの側のPHPにあります。同社の案内にも、クライアントサーバー構成の製品では、エージェントは原則として影響を受けないとあります。サーバーへの適用を急ぎ、エージェントへの配信を夜や週末に分けても、php2shellへの対策としては変わらないとみられます。ただ、上がっていないエージェントには、この先のPatchやCPを当てられません。段階配信の手順の案内も、古い版のエージェントはできるだけ短い期間で移すよう求めています。

気をつけたいのは順番です。エージェントを段階的に上げる同社の手順は、サーバーに当てる前の設定から始まります。管理コンソールでエージェントのプログラムのアップグレードを止めておき、サーバーを上げてから、選んだエージェントに配る流れです。サーバーに当てたあとで設定しても、配信が始まった端末には間に合わないでしょう。

サーバー側の作業は、同社の検証環境では30分ほどでしたが、環境によってはもっとかかるそうです。サーバーのOSの再起動は要りません。エージェントの再起動が要るかどうかは、管理コンソールの「再起動が必要」の欄に出ます。

日本語と英語の案内で、見込みが違う製品

修正がまだの製品では、日本語と英語の案内で見込みが合っていません。

Apex OneとApex Centralは、日本語も英語もそろいました。ずれているのはその下の2行です。Deep Discovery Analyzerの見込みは日本語が12日、英語が18日で、6日の開き。日本語の更新の履歴を見ると、この行は10月28日の更新から変わっていないようです。日本語の表に載っていないMobile Security for ENTも、英語の表では影響ありでした。

この2つを使う会社は、英語の案内も一緒に見ておくと、見込みのずれに早く気づけます。¹

SaaS版だけの会社は対象外

今回のCPの対象になるのは、オンプレミスのApex One（Apex One 2019）か、Apex Centralの管理サーバーを持つ会社です。Apex One（Mac）も、Apex Oneと同じ扱いになります。

Apex One as a Serviceと、Vision OneのStandard Endpoint Protectionは、10月23日に修正済みとされています。ウイルスバスター ビジネスセキュリティサービスは、影響なしの扱いです。一方、同じ表ではDeep Discovery InspectorやEmail Inspectorなども影響ありです。Web Security as a Serviceの認証エージェントやSafe Lock TXOne Editionも含め、修正の形は製品ごとに違います。脆弱性そのものの条件はSecPulseのCVE-2026-109618のページで、php2shellのこれまでの流れはphp2shellの1週間の図解でたどれます。

CPを当てる日の段取り

1. Apex Oneの管理コンソールの［ヘルプ］＞［バージョン情報］で、サーバーのビルドを見ます。Service Pack 1（ビルド11092）より前なら、先にService Packが要ります。
2. エージェントを段階的に上げるなら、CPの前に設定を変えます。［エージェント］＞［エージェント管理］でルートドメインを選び、［設定］＞［権限とその他の設定］を開きます。［その他の設定］で、エージェントがアップデートするコンポーネントを「パターンファイル」などに絞り、全エージェントに適用します。
3. スナップショットかサーバーのフルバックアップを取ります。Apex Oneの認証証明書のバックアップは、インストールの途中で確認が出ます。サーバーにエージェントが同居していれば、先にアンロードします。
4. CPを当て、［バージョン情報］のビルドが20113になったかを見ます。そのあと、ActiveUpdateサーバーからすべてのコンポーネントをアップデートします。
5. Apex Centralとつないでいれば、Apex Oneの［管理］＞［設定］＞［Apex Central］で接続テストをします。失敗したらFAQの回避策を使います。Apex Central自体にもCP（ビルド7351）を当てます。ただ、FAQは同じ日の時点で、Central側の修正を「予定」としています。

暫定対応で残したバックアップ（Apex OneのPHP_bak、Apex CentralのPHP_bakとzlibwapi.dll.bak）をいつ消すかは、確認した同社の案内には見当たりませんでした。CPを当てて動きを見届けてから、片づける日を決めれば足りるでしょう。