買収サイトが1年後にハッカーに乗っ取られた

WordPressで動くWebメディアを買収した直後から「収益も上がっているし、アクセスも安定している」と安堵していた買い手が、1年後にGoogleから「このサイトは危険です」という赤いブロック画面を突きつけられる──この種の「WordPressセキュリティ地雷の遅延爆発」は、決してレアケースではありません。買収審査中は正常に動作し、引き渡しのタイミングでも問題は表面化しない。それでも、売却前から仕込まれたバックドアや、更新が止まったプラグインの脆弱性は、買収後の管理の隙を静かに待ち続けています。

国内のWebメディアM&A案件の大半は、基盤にWordPressを使っています。売却価格が数百万から数千万円の案件であっても、WordPressのバージョン管理・プラグインの更新状況・テーマの出所・管理者パスワードの強度といったセキュリティ状態は、仲介業者が実施する審査のスコープに原則含まれていません。買い手は「動いているから大丈夫」と判断し、売り手は「今まで問題なかった」で済ませる。この認識の隙間に、放置プラグイン・nulledテーマ・プレミアムプラグインのライセンス失効という3つの時限爆弾が静かに埋まっています。本記事では、それぞれの爆発メカニズムと、WP-CLI・Wordfenceを用いた技術的DDの全手順を、実務レベルで分解します。

1. なぜWordPressは「買収後に爆発する」のか ── 売却前は正常に見える攻撃ベクタの構造

1-1. Webメディア買収案件の大半はWordPress ── 攻撃者に最も狙われるプラットフォームを買う現実

世界のCMS市場シェアの60%超を占めるWordPressは、同時に世界で最も攻撃者に研究・悪用されているプラットフォームでもあります。Sucuri社の年次マルウェアレポートによれば、感染が確認されたWebサイトのうちWordPressが占める割合は毎年7〜8割前後で推移しており、「人気プラットフォームであること」と「攻撃の標的として最優先されること」は表裏一体の関係にあります。国内のWebメディアM&Aで売り物に出るサイトの大半がWordPressを使っている以上、買い手はWordPressというプラットフォームそのものが内包する構造的なリスクを、購入価格の評価に織り込まなければなりません。

1-2. バックドアは「潜伏する」── 攻撃者は即座に動かず、売却完了後のタイミングを狙う

バックドアという言葉から「侵入即悪用」を想像するかもしれませんが、現実の攻撃者の多くはより計算的に動きます。売却前にバックドアを仕込んだ攻撃者（または悪意を持った売り手）が引き渡し後しばらく沈黙を保ち、買い手が「サイトは安定している」と油断した頃合いを見計らってアクティベートする、あるいは買収後に管理者が変わって監視が緩んだタイミングで既存の未検出バックドアが外部から悪用される── バックドアとは「侵入済みの状態が保存されている」だけであり、発火タイミングは攻撃者が握っています。これがセキュリティ地雷の「遅延爆発」が1〜2年後に集中する理由です。

1-3. 仲介業者の審査はGA・P/Lが中心 ── セキュリティスキャンは業務スコープ外

国内のWebメディア仲介において、売り手が提出する資料は「Googleアナリティクスのスクリーンショット」「過去12〜24ヶ月の収益推移」「ドメイン年齢・被リンク概況」が定番であり、WordPressのセキュリティ状態に関するチェック項目は仲介業者の審査プロセスに構造的に含まれていません。仲介業者は財務・マーケティングの専門家として機能する設計であり、技術的なセキュリティ監査を業務に含めることは、人員・スキルセット両面から現実的ではないからです。この構造を理解した上で、買い手自身が独立した技術的DDを発注するか、自らWP-CLIとWordfenceで実施するしかないのが現状です。

1-4. 「売却前にクリーンアップすれば隠せる」── 審査期間だけ正常化される意図的な偽装

より深刻なのは、売り手が意図的に隠蔽するケースです。既にマルウェア感染が発生しているサイトに対し、売却交渉期間中だけWordfenceで表面的なクリーンアップを行い、引き渡し後に再感染を待つ、あるいは感染ファイルを削除せずに隠しディレクトリへ移動させて審査をやり過ごす── こういった手法は技術者でなければ検出が困難です。サイトが売りに出ているタイミングは、売り手の「見栄えを整えるインセンティブ」が最大化している局面です。数値を整えるように、セキュリティ状態も「見た目上だけ整える」ことが可能だという現実を、買い手は念頭に置く必要があります。

2. 【地雷①】放置プラグインの脆弱性 ── 更新が止まった瞬間から攻撃可能状態が始まる

2-1. CVEデータベースに毎週追加されるWordPressプラグインの脆弱性 ── 未更新プラグインは時間とともに危険度が増す

WordPressのプラグイン脆弱性は、CVE（共通脆弱性識別子）データベースおよびWPScan Vulnerability Databaseに毎週数十件単位で新規登録されています。重要なのは「脆弱性が公開された瞬間から、その情報を悪用するPoCコード（概念実証コード）も同時に流通し始める」という点です。プラグインを最新版に更新しさえすれば防げる攻撃が、「面倒だから後で」「動いているから触らない」という理由だけで放置され、公開済み脆弱性を使った自動スキャン・一斉攻撃にさらされ続けます。売り手が3年間更新を怠ってきたプラグインを引き継いだ買い手は、その3年分の蓄積された既知脆弱性を丸ごと相続します。

2-2. 「有効化はされていないが削除もされていない」プラグインが最も危険な理由

WordPressプラグインの脆弱性は、「有効化（アクティベート）されていなければ安全」と誤解されがちですが、これは事実ではありません。プラグインがインストールされてサーバー上にファイルが存在している限り、そのPHPファイルは特定のURLからダイレクトに呼び出せる場合があり、「無効化済みのプラグインの脆弱なファイルを直接叩くファイルインクルード攻撃」は実際に多発しています。売り手が「使わなくなったから無効化した」と言って残したまま放置されているプラグインのほうが、有効化されているものより悪質なケースすらあります。買い手がDDで確認すべきは「有効プラグインの更新状況」だけでなく、インストール済みの全プラグインの棚卸しです。

2-3. WP-CLIで放置プラグイン一覧と更新状況を取得する具体的コマンド

WP-CLIはWordPressの管理作業をCLIから実施できる公式ツールです。DDの初手として以下のコマンドを実行することで、プラグインの全件一覧・バージョン・更新状況・有効/無効状態を一括取得できます。

全プラグイン一覧の取得（更新状況付き）：

wp plugin list --fields=name,status,version,update,update_version --format=table

このコマンドの出力で「update」列に「available」が表示されているものが未更新プラグインです。さらに、最終更新から2年以上が経過しているプラグインはWordPress公式ディレクトリから削除・閉鎖されているケースもあり、その場合はセキュリティパッチの提供自体が永続的に停止されています。以下のコマンドで「WordPressディレクトリから削除済み」の判定も可能です。

wp plugin status

閉鎖済みプラグインは「closed」ステータスで表示されます。DDで発見した閉鎖済みプラグインは即時アンインストールと代替プラグインへの移行を、買収条件の実施事項として契約に組み込むべきです。

2-4. 管理者パスワードが「admin/admin」のまま放置される現場感 ── 弱認証情報はプラグイン脆弱性より致命的

技術的DDでもう一点確認すべき重大事項が、管理者アカウントの認証強度です。「admin」というユーザーIDが存在するWordPressサイトは、ブルートフォース攻撃のターゲットとして優先度が最上位に分類されます。WP-CLIでの確認コマンドは以下の通りです。

wp user list --role=administrator --fields=ID,user_login,user_email,user_registered

ユーザー名が「admin」のまま、あるいは登録メールアドレスが売り手の個人アドレスのまま残っていれば即刻変更が必要です。パスワード強度の直接確認はCLIからはできませんが、二段階認証（2FA）が導入されていないWordPressサイトは、パスワード強度に関係なくブルートフォース攻撃に対して構造的に脆弱です。Wordfenceのログイン保護機能や、WP 2FA等のプラグインによる2FA強制化は、買収後の最初の1週間以内に実施すべき最優先の防御措置です。

3. 【地雷②】Nulledテーマのバックドア ── 海賊版テーマに仕込まれた恒久的な侵入口

3-1. Nulledテーマとは何か ── 有償テーマを無料配布するサイトに潜む罠

「nulledテーマ」とは、Themeforest等の有償テーママーケットで販売されているプレミアムテーマのライセンス認証を無効化（null化）し、無料で配布するサイト・ファイルを指します。個人開発者や小規模運営のWebメディアでは「購入コストを節約するために」nulledテーマを使い始め、そのまま何年も運用し続けているケースが珍しくありません。WordPressはGPLライセンスの関係上、テーマ・プラグインの配布行為自体を完全に禁止しにくい法的グレーゾーンが存在するため、nulledサイトは現在も多数稼働しています。問題はコストの節約どころか、これらのファイルには高確率でバックドアコードが仕込まれているという点です。

3-2. バックドアの実装手法 ── PHPファイルに埋め込まれたeval(base64_decode())の恐怖

nulledテーマに仕込まれるバックドアの典型的な実装は、テーマのfunctions.phpや見落とされやすいサブファイルに埋め込まれたeval(base64_decode(...))形式のコードです。base64でエンコードされた文字列は一見して意味不明なランダム文字列に見えるため、ソースを眺めただけでは発見困難です。デコードすると、外部サーバーからの指令を受け取り任意のPHPコードを実行する「Webシェル」や、管理者権限ユーザーを密かに追加するコードが現れます。このバックドアは、テーマが有効化されている限り永続的に機能し続け、たとえ一時的にマルウェアを駆除しても、テーマファイル自体を入れ替えない限り再感染を繰り返します。

3-3. Nulledテーマはファイルのタイムスタンプまで偽装される ── 外観からの発見が困難な理由

より巧妙な点は、バックドアを仕込んだファイルのタイムスタンプが正規ファイルのものと同一に改ざんされているケースがある点です。「最終更新日が古い＝変更されていない」という前提で監視していると、改ざんを見逃します。WordPressのファイル整合性チェックには、ハッシュ値ベースの比較が必要です。Wordfenceはインストール済みテーマ・プラグインの各ファイルのハッシュ値を公式リポジトリのそれと照合する機能を持っており、nulledテーマ由来のファイル改ざんをハッシュ不一致として検出できます。ただしnulledテーマそのものはWordPress公式リポジトリに存在しないため、比較対象となるオリジナルハッシュが存在せず、「比較不能＝要精査」として扱うことになります。

3-4. テーマファイルのバックドア検出：evalコード検索とWordfenceスキャンの組み合わせ

SSHでサーバーに接続できる環境であれば、以下のコマンドでWordPressテーマディレクトリ内の疑わしいeval記述を一括検索できます。

grep -r "eval(base64_decode" /path/to/wp-content/themes/ --include="*.php"

grep -r "eval(gzinflate" /path/to/wp-content/themes/ --include="*.php"

この出力に1行でも結果が返れば、そのファイルは即刻精査対象です。合わせてWordfenceの「Scan」機能を実行し、「Files Modified」「Suspicious code」「Known malware」の各カテゴリに挙がるファイルを全件確認します。DDの段階でこれを実施するには、買い手側がサーバーへのSSHアクセス（リードオンリー権限でも可）を売り手から提供してもらう必要があり、この権限を拒否する売り手はそれ自体がリスクの予兆と見なすべきです。

4. 【地雷③】プレミアムプラグインのライセンス失効 ── 買収後にセキュリティアップデートが届かなくなる

4-1. プレミアムプラグインの「年間ライセンス制」とドメイン紐づき認証の仕組み

Elementor Pro・WP Rocket・Advanced Custom Fields (ACF) Pro・Gravity Formsなど、多くの高機能プレミアムプラグインは「年間ライセンス制」を採用しており、ライセンスは購入者のアカウントと登録ドメインに紐づけられています。ライセンスが有効な間はWordPress管理画面から自動更新を受け取れますが、年間ライセンスが失効した瞬間から、そのプラグインはセキュリティパッチを含む全てのアップデートを受け取れない状態に移行します。プラグイン自体は動き続けるため、運営者が気づかないまま脆弱な旧バージョンが稼働し続けるというのが、この問題の最も危険な側面です。

4-2. 売却時点でライセンスが失効している・移管できないプラグインが多数存在する現実

M&A案件で頻発するのは、「売り手がライセンスを購入し、有効期間中は問題なく動いていたが、更新を忘れたまま失効していた」という状況と、「ライセンスは売り手個人アカウントに紐づいているため、サイト売却時に移管できない」という状況の両方です。ライセンスの移管可否はプラグインベンダーのポリシーによって異なり、一部ベンダーは移管自体を許可しておらず、買い手が新規購入を強いられます。複数のプレミアムプラグインを使っているサイトでは、買収後の初年度だけでライセンス再取得費用が数十万円規模に達するケースも珍しくなく、この費用は当然ながらIMには一切記載されていません。

4-3. ライセンス切れプラグインが引き起こす具体的な被害シナリオ

2023年に公開されたElementor Proの重大な脆弱性（CVE-2023-32243）は、認証済みユーザーが管理者権限を奪取できるというものでした。修正バージョンへのアップデートが配信されましたが、ライセンス失効状態のサイトにはこのセキュリティパッチが届かず、既知の攻撃手法で管理者権限を奪取される状態が放置されます。こうした「ライセンス切れ＝パッチ未適用＝既知脆弱性が悪用可能」という連鎖は、プレミアムプラグインを多用しているメディアほど深刻で、買収後に発覚したとしても売り手への遡及は極めて困難です。

4-4. DDで確認すべき「プレミアムプラグイン棚卸し」の実務手順

買い手側がDDで確認すべき事項は以下の通りです。まずWP-CLIで全プラグイン一覧を取得し（前述のwp plugin listコマンド）、有償プラグインを特定します。次に売り手に対して「各プレミアムプラグインのライセンス購入証明（領収書・注文確認メール）・現在の有効期限・移管可否の確認（ベンダーに問い合わせた結果）」を書面で提出するよう要求します。この開示を渋る売り手、あるいは「動いているから問題ない」と言い張る売り手は、ライセンス管理の実態が把握できていないと判断すべきです。ライセンス棚卸しの結果は、移管不可のプラグインの再取得費用を試算し、買収価格の調整根拠または売り手負担条件として契約に組み込みます。

5. 「Google Safe Browsingブラックリスト入り」という最悪の末路 ── 検索流入ゼロ・収益消滅・ドメイン評価崩壊の連鎖

5-1. マルウェア感染からGSB登録まで72時間以内に検索流入が消える

Googleのクローラーがサイト上のマルウェアを検出するか、ユーザーからの「危険なサイト」報告が一定数に達すると、Googleは当該URLをSafe Browsing APIのブラックリストに登録します。この登録が行われると、Chromeブラウザはサイトへのアクセスをブロックする赤い警告画面（「このサイトは危険です」）を表示し、Googleサーチコンソールには「セキュリティの問題」として通知が届きます。さらにGoogleの検索アルゴリズムはブラックリスト登録サイトを検索結果から実質的に除外します。感染の検知からSERPでの流入消失まで、ケースによっては72時間以内に完了します。前日まで月100万PVあったサイトが、翌日ほぼゼロになるのがこの種の事故の特徴です。

5-2. AdSenseポリシー違反による広告停止 ── 収益ゼロ状態が数週間単位で継続する

マルウェア感染・フィッシングページの設置はGoogle AdSenseのポリシー違反に該当し、広告配信が自動停止されます。Googleの審査体制上、マルウェア完全駆除の完了後にサーチコンソールからの再審査申請を行い、GSBブラックリストから解除されてからAdSenseの広告配信が再開されるまで、最短でも数週間、ケースによっては数ヶ月を要します。この間、サイトの収益はゼロです。買収対価の回収計画が月次の広告収益を基準に組まれている場合、数ヶ月分の収益消失は投資回収のタイムラインを大幅に狂わせます。

5-3. フィッシングページ設置によるドメイン評価の長期的毀損 ── SEO資産は一夜で消えない

フィッシングページの設置が確認されたドメインは、GSBブラックリスト解除後もしばらくの間、各種セキュリティベンダーのレピュテーションデータベースに「かつて危険だったサイト」として記録が残ります。この記録は企業のセキュリティソフト・メールフィルタリング・社内プロキシを通じた「ドメイン評価スコア」に影響を与え続けます。さらに、感染期間中にGoogleのクロールがマルウェアを検出していた場合、そのドメインへのリンク評価が一時的に減衰し、復旧後の検索順位が感染前の水準に戻らないケースが現実に存在します。買収したドメインの「SEO的な蓄積資産」は、こうした形で永続的に傷を負います。

5-4. GSBブラックリスト解除の実務 ── 再審査申請の前提条件と時系列

GSBブラックリストからの解除手順は

①マルウェアの完全駆除（全感染ファイルの特定・削除・安全なバックアップからの復元）

②サーチコンソールから「セキュリティの問題」セクションで再審査リクエストを送信

③Googleのクローラーによる再確認（通常数日〜1週間）

④問題なしと判断されれば警告解除

という流れですが、マルウェアが完全に除去されていない状態で再審査を申請すると否認され、再申請までの待機期間がリセットされます。「感染ファイルを全て把握して除去する」という前提が崩れると、解除作業は何週間もループします。この復旧作業には専門のWordPressセキュリティエンジニアへの発注が現実的であり、費用は数十万円規模に達します。

6. 技術的DD：WP-CLI・Wordfenceで実施するセキュリティ監査の全手順

6-1. DDの前提条件：SSH（またはSFTP）アクセスの提供要求

技術的DDを実施するための最低条件は、サーバーへのSSHまたはSFTPアクセスの提供です。リードオンリー（読み取り専用）権限で構いませんが、WordPress管理画面だけでは実施不可能なバックドア検索・ファイル整合性チェック・ログ確認には、サーバーレベルのアクセスが不可欠です。「SSH権限は提供できない、管理画面でのスキャン結果を共有する」という売り手の提案は、DDとして不十分です。SSH提供を断る理由として「セキュリティ上の懸念」を挙げる売り手もいますが、一時的なIPアドレス制限付きの読み取り専用アカウントを作成する程度のことはサーバー管理者であれば容易に実施可能であり、拒否自体が赤信号です。

6-2. WP-CLIによる全件棚卸しコマンドセット

以下のコマンドセットを実行することで、プラグイン・テーマ・WordPressコア・ユーザー管理の状態を一括確認できます。

WordPressコアバージョン確認：wp core version

コアファイルの整合性チェック：wp core verify-checksums

全プラグイン一覧（更新状況付き）：wp plugin list --fields=name,status,version,update --format=table

全テーマ一覧：wp theme list --fields=name,status,version,update --format=table

管理者アカウント全件：wp user list --role=administrator

最近作成されたユーザー（不審アカウント確認）：wp user list --orderby=registered --order=DESC --number=20

wp core verify-checksumsでコアファイルの改ざんが検出された場合、それ自体が深刻な侵害の証拠です。コアファイルへの改ざんが確認されたサイトは、プラグイン・テーマの問題以前に「既に制御を失っている」と判断すべきです。

6-3. Wordfenceスキャンの実施と結果の読み方

売り手の管理画面アカウント（管理者権限）をDDの目的で一時的に提供してもらい、Wordfence（無料版で可）をインストールしてスキャンを実行します。スキャン結果で最優先に確認すべき項目は以下の3カテゴリです。「Known malware」（既知マルウェアパターンとの一致）、「Files Modified」（公式リポジトリのハッシュと一致しないファイル）、「Suspicious code」（eval・base64_decode等の難読化コードを含むファイル）。いずれかのカテゴリに1件でもヒットした場合は、その内容をスクリーンショットで保存し、買収交渉における減額根拠または条件交渉の材料として活用します。

6-4. アクセスログ・エラーログの確認 ── 過去の不審アクセスの痕跡を読む

サーバーのアクセスログ（通常/var/log/nginx/access.log または /var/log/apache2/access.log）を確認し、過去3〜6ヶ月の不審なアクセスパターンを確認します。具体的にはwp-login.phpへの大量リクエスト（ブルートフォース攻撃の痕跡）、xmlrpc.phpへのPOSTリクエスト（WordPress XML-RPC経由の攻撃）、不審なUserAgent（スキャンツールの特徴的な文字列）の3点が主な確認対象です。ログに攻撃の痕跡が大量に残っているサイトは「攻撃に気づいていなかった」か「気づいていたが対処していなかった」かのどちらかであり、どちらも買い手にとって同等にリスクです。

7. 契約書に書くべき「WordPressセキュリティ表明保証」── 買い手・売り手それぞれの実務準備

7-1. 表明保証に明記すべき4項目 ── プラグイン・テーマ・ライセンス・認証管理

WordPressサイトの売買契約における表明保証条項には、通常の事業譲渡に加えて以下の4項目を個別に明記すべきです。

①全プラグイン・テーマが公式ライセンスまたはGPL準拠の正規品であり、nulledファイルを含まないこと

②譲渡時点でマルウェア・バックドア・不審なユーザーアカウントが存在しないこと

③プレミアムプラグインのライセンス状況と移管可否を書面で全件開示していること

④管理者パスワードが強固であり、不正アクセスの形跡が過去12ヶ月に存在しないこと

これらの表明が虚偽であった場合、感染の修復費用・収益損失・ドメイン評価回復に要した費用の補償を売り手に請求できる根拠として機能します。

7-2. 「本番環境へのSSHアクセス提供」がDD実施の最低条件 ── 権限提供を拒む売り手は取引を止める

DDの実施に際して売り手に求めるべき技術的な開示として、SSHアクセス（読み取り専用権限）の一時提供・Wordfenceスキャン実施のための管理者権限付与・過去6ヶ月分のアクセスログ・エラーログの提供・全プレミアムプラグインのライセンス書類の4点を書面で要求します。これらの提供を拒む売り手、あるいは「管理画面のスクリーンショットで代替する」という提案をする売り手は、スコープを絞ったDDしか実施できず、本稿で解説した地雷を見落とすリスクが構造的に残ります。この条件を「DD実施の前提条件」として基本合意書（LOI）に明記しておくことで、交渉段階での情報開示拒否に対して法的根拠のある異議申し立てが可能になります。

7-3. 売り手が譲渡前6ヶ月でやるべきセキュリティ棚卸し ── 値下げ圧力を防ぐ先手の自己開示

売り手の視点では、WordPressセキュリティの状態が悪いまま買い手のDDで発見されることが最も損な展開です。発見された瞬間に「知っていたのに隠した」または「把握できていない程度の管理しかしていなかった」という評価につながり、譲渡対価の値下げ圧力がかかるか、交渉決裂のリスクが生じます。売却の意思を固めた段階でWordfenceスキャンを自社で実施し、感染があれば修復、プラグインは全件最新化、nulledテーマは正規品に置き換え、プレミアムライセンスの状態を棚卸しして移管方針をまとめた上でIMに添付する── この先手の自己開示を行った売り手のIMは、技術的な信頼性の高さが数字の外側から伝わり、値下げ交渉を受けにくくなります。

7-4. 補償期間の設計 ── 感染が遅延爆発する構造に合わせた長期設定

WordPressセキュリティ地雷の「遅延爆発」という性質上、表明保証の補償期間を通常の1年で設計するのはリスクが残ります。バックドアが仕込まれており、それが買収後1年以上潜伏した後に悪用されるシナリオへの備えとして、補償期間は最低2年、理想的には3年を設定し、補償対象の範囲にはマルウェア駆除費用・検索流入損失に相当する逸失利益・ライセンス再取得費用を明示的に列挙することを推奨します。「知らなかった」を免責とする条項は売り手に有利な設計ですが、nulledテーマの使用やライセンス失効という事実は「知らないはずがない」性質の事項であり、故意・過失を問わず補償義務を課す設計が買い手保護の観点から合理的です。

財務の数字とアクセス解析だけ見て買うと、買ったのはメディアではなく「管理されていないWordPressのリスク総体」だったということが、買収後1年で判明します。WordPressは誰でも使えるプラットフォームである分、誰でも使いっぱなしにできてしまう。その「使いっぱなし」の代償が、買収後の買い手に全て集約される構造になっています。プラグインの更新状況を確認し、テーマの出所を精査し、ライセンスの移管可否を書面で取り付ける。この3つのDDを徹底するだけで、WordPressサイト買収の技術的リスクの大半は事前に数値化して交渉の俎上に乗せられます。足場を確かめずに踏み込んだ買い手だけが、1年後の爆発に巻き込まれます。