PHP脆弱性とメール — 届く「対応のお願い」を疑い、自社のフォームの通知メールを確かめ、顧客への連絡は事実だけを書く

PHPの重大な脆弱性のあと、メールまわりで気にすべきことは3つです。便乗した偽のメールの見分け方、問い合わせフォームやWebメールなど自社のメールの裏側にPHPがいないか、顧客に知らせるメールの書き方。サーバーを触らない担当者向けに整理します。

PHPの脆弱性とメールの関係で、マーケティング担当が気にすべきことは3つです。脆弱性に便乗した「対応のお願い」メールを疑うこと、自社のメールの裏側でPHPが動いていないかを確かめること、顧客に知らせるメールには確認できた事実だけを書くこと。サーバーを直すのはシステムの担当者や事業者の仕事ですが、この3つはメールを扱う部署の持ち場です。

2026年10月21日に公表されたPHPの脆弱性（通称 php2shell）の中身と、カートや配信ツールが止まったときの広告・予約メールの扱いは、PHPの重大な脆弱性「php2shell」— マーケティング担当が今日確かめることに書きました。この記事では、そこで書かなかった「メール」の話だけを扱います。

※私たちはセキュリティの専門会社ではありません。サーバーの具体的な対応は、システムの担当者やサービスの事業者の案内に従ってください。

先に、言葉を揃えます

言葉	この記事での意味
PHP	Webサイトの裏側で動くプログラミング言語。WordPressや、問い合わせフォームの多くがこれで動いている
脆弱性	プログラムの欠陥のうち、攻撃に使われるおそれがあるもの
フィッシングメール	本物の会社を装って、偽のログイン画面に誘い、IDやパスワードを入力させるメール
送信フォーム	Webページの問い合わせ欄。入力された内容を、担当者あてのメールに変えて届ける仕組みが裏で動いている
Webメール	ソフトを入れずに、ブラウザでメールを読み書きする画面。レンタルサーバーに付いてくることが多い

1. 「脆弱性対応のお願い」メールを疑う

大きな脆弱性が話題になると、それを口実にしたメールが届くことを前提にしておくのが安全です。今回の件で、便乗したメールがどれだけ出回っているかを私たちは確認できていません。ただ、話題になったことを口実にする手口は、脆弱性に限らず、情報漏えいのあとなどにも繰り返し使われてきた形です（相次ぐ情報漏えいのあと、顧客リストを持つマーケティング担当が今週見直すことでも同じ注意を書きました）。

想定しておく文面は、たとえば次のような形です。

「PHPの脆弱性への対応のため、管理画面に再ログインしてください」
「セキュリティ更新のため、アカウントの確認が必要です。本日中に手続きがない場合は停止します」
「メンテナンスで配信が止まったため、配信設定の再登録をお願いします」

本物の事業者も同じ時期に似た件名のお知らせを送ってくるので、件名だけでは見分けられません。見分ける基準は、メールの中のリンクを使わずに確かめられるかどうかです。

確かめ方	やること
自分で開く	メールのリンクは押さない。ブックマークや、自分で打ったアドレスから管理画面に入り、同じお知らせが出ているかを見る
お知らせページを見る	事業者の公式サイトのお知らせ欄に、同じ内容が載っているかを見る
急がせる文面を疑う	「本日中」「停止します」と急がせるものほど、一度手を止める
社内で共有する	怪しいメールを受け取ったら、同じツールを使っている人に知らせる。一人が押せば足りるのが、この手口です

ここで覚えておきたいのは、脆弱性の修正はサービスの事業者が自分のサーバーで行うもので、利用者がログインし直して直るものではないということです。SaaS（自社でサーバーを持たずに使うサービス）の利用者に、脆弱性の対応としてパスワードの入力を求める理由は、ふつうはありません。

2. 自社のメールの裏側にPHPがいないか確かめる

「メールはPHPと関係ない」と思われがちですが、マーケティング部門が使うメールの周りには、PHPで動いているものが混ざっていることがあります。見落としやすいのは次の3つです。

問い合わせフォーム・資料請求フォーム

フォームに入力された内容を担当者あてのメールに変えて送る仕組みは、PHPで書かれていることが多い部分です。とくに、キャンペーンのときに外注先が作ったフォームや、レンタルサーバーに置いたまま誰も触っていないフォームが危ない場所です。フォームのサービス（事業者が管理するもの）を使っているなら、更新は事業者がやります。自分たちのサーバーに置いたものは、誰も直してくれません。

Webメール

レンタルサーバーに付いてくるWebメールの画面も、PHPで動いているものがあります。使っていないなら、使わない設定にできないかをサーバーの担当者に聞いてみてください。

メールのためだけに残しているサーバー

サイトは別の場所に移したのに、メールのためだけにレンタルサーバーを残している、という会社は少なくありません。私たちもそうでした。サイトはPHPを使わない構成に移していましたが、メール用に残しているレンタルサーバーが1台あり、そこも事業者が同じ時期に緊急メンテナンスを入れていました。サイトの引っ越しのときに「サイトは移した」で話が終わり、残ったサーバーのことは誰の頭にもない。こういう場所が、棚卸しで出てきます。

確かめる順番は、次の形が簡単です。

会社のドメイン（メールアドレスの@より後ろ）ごとに、どこのサーバーで何が動いているかを並べる
それぞれ「事業者が管理しているもの」か「自分たちで置いたもの」かに分ける
自分たちで置いたものは、誰に更新を頼めばよいかを決める。使っていないものは止める

この一覧づくりはAIに手伝わせると早く終わります。ただし、AIはサーバーの中身を知らないので、推測で「影響なし」と書きがちです。「分からないものは要確認と書く」と必ず指示し、確かめるのは人がやります。ツール同士をつなぐ鍵の棚卸しは自動化ツールとAIエージェントに渡した「連携の鍵」を棚卸しするにまとめています。

3. 顧客に知らせるメールは、確認できた事実だけを書く

自社のサービスやフォームが止まった、あるいは影響がありそうだと分かったとき、顧客にメールで知らせるかどうかを決めることになります。中身の判断（被害の有無や、届け出が必要かどうか）はシステムの担当者や専門家の仕事です。マーケティング担当が受け持つのは、文面と送り方です。

書くこと・書かないこと

書くこと	書かないこと
何が止まったか、いつからいつまでか	確認が済んでいないのに「影響はありません」「安全です」と言い切ること
いま分かっていることと、まだ分かっていないこと	原因や被害の推測
顧客にお願いしたいこと（あれば）	ログイン画面やパスワード変更画面へのリンク
続報をどこで出すか（自社サイトのお知らせ欄など）	便乗の売り込みや、別のキャンペーンの案内

いちばん大事なのは、本文にログイン用のリンクを置かないことです。1つ目の節で書いたとおり、偽のメールはまさに「ログインし直してください」という形で届きます。自社の正規のメールが同じ形をしていると、顧客は本物と偽物を見分けられなくなります。手続きが必要なら「いつもお使いのブックマークや公式サイトから入ってください」と書くほうが、顧客を守れます。

送る前に確かめること

送り元が本物だと分かる状態か。 送信元の認証（受け取る側が「このメールは本当にこの会社から来たか」を確かめられる設定）が整っていないと、正規のお知らせが迷惑メールに入るか、偽物と区別がつかなくなります。点検の仕方はなりすましメール対策は、メールを送る部署の仕事に書きました
配信ツール自体が止まっていないか。 お知らせを出したいときに、配信ツールがメンテナンス中ということも起こります。急ぎなら、自社サイトのお知らせ欄に先に載せ、メールはあとから追いかける順でもかまいません
誰が最後に文面を見るか。 急いで書いた文面ほど、言い切りや推測が混ざります。送る前に、事実を把握している人が一度読む段取りにしておきます

文面の下書きをAIに作らせるのは問題ありません。ただし、AIは丁寧に書こうとして「ご安心ください」「影響はございません」を足しがちです。「確認できた事実だけを書く。安全だと言い切らない。リンクは自社サイトのお知らせ欄だけにする」と最初に指示し、出てきた文面は人が確認します。AIの出力をどこで人が見るかの決め方はAIの出力を人がどう確認するかにまとめています。

まとめ

PHPの脆弱性とメールの関係で気にすべきことは、偽のメール、自社のメールの裏側、顧客への連絡の3つ
「脆弱性対応のため再ログインを」というメールは、リンクを押さずに、自分で管理画面やお知らせ欄を開いて確かめる
問い合わせフォーム、Webメール、メールのためだけに残したサーバーは、PHPが動いていることがある。自分たちで置いたものは自分たちで頼む
顧客へのお知らせは、確認できた事実だけを書き、ログイン用のリンクを置かない
AIは一覧づくりや下書きに使えるが、「影響なし」「安全です」を推測で書かせない

私たちが自社のマーケティングをAIで運用する中で、何をAIに任せ、どこに人の確認を置いているかは、無料のレポートにまとめています。止まったときに誰が何をするかを決めておく参考にしてください。無料レポートを受け取る

本記事の内容は2026年11月時点のものです。