Shikata Ga Nai

Private? There is no such things.

週末前のチェックリスト(印刷用): PHPは悪用が確認された。Linuxカーネルと組み合わせて、rootまで取られる

防御 更新

何が起きたか

10月26日から28日に、CISAのKEVカタログ(悪用が確認された脆弱性の一覧)に、5つの製品が追加されました。いちばん大きいのは、10月21日に修正版が出たPHPの2件(CVE-2026-109618、109619)です。10月26日に、KEVに載りました。

PHPについて、確認できたことは、以下のとおりです。

  • IPAは、10月27日に、KEVへの登録を追記しました。国内での攻撃被害の事例は、把握していない、としています。
  • JPCERT/CCは、10月29日に、注意喚起を更新しました。悪用を試みる通信を観測した、という報告が、相次いでいます。あるファイアウォール製品の、特定のバージョンで、侵害が成功したことを示す痕跡が確認された、という報告もあります。製品名は、書かれていません。
  • 攻撃者は、PHPの2件と、Linuxカーネルの権限昇格の脆弱性を、組み合わせた攻撃を、作っているとされています。侵害した機器を足がかりに、内部のネットワークへ広げようとした形跡も、示されています。
  • KEVの10月28日の追加(Linuxカーネル、CVE-2026-46300)の説明に、PHPの2件と組み合わせて、PHPのWebシェルを置き、rootでコマンドを実行できる、と書かれています。

この週にKEVに追加された5つの製品は、以下のとおりです。「確認元」の「原文」は、メーカーや公的機関の案内を、直接読んだものです。

KEV追加日 製品(CVE) 案内の日付 確認元 案内の悪用の書き方
10月26日 PHP(CVE-2026-109618、109619) 10月21日 原文 JPCERT/CCは、悪用を試みる通信の報告が相次ぐ、としている
10月27日 Google Brotli(CVE-2026-111497) 10月21日(Google)、10月26日(JPCERT/CC) 原文(JPCERT/CC) 記載なし
10月27日 Adobe Commerce、Magento(CVE-2026-48356) 7月14日(8月11日更新) 原文 Adobeは、悪用を把握していない、としている
10月28日 VMware ESX(CVE-2026-41709) 7月29日(8月19日更新) 原文 悪意のある管理者が、悪用できる、という書き方
10月28日 Linuxカーネル(CVE-2026-46300) 未確認 KEVのみ KEVが、PHPの2件との組み合わせを書いている

KEVの追加日は、案内の日付と、同じではありません。Adobe Commerceは、約3か月半前に、案内が出ています。

この記事の材料は、10月29日までの情報です。その後の続報は、確認できていません。

自社に関係あるか

製品ごとに、「使っている / 使っていない / 分からない」を決めます。「分からない」は、使っている前提で進めます。

この記事の見方です。PHPと、Linuxカーネルを、先に確認するのが、よいと考えます。PHPは、KEVに載り、JPCERT/CCが攻撃の試みの報告を書いています。この2つは、組み合わせた攻撃が、KEVとJPCERT/CCに、書かれています。この順番は、記事の判断です。ほかの製品も、使っていれば、確認します。

使っている製品の、対象と修正版は、以下のとおりです。

製品 対象 修正版・対応
PHP 8.5.12、8.4.27、8.3.36、8.2.35より前。8.1以前は、更新が出ない 8.5.12、8.4.27、8.3.36、8.2.35。8.1以前は、サポート中の版へ移行
Google Brotli v1.2.0から1.2.1より前、v1.1.0から1.1.1より前、v1.0.3から1.0.10より前 v1.2.1、v1.1.1、v1.0.10。Node.js、Bun、PythonのBrotliパッケージなども、対象
Adobe Commerce、Magento Adobe Commerce 2.4.9、2.4.8-p5以前など(Adobeのページを確認) 2.4.9-2026-jul、2.4.8-2026-jul、2.4.7-2026-jul、2.4.6-2026-jul、2.4.5-2026-jul、2.4.4-2026-jul
VMware ESX 9.1.x、9.0.x、8.0など 9.1.x: ESXi-9.1.0.0-25370933、9.0.x: ESXi-9.0.2.0100-25595025、8.0: ESXi80U3j-25429389
Linuxカーネル 確認できていません ディストリビューションごとに違う。提供元の案内で確認

補足です。

  • PHP: 設定による緩和策は、攻撃の経路を減らすだけで、完全ではありません。更新だけが、対策です(JPCERT/CC)。
  • Brotli: JPCERT/CC(原文の要点)は、回避策はない、と書いています。
  • PHPとBrotli(Windows向けPHP): PHP公式は、10月26日に、Windows向けのPHPを、Brotli 1.2.1を含む形に更新しました。
    • 更新版は、8.5.12-1、8.4.27-1、8.3.36-1、8.2.35-1です。
    • 影響する条件は、cURL拡張の、HTTPレスポンスの自動展開が有効なときです(既定では、無効)。
    • PHPのバージョン番号は、変わりません。パッケージの表記(「-1」)で、確認します。
    • WindowsでPHPを使っている場合は、運用している会社に、更新版を適用したかを、確認します。
    • ほかのBrotliを組み込んだ製品は、各開発者の最新の案内で、確認します。
  • Adobe Commerce: 深刻度は、Critical(CVSS 3.1で9.6)で、認証なしで悪用できる、と書かれています。Adobeのページには、悪用を把握していない、という記載が、確認した版にあります。KEVには、載っています。
  • VMware ESX: 深刻度は、Low(CVSS 2.7)です。悪意のある管理者が、いくつかの操作を、ログに残さずに行える、という内容です。回避策は、ありません。ESX 7.0は、この件の表に、載っていません。
  • Linuxカーネル: 修正版の番号は、確認できていません。使っているLinuxの提供元(ディストリビューション)の、案内を確認します。

5分でできるチェック

使っている製品の行だけ、確認してください。「はい」が望ましい質問です。

  • 5つの製品に、「使っている / 使っていない / 分からない」の印を付けましたか(はい / いいえ)
  • PHPで動くWebサイトやシステムを、自社か委託先が、運用していますか(運用している / していない / 分からない)
  • 運用しているPHPは、修正版以降(8.5.12、8.4.27、8.3.36、8.2.35)ですか(はい / いいえ / 分からない)。PHP 8.1以前を使っていないことも、確認してください
  • そのサーバーのLinuxは、提供元の、最新の更新を、適用済みですか(はい / いいえ / 分からない)
  • 使っているAdobe Commerce、Magento、VMware ESXは、上の表の修正版以降ですか(はい / いいえ / 分からない / 使っていない)
  • Brotliを組み込んだ製品(Node.jsを使ったシステムなど)を、使っているかを、開発した会社に確認しましたか(はい / いいえ)

「いいえ」と「分からない」は、下の作業の対象です。

今日やること

  1. 5つの製品に、印を付ける。分からないものは、担当者か委託先に聞く。
  2. PHPとLinuxを、先に進める。PHPで動くものを、書き出し、運用している会社に、バージョンと、更新の状況を、確認する。
  3. 更新などの変更の前に、ログを保管してもらう。攻撃を受けた形跡が、あとで、見つけにくくなるためです。形跡が見つかったときは、自分で消さず、専門の業者に切り替える。
  4. 変更の前に、サイトとデータの、バックアップと、元に戻す手段を確認する。作業の時間と、サイトが止まる影響を、業者と決める。確認できないときは、更新を進めず、業者に切り替える。
  5. 更新し、更新後のバージョンを、確かめる。PHPと、Linuxの両方を、確かめる。サイトが、ふだんどおり動くことも、確認する。
  6. 使っているほかの製品(Brotli、Adobe Commerce、Magento、VMware ESX)も、同じ順番で、進める。質問は、下の2つ目の文面を使えます。
  7. 製品ごとに、修正版より前を、影響を受ける条件で使っていた場合、または、条件を確認できない場合は、侵害の確認の要否を、提供元か、管理者に確認する。製品ごとの条件は、以下のとおりです。
    • PHP: 遠隔から攻撃されるので、インターネットに公開して使っていたかが、条件の1つです。JPCERT/CC(原文の要点)が挙げる、次の点を、見てもらいます。
      • 異常に長い、または、形のおかしいPHPSESSIDのCookieが、返されていないか。
      • 不審なmultipart/form-data形式のリクエストが、ないか。その前後に、PHPのメモリの上限のエラーや、HTTPの500エラーが、出ていないか。
      • PHPのワーカーのプロセスが、予期せず止まったり、何度も再起動したりしていないか。
    • Brotli: 細工された圧縮データを展開する処理が、あったかが条件です(JPCERT/CC)。インターネットに公開していないだけでは、対象から外せません。
    • VMware ESX: 悪意のある管理者が悪用する内容です。管理者の権限を持つ人と、ログの記録を、確認します。この脆弱性は、一部の操作をログに残さずに行える、という内容なので、ログに異常がないだけでは、悪用を否定できません。影響を受ける版を使っていたときは、提供元か専門の業者に、調査の要否と方法を、確認し、必要な調査の実施と、結果の受領まで、進めます。
    • Linuxカーネル: 権限昇格の脆弱性です。別の脆弱性(PHPなど)で、入られたあとに、使われるおそれがあるので、インターネットに公開していないだけでは、対象から外せません。PHPなどの形跡と、あわせて確認します。

痕跡が見つからなくても、攻撃を受けていない、とは断定できません。

業者に送る文面は、以下のとおりです。1つ目は、PHPとLinuxの文面です。

PHPとLinuxの脆弱性について、教えてください。

  1. 当社のサイトやシステムで、PHPを使っていますか。バージョンと、動かすサーバーのLinuxの提供元(ディストリビューション)を教えてください。

  2. PHPが、8.5.12、8.4.27、8.3.36、8.2.35以降(または、使っているディストリビューションの、修正済みのパッケージ)に、更新済みか教えてください。未更新なら、更新の予定日と、作業中の業務への影響を教えてください。

  3. Linuxのカーネルは、提供元の、最新の更新を、適用済みですか。CVE-2026-46300の、修正済みか教えてください。

  4. WindowsでPHPを使っている場合は、Brotliを含む、更新版(8.5.12-1など)を、適用済みか教えてください。

  5. PHP 8.1以前を使っている場合は、サポート中のバージョンへ移す計画と、その日までの対策を教えてください。

  6. PHPについて、修正版より前を、インターネットに公開して使っていた期間に、攻撃を受けた形跡がないかを、調べるか教えてください。調べるなら、実施者、実施日、結果をもらえる日を教えてください。

  7. Linuxについて、PHPなどの形跡とあわせて、調べるか教えてください。調べるなら、実施者、実施日、結果をもらえる日を教えてください。

Brotli、Adobe Commerce、Magento、VMware ESXの文面は、以下のとおりです。

次の製品について、教えてください。(製品: Brotliを組み込んだ製品、Adobe Commerce、Magento、VMware ESXのうち、該当するもの)

  1. 当社の環境(委託先のツールも含む)で、使っていますか。

  2. 使っている場合は、バージョンと、今回のCVE(CVE-2026-111497、CVE-2026-48356、CVE-2026-41709)の対象かを教えてください。

  3. 対象の場合は、修正版への更新の状況を教えてください。未更新なら、更新の予定日と、作業中の業務への影響を教えてください。

  4. 更新のあとに、バージョンを確認した結果を教えてください。

  5. 対象のバージョンを使っていた期間に、侵害の確認が必要かどうかと、必要なときの実施者、実施日、結果をもらえる日を教えてください。

「依頼した」「緩和策を入れた」は、完了ではありません。次の3つがそろったら、完了です。

  • 5つの製品すべてが、次のどれかになっている。確認できていないものは、完了ではありません。
    • 使っていない。
    • 使っているが、メーカーの案内で、対象のバージョンではない、または、対象の条件を満たさないと確認できた。
    • 修正版以降と確認できた。WindowsでPHPを使っている場合は、cURL拡張の自動展開が無効だと確認できた、または、更新版(8.5.12-1など)を適用し、パッケージを確認した。
    • 更新し、更新後のバージョンを確かめた。WindowsでPHPを使っている場合は、同じ確認を、あわせて行った。
    • PHP 8.1以前だったので、サポート中のバージョンへの移行を終えた。または、公開を止めた。修正済みのパッケージを入れただけ、緩和策を入れただけ、移行の計画だけの段階は、当面の対策で、完了ではありません。
  • 製品ごとに、修正版より前を、影響を受ける条件で使っていた場合、または、条件を確認できない場合は、侵害の確認の要否が確認され、必要なら確認が実施され、結果を受け取っている。
  • 形跡が見つかったときは、専門の業者による調査が実施され、結果を受け取り、見つかった問題の是正まで済んでいる。

自社で対応が難しい場合

次のどれかに当たるときは、サイトを作った会社、保守の業者、専門の業者に切り替えてください。

  • PHPやLinuxの、バージョンや提供元が、分からない
  • サーバーに入れない、バックアップと元に戻す手段を、確認できない
  • 更新で、サイトが動かなくなりそう、または、PHP 8.1以前で、移行の方法が分からない
  • 上の「攻撃を受けた形跡」に当たるものが、見つかった。インシデントとして扱い、ログなどの証拠を保全したうえで、専門の業者に、詳しい調査を頼んでください

出典

「社内限定・閉域網だから安全」とは言えない。病院2件の事例

防御 リモート接続

何が起きたか

「うちのシステムは、社内限定だから大丈夫」と説明されることがあります。国内の病院2件では、外部と切り離されていると思われていたシステムが、保守のために外とつなげていたVPN機器から入られ、診療が2〜3か月、制限されました。2021年と2022年の事例です。警察庁の2025年上半期の報告でも、VPNやリモートデスクトップ用の機器は、ランサムウェアの主な侵入経路です。

以下は、病院が公開した調査報告書に基づきます。

つるぎ町立半田病院(2021年10月)

  • 2021年10月31日の未明に、病院内のプリンターが、一斉に犯行声明を印字し始めて、発覚しました。ランサムウェア(LockBit 2.0)に感染し、電子カルテなどが使えなくなりました。一時は、救急と新規の患者の受け入れを止め、手術も、できるだけ延期しました。通常診療に戻ったのは、2022年1月4日です。
  • 侵入口は、電子カルテなどの保守のために接続していた、VPN装置(Fortinet製)の脆弱性とみられています。報告書は、「極めて高い」「可能性が高い」と書いています。その装置は、導入のときから更新されず、2018年に見つかった脆弱性(CVE-2018-13379)が、残っていました。報告書によると、Fortinetは、2019年から2021年6月までに、4度、注意喚起を行っています。
  • 報告書は、VPN装置の管理者の資格情報が、ダークウェブで公開されていた事実も、挙げています。
  • 病院の中の設定も、弱いものでした。
    • パスワードの最小の桁数が、5桁だった。
    • ログインに失敗しても、一定時間ログインを制限する設定(ロックアウト)が、なかった。
    • 管理者のIDが、初期のままだった。
    • 一般のユーザーも、管理者のグループに入っていた。
    • ウイルス対策ソフトは、導入していたが、電子カルテの導入のときの不具合で、動かしていなかった。
  • 被害や影響を受けた端末は、40台です。2018年までにオフラインで保管していたバックアップは、無事で、復旧に使えました。
  • 事案のあと、VPN装置の更新や端末の初期化が、ログを保存しないまま行われたので、侵入経路は、ログでは確定できていません。
  • 報告書は、閉域網なら安全、という思い込み(安全神話)が、対策を止めていたと、書いています。閉域網も、ソフトウェアのサプライチェーンに対しては開かれていて、間接的にインターネットとつながっている、とも書いています。

大阪急性期・総合医療センター(2022年10月)

  • 2022年10月31日に、電子カルテを含む基幹システムのサーバーの大部分が、ランサムウェアで暗号化されました。院内の端末(約2,200台)にも、不正アクセスの痕跡があり、すべてのサーバーと端末を、クリーンインストールしました。基幹システムの再稼働に43日、部門システムを含む診療システム全体の復旧に73日、かかっています。
  • 診療も制限されました。2022年11月の新入院患者数は、前年の同じ月の33.3%、初診患者数は17.9%でした。被害額は、概要の時点で、精査中です。調査と復旧の費用が数億円以上、診療制限による逸失利益が十数億円以上と、見込まれています。
  • 侵入は、病院ではなく、給食の事業者から始まっています。
    • 給食事業者の給食システムに、構築した事業者が、リモートの保守のために置いたVPN機器があり、それが侵入口になりました。脆弱性の悪用か、漏えいして公開されたIDとパスワードの使用が、考えられています(概要)。
    • 次に、給食事業者の端末から盗まれた、病院のサーバーの認証情報で、病院の給食サーバーに、リモートデスクトップで入られました。
    • 病院の給食サーバーと、ほかのサーバーは、IDとパスワードが共通で、盗むのは容易でした。そこから、電子カルテなどの基幹システムに、広がっています。
  • 報告書は、原因を、次のように挙げています。
    • VPN機器やファイアウォールなど、外部の通信機器の保守と脆弱性の管理の役割分担が、あいまいだった。
    • リモート保守が、常時の接続で、許可の基準が、あいまいだった。許可したあとの、利用状況も、確認していなかった。
    • 内部のセキュリティの面では、ユーザーすべてに管理者権限が与えられていた。Windowsのパスワードが、サーバーと端末で、すべて共通だった。ロックアウトの設定がなかった。

2件から分かること

  • 入口は、保守用のVPNでした。「閉域網」と呼ばれていたシステムの、外とのつなぎ目です。
  • 入口となる機器や接続の管理に、問題がありました。半田は、導入のときから更新されず、脆弱性が放置されていました。大阪は、保守と脆弱性管理の役割分担が、あいまいでした。
  • 入られたあとを止める仕組みが、弱いものでした。共通のパスワードと、管理者の権限は、2件に共通します。短いパスワードは、半田で確認されています。
  • 入口の管理には、外部の事業者も関わります。大阪では、給食の事業者側のVPN機器が、侵入口になりました。半田では、事業者が、VPN装置の構築と保守に、関わっていました。
  • 復旧に、2〜3か月かかりました。バックアップがあっても、すぐには戻りませんでした。

警察庁の、令和7年上半期の報告(2025年9月)は、ランサムウェアの被害を受けた企業と団体へのアンケートで、VPNやリモートデスクトップ用の機器からの侵入が、感染経路の8割以上を占めている、としています。原因として、機器のIDやパスワードが、非常に安易だったこと、不必要なアカウントが、適切に管理されずに存在していたこと、を挙げています。

IPAの「情報セキュリティ10大脅威 2026」(組織向け、2026年1月公開)は、1位がランサム攻撃による被害、2位がサプライチェーンや委託先を狙った攻撃、4位がシステムの脆弱性を悪用した攻撃です。

この記事の材料は、公開済みの報告書と統計です。半田の侵入経路は、ログが残っていないため、推定です。大阪の報告書は、概要を読み、本文は読んでいません。警察庁の統計の、件数と割合の数字は、図なので、読めていません。

自社に関係あるか

「社内限定」「閉域網」「外からはつながらない」と説明されているシステムがある会社が、対象です。まず、次のどれに当たるかを決めてください。

  • 外とつながる口が、ないと、確認できている: 確認した人と、日を、記録します。委託先の保守の接続も、含みます。
  • 保守のために、VPNやリモートデスクトップなど、外とつながる口がある: 下の確認に進みます。
  • 分からない: 口がある前提で、「今日やること」の1番から進めます。システムを入れた会社や、保守の会社に、聞いてください。

5分でできるチェック

「はい」が望ましい質問です。

  • 外とつながる口(保守用のVPN、リモートデスクトップ、委託先の接続)を、すべて書き出していますか(はい / いいえ)
  • それぞれの機器について、更新を、誰が行うかが、決まっていますか(はい / いいえ)
  • 直近の更新の日を、答えられますか(はい / いいえ)
  • 保守の会社や委託先の接続は、必要なときだけですか(はい / いいえ / 常時つながっている)
  • 接続のログを、見ていますか(はい / いいえ)
  • 管理者の権限を持つ人が、必要な人だけに、絞られていますか(はい / いいえ / 分からない)
  • パスワードが、サーバーや端末ごとに、別になっていますか。ログインに失敗したときの、ロックアウトの設定が、ありますか(はい / いいえ / 分からない)
  • オフラインのバックアップが、ありますか。復元を、試したことがありますか(はい / いいえ)
  • 侵入されたときの手順(ログを保存してから、機器を更新する、など)が、ありますか(はい / いいえ)

「いいえ」と「分からない」は、下の作業の対象です。

今日やること

  1. 外とつながる口を、すべて、書き出す。保守用のVPN、リモートデスクトップ、委託先の接続を、含みます。口ごとに、使っている会社と、機器の名前を、書きます。分からないものは、「不明」と書き、確認する人と期限を、決めます。
  2. 口ごとに、更新を行う人と、直近の更新の日を、確認する。担当が決まっていない口は、担当を決める。
  3. 保守の会社や委託先の接続が、常時か、必要なときだけかを、確認する。常時のものは、必要なときだけにできるかを、保守の会社に聞く。接続のログを、誰が、いつ、見るかを決める。
  4. 管理者の権限、パスワード、ロックアウト、共通のIDの有無を、確認する。
    • 管理者の権限を持つ人が、必要な人だけに、絞られているか。
    • パスワードが、サーバーや端末ごとに、別になっているか。
    • ログインに失敗したときの、ロックアウトの設定が、あるか。
  5. オフラインのバックアップの有無と、復元を試した日を、確認する。
  6. 侵入されたときの手順を、決める。半田病院は、ログを保存しないまま、機器の更新と端末の初期化を行ったので、原因を確定できませんでした。機器を更新する前に、ログを保存する、という手順を、入れます。

保守の会社や、システムを入れた会社に聞くときの文面は、以下のとおりです。

当社のシステムの、外部との接続について、教えてください。

  1. 外とつながる口(保守用のVPN、リモートデスクトップ、委託先の接続など)を、すべて教えてください。

  2. それぞれの機器の更新は、誰が行いますか。直近の更新は、いつですか。

  3. 御社の保守の接続は、常時ですか、必要なときだけですか。

  4. 保守の接続のログは、保存していますか。

  5. 管理者の権限を持つ人は、誰ですか。

  6. パスワードの桁数は、何桁ですか。

  7. ログイン失敗時のロックアウトの設定は、ありますか。

  8. 共通のIDやパスワードを、使っていませんか。

  9. オフラインのバックアップは、ありますか。

  10. バックアップの復元を試した日は、いつですか。

  11. 侵入された場合の手順を、教えてください。

  12. 機器を更新する前に、ログを保存しますか。

個人データの漏えい等が発生した、または、発生したおそれがあり、次の4つの類型のどれかに当たるときは、個人情報保護委員会への報告が、必要になります。個人情報保護委員会のページに、挙げられている類型は、要配慮個人情報、財産的な被害のおそれがあるもの、不正の目的によるもの、1,000人を超えるもの、が挙げられています。報告の期限は、速報が、発覚から3〜5日以内が目安、確報が、30日以内(不正の目的が疑われる場合は60日以内)です。不正アクセスは、不正の目的の例に、挙げられています。

「口を書き出した」「依頼した」は、完了ではありません。今日の分は、次の4つがそろったら、完了です。

  • 外とつながる口の一覧ができ、各行に、使っている会社と機器の名前か、「不明」が書かれている。「不明」の行には、確認する人と期限が、書かれている。
  • 口ごとに、更新を行う人が決まり、直近の更新の日が、確認できている。
  • 保守の接続が、常時か、必要なときだけかが、確認できている。常時のものは、必要なときだけにできるかの、回答を受け取った。
  • 管理者の権限、パスワード、ロックアウト、オフラインのバックアップ、侵入されたときの手順の、確認が済んでいる。足りないものは、実施する人と日が、決まっている。

全体の完了は、見つかった足りない点が、実際に直った状態です。

自社で対応が難しい場合

次のどれかに当たるときは、システムを入れた会社や、保守の会社、専門の業者に切り替えてください。

  • 外とつながる口を、書き出せない、または、機器の名前が分からない
  • 保守の会社が、更新の担当や、接続のログについて、答えない
  • 管理者の権限や、パスワードの設定を、確認する権限が、ない
  • 上の確認で、見覚えのない接続、アカウント、設定が見つかった。インシデントとして扱い、ログなどの証拠を保全したうえで、専門の業者に、詳しい調査を頼んでください

出典

Q. PHPが古くて、更新するとサイトが動かなくなりそう。どうすればいい?

防御 更新

何が起きたか

Q. うちのサイトは、古いPHPで動いています。PHPの重大な脆弱性が出たと聞きましたが、更新すると、サイトが動かなくなりそうです。どうすればいいですか。

PHPの2件の脆弱性(CVE-2026-109618、109619)は、10月26日に、CISAのKEVカタログ(悪用が確認された脆弱性の一覧)に載りました。PHPの開発チームが、10月21日に、修正版を出しています。

PHP公式の勧告には、古いPHPについて、以下のことが書かれています。

  • 修正版は、PHP 8.5.12、8.4.27、8.3.36、8.2.35です。
  • PHP 8.1以前は、PHPの開発チームの更新が、もう出ません。
  • ディストリビューションや、長期サポート(LTS)の提供元が、修正を、古い版に移して、提供している場合があります。提供元に問い合わせるか、サポート中の版に移す、とされています。
  • 重大さを考えて、PHPの開発チームは、PHP 7.4、8.0、8.1向けに、最小限の修正のソースを、公開しています。自分でビルドする人や、LTSの提供元が、使えない人のためです。
  • 完全な緩和策は、ありません。以下の設定は、攻撃の経路を減らすだけで、サーバーを安全にはしません。

JPCERT/CCは、10月29日の更新で、悪用を試みる通信の報告が、相次いでいる、と書いています。あるファイアウォール製品の、特定のバージョンで、侵害が成功した痕跡が、確認された、という報告もあります。IPAは、更新や移行が終わるまで、脆弱な状態を、放置しないよう、案内しています。

この記事の材料は、10月29日までの情報です。ディストリビューションごとの対応は、確認できていません。その後の続報は、確認できていません。

自社に関係あるか

まず、次のどれに当たるかを決めてください。

  • PHPで動くものを、使っていない: この記事の作業は要りません。制作会社や、ホスティングの提供元に、確認できた場合に限ります。
  • PHP 8.2から8.5を使っている: 更新が、できます。金曜の記事の手順で、進めます。
  • PHP 8.1以前を使っている: 下の確認に進みます。
  • 分からない: 8.1以前を使っている前提で、「今日やること」の1番から進めます。サイトを作った会社や、保守の業者に、聞いてください。

5分でできるチェック

「はい」が望ましい質問です。

  • PHPのバージョンを、運用している会社に、確認してもらいましたか(はい / いいえ)
  • 8.2から8.5のどれかで、修正版以降だと、確認できていますか(はい / いいえ / 分からない)
  • 8.1以前のとき、サポート中の版に移す計画(担当者、日)が、ありますか(はい / いいえ / 8.1以前ではない)
  • 8.1以前のとき、使っているLinuxの提供元が、修正を提供しているかを、確認しましたか(はい / いいえ / 8.1以前ではない)
  • 8.1以前のとき、移行が終わるまでの対策(設定の変更、外からのアクセスの制限など)を、決めましたか(はい / いいえ / 8.1以前ではない)

「いいえ」と「分からない」は、下の作業の対象です。

今日やること

  1. PHPのバージョンを、運用している会社に、確認する。8.1以前なら、2番へ。8.2から8.5なら、修正版以降かを、確認します。
  2. 更新できない理由を、運用している会社と、整理する。たとえば、古いプログラムが、新しいPHPで動かない、などです。理由が分かれば、移行にかかる作業と、期間が、見えます。
  3. 使っているLinuxの提供元(ディストリビューション)が、PHPの修正を、提供しているかを、運用している会社に、確認する。提供している場合も、これは、当面の対策です。移行か、公開停止が、完了の条件です。この扱いは、この記事の判断です。
  4. 移行までの間の対策を、運用している会社と決める。
    • 外部からのアクセスの遮断や、サービスの一時停止を、業務への影響を見て、検討する(IPAの案内)。
    • 設定による緩和策を、PHP公式の案内で、確認して、運用している会社に、判断してもらう。たとえば、session.upload_progress.enabled=0(使っていなければ)や、post_max_size を小さくする設定が、あります。設定を変えると、サイトが動かなくなることもあります。変更は、運用している会社が、判断します。
    • 緩和策は、完全ではありません。
  5. 移行の計画を、立てる。担当者、日、必要な作業(プログラムの修正の有無)を、決めます。維持管理の体制や、予算を、確保できないときは、サイトの公開を終える、という判断も、IPAは、選択肢に挙げています。
  6. 変更の前に、攻撃を受けた形跡の確認と、証拠の保全を、先に行う必要があるかを、運用している会社か、専門の業者に確認する。必要と言われたときは、その指示に従ってから、次に進みます。
    • JPCERT/CC(原文の要点)は、異常に長いPHPSESSIDのCookie、不審なmultipart/form-dataのリクエストと、その前後のメモリのエラーやHTTP 500、PHPのワーカーの異常終了を、見るよう案内しています。
    • 痕跡がなくても、攻撃を受けていない、とは断定できません。
    • 痕跡が見つかったときは、自分で消さず、専門の業者に切り替えます。
  7. 変更の前に、サイトとデータの、バックアップと、元に戻す手段を確認する。確認できないときは、変更を進めず、業者に切り替える。
  8. 移行までの間の対策を、実施し、確認する。設定による緩和策を入れたときは、設定が効いていること(ワーカーの再起動のあとも、設定が残っていること)と、サイトが動くことを、確認する。外部からのアクセスの遮断や、サービスの一時停止を選んだときは、外から開けないことを、確認する。
  9. 移行か公開停止を、実施し、確認する。移行したときは、移行後のPHPのバージョンと、サイトの動作を、確認する。公開を止めたときは、外から開けないことを、確認する。

運用している会社に送る文面は、以下のとおりです。

PHPのバージョンについて、教えてください。

  1. 当社のサイトやシステムで使っているPHPの、バージョンを教えてください。

  2. 8.1以前の場合は、更新できない理由を教えてください。サポート中のバージョンへ移す、作業の内容、実施する人、実施日、移行後に、何を確認するかを教えてください。

  3. 使っているLinuxの提供元は、CVE-2026-109618と109619の修正を、提供していますか。当社は、適用済みですか。

  4. 移行までの間の対策を、教えてください。外部からのアクセスの制限や、設定による緩和策の、可否と、実施する人、実施日、実施後に、何を確認するかを教えてください。

  5. 攻撃を受けた形跡がないかを、調べるかを教えてください。調べるなら、実施者、実施日、結果をもらえる日を教えてください。

「移行の計画を立てた」「緩和策を入れた」は、完了ではありません。次の3つがそろったら、完了です。

  • 次のどれかに当たる。
    • PHPで動くものを、使っていないと確認できた。
    • PHP 8.2から8.5で、修正版以降と確認でき、更新したときは、更新後のバージョンを確かめた。
    • PHP 8.1以前を使っていたので、サポート中のバージョンへの移行を終えた。または、公開を止めた。修正済みのパッケージを入れただけ、緩和策を入れただけ、移行の計画だけの段階は、当面の対策で、完了ではありません。
  • 脆弱な版を、インターネットに公開して使っていた場合は、攻撃を受けた形跡の確認の要否が確認され、必要なら確認が実施され、結果を受け取っている。
  • 形跡が見つかったときは、専門の業者による調査が実施され、結果を受け取り、見つかった問題の是正まで済んでいる。

自社で対応が難しい場合

次のどれかに当たるときは、サイトを作った会社、保守の業者、専門の業者に切り替えてください。

  • PHPのバージョンや、更新できない理由が、分からない
  • サーバーに入れない、バックアップと元に戻す手段を、確認できない
  • 移行の方法が、分からない、または、移行の予算を、確保できない。サイトを終える判断も、含めて、相談する
  • 上の「攻撃を受けた形跡」に当たるものが、見つかった。インシデントとして扱い、ログなどの証拠を保全したうえで、専門の業者に、詳しい調査を頼んでください

出典

業務で使わない管理画面は、インターネットに公開しない。JPCERT/CCの注意喚起の対策から

防御 リモート接続

何が起きたか

JPCERT/CCは、国内で相次いでいる不正アクセスについて、10月8日に注意喚起を出し、10月23日に更新しました。注意喚起の「汎用的な対策」には、次のものがあります(原文の要点)。

  • 業務上不要なサービスや機能(管理機能など)が、インターネットに公開されているときは、公開を停止する。
  • 利用する地域が限られるサービスでは、アクセス元の地域を制限する。
  • 既知の脆弱性の影響を受けるバージョンを使っているときは、修正済みのアップデートを適用する。

IPAの注意喚起(10月9日)にも、外部に公開するアプリケーションの対策として、「外部への公開範囲を見直す」「認証機能(多要素認証、パスワード)を強化する」が、挙げられています。

IPAの「5分でできる!情報セキュリティ自社診断」の項目18は、外部から内部ネットワークへの、不要な通信を遮断することを求めています。対策例は、ファイアウォールの機能が有効か、機器のファームウェアが最新か、機器の出荷時のパスワードを変更したか、の3つです。

注意喚起は、特定の製品の脆弱性を狙った攻撃とは、断定していません。管理画面の公開が、国内の被害の原因だったとも、書いていません。この記事は、注意喚起が挙げる対策のうち、「不要な管理機能の公開を止める」を、公開しているWebサイトの管理画面に当てはめたものです。当てはめの部分は、記事の提案です。

この記事の材料は、10月23日までの情報です。

自社に関係あるか

自社のWebサイトや、会員向けのシステム、ネットショップなどを、インターネットに公開している会社が、対象です。委託先に運用を任せている場合も、同じです。まず、次のどれに当たるかを決めてください。

  • Webサイトなどを、公開していない: この記事の作業は要りません。
  • 公開している: 下の確認に進みます。
  • 分からない: 公開している前提で、「今日やること」の1番から進めます。Webサイトを作った会社や、運用している会社に、聞いてください。

5分でできるチェック

「はい」が望ましい質問です。

  • 公開しているWebサイトなどの、管理画面のURLを、把握していますか(はい / いいえ)
  • 管理画面を、インターネットのどこからでも開ける状態か、運用している会社に確認しましたか(はい / いいえ)
  • 管理画面を開ける場所を、会社の回線など、必要な場所に、限っていますか(はい / いいえ / 分からない)
  • 管理画面のアカウントの一覧があり、使っていない人がいないと確認できていますか(はい / いいえ)
  • 管理画面のアカウントに、多要素認証を、有効にしていますか(はい / いいえ / 分からない)

「いいえ」と「分からない」は、下の作業の対象です。

今日やること

  1. 管理画面のURLを、集める。運用している会社との資料や、ブックマークを見ます。分からないものは、「不明」と書き、運用している会社に聞きます。
  2. 自社の管理画面のログイン画面が、外から開くかを、見る。スマホのWi-Fiを切り、モバイル回線で、集めたURLを開きます。ログイン画面が出るかだけを、見ます。ログインや、入力は、しません。この確認の方法は、記事の提案です。自社の管理画面に限ります。

  3. 画面が出たとき、または分からないときは、運用している会社に、次の質問を送る。

    公開しているWebサイトの管理画面について、教えてください。

    1. 管理画面は、インターネットのどこからでも、開ける状態ですか。

    2. 開ける場所を、会社の回線など、必要な場所だけに、限れますか。

    3. 管理画面のアカウントで、多要素認証は、有効ですか。有効にできますか。

    4. 設定を変えたあとに、当社が、管理画面に入れなくなるおそれは、ありますか。入れなくなったときの、戻し方を教えてください。

    5. 管理画面のアカウントの一覧(誰が、何のために持っているか)を、ください。使っていない人、見覚えのない人、無効にしたはずなのに有効になっている人が、いないかも教えてください。

    6. 作業の日、作業中に、Webサイトに出る影響、費用を教えてください。

  4. 変更の前に、作業の日時と、変更後も入れる場所(会社の回線など)を、運用している会社と決める。入れなくなったときの戻し方も、確認する。確認できないときは、変更を進めず、運用している会社に切り替える。

  5. 管理画面ごとに、次のどれかを、実施する。業務で使っていないときは、止めてよいかを、先に、運用している会社に確認する。
    • 公開を止める。
    • 開ける場所を、必要な場所に限る。
    • 限れない事情があるときは、代わりの対策(多要素認証など)を、実施する。
  6. 実施のあと、確認する。
    • 公開を止めたときは、モバイル回線で、URLを開き、ログイン画面が出ないことを確かめる。
    • 開ける場所を限ったときは、モバイル回線からは開けず、許可した会社の回線からは、入れることを確かめる。
    • 代わりの対策を選んだときは、それが実際に働くこと(ログインのときに、追加の確認が求められること)を、確かめる。
  7. アカウントの一覧を、確認する。
    • 退職や異動で、理由が分かる、使わなくなったアカウントは、停止か削除をして、状態を確認する。
    • 作成した覚えのないアカウントや、無効にしたはずなのに有効になっているアカウントが見つかったときは、自分で消さず、記録を残して、運用している会社か専門の業者に連絡する。

「質問を送った」「依頼した」は、完了ではありません。次の3つがそろったら、完了です。

  • 管理画面のURLの一覧ができ、各行に、運用している会社か、「不明」が書かれている。「不明」の行には、確認する人と期限が、書かれている。
  • 一覧のすべての管理画面で、次のどれかを、確認した。
    • 業務で使っていないので、公開を止めた。外から開けないことを、確かめた。
    • 開ける場所を、必要な場所に限った。変更後に、モバイル回線からは開けず、許可した会社の回線からは入れることを、確かめた。
    • 限れない事情があるので、代わりの対策(多要素認証など)を、実施し、実際に働くことを、確かめた。決めただけの段階は、完了ではありません。
  • 管理画面のアカウントの一覧を、確認した。
    • 理由が分かる、使わなくなったアカウントは、停止か削除をして、確認した。
    • 作成した覚えのないアカウントや、無効にしたはずなのに有効になっているアカウントが、見つかったときは、専門の業者による調査が実施され、結果を受け取り、見つかった問題の是正まで済んでいる。

自社で対応が難しい場合

次のどれかに当たるときは、運用している会社や、専門の業者に切り替えてください。

  • 管理画面のURLが分からない、運用している会社が分からない
  • 管理画面を開ける場所を、限れない、または、限ると、運用に困る
  • 設定を変えて、入れなくなったときの、戻し方が確認できない
  • 見覚えのないアカウント、ログの記録、ファイルが見つかった。インシデントとして扱い、ログなどの証拠を保全したうえで、専門の業者に、詳しい調査を頼んでください

出典

公開しているスマホアプリの中身から、APIを特定して攻撃する手口。JPCERT/CCの調査から

防御 手口

何が起きたか

JPCERT/CCは、10月15日に、国内で相次いでいる不正アクセスについて、攻撃に使われたインフラの調査結果を公開しました。10月8日の注意喚起(10月23日に更新)に続くものです。

調査記事には、次のことが書かれています(要旨)。

  • 調査の過程で、攻撃者がAIを使って、既知の脆弱性のスキャンや、API経由の攻撃を行っていたことが、確認されました。
  • 攻撃元のサーバーは、複数、確認されています。日本以外の地域向けのWebサービスも、狙われていました。
  • 確認された手口の1つは、スマホアプリ(Androidの配布ファイル)を解析して、そこで使われているAPIを特定し、SSRFなどの脆弱性が、ないかを調べる、というものです。攻撃元のサーバーに、アプリを解析するツールや、解析したファイルが、置かれていました。
  • 別のサーバーでは、MySQL、Jenkins、メールゲートウェイなどを狙う、さまざまな手法の痕跡と、標的のネットワーク内に置いたとみられるWebシェルが、確認されています。内部への侵入を試みていたと考えられる、とされています。

調査記事で確認された、1つ目の手口の流れは、次の3つです。

  1. 攻撃者が、公開されているスマホアプリのファイルを入手し、解析ツールで、中身を調べる。
  2. アプリの中から、アプリが使っているAPIを、特定する。
  3. 特定したAPIに、SSRFなど、脆弱性がないかを、調べる。

次の2点は、この流れの続きではなく、別の情報です。

  • JPCERT/CCの注意喚起(AT-2026-0030)には、別の事例として、管理用のAPIへの不正なリクエストで、情報が不正に書き換えられた、という確認があります。
  • 調査記事では、今回の攻撃と、直接関係しないとされた別のサーバーで、内部のネットワークへの侵入を試みたと考えられる痕跡(Webシェルなど)が、確認されています。

調査記事は、「被害を受けた組織に共通する点」を、明確には述べていません。国内で情報漏えいを公表した組織が、この手口で攻撃されたかは、記事から、分かりません。

この記事の材料は、10月23日までの情報です。調査記事の補足(Flutterアプリの解析)と、IPアドレスなどの技術的な詳細は、記事に書いていません。その後の続報は、確認できていません。

自社に関係あるか

スマホアプリや、Webのサービスを、自社で公開しているか、委託先に作って運用してもらっている会社が、関係します。まず、次のどれに当たるかを決めてください。

  • スマホアプリも、WebのAPIも、公開していない: この記事の作業は要りません。ただし、自社のWebサイトや、会員向けのシステムの裏側で、APIが使われていることがあります。制作会社に、確認できた場合に限ります。
  • スマホアプリか、WebのAPIを、公開している(自社、または、委託先が運用): 下の確認に進みます。
  • 分からない: 公開している前提で、「今日やること」の1番から進めます。Webサイトやアプリを作った会社に、聞いてください。

5分でできるチェック

「はい」が望ましい質問です。

  • 公開しているスマホアプリと、WebのAPI(会員向けのサイトの裏側を含む)を、書き出していますか(はい / いいえ)
  • それぞれに、開発した会社と、運用している会社が、分かりますか(はい / いいえ)
  • アプリの中に、秘密鍵や、長く使える認証の情報を、入れていないと、開発した会社に確認できていますか(はい / いいえ / 分からない)
  • APIは、サーバーの側で、利用者の確認と、操作の許可を、していると確認できていますか(はい / いいえ / 分からない)
  • 業務で使わないAPIや、管理用の機能が、インターネットに公開されていないと確認できていますか(はい / いいえ / 分からない)

「いいえ」と「分からない」は、下の作業の対象です。

今日やること

  1. 公開しているスマホアプリと、WebのAPIを、書き出す。開発した会社と、運用している会社も、書きます。分からないものは、「不明」と書き、確認する人と期限を決めます。

  2. 開発した会社や、運用している会社に、次の質問を送る。この質問の内容は、調査記事が推奨する対策に、基づいています。

    当社が公開しているスマホアプリと、API(会員向けのシステムの裏側を含む)について、教えてください。

    1. アプリの中に、秘密鍵や、長く使える認証の情報を、入れていませんか。

    2. APIは、サーバーの側で、利用者を確認し、操作の内容に応じて、許可していますか。アプリの中の署名や、難読化だけに、頼っていませんか。

    3. 短い時間に、何度もアクセスされたときの制限(レート制限)と、不審なリクエストの監視は、ありますか。

    4. 外部のURLを取得するAPIで、接続先を制限し、リダイレクトのあとの宛先も、確認していますか。

    5. 業務で使わないAPIや、管理用の機能が、インターネットに公開されていませんか。

  3. 質問と一緒に、ログの確認も、頼む。

    • JPCERT/CCの注意喚起(AT-2026-0030)に、不審なIPアドレスや、User-Agentの一覧があります。それらからのアクセスが、公開しているAPIやWebのログに、ないかを、見てもらいます。
    • IPAは、ログの確認を、まず直近1か月で行い、そのあと、3か月に広げるよう、案内しています。
  4. 回答で、問題が分かったときは、対応する人と日を決め、実施し、確認する。たとえば、アプリに埋め込まれた秘密鍵があるときは、その鍵を無効にして、新しいものに替えます。
  5. ログに、不審なアクセスの痕跡が見つかったときは、自分で消さず、ログを保全して、専門の業者に切り替える。
    • IPAは、異常なログやアカウントが見つかったときは、速やかにセキュリティインシデントと判定するよう、案内しています。
    • あわせて、専門のセキュリティベンダーに、詳細調査を依頼することを、強く推奨しています。

「質問を送った」は、完了ではありません。次の4つがそろったら、完了です。

  • 公開しているアプリとAPIの一覧ができ、各行に、開発した会社と運用している会社か、「不明」が書かれている。「不明」の行には、確認する人と期限が、書かれている。
  • 質問への回答を、文書で受け取った。
  • 回答で問題が分かったものは、対応が実施され、実施後の状態を確認した。対応しないと判断したときは、判断した人と根拠を記録した。
  • ログの確認が実施され、結果を受け取った。痕跡が見つかったときは、専門の業者による調査が実施され、結果を受け取り、見つかった問題の是正まで済んでいる。

自社で対応が難しい場合

次のどれかに当たるときは、開発した会社、運用している会社、専門の業者に切り替えてください。

  • アプリやAPIを作った会社が、分からない、または、連絡が取れない
  • 質問の内容が、分からない、または、回答の内容を、判断できない
  • ログの見方が、分からない
  • 不審なアクセスの痕跡、見覚えのないアカウントや、ファイルが見つかった。インシデントとして扱い、ログなどの証拠を保全したうえで、専門の業者に、詳しい調査を頼んでください

出典