PHP炎上中

PHPが燃え盛っているのを見て、背中に冷や汗が走った。 実を言うと、このブログエンジンを作る前、一瞬ワードプレスを使おうか悩んで、PHPでも勉強すべきか真剣に頭を抱えた記憶がある。 ワードプレス特有の重さや、何よりカスタマイズが事実上不可能な構造が気に入らなかったりもして。あの時、ただ自分で作っておいて本当によかったと思う。

1. PHP炎上中

PHPのコア部分のメモリ管理が崩壊し、認証すらいらないRCE（CVE-2026-109618など）が発生。 PHP-FPMやmod_phpを使っているサーバーはアプリコードが実行される前にお陀仏になる構造で、特にまだパッチもない7.x系を使っているところは完全に詰んでいる状態。 人ごととはいえ、トラッカーの上がっていく様子を見るだけで目眩がする。

2. じゃあNodeは安全なのか？（SKBEは実はNodeですらない）

「じゃあNodeは安全なのか？」と考えを巡らせていて、ふと気づいた。 そもそも自分がデプロイしたのは純粋なNode.js環境ではなく、Cloudflare Pagesの nodejs_compat（互換モード）だ。従来のNodeランタイムとは毛並みが全く違う。 思い返せば、開発時に素のNodeの機能やライブラリが互換しなくて死ぬほど苦労してあちこち直した記憶があるが…… ここまで来ると、当時の苦行もセキュリティ観点ではむしろプラスだったのではと思えてくる。 そもそもLinuxサーバーに直接インスタンスを立てる構造ではなく、CFPエッジのV8サンドボックス上で動いているため、仮に突破されても中で大人しく潰れるしかない。 最悪のシナリオはDBの削除だが、バックアップ・復元構造を簡単に作っておいたのでユーザーがちゃんとバックアップを取っていれば問題ないはず。

3. SvelteKit Blog Engineの構造

セキュリティをめちゃくちゃ頑張ったというより、自分のセキュリティ知識が浅いと自覚していたので、攻撃表面（Attack Surface）自体を物理的に削ぎ落とした。

• DB書き込み機能ゼロ（無）： ブログ本体にはCUD（Create、Update、Delete）ロジックが一切ない。純粋にReadのみなので、ハッキングされても改ざんすべきデータがない。

• 管理者モードの隔離： ブログと管理者ページを完全に別々にデプロイし、デプロイ時に自動注入された指定IPでなければルーティング段階でアクセス自体をブロックするようにした。

• コメント／ゲストブック： 唯一の書き込み窓口だが、MDやHTMLのパースは一切しない。生の文字列（Raw String）だけを受け取り、フロントでもText Nodeとしてのみ描画されるように処理。Stored XSSを仕掛けようとしても、スクリプトタグがそのまま綺麗な文字列として画面にレンダリングされる。

自分の無知を自覚していたからこそ、最初から守るべきものをなくす設計にしてかえって気が楽になった。 もともと誰も来ないんだから、一層寂しくも気楽なもんだ。

こうして私は、誰も来ない、ハックしようのないブログエンジンを作り上げた。（泣）