sHub-Log Security Observability + Verified Bot Intelligence

WordPressへの攻撃は、
ログイン画面だけではない。
見えない脅威を可視化し、繰り返す攻撃元を遮断する。

sHub-Logは、WordPress管理画面への不正アクセスだけでなく、プラグイン・テーマ・コア領域への探索、設定ファイルの露出確認、Webシェルやアップロード配下のPHP実行試行、ユーザー列挙、スキャナUA、ボット偽装、REST API悪用、REST経路探索、不正なクエリ、不審な404の連続発生を16カテゴリに分類して記録するWordPressセキュリティプラグインです。

「何かが来ている」ではなく、何を狙い、どこから、どのくらい来ているのかをアタックログとグラフで可視化。同じIPアドレスから攻撃が繰り返された場合は、WordPress上でそのIPを一定時間プロテクトします。

さらに、GooglebotやBingbotなどの検索Bot、GPTBotやClaudeBotなどのAI Botを検証して記録。攻撃の可視化と、検索・AIクローラーの可視化を、1つの管理画面で扱えます。

無料 WordPress.org 公式配布 GPLv2

sHub-Log 管理画面イメージ
sHub-Log 管理画面イメージ
41.2%
世界の全WebサイトでのWordPress利用率
53%+
Botなどによる自動Webトラフィック
91%
WordPress脆弱性のプラグイン比率
16
攻撃カテゴリで分類
The WordPress Threat Landscape

3つの事実から、
WordPressの現在を考える

WordPressは、世界で最も広く使われるCMSです。その大きさゆえに、ログイン画面へのブルートフォース攻撃だけでなく、WordPress脆弱性、プラグイン脆弱性、設定ミス、公開されたAPI、存在しない攻撃用パスを自動的に探す対象にもなります。

そして今、Webアクセスの半数以上は人間ではありません。必要なのは、すべてのBotを一律に拒否することではなく、正規のクローラーと、悪意あるBotや自動脆弱性スキャンを分けて理解することです。

41.2%

世界のWebサイト

2026年7月時点で、WordPressは世界の全Webサイトの41.2%に使われています。CMSとしてのシェアは59.1%です。

W3Techs ↗
53%+

自動トラフィック

Impervaの「2026 Bad Bot Report」によると、2025年のWebトラフィックの53%以上がBotなどによる自動トラフィックでした。人間によるアクセスは47%です。

Imperva ↗
91%

プラグイン由来

Patchstackによると、2025年に確認されたWordPressエコシステムの新しい脆弱性11,334件のうち、91%はプラグインで発見されました。

Patchstack ↗

Botとは、人の代わりにWebサイトを自動巡回・操作するプログラムです。検索エンジンの情報収集、AIサービスのクロール、監視などに使われる一方、脆弱性探索、認証情報の総当たり、コンテンツ取得、スパムにも使われます。

The Attack Surface Has Changed

ログイン防御だけでは、
現在のWordPress攻撃は見えない。

かつて、WordPressセキュリティの中心的な課題は、wp-login.phpや管理画面への不正ログインでした。ブルートフォース攻撃や、流出したID・パスワードを試すクレデンシャルスタッフィングへの対策は、今も重要です。

しかし、攻撃は必ずしもログイン画面から始まりません。

自動化された脆弱性スキャナーや悪意あるBotは、ログインせずに次のような場所へ直接アクセスします。

  • .env、wp-config.php、バックアップファイル、SQLファイル
  • /wp-content/plugins/配下の既知または推測されたパス
  • /wp-includes/配下のWordPressコア領域
  • shell.php、wso.php、c99.phpなど、Webシェルで使われることがあるパス
  • /wp-json/などのREST API、設置場所や経路を変える探索
  • /xmlrpc.php
  • SQLインジェクション、XSS、パストラバーサルを意図したクエリ
  • 大量の存在しないURL

1回ずつ見れば、単なる404や数回のアクセスに見えるかもしれません。しかし、同じIPが短時間に複数の弱点を少しずつ探していれば、それはWordPressサイトに対する偵察行動と考えるべきです。同一IPが設置場所やRESTの入り口を変えながら繰り返す探索も、その一例です。

AI時代に増えたのは、脆弱性だけではなく「攻撃を自動化する力」です

AIがWordPressの脆弱性を生み出している、という意味ではありません。一方、Impervaは、生成AIや大規模言語モデルの普及がBot開発のハードルを下げ、攻撃者が自動攻撃をより大規模に展開しやすくなったと報告しています。

攻撃対象は、管理画面だけではありません。WordPress本体、プラグイン、REST API、設定ファイル、バックドア候補のパスまで、機械が継続的に探す時代になっています。

attack-log — 203.0.113.x / 10 min window
12:01:04 CONFIG_SCAN  /.env
12:02:37 CONFIG_SCAN  /wp-config.php.bak
12:03:55 PLUGIN_SCAN  /wp-content/plugins/…/readme.txt
12:05:12 CORE_SCAN    /wp-includes/…
12:06:48 REST_ABUSE   /wp-json/wp/v2/users
12:07:20 UA_EMPTY     (no user-agent)
score 40+40+25+25+20+15 = 165
→ RECORD (50) / PROTECT (100) — IP blocked

※ 表示は挙動を説明するためのイメージです。

少量でも、複数の弱点を探っていれば見逃しにくくする。

単純なアクセス回数制限では、1分間に何百回もアクセスする攻撃は見つけやすくても、複数の弱点を低頻度で探す偵察は見落としやすくなります。sHub-Logのリスクスコアリングは、攻撃の種類に重みを付け、IPごとに時間枠で加算します。

初期設定では10分の時間枠で集計し、合計50で記録、合計100でプロテクトします。時間枠、配点、記録しきい値、プロテクトしきい値は変更できます。

回数だけではなく、攻撃の組み合わせを見る。 これが、sHub-Logのリスクスコアリングです。

※ リスクスコアリングは初期状態では OFF です。サイトのアクセス状況を確認したうえで有効化できます。

検知した動き配点（初期値）
裏口探索50
設定ファイル探索40
不正なクエリパラメータ40
REST経路探索35
不審な404多発30
大量リクエスト30
プラグイン脆弱性スキャン25
WordPressコア脆弱性スキャン25
REST API悪用試行20
管理画面ハッキング15
スパム・その他15
User-Agent が空15
Why We Built It

完全復旧に2週間かかった経験から、このプラグインは始まった。

sHub-Logを開発したシンタックスクラウド代表は、インターネット専業代理店時代からクリエイティブとSEOデジタルマーケティングに携わってきました。

転機になったのは、2010年代に担当していたWordPressサイトがクラッキングされたことでした。最初の被害では、原因特定、改ざん範囲の確認、復旧、再発防止まで約2週間かかりました。

その後、別の顧客サイトでも被害が発生しましたが、前回の知見により数日で復旧できました。

この経験から、サイト運用はコンテンツ更新やサーバー管理だけではまったく足りないと考えるようになりました。

sHub-Logは、机上で考えたセキュリティ製品ではありません。

実際の被害と復旧を経験し、日々のWordPress運用で必要だった、「いま何が起きているのか分かる画面」をWordPress.org公式プラグインとして公開したものです。

Detect · Record · Protect

16カテゴリで分類し、記録し、繰り返すIPをプロテクトする。

sHub-Logは、WordPressに届いた不審なリクエストを 16カテゴリに分類します。

大量リクエスト REST API悪用試行 REST経路探索 管理画面ハッキング プラグイン脆弱性スキャン テーマ脆弱性スキャン WordPressコア脆弱性スキャン 設定ファイル探索 裏口探索 ユーザー列挙 不正なクエリパラメータ スキャナツール ボット偽装 スパム・その他 不審な404多発 スコアリング検知
カテゴリ見ている動き
大量リクエスト同じIPから短時間に集中するリクエスト
REST API悪用試行ユーザー情報取得などを意図したREST APIへの探索
REST経路探索同一IPが短時間に設置場所やRESTの入り口を変えながら探索するスキャン。正規のREST経路はパス単体では遮断しません
管理画面ハッキング未ログイン状態での管理系URLへの到達（ソフトカテゴリ）
プラグイン脆弱性スキャン404となった/wp-content/plugins/配下へのプローブ
テーマ脆弱性スキャン404となった/wp-content/themes/配下へのプローブ
WordPressコア脆弱性スキャン404となった/wp-includes/配下へのプローブ
設定ファイル探索.env、wp-config、.git、怪しいバックアップ名などへのアクセス
裏口探索既知のWebシェル名や/wp-content/uploads/配下のPHP実行試行
ユーザー列挙数値の?author=N連打やユーザーサイトマップへの探索
不正なクエリパラメータSQLインジェクション、XSS、パストラバーサルなどの基本パターン
スキャナツールsqlmap、nikto、wpscanなど既知スキャナのUser-Agent
ボット偽装既知クローラーを名乗るが検証に失敗したアクセス（ソフトカテゴリ）
スパム・その他xmlrpc.phpへのアクセス、PROPFIND/TRACE/TRACK
不審な404多発短時間に多数の存在しないURLを探る動き
スコアリング検知複数の攻撃シグナルを重み付けし、しきい値を超えた状態

「脆弱性を診断する」のではなく、「狙われている兆候を捉える」

sHub-Logは、インストール済みプラグインをCVEデータベースと照合する脆弱性診断ツールではありません。また、サーバー内のファイルを検査するマルウェアスキャナーでもありません。

その役割は、外部からWordPressへ届く探索や攻撃の兆候を分類し、アタックログとして残すことです。脆弱性を塞ぐには、WordPress本体、プラグイン、テーマを修正版へ更新する必要があります。そのうえで、「更新前後に何を狙われていたか」「同じIPが探索を続けていないか」を把握することが、運用上の次の判断につながります。

Security Visibility

「危なそう」ではなく、件数と種類で説明できる。

sHub-Logは、WordPressのセキュリティ可観測性を、小規模な運用チームでも扱える形にします。

  • アタック推移グラフ
  • 期間と集計間隔の選択
  • 16カテゴリ別の集計
  • IP、アクセス先URL、User-Agent、日時の記録
  • カテゴリによるログ絞り込み
  • CSVダウンロード
  • ログ保存期間の設定と自動整理（初期値90日）
  • プロテクト中IPの一覧と手動解除
  • IPホワイトリスト
  • Cloudflareなどの信頼するリバースプロキシに対応

月次レポートにそのまま使える

Web制作会社やMSPは、顧客サイトで「何も起きていない」と推測する代わりに、検知した攻撃の種類と推移を月次レポートで共有できます。社内IT担当者は、経営層や関係部署へ状況を数字で説明できます。

メールアラート

急上昇アラート：特定カテゴリの攻撃が短時間に増えたとき。
高止まりアラート：一定時間内の合計件数がしきい値を超えたとき。
どちらも初期状態ではOFFです。必要なサイトだけで有効化できます。

WordPress Core Vulnerability: wp2shell

プラグインだけではない。
WordPressコアにも、例外的に重大な脆弱性は起こる。

WordPressエコシステムで報告される脆弱性の大半はプラグインにあります。2025年は91%がプラグイン由来でした。しかし、WordPressコアの脆弱性は件数が少なくても、標準構成の多数のサイトへ一斉に影響する可能性があります。

2026年7月、WordPressコアの2つの脆弱性、CVE-2026-60137とCVE-2026-63030を組み合わせた攻撃チェーン「wp2shell」が明らかになりました。IPAによると、影響を受けるWordPress 6.9以降では、2件の脆弱性の組み合わせにより、認証なしで遠隔コード実行に至る可能性があります。2026年7月21日には、米国CISAのKnown Exploited Vulnerabilities（KEV）カタログへ、実際に悪用された脆弱性として掲載されました。

この問題は、米国でもBleepingComputer、Wiz、Tenable、Bitdefenderなどのセキュリティメディア・企業によって報じられました。攻撃者がREST APIのバッチ処理を悪用し、脆弱なWordPressでコード実行やWebシェル設置に至る危険性が指摘されています。

一方、正規機能でも使う REST 経路をパスだけで常時遮断するのは難しいため、sHub-Log は同一IPが短時間に設置場所や REST の入り口を変えながら探索する動きを「REST経路探索」として検知し、繰り返すIPをプロテクトできます。401や404が混在していても、探索のやり方自体を見ます。

2026年7月22日、sHub-Logは当日中に検知カテゴリを追加

7月21日（米国時間）

CISA KEVカタログに掲載

7月22日（日本時間）

IPAが注意喚起を公開

7月22日（同日）

sHub-Logに「WordPressコア脆弱性スキャン」カテゴリを追加

同日

sHubで運用する顧客サイトの安全性確認を完了

追加した機能は、/wp-includes/配下の存在しないパスを探るアクセスを、WordPressコア領域へのプローブとして分類・記録するものです。

これは、wp2shell固有のREST API通信や攻撃成功を識別するシグネチャではありません。重大なコア脆弱性の公表を受け、従来のログイン画面中心の監視から、WordPressコア領域を探る動きも独立して可視化するために追加したカテゴリです。

更新の代わりになる機能ではありません

wp2shellの脆弱性そのものを修正するのは、WordPressのセキュリティアップデートです。sHub-Logは、wp2shellへの感染有無を診断したり、脆弱性を仮想パッチしたりする製品ではありません。

役割はこう分かれます。

必要な対応担うもの
脆弱性を修正するWordPressを6.8.6、6.9.5、7.0.2以降の修正版へ更新
探索されている兆候を残すsHub-Logの検知・分類・記録
同じIPから繰り返される攻撃を抑止するsHub-Logの期限付きIPプロテクト
侵害後のファイルやアカウントを調査する専門的なインシデント対応、マルウェア検査

コア更新は必ず実施してください。そのうえで、公表から対応までの時間を短くし、更新前後の攻撃の兆候をログに残すことが重要です。

Bots Now Outnumber Humans

Webアクセスの半数以上がBotなら、
Botを「見分ける」ことが必要になる。

Botはすべて悪者ではありません。GooglebotやBingbotは、検索結果へページを登録するためにサイトをクロールします。GPTBot、ClaudeBot、PerplexityBotなどのAIクローラーも、サービスごとの目的とルールに基づいてWebへアクセスします。

一方で、次のような悪意あるBotも存在します。WordPressやプラグインの脆弱性を自動探索するBot、ログイン画面でブルートフォース攻撃を行うBot、流出した認証情報を試すクレデンシャルスタッフィングBot、.envやwp-config.phpを探すBot、Webシェルやバックドア候補を探索するBot、スパムや無断スクレイピングを行うBot、Googlebotなどを名乗る偽装Bot。

必要なのは、User-Agentに書かれた名前をそのまま信用することではありません。

Search SEO Layer

Googlebot、Bingbot など

Googlebot、Bingbot、DuckDuckBotなど、検証済み検索クローラーのアクセス推移を記録します。検索Bot全体のアクセス数、Botごとの内訳、サイト公開や改修後のクロール変化、sitemapや内部リンク改善後の短期的な手がかりが分かります。

AI Layer

GPTBot、ClaudeBot、PerplexityBot など

GPTBot、ClaudeBot、PerplexityBot、OAI-SearchBotなど、検証済みAIクローラーのアクセス推移を記録します。AI Bot全体のアクセス数、Botごとの内訳、コンテンツ公開後にAIクローラーが来たか、AI Botトラフィックの短期的な変化が分かります。

「Googlebotと名乗るアクセス」と「正規のGooglebot」は同じではない。

User-Agentは、アクセス元が自由に書き換えられます。悪意あるBotがGooglebotを名乗ることも難しくありません。

sHub-Logは、次の段階を通ったアクセスだけを正規Botとして扱います。

  • User-Agentが既知の検索BotまたはAI Botと一致する
  • FCrDNS（逆引き後に正引きでIPを再確認）または、運営企業が公開する公式IPレンジでアクセス元を検証する

検証済みのBotだけをBotアクセスログへ記録するため、偽GooglebotやUser-AgentだけをコピーしたBotを正規クローラーの集計へ混ぜにくくします。

さらに、攻撃ログとは別のテーブル・別の管理画面で扱います。セキュリティの記録と、検索・AIクローラー分析を混同しません。

検証できなかったBotを、それだけで自動遮断するわけではありません。正規Botとしてレート計測から除外せず、攻撃パターンやアクセス頻度が設定条件に該当した場合にプロテクトします。

分かることと、分からないこと

分かること

  • 検証済み検索Bot・AI Botがサイトへ来た回数
  • Botの種類ごとの内訳
  • 最大14日間のアクセス推移
  • サイト改修や記事公開後にクロールが変化したか

分からないこと

  • ChatGPTやPerplexityの回答で、実際に引用されたか
  • Google検索順位が上がったか
  • AIサービス内でコンテンツがどのように評価されたか

AI Botの増加は、AI検索での評価向上を証明するものではありません。長期の検索成果はGoogle Search Console、直近の検証済みクローラーの動きはsHub-Logという役割分担が現実的です。

A Focused Role, Not an All-in-One Claim

万能だと言わない。
役割を明確にする。

sHub-Logは、WAF、マルウェアスキャナー、バックアップ、二要素認証、CVEベースの脆弱性診断をすべて置き換える製品ではありません。

セキュリティ対策主な役割
WordPress・プラグイン更新公開された脆弱性を修正する
WAFWordPressへ到達する前を含め、通信をルールで遮断する
マルウェアスキャナーサーバー内の不正ファイルや改ざんを検査する
バックアップ被害発生後の復旧点を確保する
2FAログイン認証を強化する
sHub-LogWordPressへ届いた不審な探索を分類・記録し、繰り返すIPを期限付きでプロテクトする

すでにWAFやバックアップがあっても、WordPress側で何が検知されたかを確認したい場面があります。sHub-Logは、そのためのWordPress向けセキュリティ可観測性と軽量なIPプロテクションを提供します。

Free Version

無料版で、攻撃の可視化とBotの検証まで。

sHub-Logの無料版で、次の機能を利用できます。

  • 16カテゴリの攻撃検知とアタックログ
  • 繰り返すIPの自動プロテクト
  • ログイン失敗回数に基づくIPプロテクト
  • アタック推移グラフ
  • カテゴリ別フィルタ
  • CSVダウンロード
  • リスクスコアリング（設定で有効化）
  • 検証済み検索Bot・AI Botのアクセスログ（最大14日）
  • 急上昇・高止まりメールアラート（設定で有効化）
  • IPホワイトリスト
  • Cloudflareなどの信頼するリバースプロキシ設定
  • 日本語・英語を含む多言語管理画面

初期状態は、安全側から始める

誤検知の影響を考慮し、リスクスコアリング、Botアクセスログ、メールアラートなどは初期状態でOFFです。最初は基本設定で運用し、アクセス状況を確認してから詳細設定を調整できます。

迷った場合は「推奨設定」へ戻せます。

導入は、WordPress 管理画面からインストールして有効化するだけです。

Pricing

価格は、1ヶ月にコーヒー1杯

同じ機能を、その国の物価感覚に合った金額で。価格は国や地域のコーヒー1杯の価格に連動させる方針です。

Free
¥0

WordPress.org 公式配布 / GPLv2

  • 16カテゴリの攻撃検知・記録・遮断
  • アタック推移グラフ / CSV ダウンロード
  • 正規 bot アクセスログ（最大14日）
  • メールアラート・リスクスコアリング

Paid — 2026年8月予定
¥392円 / 月
¥4,700円 / 年

日本のコーヒー1杯（¥392）

月次の支払は今後対応予定です。2026年は「年払い」のみとなります。

  • URL 別の bot アクセスランキング
  • 急上昇ページ
  • ページごとの bot 内訳（検索 / AI）
  • 無料版の機能はそのまま利用可能

セキュリティの可視化と、検索・AI のクロール可視化。それが月にコーヒー1杯分で回るなら、判断は難しくないと考えています。

Who It's For

WordPressを「作って終わり」に
できないチームへ

WordPressを「作って終わり」にできないチームへ。

WordPress制作会社・デジタルエージェンシー

納品後の保守サービスに、攻撃ログ、IPプロテクト、CSVレポートを加えられます。複数顧客へ同じ基準で状況を説明できます。

MSP・マネージドWordPressホスティング

顧客サイトで検知された探索や不審な404を分類し、サポートや月次報告に活用できます。Cloudflareなどのリバースプロキシ環境にも対応します。

社内ITチーム

専任のセキュリティ担当者がいない組織でも、攻撃の種類と推移を管理画面やCSVで共有できます。

WooCommerce・オンラインビジネス

停止や改ざんが売上と信用へ直結するサイトで、ログイン画面以外の探索を把握できます。

出版社・デジタルメディア

WordPressセキュリティとともに、検証済み検索クローラー、AIクローラーのアクセス傾向を確認できます。

SEO会社・コンテンツ運用チーム

Google Search Consoleだけでは把握しにくい、公開・改修直後の検証済みクローラーアクセスを補助データとして利用できます。

そのほか、こんな現場でも

WordPress 制作会社・受託開発 … 納品後の保守メニューに組み込みやすい オウンドメディア・コンテンツ運営 … AI に読まれる前提でのクロール確認 EC（WooCommerce など） … 攻撃対象になりやすく、停止が売上に直結する 医療・クリニック・士業 … 情報の信頼性が重要で、改ざんの影響が大きい 教育機関・自治体関連サイト … 複数サイトの運用と、記録の必要性 マネージドホスティング事業者 … 顧客への付加価値、サポート負荷の軽減 Web 専任がいない情シス … 何が起きているかを説明できる資料が手に入る
Day-2 Operations

入れたあと、迷わないために

セキュリティプラグインは、入れたあとに使い続けられるかで価値が決まります。

  • 管理画面の「シンプル（設定）版」と「詳細設定版」 — 最初は最小限、慣れたら細かく
  • 「推奨設定」ボタン — 迷ったら初期値に戻せる
  • 日本語・英語ほかの管理画面 — 海外拠点や外部パートナーとも共有しやすい
  • ログの自動整理 — 保存期間を決めれば、あとは自動で削除
  • CSV ダウンロード — 集計や報告書づくりを外に持ち出せる
  • 信頼するプロキシ設定 — Cloudflare などの配下でも、実 IP で判定できる

使い方の詳しい解説は、別ページで用意しています。

Privacy and Transparency

アタックログを外部サービスへ送らない。

sHub-Logは、WordPress.org公式ディレクトリで配布されるGPLv2プラグインです。

アタックログ、IPアドレス、ユーザー情報、サイトコンテンツを、シンタックスクラウドへ送信しません。ログはWordPressのデータベースへ保存されます。外部通信は、設定と機能に応じて次の用途に限定されます。

  • 署名付きアラート定義、メールテンプレート、スコア定義の取得
  • 正規Bot検証のために各社が公開する公式IPレンジJSONの取得

BotのIPレンジは24時間キャッシュします。取得や署名検証に失敗した場合は、内蔵デフォルト、ローカルバックアップ、または管理画面の設定値を使用します。

有料版は、syn-c.jp 側で提供するサービスです。無料版は、有料版の開始後も引き続き機能します。 既存の無料機能を有料に移すことは考えていません。

Sources

統計・脆弱性情報の出典

数値とwp2shellに関する記述は、一次情報と米国セキュリティメディアの記事を確認して掲載しています。

  1. W3Techs — WordPress usage statistics, July 2026
  2. Imperva — Bad Bot Report 2026: Bots in the Agentic Age
  3. Patchstack — State of WordPress Security in 2026
  4. IPA — WordPressの脆弱性対策について（wp2shell）
  5. BleepingComputer — Critical wp2shell WordPress flaws exploited to install webshells
  6. Wiz — Exploitation in the Wild of wp2shell
  7. Tenable — wp2shell: WordPress Core Pre-Auth RCE FAQ
  8. Bitdefender — Technical Advisory: wp2shell
Get Started

まずは、あなたのWordPressに
何が来ているかを見る。

ログイン画面を守るだけでは足りません。

プラグイン領域、WordPressコア領域、設定ファイル、REST API、REST経路探索、バックドア候補、不審な404。外から届く探索を分類し、記録し、繰り返す攻撃元をプロテクトする。

同時に、検索BotとAI BotをUser-Agentだけで信用せず、FCrDNSや公式IPレンジで検証して、その動きを別の画面で見る。攻撃の可視化と、正規クローラーの可視化を、1つのWordPress管理画面で。

sHub-Logは、復旧に2週間かかった経験から生まれました。あのとき欲しかったのは、機能の多さではなく、何が起きているのか分かる画面でした。