自社のWebサイトや業務システムについて、どのような技術が使われ、誰がその安全性を管理しているか、把握できているでしょうか。

2026年10月、Webシステムに関わる二つのセキュリティ情報が相次いで公表されました。一つは、Androidアプリを解析してAPIを特定し、攻撃に利用する手法に関する調査報告。もう一つは、Webサイトなどで広く使われているPHPの重大な脆弱性と、その修正版の公開です。

二つの話題は、問題が生じる場所も対応方法も異なります。さらに企業のシステムでは、開発会社と運用会社が別ということも珍しくありません。脆弱性が見つかったとき、自社ではどこを確認し、誰に対応を依頼すればよいのでしょうか。今回は、Webシステムの構成と管理責任、そして診断範囲の考え方を整理します。

2026年10月15日、JPCERT/CCは、国内で相次いで公表された不正アクセス事案に関連し、攻撃元サーバーの調査結果を公開しました。特徴的だったのは、Androidアプリの配布ファイル（APK）を解析してAPIを特定し、そのAPIにSSRFなどの脆弱性がないか調べていた痕跡です。攻撃者がAIを利用して、既知の脆弱性のスキャンやAPI経由の攻撃を行っていたことも確認されています。^[1]

このように公開アプリを解析し、接続先のサーバーを狙う手法を、情報通信研究機構（NICT）は「A2B攻撃（App-to-Backend Attack）」と名付けて注意を呼びかけています。^[2] ただし、APIの接続先が判明すること自体が脆弱性なのではありません。正規アプリ以外からのリクエストも想定して、API側で適切に検証できるかが問題になります。

一方、10月21日にはPHPの重大な脆弱性2件（CVE-2026-109618、CVE-2026-109619）に対する修正版が公開されました。悪用されると、認証なしでリモートから任意のコードを実行される可能性があります。^[3] JPCERT/CCは翌22日、該当環境での対策適用と侵害有無の調査を呼びかけています。^[4]

APIへの攻撃ではアプリケーションの設計やアクセス制御が、PHPの脆弱性ではアプリケーションを動かす実行環境が問題になります。この違いを理解するために、Webサービスの裏側を見てみましょう。

例えばショッピングサイトでは、商品検索から注文確定までの間に、商品・在庫・会員・決済・配送などの機能が動いています。外部の決済事業者や物流システムと連携する場合もあり、画面上では一つのサービスでも、裏側では複数のシステムが情報をやり取りしています。その受け渡しに用いられる仕組みがAPI（Application Programming Interface）です。

スマートフォンのアプリで購入履歴を表示する場面を考えてみます。アプリはAPIを通じて注文情報を取得しますが、仮に注文番号を変更するだけで別の利用者の履歴を取得できるとしたら、情報漏えいにつながります。これはOWASPの「API Security Top 10」で最上位に挙げられているBOLA（オブジェクトレベルの認可不備）の例です。^[5]

ログインした本人であることを確認する「認証」と、その人が特定の注文情報を取得してよいか判断する「認可」は別です。正規の利用者が送ったリクエストでも、他人の情報を返してはいけません。APIでは、処理対象ごとに権限を確認する設計が求められます。

これに対してPHPは、サーバー側でプログラムを動かす技術の一つです。注文処理のプログラムが適切に作られていても、その実行環境に未修正の脆弱性が残っていれば、別の経路で侵害される恐れがあります。今回の脆弱性は、環境によってはアプリケーションのコードが動く前の段階で悪用され得るとされており^[3]、APIの認可を見直すだけでは解決しません。

Webシステムには、このほかにもOS、Webサーバー、データベースなどが関わります。どこに弱点があるかによって、確認方法も修正方法も変わるのです。

技術的な違いを理解したところで、次は運用の問題です。例えば、Webサイトの保守は制作会社、サーバーはホスティング会社、スマホアプリは別の開発会社という構成では、脆弱性が見つかった場所によって対応先が変わります。

WordPressを使った企業サイトは、よい例でしょう。WordPress本体やプラグインの更新は制作・保守会社が担当していても、PHPのバージョン変更はホスティング会社の管理画面から利用者が操作する契約かもしれません。さらにPHPを更新すると古いテーマやプラグインが動かなくなる場合があり、動作確認の担当も必要です。今回、PHP公式プロジェクトが公開した修正版は8.2以降が対象です。古いバージョンを利用している場合には、提供元の対応状況を確認し、必要に応じてバージョン移行を検討することになります。^[3]

制作会社は「PHPはサーバー側」、ホスティング会社は「バージョンの選択は利用者側」と考えていたら、双方が契約どおりに動いていても更新が残ってしまう可能性があります。

APIの場合は、事情が少し異なります。PHPのような既製品の脆弱性は修正版や注意喚起で知ることができますが、APIの認可不備は自社システム固有の問題であり、外部からの注意喚起だけでは発見できない場合があります。アプリの開発会社が「権限の確認はサーバー側」、APIの開発会社が「自社アプリからしか呼ばれない」と考えていれば、正規アプリを経由しない攻撃への備えが抜け落ちます。納品後に保守契約がなければ、改修の依頼先から決め直すことになります。

責任分界点を確認する目的は、事故の際に責任を押し付け合わないためだけではありません。情報を受け取る人、影響を判断する人、修正する人、完了を確認する人を決め、必要な作業を止めないためです。

IPAの「安全なウェブサイトの運用管理に向けての20ヶ条」でも、クラウドなどのサービスを利用する場合は、事業者側の作業範囲と対策を把握し、不足する対策は自組織での対応を検討するよう求めています。^[6] 専門作業を委託することと、企業として対応状況を把握することは分けて考えたいところです。

構成と担当者が分かったら、次に見直したいのが脆弱性診断の対象範囲です。「以前に診断を受けた」という事実だけで、現在のシステム全体を確認できているとは限りません。

例えばWebサイトの会員ページを診断していても、スマホアプリ専用のAPIが対象外になっている場合があります。逆にサーバーの設定を調べていても、利用者ごとの注文情報をAPIが適切に制限しているかは別途検証が必要です。診断対象を追加・変更した後に、以前の診断結果をそのまま現在の安全性の根拠にするのも避けたいところです。

診断の種類によって、主に確認する項目は異なります。

診断の種類	主な確認対象（例）
Webアプリ診断	認証・認可、セッション管理、入力データの取り扱い、Web APIなど
スマホアプリ診断	端末内のデータ保護、通信、連携するAPIなど
ネットワーク診断	公開サーバーやネットワーク機器の不要なサービス、既知の脆弱性など
サーバ構成診断	OS・ミドルウェアの設定、セキュリティパッチの適用状況など

※診断可能な項目や範囲は、サービスの仕様や診断条件によって異なります。

今回のPHPのように修正版が公開されている問題については、影響の確認と更新、必要に応じた侵害調査が先決です。脆弱性診断はパッチ適用の代わりにはなりません。過去の診断報告書を確認し、どの環境・機能が対象だったか、変更後に再確認しているかを整理しておくと、次の診断範囲を決めやすくなります。

まずは外部から利用できる自社のWebサイト、業務システム、スマホアプリを一覧にし、開発・保守会社、サーバーの管理者、外部サービスとの連携先を整理しましょう。長く運用しているシステムほど、途中で委託先や担当者が変わり、管理範囲が曖昧になっていることがあります。

現状を確認する際には、次の7項目を使ってみてください。

分からない項目があれば、すぐに新しい製品を導入するのではなく、まず委託先や管理者に確認しましょう。古いAPIやテスト環境が残っていないか、診断範囲から外れている機能がないかを見直すことも有効です。システムの現状が分かれば、どこに優先して手を打つべきか判断しやすくなります。

APIへの攻撃とPHPの脆弱性は、Webシステムの異なる部分に生じる問題でした。APIでは設計・実装上のアクセス制御を、PHPのような実行環境では脆弱性情報と更新状況を確認する必要があります。その対策を実行するためには、システムの構成だけでなく、開発・運用に関わる会社との責任分界も欠かせません。

新たな脆弱性の発見を止めることはできません。それでも、影響を判断し、対応を依頼し、結果を確認できる体制を整えることはできます。

ドコモソリューションズでは、Webアプリ診断、スマホアプリ診断、ネットワーク診断、サーバ構成診断、ペネトレーションテストなど、対象システムに合わせたセキュリティ診断を提供しています。WebサイトやスマホアプリからAPI、サーバーまで、どこを診断対象に含めるべきかの整理からご相談いただけます。お気軽にお問い合わせください。

• [1] JPCERT/CC「連続不正アクセス事案の攻撃手法に関する調査」（2026年10月15日）
• [2] 情報通信研究機構（NICT）「【注意喚起】 相次ぐ情報漏えい、その原因の一つは「アプリ解析からのサーバ攻撃」」（2026年10月13日）
• [3] The PHP Group「Security advisory: Critical remote code execution vulnerabilities, update now」（2026年10月21日）
• [4] JPCERT/CC「PHPにおける複数の脆弱性（CVE-2026-109618、CVE-2026-109619）に関する注意喚起」（2026年10月22日）
• [5] OWASP「OWASP Top 10 API Security Risks – 2023」
• [6] IPA「安全なウェブサイトの運用管理に向けての20ヶ条 ～セキュリティ対策のチェックポイント～」

※Androidは、Google LLCの商標です。

※WordPressは、WordPress Foundationの登録商標です。

※その他、記載されている会社名、製品名、サービス名は、各社の商標または登録商標です。