JVNは11月4日にAkeebaの4製品のCSRFの脆弱性（CVE-2026-105296）を公表した。影響を受けない版の境目は、開発元が7月30日に出した版と一致し、97日の差があった ── 担当サイトの版と、管理画面の使い方を確かめる13項目（2026年11月時点）

目次

1. 01 何が書いてあるか — JVNは11月4日に公表した。影響を受けない版の境目は、開発元が7月30日に出した版と一致した
   1. JVNが書いたこと
   2. 開発元が7月30日に書いたこと
   3. 2つを並べて読む
2. 02 なぜ・背景 — CSRFは、ログインしている人の手を借りる攻撃である
   1. CSRFとは何か
   2. 防ぎ方は、「その要求が自分の画面から来たか」の確認である
   3. 開発元の評価と、ほかの出典の数字を、並べる
   4. 「悪用されていない」と「更新しなくてよい」は、別の話
   5. 間隔は、ベンダー告知を読む習慣の差になる
3. 03 用語 — 出てくる言葉を、先にそろえる
   1. 「更新」と「更新の確認」は別の作業
4. 04 型別 — 適用範囲、書かれていないこと、手順
   1. 🅰 どのサイトが当てはまるか
   2. 🅱 JVNと開発元が書いていないこと
   3. 🅲 手順 — 版を調べ、運用を見て、記録を残す
   4. 更新の前に知っておきたい、Joomla!用10.3.7の別の修正
   5. 運用で変えられること — 管理画面を開いたまま、別のページを見ない
5. 05 明日、担当サイトで確認できることチェックリスト
6. 06 代替・他の選択肢 — 更新、更新までの運用、バックアップの別の手段
   1. 選び方を、状況ごとに表で並べる
   2. ブラウザの既定のCookieの扱いは、守りの1つだが、頼りきらない
   3. 調べる道具
7. 07 当サイトで確かめたこと — この製品は使っていないが、画面の隠しの値は見られた
   1. この4つの製品は、使っていない
   2. フォームの隠しの値を、4回取って比べた
   3. この結果の読み方
   4. 確かめていないこと
8. 08 このテーマは、ここまで — 更新の記事から、管理用の部品の運用へ
   1. これまでの記事
   2. 今回の記事の位置
   3. 2026年11月6日 — この記事の確認日
9. 09 この記事のまとめ

01 何が書いてあるか — JVNは11月4日に公表した。影響を受けない版の境目は、開発元が7月30日に出した版と一致した

JVN（JPCERT/CCとIPAが運営する、脆弱性情報の公開サイト）は2026年11月4日に、「複数のAkeeba製品におけるクロスサイトリクエストフォージェリの脆弱性」を公表した。Akeebaは、JoomlaやWordPressなどのサイトのバックアップや、管理の補助に使われる製品を作っている会社である。CVE番号は、CVE-2026-105296である。この記事は、この件を、担当サイトの運営の側から読む。

JVNが書いたこと

JVNは、影響を受ける製品と版を、次の4つとして挙げている。表にまとめる。右の列は、開発元が7月30日のお知らせで「この日に公開した」と書いた版である。

製品	JVNが挙げた、影響を受ける版	開発元が7月30日に公開した版
Akeeba Backup for Joomla!	10.3.7より前	10.3.7
Akeeba Backup for WordPress	9.1.8より前	9.1.8
Akeeba Solo	9.1.8より前	9.1.8
Admin Tools for Joomla!	7.9.0より前	7.9.0

JVNは、原因を、「Akeeba Ltd.が提供する複数の製品では、いくつかの操作においてCSRF対策が適切に実装されていません。」と書いている。想定される影響は、「当該製品にログインした状態のユーザが細工されたページにアクセスした場合、意図しない操作をさせられる可能性があります。」である。対策は、開発元が提供する情報をもとに、最新版へ更新することである。どの操作が当たるかは、JVNのページには書かれていない。一方、Joomla!用10.3.7のリリースノートは、CSRFトークンを足した操作（リモート保存先のアーカイブの削除とダウンロード、移行ウィザード、アップロード、S3の取り込み、FTP/SFTPの接続試験、設定ウィザードなど）を挙げている。それがJVNの対象と同じ範囲かは、確かめていない。

JVNは、Akeeba Backup for Joomla!の項で、この脆弱性はIPAに報告があり、JPCERT/CCが開発元との調整を行ったと書いている。さらに、同じ項で、この製品の開発者は、この報告とは独立に脆弱性を見つけていて、対策済みの各版のリリース作業を進めていた、とも書いている。ほかの3製品の項に、同じ記述は無かった（筆者が読んだ範囲）。

開発元が7月30日に書いたこと

開発元のお知らせは、2026年7月30日付けで、4つの製品の新しい版を出したと書いている。冒頭に、こうある。

"These releases are mainly focused on security hardening."（訳: これらのリリースは、主に、安全の強化に力を入れている。）

お知らせは、アクセス権の確認の修正と、CSRFの確認の改善を挙げ、この件について、"none of the issues fixed could result in your site getting hacked"（訳: 修正した問題のどれも、サイトが乗っ取られる結果にはなりえなかった）と書いている。CSRFの改善については、最悪の場合の例として、バックアップ製品でサイトの外に置いた複製の削除（IDを知っている場合）と、Admin Toolsの一時フォルダの掃除の実行を挙げている。

2つを並べて読む

JVNが挙げる版の境目の番号は、開発元が7月30日に公開した版の番号と、4製品とも一致している。JVNは、開発元のお知らせを、ベンダーのリンクとして挙げ、NVDの記録も、そのお知らせを参考として挙げている。ここから、筆者は、JVNの影響を受けない版は、開発元が7月30日に出した版だったと読む。7月30日から、JVNが公表した11月4日までは、97日ある。この間隔の理由は、JVNにもお知らせにも書かれていない。

02 なぜ・背景 — CSRFは、ログインしている人の手を借りる攻撃である

CSRFとは何か

CSRFは、ログインしている利用者のブラウザに、本人が意図しない要求を送らせる攻撃である。CWEの説明（CWE-352）は、次のように書く。"The web application does not, or cannot, sufficiently verify whether a request was intentionally provided by the user who sent the request, which could have originated from an unauthorized actor."（訳: ウェブアプリケーションが、その要求が、要求を送った利用者によって意図して出されたものかを、十分に確かめていない、または確かめられない。その要求は、権限の無い者から出された可能性がある。）

OWASPは、ブラウザの要求には、そのサイトに結びついた認証の情報（たとえばセッションのCookie）が自動で付くので、サイトは、利用者本人の要求と、偽の要求を区別できないと説明している。

防ぎ方は、「その要求が自分の画面から来たか」の確認である

開発元は、自社の製品では、セッションのトークン（JoomlaとSolo）またはnonce（WordPress）を使うと書いている。どちらも、いまのログインに結びついた、予測できない値である。画面から出す要求に、この値を付けておき、サーバーが受け取ったときに照らす。WordPressの公式の説明には、"A nonce is a “number used once”"（訳: nonceは「一度だけ使う番号」である）とある。続けて、実際のnonceは厳密には数字だけでなく、一度だけ使われるわけでもなく、一定の寿命があると書いている。

開発元の評価と、ほかの出典の数字を、並べる

この件には、複数の出典が、それぞれの見方で点数や評価を付けている。1つにまとめず、出典ごとに並べる。

出典	書かれていた評価
JVN	CVSS v4.0の基本値5.1、CVSS v3.0の基本値5.4。利用者の操作が必要という条件が付く（UI:A、UI:R）
開発元（Joomla!用10.3.7のリリースノート）	CSRFの確認の追加は「LOW」。"The security issues addressed are low severity and we have no indication any of them were exploited"（訳: 対応した安全の問題は重大度が低く、悪用された形跡は無い）
NVD	点数は、JPCERT/CCが付けたものとして、JVNと同じ5.1と5.4が載る。NVD自身の分析は、状態が「Received」で、まだ分析されていない
NVDの記録に載った、CISAの評価	悪用「none」（確認されていない）、自動化「no」、技術的な影響「partial」（2026年11月4日14時53分、協定世界時）

4つの評価は、大きくは食い違っていない。どれも、悪用が確認されていない、重大度は中程度以下という読みに収まる。点数の「5.1」と「5.4」は、版の違いによる、同じ脆弱性への別の採点である。

「悪用されていない」と「更新しなくてよい」は、別の話

評価が低くても、更新の判断は、担当サイトの事情で決まる。たとえば、バックアップは、ほかの事故が起きたときに戻すための最後の手段である。開発元が挙げた最悪の例は、バックアップの改ざんや削除で、これは、別の事故が重なったときに効く、というのが筆者の読みである。この読みは、開発元の評価とは別で、確かめたものではない。

間隔は、ベンダー告知を読む習慣の差になる

7月30日のお知らせと、Joomla!用10.3.7のリリースノートには、CVE番号が書かれていない（筆者が読んだ範囲）。CVE番号の一覧だけを見ていた人は、7月には、この件を知る手がかりが無かった。開発元のお知らせや、リリースノートを読んでいた人は、7月30日に、CSRFの確認が加わった版が出たことを知れた、というのが筆者の読みである。05章は、JVNと、開発元のお知らせの両方を読む習慣を、項目にした。

03 用語 — 出てくる言葉を、先にそろえる

「更新」と「更新の確認」は別の作業

この記事の「更新」は、拡張機能（プラグイン）を、新しい版に上げることを指す。「更新の確認」は、担当サイトの版が、JVNの境目より前か後かを、確かめることを指す。更新の前に、確認だけを、全サイトで済ませる。

04 型別 — 適用範囲、書かれていないこと、手順

🅰 どのサイトが当てはまるか

当てはまるのは、この4つの製品のどれかを、境目より前の版で使っているサイトである。Akeebaの製品でも、JVNの一覧に無いものは、この脆弱性の対象として挙げられていない。たとえば、Admin Tools for WordPressは、JVNの一覧に無い。開発元は、通常の設定では、これらの製品は、Joomlaのスーパーユーザー、WordPressの管理者、またはSoloのログイン用のアカウントにしか開かないと書いている。JVNの想定から読むと、攻撃の対象になるのは、そうした管理者が、ログインしたまま、別のページを開いた場合である。

🅱 JVNと開発元が書いていないこと

• どの操作が、JVNの脆弱性にあたるか。JVNのページには、操作の名前が書かれていない。
• 開発元のお知らせが挙げた2つの例（複製の削除と、一時フォルダの掃除）が、JVNの脆弱性の範囲と同じかどうか。確かめていない。
• 7月30日から11月4日までの97日の理由。
• Admin Tools for WordPressなど、JVNの一覧に無い製品の、同じ種類の問題の有無。
• Joomla!用以外の3製品の、リリースノートの内容。開いていない。

したがって、どの操作が、いつから動かされえたかは、この記事では言えない。言えるのは、境目の版と、開発元が公開した日付と、JVNの公表日である。

🅲 手順 — 版を調べ、運用を見て、記録を残す

手順は、3つに分けられる。1つ目は、版を調べることである。担当サイトの台帳（担当サイトの版や設定を、1サイト1行で書いて残す表）で、4つの製品の名前を探し、見つかったサイトは、管理画面の拡張機能の一覧で、版を開いて確かめる。台帳に、Joomla!用かWordPress用かも書く。2つ目は、管理画面を使う人の運用を聞くことである。3つ目は、更新の前後のバックアップの扱いを決めることである。

更新の前に知っておきたい、Joomla!用10.3.7の別の修正

Joomla!用10.3.7のリリースノートは、セキュリティの強化だけでなく、バックアップの中身と、保存先の設定に関わる修正を2つ、最初に挙げている。1つは、PDO MySQLまたはPostgreSQLのドライバーを使うサイトで、以前の版のバックアップが、DOUBLE型の列の値を、14桁までに切り捨てていたことである。リリースノートは、MySQLiのドライバー（Joomla!サイトの大多数）は影響を受けなかったと書き、影響を受けた場合は、新しいバックアップを取り直すことを勧めている。もう1つは、Box、Dropbox、Google Drive、OneDriveへのアップロードの途中でトークンを更新すると、別のプロファイルの保存先の設定が上書きされる場合があったことである。

この2つは、JVNの脆弱性とは別の修正で、JVNだけを読んで更新すると、見落とす。更新後に、バックアップを1回取り、保存先の設定を見直す項目を、05章に入れた。ほかの3製品に、同じ種類の修正があるかは、確かめていない。

運用で変えられること — 管理画面を開いたまま、別のページを見ない

JVNの想定は、ログインしたまま、細工されたページを開くことである。更新までの間にできる運用の工夫は、管理画面を開くブラウザと、それ以外のページを見るブラウザを、分けることと、使い終わったらログアウトすることである。これらは、JVNや開発元が勧めた対策ではなく、筆者の案である。

05 明日、担当サイトで確認できることチェックリスト

以下は、担当サイトのバックアップや管理用の拡張機能が、JVNの脆弱性に当たるかと、管理画面の使い方を確かめる13項目である。1〜2番目は公式の文面を控える確認、3〜7番目は担当サイトの版を調べる確認、8〜11番目は運用と画面を見る確認、12番目は更新後の確認、13番目は記録を残す確認である。チェックの状態は、使っているブラウザに保存され、サーバーには送られない。

• JVNのページ（JVN#44272550）を開き、公開日と、影響を受ける4つの製品と版の番号を、台帳に書き写す
• 開発元の2026年7月30日のお知らせを開き、4つの版の番号が、JVNの境目と同じかを、1行で台帳に書く
• 担当サイトの台帳を「Akeeba」と「Admin Tools」で検索し、見つかったサイトの数を数えて、台帳の隅に書く
• 見つかったサイトのうち3つを選び、管理画面の拡張機能の一覧を開いて、製品名と版の番号を書く
• 台帳の「製品名」の列に、Joomla!用かWordPress用かを書き足す
• 境目より前の版に当たるサイトの数を数えて、台帳の隅に書く
• 当たるサイトごとに、更新する日を、台帳に日付で書く
• 更新する前に、そのサイトのバックアップが、ホスティング会社の機能などで別にも取れているかを、担当者に聞き、有る・無いで書く
• 管理画面にログインする担当者を3人まで書き出し、管理用のブラウザを、ほかのページを見るブラウザと分けているかを、聞いて書く
• 管理画面を使い終わったときに、ログアウトしているかを、担当者に聞き、いつも・ときどき・していないのどれかで書く
• ログインしていない画面のフォームを2回開き、隠しの欄の値が、毎回変わるかを、開発者ツールで比べて、変わる・変わらないで書く
• 更新した後に、バックアップを1回取り、取れたかと、保存先の設定が前のままかを、サイトごとに書く
• 次の確認日を、台帳に書き、その日に、JVNと開発元のお知らせの両方を開くと、1行で書く

06 代替・他の選択肢 — 更新、更新までの運用、バックアップの別の手段

選び方を、状況ごとに表で並べる

表の内容は、JVNの対策（最新版への更新）以外は、筆者の案である。更新が出来ない事情があるときに、どの選択肢が残るかを、並べた。

状況	選べる対応	利点	注意すること
すぐ更新できる	最新版へ更新する	JVNが書いた対策そのもの	更新の前後にバックアップを取る。別の修正（保存先の設定など）も確かめる
日にちを置かないと更新できない	更新の日を決め、それまでは、管理用のブラウザを分け、使い終わったらログアウトする	ログインしたまま別のページを開く場面を減らせる	更新の代わりにならない。日付を台帳に書く
管理画面へのアクセスを、場所で絞っている	絞る設定は、そのまま保つ	外から直接つなぐ攻撃を止められる	ログイン中の利用者のブラウザを使う攻撃は、その利用者が許可された場所にいれば通りうる。この製品では確かめていない（筆者の読み）
この製品を使わない運用にしたい	ホスティング会社のバックアップの機能へ移す	管理画面の拡張機能が1つ減る	復元の試験を1回行う。移す手間と費用が要る

ブラウザの既定のCookieの扱いは、守りの1つだが、頼りきらない

開発元のリリースノートは、"Most of the actions are submitted in a way that current web browsers' default cookie policy already blocked from cross-site abuse."（訳: ほとんどの操作は、最近のブラウザの既定のCookieの扱いが、別のサイトからの悪用をすでに止める形で送られている。）と書いている。MDNは、SameSiteの指定が無いCookieを、ブラウザによってはLaxとして扱うと説明している。ただし、その既定は、ブラウザごとに違い、緩い版の場合がある。OWASPの手引きは、LaxでもGETの要求は通るので、状態を変える操作がGETで動くなら、止められないと書いている。ブラウザの既定を、更新を遅らせる理由にしない。

調べる道具

当サイトの🔧 【セキュリティ】WEBサイトの 外からできるセキュリティ対策監査ツール★ミエルン — 外から見えるバックアップファイルを探す（🔒会員限定）というツールは、ページの説明によれば、外から、ディレクトリやファイルの探索で、機密ファイルやバックアップファイルを探せる。バックアップの置き場が、外から見えないかを確かめるときに使える。拡張機能の版が分かるかは、説明に書かれていないので、確かめていない。更新の前後で、画面が崩れていないかを比べるときは、🔧 【メンテナンス】WEBサイトの状況チェック・比較ツール　★チガウン — 試験用のサイトと本番の違いを、ページごとに比べる（🔒会員限定）というツールが使える。管理画面の中を比べられるかは、説明に書かれていないので、確かめていない。バックアップのファイルが、公開の場所に残っていた記録は、当サイトの「控えファイルを外から確かめた日 ── 当サイトで読めたのは25本。「403でも置かない」理由と、次から積もらない手順」に書いた。

07 当サイトで確かめたこと — この製品は使っていないが、画面の隠しの値は見られた

この4つの製品は、使っていない

当サイトは、JVNが挙げた4つの製品を使っていない。したがって、当サイトで更新した記録は無く、05章の手順は、担当サイトに向けて書いた。

フォームの隠しの値を、4回取って比べた

05章の11番目の項目の見方を、当サイトの画面で試した。2026年11月6日の12時57分に、ログインしていない状態で、当サイトの無料ツールの1つ（🔧 【UX】メール送信のための mailtoを少し便利にするツール — 07章で、隠しの値を見た画面）の画面を、4回取った。うち3回は別の接続で、1回は、最初の接続の続きとして取った。画面には、フォームが3つあり、引用符の書き方が違う欄も含めて、隠しの欄が19個あった。19個のうち18個は、4回とも同じ値で、1個だけが、4回とも違う、32文字の値だった。同じ値だった18個のうち、13個は、値が空だった。

この結果の読み方

毎回違う値が1つ入っていることは、画面ごとに作り直される値が、フォームに付いていることを示している。ただし、この値が、CSRFの確認のためのものかは、外からは確かめられない。サーバーが、送信されたときに照らしているかも、外から見ては分からない。ここで書けるのは、値が4回とも違った事実までである。WordPressのnonceのように、一定の間、同じ値が出る作りもあるので、値が変わるかどうかだけで、確認の有無を決めないほうがよい。

確かめていないこと

• フォームの送信後の、サーバー側の確認。送信は試していない。
• ログイン後の画面や、管理画面のフォーム。ログインしないで開ける画面だけを見た。
• 当サイトの画面を、別のブラウザで開いたときの違い。

08 このテーマは、ここまで — 更新の記事から、管理用の部品の運用へ

これまでの記事

• WordPress本体の更新が短い間に2回出たときの、版と自動更新とバックアップの確認は、「WordPressは5日の間に、セキュリティ更新が2回出た ── 担当サイトの版・自動更新・バックアップを一覧で確かめる13項目（2026年10月時点）」で書いた。
• WordPress本体の更新の最中の脆弱性は、「WordPress本体の更新の最中に、認証なしでコードを実行されうる脆弱性が、11月3日に悪用確認リストへ載った。期限は11月6日 ── 担当サイトの更新の窓と、前後の記録を確かめる13項目（2026年11月時点）」で書いた。
• 本番の更新の前に、複製で試す方法は、「WordPress 7.2 Beta 4は「本番に入れない」試験版で、Beta 3は7.1.4に同梱された ── 本番の更新の前に、複製で更新の所要時間を測り、複製が外へ手を出さないことを確かめる13項目（2026年11月時点）」で書いた。
• 担当サイトの一覧を、数分で答えられる形にする方法は、「PHPの修正版が出た日に「どのサイトが当たるか」を数分で答えるには、担当サイトの一覧が要る ── 台帳の8列を埋めて確かめる13項目（2026年10月時点）」で書いた。
• 公開の場所に残った控えのファイルや、パスワードのファイルは、「控えファイルを外から確かめた日 ── 当サイトで読めたのは25本。「403でも置かない」理由と、次から積もらない手順」と、「Basic認証のパスワードのファイルが、公開の場所の中に9本あった ── 外からは全部403だったが、読めなかったのは1つの決まりのおかげだった。確かめ方と、公開の外へ移した記録」で書いた。

今回の記事の位置

これまでの記事は、本体のソフトの更新を扱っていた。今回は、サイトの中に入れた、管理用の拡張機能の、更新と使い方を扱った。本体の更新は気づきやすいが、拡張機能は、JVNに載るまで、更新が必要と気づきにくい、というのが筆者の読みである。7月30日に版が出ていても、97日後に公表されて、初めて確認する人がいるかもしれない。この違いが、今回の中心である。

2026年11月6日 — この記事の確認日

JVNの公開日と最終更新日は、2026年11月4日で、開発元のお知らせの日付は、2026年7月30日だった。この日以降に、JVNのページが更新された場合は、05章の最初の項目で、書き写した内容を、もう一度比べる。当サイトの、PHPの更新の記録は、「PHPの2件の脆弱性が悪用リストに載り、期限は10月29日だった ── 期限の日に当サイトで確かめた4つと、自分の記事の言い過ぎ、期限を自分のサイトの期限に読み替える方法」にある。