メタ:
- id: mdrust-wordpress-static-blog-php-security
- slug: mdrust-wordpress-static-blog-php-security
- url: /blog/mdrust-wordpress-static-blog-php-security/
- title: PHPの脆弱性で考える個人ブログの安全性。実際にWordPressをやめて静的HTMLへ移行したら思わぬ不便があった話
- date: 2026-10-22 18:10
- tags: Web, Security, Rust, AI, Projects

本ブログは、たまたま数か月前からWordPressをやめ、すべての記事をMarkdownの`.md`ファイルで管理し、静的なHTMLに書き出すシステムを構築して切り替えていた。原稿から公開前にページを作る、いわゆるAstro的な構成だ。

Astro  
[https://docs.astro.build/…/on-demand-rendering/](https://docs.astro.build/en/guides/on-demand-rendering/)

そこへ、PHPの重大な脆弱性のニュースが届いた。WordPressなどが使うPHPの実行環境に問題があり、影響を受ける構成ではログインせずに攻撃者のコードを実行されるおそれがある。かなりヤバい問題だ。

修正版は2026年10月21日に公開された  
[https://www.php.net/archive/2026.php#2026-10-21-5](https://www.php.net/archive/2026.php#2026-10-21-5)

このニュースを見て、サーバーで動くCMSという記事管理システムから、静的HTMLをFTPで公開する方式へ、まさか古い流れに戻るのかと感じた。大規模言語モデルであるLLMの登場によって、記事中心の用途では、昔ながらの静的HTMLが最先端の選択にも見えてくる。この巡り合わせが面白くて、記事にしたくなった。

## 静的HTMLは、攻撃される入り口そのものを減らせる

WordPressのような動的CMSは、通常、PHPを動かし、データベースから記事を取り出してページを作る。管理画面、プラグイン、画像のアップロードなど、外部からの入力を受け付ける処理もある。

こうした処理に欠陥があると、不正な入力から改ざんやコード実行につながる。ログイン前に動く処理の欠陥は、管理画面のパスワードを強くするだけでは防げない。会員情報を扱うサイトなら、情報流出に発展するおそれもある。

本ブログの方式では、記事の作成やHTMLの生成を手元のパソコンで済ませ、公開サーバーは完成済みのHTMLを返す。公開用CMSや記事用データベースを置かないので、それらを狙う攻撃経路を減らせる。使わない出入口そのものをなくす考え方だ。[https://cheatsheetseries.owasp.org/…/Attack_Surface_Analysis_Cheat_Sheet.html](https://cheatsheetseries.owasp.org/cheatsheets/Attack_Surface_Analysis_Cheat_Sheet.html)

ただし、HTMLに置き換えても、古いPHPやCMSが外部から動かせる状態で残っていれば危険は残る。Webサーバーや編集用PC、転送アカウント、配信するJavaScriptの保守も必要だ。

しかし実際に運用してみると、CMSを使っていたときには意識しなかった不便に直面した。

## 1\. Markdownは、人間には読みにくかった

原本は`.md`がよさそう、と少し安易に決めた。Markdownは見出しや箇条書きを記号で書くテキスト形式だ。AIに渡しやすく、整理もしやすい。しかし、そのまま眺めても画像の並びや余白など、記事の感じがつかめない。ブログを書くってレベルじゃない。

試行錯誤の末、MarkdownをHTMLに変換して表示し、その上で編集できるビジュアルエディターを作った。原本はMarkdownのまま、公開ページに近いデザインを見ながら書ける。これで一気に作りやすくなった。WordPressよりデザインそのままに編集できる。ずっとよくなった。

![左に原稿一覧、右に公開サイトに近いデザインの記事一覧を表示した画面](/blog-assets/media/d1430e8f6c54d8864813801cdb534ffda5167a4afb0a7c59de9affaed7fae620/mdrust-editor-overview-20261022.png)

## 2\. タイトルやタグの管理が困難になった

CMSでは当たり前の機能であるが統一された方式がなくなった。ファイルを並べただけでは、タイトル、日付、タグ、代表画像などを管理しにくい。とても困った。そこで原稿の先頭に、記事の設定をまとめるfrontmatterを付けた。短い例なら、こうなる。

```yaml
---
title: "31.5型4Kモニターを使ってみた"
date: "2026-10-18"
draft: false
tags: ["PC", "Review"]
---
```

実際には説明文、代表画像、記事の識別子やURL名も持たせる。共通のレイアウトと組み合わせてページを作り、タイトルや日付、タグは画面から編集できるようにした。情報の置き場所と操作画面がそろうと、管理の不便は気にならなくなった。

## 3\. 見出しや引用の記法を、毎回思い出すのが面倒だった

H1、H2といった見出しや引用、表、YouTubeの埋め込み。記事を書くたびに記法を思い出すのは面倒だ。というか.mdの方式はシャープ二つとか、簡単なのだけど馴染みがない。

見出しや引用を挿入パネルから選び、YouTubeのURLから埋め込みを作れるようにした。原稿の保存形式がMarkdownでも、人間が記号を全部手打ちする必要はない。

![見出し、リスト、引用、表などを選べる挿入パネル](/blog-assets/media/e46e710ce10905807e3f923cddb0a74c05999d3f030e27123c96bfe499718641/bandicam-2026-10-22-21-26-06-973.webp)

## 4\. 1つの記事の更新でも、公開までに時間がかかった

本システムは、1記事を更新するだけでも、ブログの記事ページや一覧、検索用データをまとめて再生成する構成にした。静的サイトだから必ず全件の作り直しが必要というわけではなく、これは本システムの作りによるものだ。公開前の比較やコピーにも時間がかかり、送信を待つ以前の処理が重かった。10分ぐらいかかってしまった。どうしようもない。

そこで生成対象をブログに絞り、同じ内容のファイルは書き直さないようにした。前回このPCから公開に成功した内容と比較し、追加・変更分だけを転送用にコピーして送る。ファイルの識別情報や変更情報が同じなら、内容照合の計算結果も再利用する。

ブログの各ページを再生成する処理は残っている。通常の更新では、全件の遠隔照合や不要なコピー・転送を省くことで、待ち時間を減らせた。これで許容できる時間で公開できるようになった。100記事ぐらいなら問題ない。1000記事になるとどうだろうか。

![記事の原本はMarkdownファイルとして保存している](/blog-assets/media/f080f77d8c622ebd59491907c65ba8084f35f50bbfbdf2c28be88731487a8a64/bandicam-2026-10-22-21-27-21-872.webp)

## 5\. 画像や動画の再アップロードが負担になった

特に重いのが画像や動画だ。本文を少し直しただけなのに、大きな素材まで送り直すのはつらい。30分とか60分とか時間がかかった。これはひどい。

素材の内容から作る識別子を公開URLに含め、同じ素材は同じURLで再利用するようにした。公開済みの記録と照合し、変わっていない素材は再送しない。新しい画像や動画は送るが、記事の更新ごとに全部送り直すことはなくなった。

![変更したファイルを転送し、公開先の内容を確認している画面](/blog-assets/media/99b97134decf87e1d3be015bb1718af3a7ef9b2626a622f8b26f36911c4618a9/bandicam-2026-10-22-21-29-41-365.webp)

## 6\. 記事を下書きに戻しても、公開先には残っていた

原稿を削除したり下書きに戻しても、公開済みのHTMLはサーバーに残る。記事の削除や公開対象からの除外は、意外に面倒だった。原稿の`.md`と、そこから書き出したHTMLを別々に扱う必要があるためだ。

今は公開を取りやめる記事を記録し、次の公開処理で反映する。公開の記録がある記事について、削除対象とサーバー上の内容を照合し、該当するHTMLと公開用Markdownだけを削除する。

画像や動画は自動削除しない。他の記事でも使っている素材を巻き込まないためだ。記事と素材を分けて扱うことで、運用しやすくなった。不要になった画像や動画の整理は、そのうち対策する。

## 7\. 自宅のPCでしか、記事を更新できなくなった

原稿も編集環境もローカルにある。WordPressのように、別の場所から管理画面を開いて更新する使い方ができなくなった。これが一番不便だった。今の運用では、原稿と公開の記録を同じPCにまとめているため、別のPCへ気軽に切り替えられない。つまり原本がある1台のパソコンからの作業が必要だ。

そこでDotsなどのエージェントを通じて、スマートフォンから自宅PCでの原稿修正を指示できるようになった。外出先で気づいた修正をその場で頼めるようになり、この不便もずいぶん小さくなった。1台のPCは常時LLM用に電源を入れてある。なんかサーバーに近い稼働になった。

## その結果メリットも増えてきた

2-3か月かけて、いろいろな不便を直したらだいぶ使いやすくなった。また大きなメリットも出てきた。原本が.mdファイルなので、マルチランゲージの変換が簡単にできることや、表示速度が速くなったことなどだ。リモートでLLMに記事の下書きを頼むことも増えた。だんだん便利になった。

## ざっと仕組みを紹介、参考になればうれしいな

全体の流れは、次のようになる。

```text
手元のPC：Markdown＋画像 → ビジュアル編集 → HTML・一覧・検索データ
公開先　：確認した変更分をFTPSで受け取り、読者へ配信
```

FTPSはファイル転送の通信を暗号化する方式だ。ファイル操作とHTML生成はRustで実装し、編集画面には、Windowsアプリ内にWeb画面を表示するWebView2を使っている。公開サーバーで記事を組み立てるCMSは動かさない。

自作するなら、まず1記事をHTMLにするところから始め、共通レイアウト、記事管理、公開処理を足していくと考えやすい。

結局、CMSが引き受けていた仕事を、手元のPCで少しずつ作り直していた。Markdownを選ぶだけで完成ではなく、編集と管理と公開まで整えて、ようやく使いやすくなった。同じようなブログを考えている人の参考になればうれしい。