スマートスライダーが表示されない
ここ数日、保守対応を行っているWordPressサイトで、同じ系統と思われる改ざん事象に複数回対応しました。
最初の兆候はSmart Slider3を埋め込んでいるショートコードが表示され、スマートスライダーが動いていないことから調査がはじまりました。
調査を進めると、いくつかのサイトで共通する痕跡が見つかりました。
その内容は、最近公表された Smart Slider 3 関連の脆弱性・不正配布事案 とかなり一致していました。
2026年3月には、Wordfence が Smart Slider 3 の 3.5.1.33 以前 に、ログイン済みの低権限ユーザーでもサーバー上の任意ファイルを読める脆弱性（CVE-2026-3098）があると公表しています。さらに Smart Slider 側は2026年4月、Smart Slider 3 Pro 3.5.1.35 に不正な更新が混入し、バックドアや隠し管理者ユーザーの作成が起こり得る と案内しました。
この記事では、実際の現場対応を踏まえて、
- どんな症状が出たのか
- どこを確認したのか
- どういう順番で復旧したのか
を、忘備録としてまとめました。
実際に確認した主な症状
今回対応したサイトでは、次のような症状が見られました。
wp-includes配下に.cache_keyのような隠しファイルが作成されていたwp-adminやwp-includesとは別に、テーマファイルやmu-plugins内にも不審なコードが残っていたfunctions.phpに、外部からのリクエストを受け取るような不審な処理が混入していた- 管理者ユーザー一覧に、作成した覚えのないアカウントが存在していた
- 一部のサイトでは、削除した不正ファイルが再生成される挙動があった
Smart Slider の公式アドバイザリでも、影響を受けたサイトでは 隠し管理者ユーザーの作成、mu-plugins や wp-includes への不正ファイル設置、.cache_key のようなファイル作成、functions.php からの再感染処理などが起こり得ると案内されています。
つまり今回の件は、単純に「1ファイルだけ置かれた」タイプではなく、
複数箇所に仕掛けを残して再侵入・再生成を狙うタイプ と考えたほうが安全です。
そのため、途中からは「怪しいファイルを1個消す」のではなく、サイト全体を侵害前提で洗い直す方針 に切り替えました。これは Smart Slider 公式の案内とも一致しています。
今回の対応は「部分修正」ではなく「侵害前提の復旧」が必要でした
今回の対応で一番強く感じたのは、
見つかった不正ファイルだけ消しても、復旧したことにはならない
という点です。
たとえば、
.cache_keyを消しただけでは不十分wp-includesを上書きしただけでも不十分- プラグイン更新だけでも不十分
でした。
実際には、
- 不審ユーザーの確認
- コアファイル上書き
- テーマ内コード確認
- データベース内 option の確認
- 各種パスワード変更
- Security Key / Salt の再発行
まで行って、ようやく「復旧した」と判断できる状態でした。
実際に行った復旧フロー
以下が、今回の対応で実際に進めた手順です。
複数サイトでほぼ同じ流れを取りました。
STEP 1 まずサイトを保全し、公開状態を見直す
最初にやったのは、これ以上の被害拡大を止めること です。
実際に行ったこと
- 対象サイトを一時的にメンテナンス状態へ
- 管理画面やサイト全体に Basic 認証をかける
- すぐ公開停止できない場合は、少なくとも
/wp-admin/へのアクセスを制限 - 可能ならFTP / SSHの外部共有も一時停止
理由は単純で、掃除の途中に攻撃者がまだ入れてしまう状態だと、
こちらが削除したファイルをまた置き直される可能性があるためです。
Smart Slider 公式も、影響が疑われるサイトについてはまずアクセスを制限し、調査前に被害の拡大を防ぐよう勧めています。
STEP 2 感染状態のままバックアップを確保する
次に、いまの状態をそのまま保存 しました。
実際に取ったもの
- サーバー上のファイル一式
- DBのエクスポートデータ
- 不審ファイル単体のコピー
- 可能ならアクセスログ・エラーログ
ここで取るバックアップは、復元用というより 調査用 です。
実際、あとで
- どこに不正ファイルが置かれていたか
- どんなコードが書かれていたか
- 複数サイトで共通する痕跡があるか
を照合するときに役立ちました。
また、Smart Slider 公式は 2026年4月7日に不正な更新が配布された としており、ロールバックするなら 2026年4月5日以前のバックアップが安全 と案内しています。バックアップから戻す場合でも、まず現状保全してから作業に入るほうが安全です。
STEP 3 Smart Slider 3 のバージョン確認と停止・削除
ここで対象サイトのプラグイン状況を確認しました。
確認したポイント
- Smart Slider 3 / Smart Slider 3 Pro が入っているか
- バージョンはいくつか
- 最近自動更新されていないか
- 複数サイトで同じ更新時期になっていないか
2026年3月に公表された脆弱性は 3.5.1.33 以前 が対象、修正版は 3.5.1.34 です。さらに4月には Pro 3.5.1.35 が不正配布された と公式が告知しており、影響を受けた場合は 3.5.1.35 を削除し、3.5.1.36 を入れ直す よう案内しています。
実際に行ったこと
- Smart Slider 3 を無効化（プラグインフォルダのリネーム）
- プラグインフォルダをサーバー上から削除
- 正式な安全版を後で再インストール
不審な更新が入っている可能性がある以上、プラグインファイルそのものを一度取り除くほうが安全です。
またプラグインフォルダを削除しても作成したスライダーのデータ自体は消えません。後ほど再度プラグインを入れるとスライダーは復活します。ただしバックアップはとっておいたほうがよいです。
STEP 4 不審な管理者ユーザーの確認と削除
次に、WordPress のユーザー一覧を確認しました。
実際の確認方法
- 管理画面の「ユーザー一覧」で管理者を全件確認
- 登録日時が分かる場合は時期を見る
- メールアドレスも確認
- DBの
wp_users/wp_usermeta側でも念のため確認
Smart Slider 公式は、不審な管理者ユーザー名の例として wpsvc_ や wp_maint_ のような形式を挙げています。また、攻撃コードが管理画面から見えにくい形でユーザーを扱う可能性にも言及しています。
実務上の注意点
ユーザー一覧に見当たらなくても安心はできません。
DBを確認すると、ユーザー本体は消えていても権限情報が残っていたり、別名義で紛れていることがあります。
実際に行ったこと
- 見覚えのない管理者ユーザーを削除
- そのユーザーが作成した投稿があれば、引き継ぎ先を変更
- 他の管理者ユーザーも全員パスワード変更対象にした
STEP 5 不正ファイルの洗い出し
ここからはファイル調査です。
今回かなり重要だったのがこの工程です。
優先的に見た場所
wp-content/mu-plugins/wp-includes/wp-admin/wp-content/themes/使用中テーマ/wp-content/uploads/- キャッシュ系ディレクトリ
Smart Slider 公式が削除対象として挙げている代表例には、wp-content/mu-plugins/object-cache-helper.php、wp-includes/class-wp-locale-helper.php、wp-includes/.cache_key などがあります。
実際の探し方
ローカルにサイトを落として検索したり、サーバー上で以下のような観点で見ました。
.cache_key_chkbase64_decodeshell_execeval(error_reporting(0)- 見覚えのない
initフック - ドットで始まる隠しファイル
特に今回の事例では、_chk パラメータを使って外部から命令を受けるようなバックドアの形が問題になっています。外部解説でも、_chk と secret key の一致を条件に、POST されたデータを処理する挙動が説明されています。
実際に注意したこと
- すぐ削除する前にバックアップ
- コアファイルなのか不正ファイルなのかを見極める
- 複数サイトで同じファイル名が出ていないか比較
STEP 6 テーマの functions.php を重点確認
今回、実務上とても重要だったのが テーマ側の確認 です。
なぜ重要か
不正ファイルを消しても、functions.php に再生成処理が残っていると、
ページアクセス時や init 実行時にまた不正ファイルが復活するからです。
Smart Slider 公式も、functions.php 内の不正コードを削除しないと再感染が起き得る と明記しています。
実際に見たポイント
add_action('init', ... )$_GET['_chk']$_POST['d']base64_decode(...)shell_exec(...)- 異常に長い1行コード
- コメントの少ない意味不明な関数
実際に行ったこと
- 使用中テーマと子テーマの
functions.phpを確認 - 差分が分かる場合は直近変更と比較
- 怪しい処理を除去
- 念のためテーマ一式もバックアップ取得
現場感としては、不正ファイルより functions.php のほうが見落としやすい です。
そしてここを見落とすと、復旧したつもりでも数時間後にまた戻されます。
STEP 7 wp-admin と wp-includes を正規版で上書き
不正な変更が WordPress 本体に及んでいる可能性があったため、
公式配布の WordPress 本体で wp-admin と wp-includes を上書き しました。
実際のやり方
- 使用中の WordPress バージョンと同系統、または最新版の正規版を入手
- 解凍
wp-adminとwp-includesをFTP/SFTPで上書き- 既存の不要ファイルがあれば削除も確認
今回の不審ファイルは wp-includes 側にも置かれていたためです。
コア配下を個別に掃除するより、正規ファイルで上書きしたほうが早くて確実 でした。
STEP 8 mu-plugins と uploads 配下を個別確認
wp-admin と wp-includes を上書きしても、wp-content はそのまま残るため、ここを別で調べる必要があります。
特に見た場所
wp-content/mu-plugins/wp-content/uploads/wp-content/cache/wp-content/upgrade/
実際に注意した点
通常、uploads 配下に PHP があるのはかなり不自然です。
画像やPDFの保存先に PHP が置かれていたら、まず疑ってよいと思います。
また mu-plugins は常時読み込まれるため、
ここにバックドアが入っていると非常に厄介です。
STEP 9 データベースの不正 option を確認・削除
今回、ファイルだけでなく DB も確認しました。
Smart Slider 公式は、wp_options テーブル内の不審な option として_wpc_ak、_wpc_uid、_wpc_uinfo、_perf_toolkit_source、wp_page_for_privacy_policy_cache などを確認対象として案内しています。
実際に行ったこと
phpMyAdmin で wp_options を開き、
_wpc_perfprivacy_policy_cache
などで検索しました。
実務上のポイント
- いきなり削除せず、まず中身を見る
- 事前に DB バックアップを取る
- プレフィックスが
wp_ではない環境ではテーブル名に注意
この工程は少し慎重さが必要ですが、
ファイルだけ掃除して DB を残すと、認証キーや不審データが残存する可能性があります。
STEP 10 wp-config.php の確認と Security Key / Salt の再発行
wp-config.php も必ず確認しました。
見たポイント
- 見覚えのない
define(...) - 追加された不審な定数
- 外部読み込みコード
- DB情報が漏えいした前提での扱い
Smart Slider 公式は、WP_CACHE_SALT のような不審な定義を削除し、
さらに WordPress の Security Keys / Salts を再生成して差し替える よう案内しています。これにより、既存ログインセッションを無効化できます。
実際に行ったこと
wp-config.phpの差分確認- 不審な追記の削除
- Security Key / Salt を再発行して差し替え
- その結果、全ユーザーが再ログイン必要な状態にした
これはかなり重要で、
もし攻撃者が Cookie や認証情報を握っていても、セッションを切れる ためです。
STEP 11 全パスワードの変更
今回の脆弱性・事象では、wp-config.php の読取やバックドア設置を通じて、
認証情報が漏れている可能性まで考えるべきです。CVE-2026-3098 では、低権限ユーザーでもサーバー上の任意ファイルを読み取れるため、wp-config.php に含まれる DB 認証情報や security keys の露出リスクがあります。
実際に変更したもの
- WordPress 管理者パスワード
- 関係する全ユーザーパスワード
- FTP / SFTP / SSH
- サーバー管理画面
- DBパスワード
- 可能なら関連メールアカウント
実際メールアカウントやDBパスワードまで変更する必要はないかもしれませんが、「侵入されたかもしれない鍵」をそのままにしておくと、ファイルをきれいにしても再侵入の余地が残りますし、ここまでやるなら徹底してやろうと思い変更しました。
STEP 12 ログ確認と最終スキャン
最後に、ログとセキュリティスキャンを行いました。
確認したもの
- サーバーのアクセスログ
- エラーログ
- Wordfence などのスキャン結果
- 直近の管理画面ログイン履歴
ログで見たキーワード例
_chkadmin-ajax.php- 不審な POST
- 見覚えのない管理者ログイン
- 外部IPからの連続アクセス
Smart Slider 公式も、アクセスログや管理者行動ログの確認を推奨しています。
また Patchstack でも、3.5.1.35 のバックドア問題は非常に危険度が高く、広範な悪用につながり得るとして緊急対応を促しています。
バックアップから戻す場合の判断
今回、サイトによっては
手作業で掃除するより、正常時バックアップへ戻したほうが速くて確実
と判断できるケースもありました。
Smart Slider 公式は、影響を受けた可能性がある場合、2026年4月5日以前のバックアップ へのロールバックを推奨しています。
ただし、バックアップ復元だけでは終わりません。
実際には復元後にも、
- Smart Slider の安全版再導入
- 不審ユーザー確認
wp-config.php確認- Salt再発行
- パスワード総変更
- 最終スキャン
は必要です。
今回の対応を通して感じたこと
今回の件は、単なる「プラグイン更新ミス」ではなく、
脆弱性の悪用と、不正更新配布の両方が関係する可能性がある厄介なケース でした。
2026年3月の CVE-2026-3098 と、2026年4月の Pro 3.5.1.35 不正配布は別の話ですが、どちらも Smart Slider 3 系列を巡る重大なインシデントとして時期が近接しています。
現場で実際に対応して感じたのは、次の3点です。
- 1個見つけたら終わりではない
functions.phpとmu-pluginsを見落とすと復旧しきれない- 「侵害された前提」で認証情報まで更新しないと不安が残る
再発防止として今後やるべきこと
正直今回のような事象は完全には防ぐことは難しいとも感じていますが、それでも最低限次をより徹底したいと考えています。
- WordPress本体、テーマ、プラグインを常に最新にする
- 使っていないプラグインは停止ではなく削除する
- 自動更新の内容を定期確認する
- 管理者アカウントを最小限にする
- 2段階認証を導入する
- 定期バックアップを世代管理する
uploads配下での PHP 実行制限を検討する- 異常時に比較できるよう、平常時のファイル構成を把握しておく
まとめ
以上、実際に複数の WordPress サイトで改ざん対応をまとめてみました。実際この対応で予定していたタスクがほとんどこなせず、かなり辛い思いをしましたが、ただ苦労しただけでは悔しいので久しぶりに記事にまとめてみました。だれかの役に立てば嬉しい。
実際に行った流れのまとめ
- サイトを隔離する
- 現状バックアップを取る
- Smart Slider 3 を確認・削除する
- 不審ユーザーを確認する
- 不正ファイルを洗い出す
functions.phpを重点確認するwp-adminとwp-includesを上書きするmu-pluginsとuploadsを点検する- DB の不審 option を確認する
wp-config.phpと Salt を更新する- すべてのパスワードを変更する
- ログ確認と最終スキャンを行う
なお、今回行った作業は必ずこれで安全というものではありません。見落としがあるかもしれません。その点をご了承ください。
以上です。
