セキュリティ特設
当サイトの守り方と脆弱性レポート
10月31日に再測定。推奨ヘッダー5種類が応答に未検出です。設定例は作成済み、本番への適用は未確認。侵害や脆弱性件数を示すものではありません。2026.10.31
公開サイトの観測結果と、これから行う設定を区別して掲載します。HTMLをアップロードしてもサーバーのHTTPヘッダーは自動で変わりません。推奨設定の欠落は防御強化の課題であり、侵害確認ではありません。
1. 今回の観測と限界
10月31日22:18ごろ（日本時間）、トップページをcurlとSiteCheck CLIで再測定。HTTP 200、Serverはnginx、X-Content-Type-Optionsはnosniffでした。Seoryの「要対応0件・注意3件」は10月26日の過去の診断であり、現在の安全性の保証や今回の5項目と同じ分類ではありません。
2. 推奨ヘッダーの確認結果
| 項目 | 観測 | 対応の考え方 |
|---|---|---|
| HSTS | 応答に未検出 | HTTPS運用を確認し短期間から導入。全サブドメイン指定は事前確認。 |
| X-Frame-Options | 応答に未検出 | 必要な埋め込みを確認し制限を設計。CSP frame-ancestorsも検討。 |
| CSP | ヘッダー未検出 | Report-Onlyから評価。Playground・外部CDNなどの機能検証が必要。 |
| Referrer-Policy | 応答に未検出 | ブラウザ既定値もあるため、欠落だけで情報漏洩とは判定しない。 |
| Permissions-Policy | 応答に未検出 | 使用しない機能を制限。必要な機能を先に確認。 |
3. 設定例と本番適用を混同しない
同梱のsecurity-headersは例です。現在のレンタルサーバーで使用可能な設定方法は未確認で、nginxの応答だけから編集権限や内部構成を決めつけることはできません。設定例を公開フォルダへ置くだけでは有効になりません。
Cloudflareへ移す場合は静的アセットの所定位置に_headersを配置し、確認環境で動作と応答を確認してから本番へ反映します。CSPのReport-Onlyは遮断しません。Playgroundを含むサイト全域へ強いCSPを一括適用すると機能を壊す可能性があります。
4. 断定しない事項
- X-Powered-Byやgeneratorの非開示は問題ではなく、PHP不使用の証明でもありません。
- X-XSS-Protection: 1; mode=blockは観測しましたが、非推奨であり「害がない」とは断定しません。現代的な対策の代わりにしません。
- 静的サイトであることだけでCSPの不要や低リスクを判断しません。
- 外部診断から内部更新・侵害の有無は分かりません。
参考：Cloudflareヘッダー設定 ／ MDNの注意事項
5. 点検に使うツール第三者検証
php2shellへの対応と、コードそのものの監査に使える2つを、実際に動かした結果つきで紹介します。
5-1. php2shell-checker（OpenAI）確認済み
PHP2Shell（CVE-2026-109618／109619）について、「この版は修正済みか」だけを判定する単機能のツールです。Apache License 2.0。悪用の試行は一切送りません。
| 入手 | 使い方 |
|---|---|
| Codexのスキルとして | $skill-installer install both skills from https://github.com/openai/php2shell-checker |
| URLだけ分かる場合 | $phpcheck-url check https://example.com |
| サーバーに入れる場合 | $phpcheck-server check the PHP version serving my site |
| 直接実行（Node.js） | node phpcheck.js "https://example.com" ／ JSONは --json |
| 結果 | 終了コード | 意味 |
|---|---|---|
OK | 0 | 公表されている版が、上流の修正版に達している |
POTENTIALLY VULNERABLE | 1 | 影響範囲の版。PHP 5.4〜5.6／7.0〜7.4／8.0／8.1は8.1.35のような高いパッチ番号でも警告 |
UNKNOWN | 3 | 版が無い・読めない・プレリリース・検査失敗 |
| 引数エラー | 2 | — |
修正版は8.2.35／8.3.36／8.4.27／8.5.12。URLモードは X-Powered-By と Server を読み、HEAD を送り、405／501のときだけ GET に落とします。転送は追わず、本文も見ません。版を隠しているサイトは UNKNOWN になります。
当サイト aifrontier.co.jp は UNKNOWN: PHP version not found（終了コード3）。外からPHP版を取得できなかったという結果であり、PHP不使用・修正済みの証明ではありません。あわせて php.net、ja.wordpress.org、drupal.org、sakura.ad.jp も試しましたが、5サイトすべて UNKNOWN でした。版を隠すのが標準になった現在、このツールが効くのは版を開示しているサーバーだけです。
作者自身が明記しています。HTTPヘッダからは、バックポートで修正済みかどうかは分かりません。OK は「公表されている版が新しい」というだけで、実際のインストールを検証したわけではありません。逆に UNKNOWN は「安全」でも「危険」でもありません。サーバーに入れる phpcheck-server を使えば、この限界を越えられます。
5-2. security-audit-skill（Cloudflare）確認済み
コーディングエージェントを監査役に変えるスキルです。Cloudflareが自社の脆弱性発見ハーネスの出発点として公開したもので、MITライセンス。
npx skills add https://github.com/cloudflare/security-audit-skill --skill security-audit
# ユーザー単位で入れる場合
npx skills add https://github.com/cloudflare/security-audit-skill --skill security-audit --global入れたあとは、対象のコードベースでエージェントを起動して、普通の言葉で頼むだけです。
security audit this codebase
find security vulnerabilities in ./src
do a security review, output to ~/audits/my-project「セキュリティ監査」「脆弱性を探して」「ペンテストして」に反応して自動で起動します。直接の監査依頼はフル監査モード、質問や限定作業はガイダンスモード。出力先を指定しない場合の既定は ~/security-audit-skill/<repo名>/run-N です。
中身は6段階です。①偵察（architecture.md と coverage-ledger.json に、構造・信頼境界・入力面・既存の証拠・決定的なカバレッジを落とす）→②カバレッジ主導の探索（台帳の単位ごとに独立した hunter を割り当て、coverage critic が穴を探す）→③候補の検証（候補ごとに別の検証役が反証を試みる）→④構造化出力（confirmed／needs_validation／rejected を findings.json に書き、report-schema.json で検証）→⑤記録の独立検証→⑥中立的な報告書（REPORT.md／FINDINGS-DETAIL.md／NEEDS-VALIDATION.md）。
| 前提 | 内容 |
|---|---|
| モデル | ツール使用と並列サブエージェントに対応していること |
| Node.js | 検証スクリプト（validate-findings.cjs など）の実行に必要 |
| サンドボックス | OSレベルの隔離。外部ネットワーク遮断、環境変数のホワイトリスト化、資源制限、書き込みは割り当てたスクラッチのみ |
仕様として、対象コードの実行をやめ、判定を needs_validation に留めます。「実行しないから安全」ではなく、確証が得られないので確定にしないという設計です。
設計の原則も明確です。①確定するのは境界の破れだけ（多層防御の片方が無いだけなら「強化の提案」であって脆弱性ではない）②検証する側は発見した側と別人（adversarial validation）③深刻度には影響が必要（チェックリストからの逸脱では付けない）④同じリポジトリへの複数回の実行は加算的——試験では1回の実行で、複数回の合計のおよそ半分しか見つからなかったと書かれています。
AIfrontierの見解 当サイトは静的HTMLでサーバー側のコードを持たないため、このスキルの本領が出る対象ではありません（HTMLとCSSに「境界の破れ」はほぼ無い）。効くのは①ビルド用スクリプト（ainews_to_obsidian.py や sitecheck.py）②受託で作るアプリケーション③WordPressのテーマ・プラグインです。サイト本体の点検は、前段のヘッダ実測とphp2shell-checkerで足ります。
php2shell-checkerは「PHPの版が修正済みか」の1点だけを、URLでもサーバーでも判定する単機能・即答の道具。security-audit-skillは「コードに境界の破れがあるか」を時間をかけて調べる監査の型。前者は今日の対応、後者は設計とリリース前の確認、という役割分担になります。
6. 自端末のランタイムを更新する（Mac／Windows／Linux）AIfrontierの見解
脆弱性の多くは「アプリ」ではなく土台に入ります。php2shell がPHP本体だったように、Node.js・Python・Perl・Ruby・PHPの本体に穴が開けば、その上で動くすべてのアプリが影響を受けます。当方もMacで brew update → brew upgrade node で確認と更新を行いました。ここではOSごとの定番手順をまとめます。
6-1. まず「どこから入れたか」を確かめる
更新が効かない原因の大半は、入れた経路と更新した経路が違うことです。OS標準・パッケージマネージャ・バージョン管理ツールの3系統があり、それぞれ別物として更新されます。
| 言語 | 版の確認 | 入っている場所の確認 |
|---|---|---|
| Node.js | node -v | which -a node（Windowsは where node） |
| Python | python3 -V ／ python -V | which -a python3 |
| Perl | perl -v（先頭2行に版） | which -a perl |
| Ruby | ruby -v | which -a ruby |
| PHP | php -v | which -a php |
6-2. macOS――Homebrew
brew update # 式（formula）の一覧を最新化
brew outdated # 更新があるものを一覧
brew upgrade node # Node.js だけ更新（ご自身の手順）
brew upgrade # 入れてあるものをまとめて更新
brew list --versions node # 入っている版の確認| 言語 | 式の名前 |
|---|---|
| Node.js | node |
| Python | python@3.14（版ごとに別の式。複数併存します） |
| Perl | perl |
| Ruby | ruby |
| PHP | php |
①標準のRubyとPerlはOS管理です。/usr/bin/ruby・/usr/bin/perl はSIPで保護され、brew upgrade では変わりません。触らず、rbenv や perlbrew、Homebrew の式を使ってください。②brew install node は「最新のCurrent」が入ります。本番はLTS推奨なので、LTSを固定したいなら nvm／volta を使います。③更新後にシェルの記憶を消す。hash -r（bash）または rehash（zsh）を実行しないと、古いパスを掴んだままになります。
6-3. Windows――winget／Chocolatey／Scoop
winget list # 入っているものと版
winget upgrade # 更新があるもの
winget upgrade --all # まとめて更新（管理者権限の推奨）
winget upgrade OpenJS.NodeJS.LTS| 言語 | winget のID（例） |
|---|---|
| Node.js | OpenJS.NodeJS.LTS／OpenJS.NodeJS（Current） |
| Python | Python.Python.3.14（版ごと） |
| Perl | StrawberryPerl.StrawberryPerl |
| Ruby | RubyInstallerTeam.Ruby.4.0（Microsoft Store版もあり） |
| PHP | winget search php で確認（配布元が複数あります） |
Chocolateyなら choco upgrade all -y、Scoopなら scoop update *。 winget・Chocolatey・Scoop・公式インストーラ・Microsoft Store が混在すると、同じ言語が複数入ります。まず winget list node で重複を確認してください。
6-4. Linux――ディストリビューションのパッケージ管理
# Debian / Ubuntu
sudo apt update && sudo apt upgrade
sudo apt install --only-upgrade nodejs python3 perl ruby php
# RHEL / Fedora
sudo dnf upgrade --refresh
# Arch
sudo pacman -Syu
# openSUSE
sudo zypper updateディストリビューション版は安定性優先で古いことがあります。Node.jsなら NodeSource のリポジトリ、Pythonなら deadsnakes、Rubyなら rbenv、PHPなら各ディストリのサードパーティ（Remiなど）を使うのが定番です。自動更新は unattended-upgrades（Debian系）や dnf-automatic（RHEL系）でセキュリティ更新だけ当てられます。
6-5. 複数の版を持ちたい場合――バージョン管理ツール
| 言語 | ツール | 更新の例 |
|---|---|---|
| Node.js | nvm／fnm／volta | nvm install --lts → nvm alias default 'lts/*' |
| Python | pyenv／uv | pyenv install 3.15.0 → pyenv global 3.15.0 |
| Perl | perlbrew／plenv | perlbrew install perl-5.44.0 → perlbrew switch perl-5.44.0 |
| Ruby | rbenv／RVM | rbenv install -l → rbenv install 4.0.9 → rbenv global 4.0.9 |
| 横断 | mise／asdf | mise use -g node@lts python@3.15 ruby@4.0 |
逆も同じです。brew upgrade node はHomebrewで入れたNodeしか上げません。pyenv配下のPythonは pyenv で、rbenv配下のRubyは rbenv で更新します。「更新したのに版が変わらない」ときは、まず which -a で経路を確認してください。
6-6. 言語ごとの現在地（2026年10月26日時点）
| 言語 | 最新 | 推奨 | 注意 |
|---|---|---|---|
| Node.js | v26（Current） | v24 LTS（Krypton）／v22 LTS（Jod） | v25はEOL。本番はLTSのみ |
| Python | 3.15 | 3.15／3.14 | 3.10は2026年10月末でEOL |
| Perl | 5.44.0 | 5.44／5.42 | 5.40系は保守のみ |
| Ruby | 4.0.9 | 4.0／3.4.12 | 3.3はセキュリティ保守のみ（EOL間近）、3.2はEOL |
| PHP | 8.5.12 | 8.5／8.4.27 | 8.3.36・8.2.35もphp2shell修正済み。8.1以前は公式修正なし |
版は各プロジェクトの公開情報にもとづく2026年10月26日時点の値です。更新は頻繁なので、実行前に公式サイトで確認してください。
6-7. 更新したあとにやること
- ネイティブ拡張の再ビルド：Node.jsなら
npm rebuild、Rubyならbundle install、Pythonならpip install -r requirements.txt --force-reinstallが必要な場合があります。 - シェルの記憶を消す：
hash -r（bash）／rehash（zsh）。 - 版を固定するファイルを置く：
.nvmrc、.python-version、.ruby-version、.tool-versions。チームとCIで同じ版に揃います。 - Docker・CIも同じ版に：手元だけ上げても、コンテナ内が古ければ意味がありません。
FROM node:24のようにタグを見直します。 - 戻せるようにする：
brewはbrew list --versionsで旧版が残ります。バージョン管理ツールなら1コマンドで戻せます。
6-8. 「更新したつもり」の落とし穴
- 同じ言語が複数入っている：
which -a nodeで2行以上出たら混在しています。 - 管理者権限で入れた版と、ユーザー領域の版：PATHの順序で決まります。
echo $PATHを確認。 - IDE・エディタが別の版を見ている：VS Codeの統合ターミナルとGUI起動でPATHが違うことがあります。
- EOL版はいくら最新にしても穴が残る：php2shellで8.1以前に公式修正が出なかったのと同じです。版を上げるのが唯一の解です。
6-9. 気づく仕組みにする
brew outdated # macOS
winget upgrade # Windows
apt list --upgradable # Debian / Ubuntu
npm audit --omit=dev # Node.js
pip-audit # Python
bundle audit check --update # Ruby
composer audit # PHP週1回これらを流すだけでも、「半年気づかない」を防げます。リポジトリ側は Dependabot や Renovate で依存の更新を自動化し、ランタイム本体は人の手で四半期ごとに見直す、という分担が現実的です。
7. 2026年10月の主要脆弱性 総覧（新設）確認済み
10月中旬から下旬にかけて、PHP・Linuxカーネル・GitLab・Oracle Java・LiteLLM・BIND 9など基盤に重大な脆弱性が相次ぎました。16コンポーネント・50件超のCVE・うちCVSS 9.0以上が8件です。優先度・全体像・章別の詳細を、専用の特設にまとめました。
個別レポートの詳細は各ページに。出典は各ページ末に掲載しています。
8. 脆弱性レポートの置き場所AIfrontierの見解
このページは、当サイトが扱うソフトウェアの脆弱性レポートの索引を兼ねます。個別のレポート（PHP、Node.js、Python、Ruby、Java、Linuxカーネル、GitLab、Tomcat など）は、版を重ねながらここに追記していきます。
| 日付 | 対象 | 内容 |
|---|---|---|
| 2026.10.26 | 2026年10月の主要脆弱性（16コンポーネント） | PHP／Node.js・Bun／Python／Ruby／Java／BIND 9／カーネル／GitLab／Tomcat／LiteLLM ほか。総覧へ |
| 2026.10.26 | 当サイトのPHP稼働有無 | php2shell-checker で UNKNOWN（終了コード3）。PHP非稼働のため妥当。5-1 |
| 2026.10.26 | 当サイト（aifrontier.co.jp） | 外部診断で「要対応0件・注意3件」。HSTS／X-Frame-Options／CSPの未設定を確認し、nginx設定を用意（本ページ） |
| 2026.10.21 | PHP 8.2〜8.5 | CVSS 9.2の未認証RCE 2件（CVE-2026-109618／109619）。php2shell の記事 |
個別レポートの原稿は、受領後にこの表へ追加し、詳細ページを /security/ 配下に置きます。「載っていない＝安全」ではありません。当サイトが扱っていない製品の脆弱性は、各ベンダーの告知を直接確認してください。
9. 見えてきたことAIfrontierの見解
今回の3件は、「外から見える範囲」で見つかる最後の数%です。静的サイトにとって本質的なリスクは、ヘッダの不足よりも①ドメインと証明書の管理 ②ビルド環境やアップロード経路の侵害 ③参照している外部スクリプト（CDN）の乗っ取りに移っています。実際、当サイトは Tailwind と cdnjs をCDNから読んでおり、CDN側が侵害されればCSPだけでは守りきれません。
実務的な含意は3つです。①ヘッダは「入れて終わり」ではなく、CDNを含めて通っているか確認する（オリジンだけ設定して満足しがちです）。②CSPは段階的に——まず frame-ancestors と default-src、次にインラインの外部化。③診断ツールの「0件」を成果として報告しない。範囲外の中身（更新状況・改ざん・権限）は、別の手段で見る必要があります。
出典
- Seory「サイトセキュリティチェック」（外部診断ツール、2026年10月26日実施） https://tools.seory.co.jp/site-security-check
- 本サイトの実測：https://aifrontier.co.jp/ のレスポンスヘッダ（nginx、2026年10月26日 13:41 JST 取得）
- 本サイト「php2shell――PHPにCVSS 9.2のRCE」（2026年10月22日） /ai-news/php2shell-2026-10-22.html