MENU

Smart Slider 3 Pro3.5.1.35サプライチェーン攻撃から復帰した経緯と方法

Smart Slider 3 Pro3.5.1.35サプライチェーン攻撃から復帰した経緯と方法

2026年4月7日、
Smart Slider 3 Pro3.5.1.35がサプライチェーン攻撃を受けた事でメインサイトが凍結。
サーバーより403の処置を受けました。

Smart Slider 3 Pro3.5.1.35は何者かが仕込んだ偽物のアップデートだったようです。

Contents

Smart Slider 3 Pro

Smart Slider 3 Proは、スライダーの制作に特化したプラグインです。
当サイトでも度々紹介しています。

そのSmart Slider 3 Proがサプライチェーン攻撃にあったからもう大変。
しかも無料版は関係なく有償プラグインのPro版のみです。

サプライチェーン攻撃からの復帰

Smart Slider 3 Proは、私が運営する3つのドメインで使用しています。
当サイトも使用しています。

このサイトが攻撃に遭わなかったのは、プラグインの自動更新をしていなかった事。
そして、クライアントのサイトも同様に自動更新にしていなかった事で助かりました。

ただひとつの私のメインサイトは自動更新していた為に、ウイルスが仕込まれたプラグインを更新してしまいました。

このサイトなら、ほぼ備忘録なので復帰も簡単でしたが、メインのサイトは記事数も膨大なので大変。

サイト凍結

メインのサイトが攻撃を受けたのを知ったのはサイトの表示が403になった時です。
サーバーからのメールも見ておりませんでした。
そしてSmart Slider 3からのメールも見ておりませんでした。
そもそもSmart Slider 3からのメールは英文なので、更新の案内かと思っていましたが、そうではなかった。

ただ、そのメールを見た事で、対処ができるかというとできません。
対処の方法を知ったのはサーバーからのメールで、既に攻撃を受けた後です。

復帰の手順

どのように復帰させるか?というのが明確になったのは良いが、それがかなり大変でした。
順を追って処置すれば簡単ではありますが、このことだけに時間を割く事が許されない。
マルチタスクなので、失念や失敗もありますので集中して行うべきと反省。

STEP
画像のバックアップ

uploadsの画像を全てバックアップしなければ、復帰後に画像が全て無くなります。

STEP
感染から凍結日までの記事のバックアップ

復帰する日付から現在までに更新した記事のバックアップを取ります。
この期間の記事をバックアップしないと、復帰時に記事がごっそり無くなります。
この期間の記事はXMLでダウンロードするか手作業でコピーして保管します。
手作業の場合は、「スラッグ」と「投稿日」を控えておきます。

STEP
wp-config.phpの内容をバックアップ

wp-config.php内の一部だけをコピーし、控えておきます。

/** WordPress のためのデータベース名 */
define('DB_NAME', '●●●●●●●');
/** MySQL データベースのユーザー名 */
define('DB_USER', '●●●●●●●');
/** MySQL データベースのパスワード */
define('DB_PASSWORD', '●●●●●●●');
/** MySQL のホスト名 */
define('DB_HOST', '●●●●●●●');
STEP
CSSやカスタマイズデータをバックアップ

CSSや広告のデータ等を念の為バックアップしておきます。
元通りになっているものもありますが、一部が反映されていない場合もあります。

STEP
インストールしたプラグインの控え

インストールしたプラグインを控えておくと、再インストール時に迷いがありません。
プラグインは初期化した事で再インストールが必要です。

STEP
ドメインの初期化

サーバーから対象ドメインを初期化します。
※初期化して復帰できるのか?という不安がありますが、データは残っているので大丈夫です。

STEP
WordPressを再インストール

初期が完了したら、新たにWordPressを再インストールします。
データベースは「自動でデータベースを生成する」を選択し、以前のデータベースを使用しない事が重要です。

STEP
wp-config.phpの編集

再インストールが終了したら新たに作成されたwp-config.phpを開きます。
STEP3で控えたデータベースの内容を、既存の内容と入れ替えて保存します。
この事で、以前のログインデータでログインする事ができます。
※注意点は、ひとつでも間違えると、エラーになります。セミコロンなどの抜けが無いように慎重に選択して書き換えます。

STEP
プラグインを再インストール

ログインできたら、各プラグインを再インストール。

STEP
CSSやカスタマイズデータの確認

CSSやカスタマイズ等の各データを反映します。

STEP
FTPで画像をアップ

バックアップしていた画像をuploadsにアップします。

STEP
感染後から現在までの記事を復帰

バックアップしていた記事のXMLファイルをアップして復帰します。
手作業でバックアップしていた場合は、投稿日の日付にして更新します。

STEP
完了確認

記事に画像が表示されているか?等を確認します。

復帰までの反省点

2度と経験したくはないが、経験したからこそ分かる事もあります。
これまでの反省点は、バックアップが完璧ではなかった事。

  1. 様々なバックアップを取る前に、何も考えずに感染前のデータに戻してしまった事。
    感染後の記事のデータはバックアップしていましたが、過去の記事も手直ししていたため、そのデータをバックアップしていなかった。
  2. 画像の最適化で優れたプラグイン「ewww」を廃止する。
    ewwwの場合、WebPに変換された画像も「uploads」に保存されます。
    大量の画像が同じフォルダ内に入っている為バックアップに時間が掛かります。

Smart Slider 3 Proサプライチェーン攻撃まとめ

大企業がサプライチェーン攻撃を受けたというニュースはよく耳にします。
私のサイトでもこれだけ大変なのに、大きなサーバーが感染するととても大変だと想像できます。

この記事は備忘録として書いていますが、既に72時間以上掛かっています。
というのは、一度復帰しましたが、全ての画像をバックアップしていなかったので、やり直しです。

全ての画像をバックアップしていますが、現在も続いています。
完了予定が70時間になっていました。
ようやく半分がダウンロードされている現状です。

つまり完全復帰はまだされてない事になります。
一応感染前の状態でサイトは閲覧できますが、ログインはできません。
実質凍結状態になっています。

画像が全てダウンロードされたら、そこからが完全復帰の作業になりますが、この膨大な画像をまたアップロードするのにどのくらいの時間がかかる事か…

WordPressでこのような事が起こるとは夢にも思わない事でした。

しかもプラグイン経由でこのような事になるとは…

感染後まずユーザーを見てみると、自分以外にユーザーが2つ増えていました。
見た目だけだとそれだけですが、裏では様々な事が行われていたようです。

また、この事があった事で、バックアップの大事さを改めて思い知らされました。

そして、何か起こった時にこの手順で復帰する事ができるということが分かったので、ある意味良しとします。

Contents