配送プラグイン「Shipo」に認証回避の脆弱性　管理者になりすまされ得る

米国立標準技術研究所（NIST）の脆弱性データベースNVDに11月14日22時17分（日本時間）、WooCommerceの配送プラグイン「Shipo」の脆弱性「CVE-2026-19907」が載った。当たるのは1.6から1.8.0で、既存の利用者名を知っていれば、認証なしで管理者を含むその利用者になりすませる。修正は9月18日公開の1.8.1に入っている。最新の1.8.4に上げ、覚えのない管理者が増えていないかを確認する。

1.6から1.8.0が当たる

NVDの記載と配布元の記録では、対象と深刻度は次のとおりだ。

• 対象: WordPressのプラグイン「Shipo」（WooCommerceが前提）
• 当たるバージョン: 1.6から1.8.0まで
• 修正が入ったバージョン: 1.8.1（NVDが参照する修正の変更が1.8.1の公開に当たる）
• 最新のバージョン: 1.8.4（11月14日の時点）
• CVE番号: CVE-2026-19907
• 深刻度: CVSS 3.1で9.8（米Wordfenceの評価。11月14日の時点でNVD自身の評価は無い）
• 弱点の種類: CWE-287（不適切な認証）

WordPress.orgの配布ページによると、Shipoはルーマニアのネットショップを複数の配送業者とつなぎ、配送ラベルの作成や受け取りロッカーの選択を足すプラグインだ。有効なインストールは30件以上と少ないが、WooCommerceで物販を営むサイトが対象になる。

番号を振ったのはセキュリティ企業のWordfenceだ。Wordfenceの説明を引くNVDの記載によると、プラグインはREST APIの要求でログインのCookieから利用者名を読み、Cookieの署名を検証しないまま、その利用者として認証していた。WordPress本体は、ログインのCookieに付く署名を照らしてから利用者を決める。Shipoは自前の処理で、署名を確かめずにCookieの利用者名から利用者を決めていたため、本物でないCookieでも別人として扱われ得た。プラグイン自身のREST APIだけに限るはずの制限も回避できたという。結果として、REST APIを通じて管理者として操作でき、新しい管理者のアカウントも作れる。

バージョンを確認する

まず管理画面のプラグインの一覧でShipoのバージョンを見る。Shipoを入れていないサイトは当たらない。サーバーでWordPressの管理コマンドWP-CLIを使えるなら、WP-CLIの説明書にあるwp plugin get shipo --field=versionでも同じ値を取れる。1.6から1.8.0と出たら当たる。1.5以前はNVDの対象の範囲に入っていない。配布元のSVNに残るタグの作成日時では、1.8.0は8月20日、1.8.1は9月18日の公開だ（1.8.0のタグ、1.8.1のタグ）。9月18日より後に一度も更新していないサイトは、当たるバージョンのままの可能性が高い。プラグインの自動更新を有効にしていたサイトも、9月以降に自動更新が正常に動いていれば1.8.1以降に上がっているはずだが、一覧で実際の値を確かめておく。

最新の1.8.4に上げる

修正は、NVDが参照する修正の変更（changeset 3701532）に入っている。この変更は9月18日に公開された1.8.1にあたり、プラグインの更新履歴も1.8.1を「セキュリティや安定性などの全般的な改善」と書く。編集部が配布元から取った1.8.0と1.8.1のコードを比べたところ、Cookieから利用者を決める処理は1.8.1で外れていた。

更新先は最新の1.8.4でよい。更新履歴では、1.8.2以降の変更はチェックアウトの住所や郵便番号、配送の扱いの改善だ。更新は、管理画面のプラグインの一覧から行うか、WP-CLIの説明書にあるwp plugin update shipoで行う。上げた後は、プラグインの一覧で1.8.4と出ることを確認する。NVDの記載に、すぐ上げられない時の回避策は無い。

悪用は確認できていない

CVE-2026-19907は、11月14日の時点で米サイバーセキュリティ・インフラストラクチャセキュリティ庁（CISA）の悪用を確認した脆弱性の一覧（KEV）に載っておらず、NVDの記載にも悪用の確認は無い。

ただし、修正が出てから公表まで2カ月近くあった。当たるバージョンを動かしていたサイトは、更新に加えて管理画面の利用者の一覧を権限で絞り、覚えのない管理者が無いかを確認する。NVDは、なりすました利用者が新しい管理者を作れるとしているためだ。見つかった時は、そのアカウントを止め、管理者のパスワードを変える。

SAGUSでは当たらなかった

SAGUSは、公開している2つのサイトにShipoのファイルのパスを問い合わせ、どちらにも無いことを確かめた。開発の依存関係とソースも、プラグインの名前と、前提となるWooCommerceの語で検索し、どちらも見つからなかった。SAGUSはWordPressもこのプラグインも使っておらず、今回の脆弱性には当たらなかった。

編集部の見方

ログインのCookieを署名の検証なしに信じた点は、WordPressが用意する認証の仕組みを自前の処理で上書きした時の典型的な落とし穴だと編集部はみる。修正版は9月に出ていたが、更新履歴は「セキュリティや安定性などの全般的な改善」としか書いておらず、公表を待たずに上げたサイトだけが守られていた。今回のように更新履歴が脆弱性の修正を明かさない場合もあるので、セキュリティの公表を待たず、自動更新か定期の更新で常に最新に保つ運用を持ちたい。