WEBサイトSHIRASAGIの2件の脆弱性（11月5日にJVNが公表）は、どちらも管理画面で特定の機能を管理するための権限を持つ人が前提だった ── 担当サイトのCMSで、広告・外部の取り込み・ファイルの取り込みの権限を持つアカウントを棚卸しする13項目（2026年11月時点）
SHIRASAGIの2件の脆弱性（11月5日にJVNが公表）は、どちらも管理画面で特定の機能を管理するための権限を持つ人が前提だった ── 担当サイトのCMSで、広告・外部の取り込み・ファイルの取り込みの権限を持つアカウントを棚卸しする13項目（2026年11月時点）
目次
- 01 何が書かれたか — 11月5日、JVNはCMSの2件の脆弱性を公表した。どちらも、管理画面で、広告やオープンデータなど特定の機能を管理するための権限を持つ利用者が前提だった
- 02 なぜ・背景 — 権限があることが前提の欠陥は、権限を持つアカウントの数で、影響の大きさが変わる
- 03 用語 — 出てくる言葉を、先にそろえる
- 04 型別 — 適用範囲、この記事が確かめていないこと、確かめる手順
- 05 明日、担当サイトで確認できること
- 06 代替・他の選択肢 — 権限を持つアカウントを、見張る・絞る・減らす方法を比べる
- 07 当サイトで確かめたこと — 当サイトはSHIRASAGIを使っていないので、更新の作業はない
- 08 このテーマは、ここまで — 「更新を急ぐ」だけでなく「入口の数を知る」へ
- 09 この記事のまとめ
01 何が書かれたか — 11月5日、JVNはCMSの2件の脆弱性を公表した。どちらも、管理画面で、広告やオープンデータなど特定の機能を管理するための権限を持つ利用者が前提だった
引用について
この記事は、JVN（JPCERT/CCと情報処理推進機構が運営する脆弱性情報のサイト）の「JVN#55454512」と、開発元の告知ページ、CVSSの仕様書、OWASPの資料を、2026年11月7日に開いて確かめた内容を書いている。開発元の告知とJVNの文は、筆者が日本語で要旨にまとめた。英文を引くときは原文のまま引き、日本語訳を添える。原文に書かれていない筆者の読みは「筆者の読み」と書いて分ける。05章のチェックリストは、筆者が整理したものである。
JVNは2026年11月5日、国産のCMS「SHIRASAGI」に複数の脆弱性があると公表した。取り上げるのは2件で、1件目はブラウザの上で任意のスクリプトが動くクロスサイトスクリプティング（CVE-2026-117679）、2件目はサーバーで任意のOSコマンドが動くOSコマンドインジェクション（CVE-2026-118869）である。どちらも、開発元が出したv1.21.1で修正されている。
WEBディレクターがこの種の知らせを読むときに、いちばん迷うのは「自分のサイトは、いつ、誰に狙われるのか」だろう。告知を読むと、2件とも管理画面にログインできて、特定の機能を管理するための権限を持つ利用者が前提だと書かれている。つまり、外から誰でも仕掛けられる欠陥ではない。2件目には、サイトにオープンデータが適切に構築されていることも、前提として書かれている。同時に、その権限を持つアカウントが何本あり、誰が持っているかは、サイトごとに違う。この記事では、告知の事実を整理したうえで、担当サイトのCMSで広告や外部データの取り込みなどの権限を持つアカウントを棚卸しする手順を13項目にした。
2件の脆弱性を、表で並べる
| 項目 | 1件目（XSS） | 2件目（OSコマンド） |
|---|---|---|
| CVE番号 | CVE-2026-117679 | CVE-2026-118869 |
| 種類 | クロスサイトスクリプティング（CWE-79） | OSコマンドインジェクション（CWE-78） |
| 影響を受ける版（JVN） | v1.12.0〜v1.21.0（「リンク表示」の型はv1.19.0〜v1.21.0） | v1.19.0〜v1.21.0 |
| CVSS v4.0の基本値（JVN） | 5.1 | 8.7 |
| CVSS v3.0の基本値（JVN） | 5.4 | 8.8 |
| 必要な権限（開発元の告知） | 広告を管理するための権限 | オープンデータのデータセットおよびそのハーベストを管理するための権限 |
| そのほかの前提（開発元の告知） | 閲覧者が、広告を表示しているページを開いて、広告をクリックする | 当該サイトにオープンデータが適切に構築されている |
| 起きること（JVNの「想定される影響」） | サイトを閲覧した利用者のブラウザで、任意のスクリプトが実行される | CMSが入っているシステムで、任意のOSコマンドが実行される |
| 修正 | v1.21.1 | v1.21.1 |
開発元の告知が書いた、2件の起こり方
1件目について、開発元の告知は2つの型を書いている。1つ目（v1.12.0〜）は、広告を管理するための権限を持つ利用者が、管理画面で広告ページの追加の属性に、悪意のあるスクリプトを含む値を入力して保存する型である。2つ目（v1.19.0〜）は、「リンク表示」の欄に入れた値が使われる型で、広告ページだけでなく、広告バナーのパーツでも起きる。どちらも、閲覧者が広告を表示しているページを開いて広告をクリックすると、スクリプトが実行されるおそれがある、という流れである。仕込む側は管理画面の利用者で、被害を受けるのは、公開されたページを見た人になる。
2件目について、告知は次のように書いている。当該サイトにオープンデータが適切に構築されていて、ログインした利用者が、オープンデータのデータセットおよびそのハーベストを管理するための権限を持っているとき、その利用者が、ハーベストのインポートの「URL」の欄に、OSコマンドを含む文字列を入力して保存し、インポートを実行すると、サーバーでコマンドが実行されるおそれがある。こちらは、被害を受けるのが、CMSが動いているサーバーそのものである。なお、「ハーベスト」は、外部のデータを取り込む機能と筆者は読んだが、告知はその定義を書いていない。
対策と、更新するときの注意
対策は、v1.21.1への更新である。更新できない場合は、告知に載っている修正のコミットを当てる方法もある。コミットの数は、XSSに8件、OSコマンドに1件と書かれている。アップデート以外の回避策は、告知に載っていない。また、v1.14.2以前の版から更新する場合は、v1.15.0のリリースに書かれた大きな非互換を考える必要がある、と告知は書く。OSコマンドインジェクションについては、v1.18.2以前はこの機能が無いか、安全な実装であるため、対象に入らないと書かれている。
報告したのは、東京理科大学の方で、情報セキュリティ早期警戒パートナーシップに基づいてIPAに報告され、JPCERT/CCが開発元との調整をした、とJVNは書く。
原文に書かれていないこと
- この2件が実際に悪用されたという記述（JVNにも開発元の告知にも、悪用の報告は書かれていない）
- 国内で、この製品がどれだけ使われているか、どの組織が影響を受けるかの数字
- 権限を持たない人が、この2件を悪用できるという記述
- 更新以外の回避策
02 なぜ・背景 — 権限があることが前提の欠陥は、権限を持つアカウントの数で、影響の大きさが変わる
「認証なし」の欠陥との違い
当サイトの別の記事で取り上げたCMS本体の脆弱性には、認証なしでコードを実行されうるものがあった。WordPress本体の更新の最中に、認証なしでコードを実行されうる脆弱性が、11月3日に悪用確認リストへ載った。期限は11月6日 ── 担当サイトの更新の窓と、前後の記録を確かめる13項目（2026年11月時点）がその例である。認証なしの欠陥は、外から誰でも届くので、更新を急ぐ以外に選択肢が少ない。
今回の2件は、性質が違う。入口は管理画面で、鍵は「その機能を管理するための権限」にある。更新が必要なことは変わらないが、更新までの間に何をするかは、権限の持ち方で変えられる。権限を持つアカウントが3本のサイトと、30本のサイトでは、同じ脆弱性でも、気にすべき範囲が違う。これは筆者の読みである。
CVSSの「PR:L」は、「誰でも」という意味ではない
JVNが載せたCVSSのベクターには、どちらの脆弱性にも「PR:L」が入っている。PRはPrivileges Required（必要な権限）で、Lは「Low（低い）」である。CVSS 4.0の仕様書は、Lowを次のように定義している。
"The attacker requires privileges that provide basic capabilities that are typically limited to settings and resources owned by a single low-privileged user."
（日本語訳: 攻撃者は、通常、権限の低い1人の利用者が持つ設定や資源に限られる、基本的な操作ができる権限を必要とする。）
ここでの「低い」は、CVSSの中での相対的な区分である。CMSの管理画面にログインできる利用者は、CVSSの言葉では「低い権限」に入りうる。「低い」という字面から、「誰でも」と読まないほうがよい。なお、権限が「None（不要）」の場合は、同じ仕様書が"The attacker is unauthenticated prior to attack"（日本語訳: 攻撃者は攻撃の前に認証されていない）と書いている。2件の脆弱性は、この区分には入っていない。
基本値は、サイトごとの事情を含まない
CVSSの仕様書は、基本値について、次のように書いている。
"The Base metric group represents the intrinsic characteristics of a vulnerability…"
（日本語訳: 基本の指標のグループは、脆弱性が本来持っている特性を表す。）
つまり、JVNが載せた5.1や8.7は、脆弱性そのものの数字である。そのCMSに、権限を持つアカウントが何本あるか、そのうち使われていないものが何本あるかは、数字に入っていない。ここは、運営する側が自分で数えるしかない。これも筆者の読みで、基本値の意味は仕様書の記述に沿っている。
CVSSの利用の手引きも、基本値の位置づけを次のように書く。
"CVSS Base (CVSS-B) scores are designed to measure the severity of a vulnerability…"
（日本語訳: CVSSの基本値は、脆弱性の深刻度を測るように作られている。）
深刻度と、自分のサイトにとっての危険の大きさは別のものである。手引きは、基本値に環境の分析や、時間で変わる脅威の情報を足すよう勧めている。この記事の棚卸しは、環境の側の材料を、自分で作る作業にあたる。
権限は、放っておくと広がる
OWASPの認可のチートシートは、最小権限の原則を次のように書く。
"Least Privileges refers to the principle of assigning users only the minimum privileges necessary to complete their job."
（日本語訳: 最小権限とは、利用者に、仕事を終えるために必要な最小限の権限だけを与える原則を指す。）
同じ資料は、公開したあとも、システムの中の権限を定期的に見直して、「privilege creep」（権限が、設計のときに決めた範囲を超えて広がっていくこと）を確かめるよう書き、その見直しの趣旨を、利用者の権限が設計のときに決めた範囲を超えていないことを確かめるものと説明している（英文の引用ではなく、筆者の要約）。担当が替わる、外注の人が入る、一時的に権限を足す、といった出来事が重なると、使われていない権限が残る。今回のように、特定の機能を管理するための権限が前提の脆弱性が出たとき、残った権限は、そのまま入口の数になる。MITREのCWE-250は、不要な権限で動かすことを「Execution with Unnecessary Privileges」（訳: 不要な権限での実行）という名前で分類している。必要より多い権限を渡さないことは、脆弱性の分類の側でも、独立した弱点として扱われている。
03 用語 — 出てくる言葉を、先にそろえる
用語: クロスサイトスクリプティング（XSS）
MITREのCWE-79は、この種類を「Improper Neutralization of Input During Web Page Generation」（訳: ページを作るときの入力の不適切な無害化）という名前で分類している。ページに仕込まれたスクリプトが、そのページを見た人のブラウザの中で動いてしまう欠陥。今回の1件目では、仕込む人は管理画面の利用者で、動くのは閲覧者のブラウザである。
用語: OSコマンドインジェクション
MITREのCWE-78は、この種類を「Improper Neutralization of Special Elements used in an OS Command」（訳: OSコマンドに使われる特殊な要素の不適切な無害化）という名前で分類している。入力欄に入れた文字列が、サーバーのコマンドとして実行されてしまう欠陥。今回の2件目では、取り込みのURLの欄に入れた文字列が対象になる。
ハーベスト（オープンデータの取り込み）
開発元の告知にある「ハーベスト」は、告知の中で定義されていない。ここからは筆者の説明で、告知の流れ（インポートの「URL」の欄に入力して、データセットをインポートする）から、URLを指定して外部で公開されたデータを取り込む機能と読んだ。2件目の脆弱性は、この機能の「URL」の欄から起きる。ほかのCMSにも、外部のフィードやファイルを取り込む機能は多い。名前は違っても、外から取り込む先を管理画面で決められる機能が、同じ種類の入口になるかを確かめる、というのがこの記事の読み方である。
権限の「編集」と「閲覧」
告知が書いている権限は、1件目が「広告を管理するための権限」、2件目が「データセットおよびそのハーベストを管理するための権限」である。閲覧だけの権限でどうなるかは、告知に書かれていない。この記事も、閲覧だけの権限を持つアカウントが対象かどうかは判断しない。棚卸しでは、「管理できる（編集を含む）」かどうかを列に分ける。
棚卸し（アカウントと権限の一覧づくり）
ここでいう棚卸しは、管理画面に入れるアカウントを1本ずつ書き出し、持っている権限を機能ごとに○×で記録することを指す。形式は表計算の1枚で足りる。大事なのは、誰が、どの機能を、最後にいつ使ったかを、あとから確かめられる形にすることである。
04 型別 — 適用範囲、この記事が確かめていないこと、確かめる手順
適用範囲: SHIRASAGIを使っているサイトと、権限の仕組みを持つすべてのCMS
脆弱性の直接の対象は、SHIRASAGIのv1.12.0〜v1.21.0（OSコマンドの1件はv1.19.0〜v1.21.0）である。担当サイトがSHIRASAGIを使っていなければ、更新の作業はない。それでも、権限を持つ利用者が前提の欠陥は、どのCMSにも出うる。この記事の手順は、SHIRASAGIの場合はそのまま、ほかのCMSでは「広告・外部の取り込み・ファイルの取り込みを管理できる権限」を探して読み替える形にした。
この記事が確かめていないこと
この記事は、JVNと開発元の告知を読んで整理したものである。修正のコミットの中身、NVDの記録、SHIRASAGIの実際の画面は、開いていない。「どの入力欄にどんな文字列を入れると動くか」といった手順も、書かないし、試していない。CVSSの数字も、JVNが載せた値だけを書いた。NVDなどが別の値を載せているかは、確かめていない。
確かめる手順1: 告知を開いて、版と権限の条件を書き写す
JVNの告知とベンダーの告知を開き、CVE番号、影響を受ける版、必要な権限の文を、自分のノートに書き写す。権限の文は、要約せずに書き写す。要約すると、「管理するための権限」が「使える」に変わるなど、条件がずれる。
確かめる手順2: 担当サイトのCMSと版を、管理画面で確かめる
担当サイトのCMSの名前と版は、管理画面の設定やフッター、更新の画面で確かめられることが多い。版の確かめ方は、当サイトのPHPの修正を入れても、版の番号も「作った日」も入れ替える前と同じ文字だった ── 修正が入ったかを値で確かめる4つの方法と、3本目の知らせ（CVE-2026-115560）を当サイトで確かめた記録に書いた。版の表示が同じでも、修正が入っているとは限らない例である。更新の担当者に頼んで、更新の記録も見せてもらう。
確かめる手順3: 管理画面に入れるアカウントを、全部書き出す
管理画面のアカウント一覧を開き、アカウントの名前、役割、最後にログインした日の3つを書き出す。一覧に最後のログイン日が出ない場合は、そう書いて、出ない理由を管理者に聞く。外部の制作会社や、退職した人のアカウントが残っていないかも、この段階で目に入る。
確かめる手順4: 機能ごとに、管理できるかを○×で記録する
書き出したアカウントごとに、次の3つの機能を管理できる（編集を含む）かを○×で書く。広告やバナーのページ、外部データの取り込み、ファイルの取り込みである。CMSによって名前は違う。画面で見つからない機能は、「画面に無い」と書く。
実務のヒント
表の行は、人ではなくアカウント単位で書く。1人が複数のアカウントを持つ場合や、共有のアカウントが残っている場合を、見落とさないためである。共有のアカウントを見つけたら、誰が使っているかを書く。分からなければ「不明」と書く。
確かめる手順5: 権限が○で、使われていないアカウントに印を付ける
○が付いたアカウントのうち、この3か月でログインしていないものに印を付ける。3か月は目安で、担当サイトの運用に合わせて決めてよい。印を付けたら、担当者に「この権限は、まだ要るか」を聞く。外すかどうかは、使っている人の返事を聞いてから決める。急に外すと、業務が止まることがある。
確かめる手順6: 取り込み先と、入力済みの値を見る
外部データの取り込みの設定が登録されているなら、取り込み先のURLを全部書き出す。書き出した先が、自分たちで登録したものか、知らないものが混ざっていないかを見る。知らない取り込み先があれば、更新の前に、管理者へ確認する。広告ページの追加の属性やリンク表示の欄も、入力済みの値を数ページ分、目で見る。ここで見るのは、見慣れない文字列が入っていないかである。
確かめる手順7: 更新できないときの手順を、先に決める
告知は、更新以外の回避策を載せていない。更新できない事情があるなら、修正のコミットを当てる方法が選べる、と告知は書くが、コミットを当てるのは開発の作業である。担当サイトで更新が難しい場合は、更新できる日と、それまでの間に権限を絞る日を、先に決めて記録する。更新元の版がv1.14.2以前なら、大きな非互換があるので、更新の前に、リリースノートを読む日も決める。
使い方の例: 外注先のアカウントが残っていた場合
ここからは、告知にある話ではなく、棚卸しの使い方を示すための仮の例である。サイトの制作を外注した会社のアカウントが、納品のあとも管理画面に残っていて、広告と外部データの取り込みの権限を持っているとする。手順3で全アカウントを書き出すと、最後のログインが数か月前のこの行が見つかる。手順5で担当者に「この権限は、まだ要るか」を聞き、更新の作業や保守で使っていると分かれば、残す。使っていなければ、権限を絞る日を決める。脆弱性の知らせが出る前に、この表が手元にあれば、知らせを読んだその日に、影響を受けるアカウントの数を答えられる。
機能ごとに、棚卸しで見る点が違う
- 広告・バナー: 広告ページの追加の属性と「リンク表示」の欄に、入力済みの値に見慣れない文字列が無いかを見る（1件目に関わる機能）
- 外部データの取り込み: 取り込み先のURLの一覧を見る。登録した覚えのない取り込み先が無いかを確かめる（2件目に関わる機能）
- ファイルの取り込み: 今回の告知には出てこない。外部から取り込む機能として、同じ種類の入口になりうるかを、CMSの説明で確かめる（筆者の整理）
05 明日、担当サイトで確認できること
以下は、担当サイトで、告知を読み、権限を持つアカウントを棚卸しするための13項目である。1〜4番目は告知と版の確認、5〜9番目はアカウントと権限の棚卸し、10〜13番目は取り込み先と広告ページの確認、決めたことの残し方である。1項目は5分以内でできる。チェックの状態は、お使いのブラウザに保存され、サーバーには送られない。
- JVN#55454512を開き、CVE番号2件と、影響を受ける版の範囲を書き写す
- 開発元の告知を開き、必要な権限と前提を書いた文を、2件とも要約せずに書き写す
- 担当サイトのCMSの名前に、SHIRASAGIが含まれるか確認する。含まれなければ、以降は自分のCMSに読み替える
- SHIRASAGIなら、版を管理画面で開き、v1.12.0〜v1.21.0に入るかを確認して書く
- 管理画面にログインできるアカウントを全部書き出し、その数を書く
- 各アカウントについて、広告・外部データの取り込み・ファイルの取り込みを管理できるかを、○×で書く
- 3つのどれかが○のアカウントの数を数えて書く
- ○のアカウントのうち、3か月ログインしていないものに印を付ける
- 印を付けたアカウントの担当者に、権限がまだ要るかを聞き、返事を書く
- 外部データの取り込みに登録されている取り込み先のURLを、全部書き出す
- 書き出した取り込み先のうち、自分たちで登録したと確認できないものに印を付ける
- 広告ページの追加の属性とリンク表示の欄を、3ページ分開き、入力済みの値を目で見る
- 更新できる日と、それまでに権限を絞る日を決め、確認した日付と一緒に記録する
チェックが終わったら、アカウントと権限の表を1枚にまとめて、担当サイトの記録に残す。表に日付を入れておくと、次に告知が出たとき、前回との違いが見える。権限を絞った場合は、絞った日と、誰に確認したかも書く。
06 代替・他の選択肢 — 権限を持つアカウントを、見張る・絞る・減らす方法を比べる
権限を持つアカウントへの備えには、棚卸しのほかにも方法がある。それぞれの向き不向きを、次の表に整理した。比べ方は筆者の整理で、公式の分類ではない。
| 方法 | 向いている場面 | 注意 |
|---|---|---|
| 棚卸しして、使われていない権限を外す | アカウントが多く、担当の入れ替わりがあるサイト | 外す前に、使っている人へ確認する。確認の記録を残す |
| 権限を機能ごとに分ける | 編集の担当が複数いて、全員に全部の機能を渡している場合 | CMSが権限の細かい分け方に対応しているかを、先に確かめる |
| 取り込みなどの機能を、使うときだけ有効にする | 外部の取り込みを、月に数回しか使わない場合 | 機能の有効と無効を切り替えられるCMSに限る。切り替えの権限も棚卸しの対象にする |
| 管理画面への入口を絞る | 管理画面を使う場所が決まっている場合 | 入口を絞る設定は、ほかの利用者の作業を止めないか確かめてから行う |
| 更新を急ぐ | 修正版が出ていて、更新の影響を確認できる場合 | 権限の見直しの代わりにはならない。両方を行う |
当サイトの過去の記事で扱った、近い話題
サイトにつながる外部ツールと、その権限を棚卸しする手順は、サイトにつながる外部ツールと権限は、サービスごとに別々の画面で管理されている ── 計測・CMS・広告の連携を棚卸しする14項目（2026年9月時点）に書いた。サイトを作る道具の更新を台帳にして確かめる考え方は、GitLabの脆弱性が10月29日にCISAの悪用確認リストへ載り、期限の欄は11月1日だった。対象は自前で動かす側で、GitLab.comは修正済みと提供元が書く ── サイトを作る道具の更新台帳を作って確認する13項目（2026年10月時点）の型で、権限の棚卸しにも使える。入口の機器のアカウントを確かめる話は、VPN機器のIvanti Connect Secureの2件が悪用確認リストに載り、期限の欄は11月2日と13日に分かれた ── 担当サイトへの入口の機器の台帳・アカウント・ログを確かめる13項目（2026年11月時点）にある。
更新の期限を決める手順は、WordPress 7.1.4は10月28日に出て、公式は直ちに更新するよう勧めた ── 担当サイトの版を一覧にして更新の期限を決める13項目（2026年10月時点）に書いてある。ログイン画面の異常を、アカウント単位で見る考え方は、Cloudflareは、ログインと会員登録の異常をアカウント単位で調べる画面を先行利用の顧客に出した ── 同じ問いを自社の記録に当てて確認する13項目（2026年10月時点）で扱った。
管理画面の保護を、外から確かめる手段として、当サイトには🔧 【セキュリティ】WEBサイトの 外からできるセキュリティ対策監査ツール★ミエルン — 外部から管理サイトの情報を集めて、セキュリティリスクを評価・監査する（利用には無料の会員登録が必要です）がある。担当者の入れ替えなどでアカウントのパスワードを作り直すときは、🔧 【運営】パスワード・ジェネレーター、シンプルで使いやすさにこだわってみた、ツール — 新規登録や再発行のパスワード設定に使えるパスワードを作るが使える。
07 当サイトで確かめたこと — 当サイトはSHIRASAGIを使っていないので、更新の作業はない
この記事のために、当サイトの設定は変えていない
当サイトはSHIRASAGIを使っていない。そのため、この2件の脆弱性についての更新の作業は、当サイトにはない。この記事は、担当サイトで確かめる手順として書いた。2026年11月7日に、JVN、開発元の告知、CVSSの仕様書、OWASPの資料を開いて読んだが、当サイトの設定や権限は、この記事のために変えていない。
当サイトの管理画面のアカウントは、この記事のためには数え直していない
当サイトにも、管理画面に入れる利用者がいる。ただし、この記事を書くために、当サイトの管理画面のアカウントと権限を数え直してはいない。権限の棚卸しは、05章の13項目と同じ手順で行い、結果をこの記事に日付つきで追記する。外部ツールの連携の棚卸しは、先に挙げた記事で行った。管理画面の入口に近い、パスワードのファイルの置き場所を確かめた記録は、Basic認証のパスワードのファイルが、公開の場所の中に9本あった ── 外からは全部403だったが、読めなかったのは1つの決まりのおかげだった。確かめ方と、公開の外へ移した記録と、控えファイルを外から確かめた日 ── 当サイトで読めたのは25本。「403でも置かない」理由と、次から積もらない手順に書いた。
08 このテーマは、ここまで — 「更新を急ぐ」だけでなく「入口の数を知る」へ
これまでの記事
- WordPress本体の更新の最中に、認証なしでコードを実行されうる脆弱性が、11月3日に悪用確認リストへ載った。期限は11月6日 ── 担当サイトの更新の窓と、前後の記録を確かめる13項目（2026年11月時点） — 認証なしの欠陥と、更新の窓
- サイトにつながる外部ツールと権限は、サービスごとに別々の画面で管理されている ── 計測・CMS・広告の連携を棚卸しする14項目（2026年9月時点） — 外部ツールと権限の棚卸し
- VPN機器のIvanti Connect Secureの2件が悪用確認リストに載り、期限の欄は11月2日と13日に分かれた ── 担当サイトへの入口の機器の台帳・アカウント・ログを確かめる13項目（2026年11月時点） — 入口の機器のアカウント
- PHPの修正を入れても、版の番号も「作った日」も入れ替える前と同じ文字だった ── 修正が入ったかを値で確かめる4つの方法と、3本目の知らせ（CVE-2026-115560）を当サイトで確かめた記録 — 版の確かめ方
- PHPの重大な脆弱性「php2shell」を、初心者から上級者まで1本で ── 自分のサイトは関係あるか、更新の順番、更新の後に確かめること、攻撃を受けたかの調べ方、当サイトとチームの記録 — 更新の順番
注意
この記事は、2026年11月7日に確かめた内容に基づく。版の範囲やCVSSの数字は、JVNと開発元の告知が更新されると変わることがある。担当サイトで使うときは、その日に告知を開き直すこと。
現在の貴方のIPアドレス
このサイトで書いている人
