VvvebのテーマのZIPでPHPを動かせる脆弱性　nginxの設定も直す

米国立標準技術研究所（NIST）の脆弱性データベース（NVD）は11月13日（日本時間）、オープンソースのCMS「Vvveb」の脆弱性「CVE-2026-126378」を公開した。開発者のadvisoryによると、テーマを取り込む機能の確認に欠陥があり、管理者の権限を持つ攻撃者が、nginxで動くサイトで任意のPHPのコードを動かせる。開発者は10月29日に1.0.9.0を出し、Webサーバーの設定例を改めた。サイトを動かす組織は、1.0.9.0に上げたうえで、nginxの設定も新しい例に合わせる。

1.0.8.6以前のVvvebが当たる

Vvvebは、ページビルダーを持つPHPのCMSで、ブログやECサイトを作れる。NVDと開発者のadvisoryの記載では、対象と深刻度は次のとおりだ。

• 対象: Vvveb（GitHubのgivanz/Vvveb）
• 当たるバージョン: 1.0.8.6以前
• 直ったバージョン: advisoryの欄は空。1.0.8.6の次は10月29日の1.0.9.0
• 深刻度: CVSS 4.0で9.4、CVSS 3.1で9.1（どちらも採番した米VulnCheckの評価）
• 弱点の種類: CWE-434（危険な種類のファイルの無制限なアップロード）。advisoryはCWE-22（パスの制限の不備）も挙げる
• 条件: 管理者の権限が要る

原因は、テーマのZIPを取り込む時に中のファイルを確かめる関数「validFile()」にある。正規の入口のファイル「theme.php」だけを通すつもりで、パスの末尾でなく「/theme.php」の文字列を含むかで判定していた。そのため、テーマの直下か下位のフォルダかを問わず、パスに「/theme.php」を含むPHPのファイルは中身によらず確認を通り、公開フォルダの下のテーマのフォルダに展開される。Apacheではテーマのフォルダの.htaccessがPHPの実行を止めるが、同梱のnginxの設定例は、メディアのフォルダでしかPHPの実行を止めていなかった。

バージョンと設定を確かめる

まず、Vvvebを置いたフォルダの直下のindex.phpを開き、「V_VERSION」の定義の値を見る。リリースに添付された配布ファイル（latest.zip）の1.0.9.0では、ここが「1.0.9.0」になっている。GitHubのソースの同じ場所は「0.0.7」のままなので、配布ファイルで入れたサイトの値で見る。1.0.8.6以前なら当たる。

次に、Webサーバーがnginxかを確かめる。Vvvebのnginxの設定例は、利用者が/etc/nginxの下に写して使う形なので、Vvveb本体を上げても設定は変わらない。使っている設定の「location ~ \.php$」の段が、どのPHPのファイルもそのままPHPの実行（fastcgi_pass）に渡す形で、テーマのフォルダ（/themes）にPHPを拒む設定が無ければ、テーマのフォルダの下のPHPのファイルが直接動く。

あわせて、テーマのフォルダに覚えのないPHPのファイルが無いかを見たい。1.0.9.0のlatest.zipでは、既定のテーマのPHPのファイルは、blog-defaultとlandingの直下のtheme.phpの2つだけだ。一般的なコマンドの「find public/themes -name '*.php'」をサーバーで実行すれば一覧が出る。配布ファイルに無いテーマのtheme.phpは、直下の物も下位のフォルダの物も、中身まで確かめたい。

1.0.9.0に上げて設定を差し替える

開発者は10月29日に1.0.9.0を出した。リリースノートは15件のセキュリティの修正を挙げ、その中に「Deny php execution inside media, themes and plugins directories」（変更）がある。この変更で、同梱のnginxの設定例は、管理画面とインストール、index.php以外へのPHPのアクセスを、すべてindex.phpに回す形になった。テーマのフォルダのPHPは直接動かない。

ただし、SAGUSが1.0.9.0のコードを読んだ限り、「/theme.php」の文字列で判定する確認は消えた一方で、テーマのZIPに入ったPHPのファイルを取り込みで拒む処理は無い。実行を止めているのはWebサーバーの設定だ。1.0.9.0に上げたうえで、nginxの設定のうちPHPを扱うlocationを、1.0.9.0のlatest.zipのnginx.conf（ソースではnginx-live.conf）に合わせる。設定を丸ごと上書きすると、サーバー名などの自前の設定を失うので、「location ~ \.php$」の段で管理画面とインストール以外のPHPをindex.phpに回す部分を写す。「nginx -t」で確かめてから読み込み直す。すぐに上げられない時も、advisoryが修正として挙げる、/themesの下のPHPを拒むlocationの設定は先に入れられる。

悪用の報告はまだ無い

CVE-2026-126378は、11月13日の時点で、米サイバーセキュリティ・インフラストラクチャセキュリティ庁（CISA）の悪用を確認した脆弱性の一覧（KEV）に載っていない。NVDと開発者、VulnCheckのadvisoryにも、悪用の報告は無い。管理者の権限が要るので、誰でも突ける穴ではない。ただし、開発者のadvisoryは10月29日から公開されており、再現の手順も載っている。管理者のパスワードが漏れていれば、乗っ取りにつながる。

SAGUSでは当たらなかった

SAGUSは、開発に使う端末の作業場所にある依存関係と設定のファイル（composer.jsonやDockerfileなど）を、grepで「vvveb」の語で検索し、見つからなかった。端末にはPHPもComposerも入っていない。本番のサイトとRolloutのサイトでは、Vvvebの管理画面の既定のパスに問い合わせ、どちらも404で、Vvvebは動いていなかった。SAGUSはVvvebを使っておらず、今回の脆弱性には当たらなかった。

編集部の見方

編集部は、この件の要点は、効いている対策がアプリのコードでなくWebサーバーの設定の例にある点だと見る。バージョンの番号だけを見る管理では、1.0.9.0に上げた時点で済んだと扱われ得る。Vvvebをnginxで動かす組織は、バージョンを上げた日に、使っている設定とテーマのフォルダの中身もあわせて見直したい。