PHP CGI RCE（CVE-2024-4577 / CVSS 9.8）・WordPress改ざんによる「詐欺サイト化」対策：Astro＋Rust WASM静的分離

PHPは、まだインターネットが普及し始めたばかりの1995年に、ラスマス・ラードフ（Rasmus Lerdorf）氏が個人のホームページにアクセスカウンターなどを手軽に付けるための道具（Personal Home Page Tools）として生み出しました。

当時のWebページは文字と画像を並べるだけの静的なファイルでしたが、PHPは「HTML文書の途中に直接プログラムを書き込める」という画期的な手軽さを持っていたため、世界中に爆発的に広まりました。

その後、PHPを使って作られた「WordPress（ワードプレス）」が登場し、専門知識がなくてもブログや会社サイトを作れるようになったことで、世界中のWebサイトの約75%近く（サーバーサイド言語シェア）で使われる巨大な基盤となりました。

しかし、1990年代の「性善説のインターネット」で生まれた「誰でもどこでも気軽にプログラムを実行できる」という長所は、自動攻撃ボットが24時間巡回する現代においては「どこからでも攻撃命令を差し込める」という最大の弱点へと裏返ってしまいました。

特に、機能を追加するために後から入れた「プラグイン（拡張部品）」のどれか1つでも更新が止まると、そこから犯人が侵入して何万ページもの偽ブランド品通販画面を自動生成する「日本語キーワードハック」が発生します。

これはPHPという言語が悪いというよりも、「30年前に手軽さを最優先して作られた仕組みを、現代の厳しい防犯環境でもそのまま公開サーバーで動かし続けている構造」に原因があります。

まず1つ目は、Googleなどの検索窓に「site:自社のドメイン名（例：site:example.co.jp）」と入力して検索してみることです。

もし自社のホームページが10ページほどしかないはずなのに、検索結果が「約15,000件」と表示されたり、見覚えのないブランド品・時計・外国語のタイトルが並んでいたりした場合は、すでに裏側が改ざんされているサインです。

2つ目は、URLの末尾に「/wp-login.php」や「/?author=1（管理者IDの露出確認）」を入力した際、誰でもログイン画面や投稿者アカウント名が見えてしまう状態になっていないかを確認することです。

これらが含まれている場合、自社サイトは動的CMS（WordPressやPHP）で動いており、定期的なバージョンアップが止まっていると危険な状態になります。

特に危険なのが、数年前にホームページをリニューアルした際、昔のサイトを「/old/」「/test/」「/bk/」「/2019/」といった別フォルダに残したまま放置しているケースです。

メインのホームページを綺麗に作り直していても、同じサーバーの片隅に放置された古いテスト用WordPressから侵入され、現在の本番サイトまで書き換えられてしまう事例が後を絶ちません。

実際に、ホームページ改ざんに気づかず数ヶ月放置した結果、決済代行会社や検索エンジンからドメイン全体が「危険な詐欺サイト」としてブラックリスト登録され、全社員の業務用メールまで相手先に届かなくなる業務停止事例が発生しています。

さらに経済面（TCO：総所有コスト）で比較しても、従来の動的CMS（PHP / WordPress）は「初期制作費が安く見えても、5年間の保守・プラグイン改修・PHPバージョンアップ対応・緊急復旧で数百万円が消えていく」という隠れコスト構造を持っています。

PHPは原則として約2年間のアクティブサポートと1年間のセキュリティサポートで寿命（EOL：End of Life）を迎えるため、3〜4年ごとに必ず「PHPバージョン引き上げに伴うプログラム改修費用」が発生します。

これに対し、最初から公開サーバーにPHPもデータベースも置かない「Astro静的生成 ＋ Rust WASM分離アーキテクチャ」を採用すれば、完成したHTMLファイルを配信するだけなので、言語の寿命によるサイト改修費用そのものが消滅します。

また、2026年度から始まる経済産業省「サプライチェーン強化に向けたセキュリティ対策評価制度（SCS評価制度 ★3・★4）」においても、外部公開システムの脆弱性管理と攻撃面の最小化は重要な審査ポイントとなります。

これからのWebサイト発注・リニューアルにおいては、「とりあえずWordPressで作る」という慣習を見直し、提案依頼書（RFP）の段階で「公開オリジンからの動的スクリプト・DB排除（静的分離）」を指定することが最も合理的な経営判断となります。

このモデルでは、「外部からの未検証入力（Query String / POST Body / HTTP Header）」と「サーバー上のファイルシステム操作（include / require / file_put_contents）」および「シェル実行（exec / system / proc_open）

」が同一プロセス空間内に隣接しています。

さらにWordPressのようなプラグインアーキテクチャでは、サードパーティ製プラグインがコアと同じOSユーザー権限（www-data等）とデータベース接続権限を共有するため、最小権限の原則（Principle of Least Privilege）がプロセス内部で成立しません。

この問題を根本から解決するモダンアーキテクチャが、「ビルド時静的生成（Astro SSG）」「クライアントサイド計算（Rust WebAssembly）」「厳格な型境界を持つ最小API（Rust Axum/Actix + PostgreSQL RLS）」の3層分離です。

まず第1層として、記事やページコンテンツはCI/CDパイプライン上でAstroによって純粋な静的HTML/CSSへ事前コンパイルされ、公開エッジサーバー（Nginx）には一切の動的インタプリタ（php-fpm / cgi-bin / node）を配置しません。

次に第2層として、従来ならサーバー側のPHPで処理していた「サイト内検索」「リスク自己診断」「料金・スコア計算」などのインタラクティブ機能は、Rustからコンパイルした `.wasm` モジュールとして訪問者のブラウザ内の線形メモリサンドボックスで高速実行します。

そして第3層として、どうしてもサーバー側で状態保存が必要なお問い合わせ送信などだけを、JSON SchemaおよびRustの代数的データ型（`serde` + 厳格バリデーション）で保護された単一機能のマイクロエンドポイントで受け取ります。

CVE-2012-1823の修正パッチでは、クエリ文字列の先頭が半角ハイフン `0x2D`（`-`）である場合にオプション解釈を抑止するエスケープ処理が追加され、12年間にわたり安全だと信じられてきました。

しかしWindows OSのWin32 API（`WideCharToMultiByte` 等）が内部で行う文字コード変換には、Unicode文字をマルチバイト文字セット（日本語CP932 / Shift_JIS、簡体字中国語CP936、繁体字中国語CP950）へ変換する際。

完全一致する文字がない場合に「最も形が似たASCII文字へ勝手にマッピングする（Best-Fit Mapping）」という仕様が存在します。

攻撃者がHTTPリクエストのクエリ文字列として `%ADd+allow_url_include%3d1+-d+auto_prepend_file%3dphp://input` を送信すると、WebサーバーおよびPHPのエスケープ検査段階では先頭バイトが `0xAD`（ソフトハイフン）であるため。

`0x2D`（`-`）のブラックリスト検査をすり抜けます。

ところがその後、Windowsカーネルがコマンドライン文字列をCP932ロケールで変換した瞬間、ソフトハイフン `0xAD` がベストフィット変換によって本物のASCIIハイフン `0x2D`（`-`）へと化け。

`php-cgi.exe -d allow_url_include=1 -d auto_prepend_file=php://input` という任意コード実行オプションとして解釈されてしまいます。

これにより、認証を一切経ることなく、HTTP POSTボディ（`php://input`）に記述された任意のPHPコードがサーバー上で即座に実行（Unauthenticated RCE）されるという致命的な事態が発生しました。

この事例が示す本質的な教訓は、「ブラックリスト方式のエスケープ処理は、OSロケール変換や複数レイヤー間の文字解釈の不一致（Parser Differential）によって容易にバイパスされる」という点にあります。

の命令空間 $\mathcal{I}_{\text{exec}}$ への到達可能な合成写像 $f_{\text{eval}} \circ f_{\text{parse}} : \Sigma^* \to \mathcal{I}_{\text{exec}}$ が存在することと同値です。

従来のWAF（Web Application Firewall）やエスケープ関数は、入力部分集合 $\Sigma_{\text{bad}} \subset \Sigma^*$ をヒューリスティックに除去する試みですが。

文字エンコーディング層とコマンドパーサ層の意味論的乖離（Semantic Gap / Parser Differential: $D_{\text{WAF}}(x) \neq D_{\text{Runtime}}(x)$）が存在する限り。

バイパス入力 $x^* \in \Sigma^* \setminus \Sigma_{\text{bad}}$ の存在をゼロにはできません。

これに対し、オープンナレッジが採用する「静的分離アーキテクチャ」では、公開オリジンサーバー（`ap01.ok.st`）のプロセス空間から動的スクリプト解釈器（PHP / Python / Perl / Node.js `eval`）およびシェル呼び出し機構を物理的に除去し。

$\mathcal{I}_{\text{exec}} = \emptyset$（空集合）とします。

公開されたファイルシステムは OpenZFS データセット上で `readonly=on` かつ 256-bit 暗号学的ハッシュ木（Merkle Tree: 各 `blkptr_t` が子ブロックの SHA-256 / Fletcher4 チェックサムを保持）としてマウントされるため。

任意のHTTPリクエスト $r \in \Sigma^*$ に対してサーバー状態遷移は $\Delta S(r) = 0$（純粋関数的な読み取り応答のみ）に束縛されます。

さらに、エッジ前段のURI正規化およびAPIゲートウェイ層は、`#![forbid(unsafe_code)]` を強制した Rust 2024 で実装され、スライス境界検査付きの決定論的有限オートマトン（DFA）として $O(N)$ 時間・ゼロヒープアロケーションでリクエストターゲットを検証します。

これにより、CP932 Best-Fit Homograph（`0xAD`, `0xC2 0xAD`, `0xE2 0x80 0x90..0x95`）、Null Byte Injection（`0x00`）、Path Traversal（`..`）、および不正なパーセントエンコーディングは。

バックエンドルーティングに到達する前の型境界で数学的に100%拒絶されます。

下に示す Rust 2024 実装コードおよび Kani / 形式的プロパティ検証テストは、すべての256通りのバイト値と任意のURI長に対してパニックゼロ（Panic-Free）・メモリ安全・決定論的拒絶を保証する実行可能な証明（Executable Proof）です。

言語処理系の観点では、従来のインジェクション脆弱性はLexer（字句解析器）およびParser（構文解析器）へ渡る前の生文字列連結によってAST（抽象構文木）が書き換えられる現象であり、Rustの線形型（アフィン型システム）とFreeBSD Jails / Capsicumによるプロセス権限隔離を組み合わせることで、構造的に排除されます。