← 脆弱性の記事一覧へ

セキュリティノート

YOOtheme Pro画像処理の脆弱性が悪用されWebシェル設置

分類:攻撃手法RCE攻撃手法パストラバーサル攻撃手法Webシェル対象技術CMSインシデント種別悪用確認

要点

影響を受けるもの

今すぐやること

  • YOOtheme Proを使っているサイトは5.0.53以降に更新する。
  • 更新前に攻撃を受けていないか、アップロード用フォルダとアクセスログを確認する(具体的な痕跡は後述)。

何が起きているか

事実(YOOtheme、GitHub Advisory、Unit 42、JPCERT/CC)

  • YOOthemeは2026年10月21日、YOOtheme Pro 5.0.53を公開し、変更履歴に「CVE-2026-102785:画像ハンドラー経由の認証なしのリモートコード実行を修正」と記載した(YOOtheme Pro Changelog)。
  • GitHub Advisory Databaseの説明によると、YOOtheme Proの公開された画像変換処理は、画像の加工内容と出力先をリクエストの署名に十分に結び付けていなかった。認証されていない攻撃者は、サイト上の正規の画像URLに含まれる署名を使い回し、画像処理を付け足してキャッシュ用フォルダの外に出て、PHPを実行できる公開フォルダに「PNG(画像)とPHPを兼ねたファイル」を書き込める。弱点の分類はCWE-434(危険な種類のファイルのアップロード)、CVSS v4の基本値は10.0(GHSA-8w8j-f6ph-29mm)。
  • Palo Alto NetworksのUnit 42は10月26日、この脆弱性の悪用を観測したと報告した。報告の要点は次のとおり(Unit 42)。
    • CVEは10月22日に公開され、PoC(攻撃の検証コード)は10月23日には出回っていた。
    • 最初のWebシェルは修正版公開の2日後に書き込まれた。攻撃は自動化されていた。
    • 自動スキャナーが、PHPコードを埋め込んだJPEGを wp-content/uploads/ に書き込み、数秒以内に echo と id を実行して動作を確かめた。サーバーはHTTP 500を返すが、ファイルは書き込まれる。
    • 約2分後、人手の攻撃者が別のIPアドレスから「ALFA Team」のWebシェルを設置し、遠隔操作ツールgsocketの導入や、GitHubからの追加ファイルの取得を試みた。
  • JPCERT/CCは11月5日のWeekly Report(10月25日〜31日分)でこの脆弱性を取り上げ、「Palo Alto Networksは、今回修正された脆弱性を悪用した攻撃を確認している」として更新を呼びかけた(JPCERT/CC Weekly Report 2026-11-05号)。
  • 2026年11月7日時点で、CISAのKEVには登録されていない。

影響を受ける製品・バージョン

製品影響を受けるバージョン修正版
YOOtheme Pro(WordPress版)5.0.0〜5.0.525.0.53以降
YOOtheme Pro(Joomla!版)5.0.0〜5.0.525.0.53以降
  • 影響を受けるのは、ログインなしで誰でも呼び出せる画像処理(画像のリサイズ・切り抜きとキャッシュ)である(GitHub Advisory)。
  • YOOtheme Pro 4以前が影響を受けるかどうかは、YOOthemeの変更履歴とGitHub Advisoryには書かれていない。

修正版・回避策

  • 修正:YOOtheme Pro 5.0.53以降に更新する(YOOtheme)。WordPressとJoomla!で同じ版番号が使われている。
  • 回避策:ベンダーから公式の回避策は示されていない。更新までのつなぎとして、アップロード用フォルダでのPHP実行を止める設定は被害を小さくすると考えられるが、それだけで脆弱性が直るわけではない。

今すぐやること

  1. YOOtheme Proの版を確認し、5.0.0〜5.0.52なら5.0.53以降に更新する。
  2. wp-content/uploads/ などのアップロード・画像用フォルダに、yt と16進数7桁を組み合わせた名前の .php ファイル(yt[0-9a-f]{7}.php)や、ALFA_DATA(中に alfacgiapi)というフォルダがないか探す(Unit 42が示した痕跡)。
  3. アクセスログで、index.php?yootheme=cache へのリクエストのうち FromFile=php://input や Save= を含むものを探す(Unit 42が示した攻撃URLの形)。
  4. 痕跡が見つかったら、ファイルを消すだけで終わらせず、サーバー全体の調査、管理者パスワードとデータベース接続情報(wp-config.php など)の変更、きれいなバックアップからの復元を検討する。

考察

  • 更新しても、すでに置かれたWebシェルは消えない: 悪用は修正版の2日後に始まっている。10月21日以降に5.0.52以前で動いていたサイトは、更新済みでも一度は痕跡を確認すべきだと考える。
  • 「エラーが出たから失敗」とは限らない: Unit 42によると、攻撃リクエストにはHTTP 500が返るがファイルは書き込まれる。エラー件数だけを見て安心するのは危うい。
  • テーマは見落とされやすい: プラグインの更新は管理していても、有償テーマはライセンスキーが切れていて自動更新されないことがある。制作会社に任せたサイトほど、版番号の確認が漏れやすいと考える。
  • 画像に見せかけたPHPは検知をすり抜けやすい: Webシェルは正しいJPEGとして開ける形で、画像の再変換にも耐えるよう作られていた(Unit 42)。拡張子や画像としての妥当性だけで判定する仕組みでは見逃しうる。

出典

原文をGitHubで読む ↗

あわせて読む

Chainalysis ― 全利用者のパスワードハッシュとトークンが漏えい