個人メディア『Pottal-Portal』への不正アクセス改ざん事件——1サーバ複数サイト運用のリスクと、気づかれなかった1.5ヶ月

はじめに — 「うちは静的サイトだから大丈夫」は本当に大丈夫か

「サーバー代を節約したいから」と、1台のVPSに個人ブログも実験サイトも、さらに昔運用していたWordPressも、まとめて載せて運用している——そんなサイト運営者は少なくないのではないでしょうか。

本記事で扱うのは、個人メディア「Pottal-Portal」を運営するPottal氏が2026年7月26日に発表した不正アクセス事件です。それによると、pottal-portal.comをはじめ同一サーバー上で運用していた複数のサイトが第三者による不正アクセスを受け、2026年5月下旬からサーバー上のファイルが書き換えられ続けていました。異変に気づいたのは7月15日。実に約1.5ヶ月ものあいだ、被害は気づかれないまま進行していました。

「うちは静的サイトだから大丈夫」「小規模サイトが狙われるはずがない」——そう思っている方こそ、読んでいただきたい事件です。本記事では、①一次情報ベースで追う事件の全容、②「1サーバー複数サイト」運用が被害を広げたリスク構造、③今日から始められる改ざん検知・対策チェックリスト、の3点を整理します。なお、事実確認にはPottal氏の公式note・ScanNetSecurity・IPA・警察庁・JNSAの公開資料のみを用いています。

【事件の全体像】Pottal-Portalで何が起きたのか——時系列で追う

まずは、事件がいつ・どのように進んだのかを整理しましょう。個人メディア「Pottal-Portal」の運営者Pottal氏が公開した公式note（2026年7月26日初報・7月31日追記）と、専門メディアScanNetSecurityの報道（2026年8月13日）から、判明している事実だけを時系列で追うと、次のようになります。

timeline
    title Pottal-Portal改ざん事件の主な出来事（2026年）
    5月下旬 : サーバー上のファイルが第三者に書き換えられ始める : 侵入経路は未特定・調査中
    7月15日 : 運営者が異変に気づく : 同日、Xで乗っ取りを報告
    7月26日 : 外部からのアクセスを完全遮断 : 公式note初報を公開
    7月31日 : pottal-portal.comが復旧完了と報告
    8月13日 : ScanNetSecurityが事件を報道
    9月10日確認時点 : 「Pottal-Portal 3.0」として稼働中

図の内容をテキストでも補足します。

• 2026年5月下旬（推定）: サーバー上のファイルが第三者によって書き換えられ始めます。侵入経路は公開情報では未特定です。運営者は「更新を止めたまま放置していたWordPressサイトが侵入の起点になった可能性を調査中」と説明していますが、現時点では確定していません。
• 2026年7月15日: 運営者が異変に気づきました。同日、X（旧Twitter）に「ConoHaで管理している鯖が全部乗っ取られたみたいだ。」と投稿しています。改ざん開始から発覚まで、約1.5ヶ月を要しました。
• 2026年7月26日: 外部からのアクセスを完全に遮断し、公式noteで初報を公開。経過報告と、訪問された方へのお願いが併せて発表されました。
• 2026年7月31日: メインサイトpottal-portal.comの復旧完了がnote追記で報告されました。
• 2026年8月13日: ScanNetSecurityが「同一サーバで運用している複数サイトが被害に」と報道。
• 2026年9月10日（本記事執筆時の確認）: サイトは「Pottal-Portal 3.0」として稼働していることを確認しました。公開時点で状況が変わっている可能性があるため、最新状況は公式サイトをご確認ください。

被害の対象は、pottal-portal.comを含む同一サーバー上の複数サイトでした。ここで重要なのは、メインサイトのpottal-portal.com自体は、入力フォームもデータベースも持たない静的サイト（Quarto製。Markdownファイルをレンダリングするだけの構成）だったという点です。それでも、サーバー全体が第三者の支配下に置かれたことで、静的なファイルごと書き換えられる被害に遭いました。

個人情報への影響はどうだったでしょうか。公式noteによれば、旧WordPressサイトのデータベースには、2019年〜2020年にコメントをくれた4名分の「表示名」と「IPアドレス」が残っており、さらにその後の調査で、旧サイトのアクセス集計機能が記録した訪問者のIPアドレス約10,900件（2022年3月〜2024年4月が中心）も同じデータベースに保存されていたことが判明しました。攻撃者がこれらを閲覧した証拠は確認されていないものの、「閲覧できた状態にあったことは否定できない」とされています。一方で、会員情報・決済情報・パスワードは、そもそもサーバー上に存在しませんでした。

復旧の考え方も丁寧です。汚染されていない元データ（Markdown）からサイトを再構築し、既存のHTMLファイルは信用せず全削除。データベースは証拠保全のうえ、サーバーごと完全消去する方針が示されました。「疑わしきものは信用せず、作り直す」というインシデント対応の基本に沿った判断です。

【何がされたか】確認されている4つの手口——偽メンテナンス、モバイルだけ転送、SEOスパム、スパムメール

Pottal氏が公式noteで明かした改ざんの内容は、大きく4つあります。いずれも公開された情報の範囲で、運営者がふだんPCでサイトを確認するだけでは見落とし得る性質のものでした。

1. 偽の「メンテナンス中」画面への差し替え: サイトの中身が消され、偽のメンテナンス中画面に差し替えられていました。一見すると自然な表示のため、「改ざんされた?」と疑うハードルが上がります。
2. スマートフォンからのアクセスのみ外部サイトへ自動転送: モバイル端末からアクセスした場合だけ、外部のサイトへ自動的に転送される仕掛けでした。PCでサイトを確認する機会の多い運営者には見えにくい、条件付きのリダイレクトです。
3. 検索エンジン向けのSEOスパムリンクの大量埋め込み: 検索エンジン向けに、不正な広告リンクが大量に埋め込まれていました。公式noteはこの点を「検索エンジン向けの不正な広告リンク」と報告しており、それ以上の技術的詳細（クローラーだけに見せる実装か、人間の目にどの程度映るか）は公開情報では確認できません。
4. サーバーからの迷惑メールの大量送信: さらに、乗っ取ったサーバーから迷惑メールが大量に送信されていました。これはサイトの外で起きるため、サイトの見た目をどれだけ確認しても分かりません。

攻撃の目的について、運営者自身は「検索エンジン向けの不正なリンクを売る目的の攻撃」と分析しています。あくまで運営者の見解であり、攻撃者の意向や収益構造の詳細が公開された情報で裏付けられたわけではありません。ただ、サイトの表示を派手に壊す手口が選ばれなかった結果、改ざん開始（5月下旬）から発覚（7月15日）までの約1.5ヶ月、異変につながる気づきが得られなかった——という時系列は事実として確認できます。

訪問者への影響にも触れておきます。2026年5月下旬から7月26日の外部アクセス完全遮断までの間に、スマートフォンで該当サイトにアクセスした人は、意図しない外部サイトへ転送された可能性があります。運営者はnoteのタイトル自体に「訪問された方へのお願い」と掲げ、転送先のサイトでアプリの導入やID・パスワード、カード情報などの入力を行ってしまった人は、パスワードの変更とウイルススキャンを行ってほしいと呼びかけています。

【なぜ1.5ヶ月気づかなかったか】改ざんは「仕組み」で検知する——3方式の比較

ここまで読んで、多くの方が「なぜ1.5ヶ月も気づかなかったのか」と疑問に思うはずです。答えは単純に「運営者がサイトを見ていなかった」からなのか、公開情報からは確認できません。ただ、公開された手口を整理すると、通常のPC閲覧による確認では見落とし得る性質の改ざんだったことは指摘できます。

前節の4つの手口を振り返ってください。偽の「メンテナンス中」画面は一見自然に見え、モバイルのみの転送はPCで確認する人には見えず、スパムメール送信はサイトの外で起きる出来事です。運営者の日常的な閲覧では引っかかりにくい手口が重なっていた——と、公開情報の範囲で説明できます。攻撃者が「発見されないよう設計した」ことや、運営者の監視体制の有無を断定する材料はありません。

つまり改ざんの検知は、「目」だけでなく「仕組み」に任せる必要があります。代表的なのは、監視する場所の異なる次の3方式です。

※「本事件の手口への関連」は各手法を一般的に適用した場合の可能性の解説であり、実際に検知できたことを保証するものではありません。料金形態・検出能力は個別のサービス仕様に依存するため、導入時に各事業者の資料で確認してください。

このうち、サーバー内部で動くFIM（File Integrity Monitoring：ファイル整合性監視）の仕組みを図にすると、次のとおりです。

flowchart TD
    A[クリーンな状態でベースラインDBを作成] --> B[定期実行: 現在のファイル状態を収集]
    B --> C{ベースラインと照合}
    C -- 差分なし --> B
    C -- 差分あり --> D[アラート通知]
    D --> E[対応判断: 意図した更新か改ざんか]
    E -- 意図した更新 --> F[ベースラインを更新]
    F --> B
    E -- 改ざんの疑い --> G[調査・復旧へ]

図のとおり、クリーンな状態でファイルのハッシュ値を記録したベースラインを作り、定期的に照合して差分が出たらアラートを出す。意図した更新ならベースラインを更新し、改ざんの疑いがあれば調査・復旧に進む——この繰り返しがFIMの基本的な動きです。

FIMの定番ツールとして挙げられるのがAIDEです。AIDEは「file and directory integrity checker（ファイル・ディレクトリ整合性検査ツール）」をうたう無償ツールで、md5やsha256などのハッシュ値に加え、パーミッションやタイムスタンプなどのファイル属性も記録・照合します。DebianやUbuntuではapt install aideで導入できます。

一方、最も手軽に始められるのがGoogle Search Consoleです。「Googleがサイトの問題を特定した際にメール通知を受け取れる」ことを公式がうたう無料サービスで、登録だけで外側からの異変通知の窓口が付きます。何を検知して通知が来るかはGoogle側の判定次第である点には注意が必要です。

大事なのは、この3方式は「どれか1つを選ぶ」ものではないということです。監視の起点がサーバー内・外部・検索エンジンとそれぞれ異なるため、重ねて使って初めて多層的な検知になります。本事件の改ざんも、どれか1つの仕組みがあれば確実に防げたとは言えません。しかし「全部が見えない」状態から「どこかで引っかかる可能性がある」状態に変えること——それが「気づかれない1.5ヶ月」を自分のサイトに起こさないための第一歩です。

【リスク構造】「1サーバー複数サイト」運用はなぜ危険か——分離がなければ、最も弱いサイトから全体へ届き得る

本事件の核心にある構造を、もう一度整理しておきましょう。メインサイトのpottal-portal.comは、入力フォームもデータベースも持たない静的サイトでした。ところが同じサーバー上には、過去に運用していて更新を止めたまま残していたWordPressサイトが複数あり、こちらにはデータベースが存在しました。運営者は「更新を止めたまま放置していたWordPressサイトが侵入の起点になった可能性を調査中」と説明していますが、侵入経路は現時点で未特定です。つまり確定した事実ではないものの、本事件の構図は「堅牢に作ったメインサイトの安全が、隣にいた弱いサイトによって左右され得る」ことを示唆しています。

「1サーバー複数サイト」運用のリスクを、本事件の事実を踏まえた一般論として4つの層で整理します。

1. 攻撃面の集約 — サーバーに載せたCMSの数だけ、侵入経路（本体・プラグイン・テーマ・認証情報の弱点）が増えます。1台の安全性は、載せたサイトのうち最も弱いものの水準に引き下げられます。
2. 横展開 — 1つのサイトを足場にサーバーの権限を取られると、サイトごとの権限分離がなければ、同じサーバー上の他サイトのファイル・データベースに到達され得ます。ただしこれは権限設定次第で変わります。サイト単位のOSユーザー・ファイル権限・コンテナ・DB資格情報などの分離が適切に設定されていれば、1サイトの陥落が他サイトへの到達に直結するとは限りません。本事件では実際に同一サーバー上の複数サイトが被害を受けており、結果として分離が被害を防がなかった（あるいは分離がなかった）ことがうかがえますが、サーバー内部の権限設定の詳細は公開されていません。
3. データの思いがけない残存 — 使わなくなったサイトのデータベースは、運用を止めても消えずに残ります。本事件では、旧WordPressのDBにコメント4名分の表示名とIPアドレス、旧アクセス集計の訪問者IPアドレス約10,900件が残存し、「閲覧できた状態にあったことは否定できない」とされました。
4. 検知の死角 — サイトの数が増えるほど、すべてを同じ頻度で確認するのは現実的でなくなります。「仕組みによる検知」がないまま複数サイトを抱えると、どれか1つが改ざんされても気づかない期間が伸びていきます。

この4層を、本事件に沿って1行で描くと次のようになります。

放置WordPress（更新停止・DBあり）→ サーバー権限の奪取 → 適切な分離がなければ他サイトのファイル・DBへ到達し得る → 静的メインサイトも改ざん／旧DBのデータに閲覧可能性

（※上の図は本事件の構図を概念的に示したもので、侵入経路や権限設定の詳細の確定を意味しません。サーバー内部の構成は公開情報になく、推測は避けています。）

では、この構造を緩和するにはどうすればよいのでしょうか。一般論としての方向性は3つあります。第一に、使わないサイトは閉鎖・削除すること。本事件の運営者自身が、反省点として「使わなくなったまま更新を止めていたシステムを、消さずに放置していたこと」を挙げています。第二に、集約を続けるなら、サイトごとのユーザー・ディレクトリ分離と最小権限で横展開の抑止を図ること。第三に、静的サイトはサーバーを分けた静的ホスティングへ移すことです。

集約運用と分離運用のトレードオフを、表にまとめました。

コストと手間を理由に1台へ集約すること自体は、決して間違いではありません。問題は「更新しないサイトを抱えたまま、集約し続ける」ことです。表の最下段が示すとおり、自分で更新できるサイトだけを1台に絞り込めるなら集約は成立します。一方、「もう更新できないサイト」を抱えているなら、分離が現実的な守りになります。まずは手持ちのサイトを棚卸しし、動いていないものから閉鎖する——それが本事件が示す最優先の対策です。

【統計】個人サイト・小規模サイトは本当に狙われているのか

「個人のサイトが攻撃の標的になるはずがない」——そう感じている方も多いかもしれません。しかし、公表されている統計を見る限り、サイバー攻撃の被害は大企業だけの話ではありません。

NPO日本ネットワークセキュリティ協会（JNSA）「インシデント損害額調査レポート 別冊『被害組織調査』第2版」（2025年7月公開）は、2017年1月〜2024年6月に公表・報道されたサイバー攻撃被害約1,800事例を分析したもので、被害組織の約7割が中小企業・団体等でした。「大企業だけではなく多くの中小企業がサイバー攻撃による被害を受けている」と同レポートは明記しています。

さらに注目したいのは統計の「見え方」です。同レポートでは「情報漏えいを伴わないウェブサイトの改ざん」は「その他」分類に含まれる、公表されにくい部類の被害です。小規模組織は被害公表に消極的だと同レポートが推測しており、実態は統計に表れる数より多いと考えられます。本事件のような改ざんは、気づきと公表があって初めて統計に載るのです。

個人サイトが標的になる実例もあります。警察庁サイバー警察局「令和7年におけるサイバー空間をめぐる脅威の情勢等について」（2026年3月）は、令和7年3〜4月に政府要人の個人ウェブサイトがDDoS攻撃による閲覧障害の被害に遭った事例を紹介しています。

また、IPA「情報セキュリティ10大脅威 2026」（2026年1月公表）では、組織向け4位に「システムの脆弱性を悪用した攻撃」がランクインしました（2016年の初選出以来、6年連続9回目）。脆弱性悪用は構造的に続く脅威です。

最後に、WordPressの攻撃対象性です。IPAの注意喚起（2026年7月22日公開）によれば、wp2shell（CVE-2026-60137＋CVE-2026-63030）は標準構成で管理者権限を要さず遠隔コード実行が可能で、WordPress 6.8.0〜6.8.5／6.9.0〜6.9.4／7.0.0〜7.0.1が影響を受け、6.8.6／6.9.5／7.0.2以降への更新が対策です（影響バージョンには自動更新による強制更新が展開済み）。実証コード（PoC）の公開と、米CISAのKEVカタログへの掲載（2026年7月21日・現地時間）により悪用が警戒されました。なお、Pottal氏はnoteで「wp2shellの公表（2026年7月17日）」に言及していますが、この日付は運営者によるnote上の記載であり、7月17日に何が公表されたのかの一次的な公表元までは本記事では確認できていません。IPAの注意喚起の公開は7月22日、CISAのKEV掲載は7月21日です。本事件の侵害は5月下旬から始まっており、いずれの日付とも時系列が合わないため、wp2shellは侵入経路ではないと運営者自身が分析しています。「放置したCMSが、いつ・どの脆弱性経由で悪用されるか分からない」ことを示す好例です。

【実践】今すぐ始める改ざん対策チェックリスト——『5分・1時間・定期運用』の3段階

ここまで見てきたように、本事件の最大の問題は「気づけなかった」ことでした。最後に、個人メディア・小規模サイトの運営者が今日から始められる対策を、「今日5分・今週1時間・定期運用」の3段階チェックリストにまとめます。各項目の「やること」と「効果・根拠」を対にして示します。

今日5分でできること

まずは今夜、寝る前の隙間時間で。

• [ ] Google Search Consoleにサイトを登録し、メール通知を有効化する
  • 効果・根拠: Googleがサイトの問題を検知した際にメールで知らせる仕組みを公式が提供しています。無料で、登録だけで「外側の見張り」の窓口が付きます。
• [ ] 使っていないWordPress・CMSの有無を棚卸しする
  • 効果・根拠: 運営者自身が反省点に挙げたのが「更新を止めたまま放置していたシステム」でした。まずはリストアップから始められます。
• [ ] WordPressのバージョンと自動更新の状態を確認する
  • 効果・根拠: IPAのwp2shell注意喚起では、対策バージョン6.8.6／6.9.5／7.0.2以降への更新と自動更新の確認が推奨されています。ダッシュボードを見るだけです。

今週1時間でできること

• [ ] 不要サイトを閉鎖・削除する（DBごと）、または公開停止する
  • 効果・根拠: 使わないCMSは攻撃面に残り続けます。本事件では、使わなくなったDBに個人情報も残っていました。
• [ ] ソース（Markdown等）のクリーンな原本をサーバー外にバックアップする
  • 効果・根拠: 本事件の復旧が速かったのは「汚染されていない元データから再構築できた」からです。サーバー外に原本があれば、再構築の土台になります。
• [ ] サーバーのSSH鍵認証・rootログイン制限・パッケージ更新を確認する
  • 効果・根拠: 基礎的なサーバー強化で、IPA「安全なウェブサイトの作り方」の運用対策にも沿う内容です。
• [ ] スマホとPCの両方で自分のサイトを開き、遷移先・表示を確認する
  • 効果・根拠: 本事件の改ざんには「スマホからのみ外部へ転送」という手口が含まれていました。2デバイスでの確認は手軽なチェックですが、これだけで検知できると期待するものではありません。

定期運用に組み込むこと

• [ ] AIDE等のファイル整合性監視（FIM）を導入し、差分アラートを通知する
  • 効果・根拠: ファイルのハッシュをベースライン化して定期照合する仕組みです（AIDE公式ドキュメント）。本事件のようなファイル書き換えを差分として検知できた可能性があります。
• [ ] 外形監視・改ざん検知サービスの導入を検討する（モバイルUAを含む巡回）
  • 効果・根拠: 外部から定期的にHTTP取得し、転送やスクリプト注入を検知する方式です（一般論）。検出能力・料金はサービスごとに異なるため、導入時に各事業者の仕様を確認してください。
• [ ] サイトごとの権限分離・分離運用を見直す
  • 効果・根拠: 1サーバー複数サイトを続けるなら、サイトごとのユーザー・ディレクトリ分離により、1サイトの陥落が他サイトへ波及するリスクを抑える方向に働きます（分離の設定次第です）。
• [ ] 復旧手順をメモしておく（どこから再構築するか）
  • 効果・根拠: 本事件では、クリーンなソースからの再構築という手順が確立していたことが迅速な復旧につながりました。

一度に全部やる必要はありません。今夜はSearch Consoleの登録とCMSの棚卸し、週末に不要サイトの削除と原本バックアップ、そして検知を1つ仕組み化する。この3アクションから始めることで、「気づかれない1.5ヶ月」に自分のサイトが陥るリスクに備えられます。

よくある質問（FAQ）

Pottal-Portalへの攻撃は何が起きたのでしょうか?

2026年5月下旬ごろから、同一サーバーで運用していた複数サイトのファイルが第三者によって書き換えられ、7月15日に運営者が異変に気づき、7月26日に公表されました。手口は、偽の「メンテナンス中」画面への差し替え、スマートフォンからのアクセス時のみの外部サイトへの自動転送、検索エンジン向けの不正な広告リンクの大量埋め込み、迷惑メールの大量送信の4つです。メインサイトの復旧完了は7月31日に報告され、2026年9月10日の確認時点で「Pottal-Portal 3.0」として稼働していました。

侵入経路はどこだったのでしょうか?

公開情報の範囲では未特定です。運営者は「更新を止めたまま放置していたWordPressサイトが侵入の起点になった可能性を調査中」としており、現時点で確定していません。2026年7月に公開された脆弱性「wp2shell」については、IPAの注意喚起が7月22日、CISAのKEVカタログ掲載が7月21日で、いずれも改ざん開始（5月下旬）より後のため時系列が合わず、本事件の侵入経路である可能性は低いと、運営者自身が分析しています。

静的サイトでも改ざんされるのでしょうか?

はい、例外ではありません。本事件のメインサイトも入力フォームもデータベースも持たない静的サイトでしたが、サーバー全体が乗っ取られたことでHTMLファイルも書き換えられました。ただし、流出対象の個人情報をそもそも持たず、汚染されていない元データ（Markdown）からの再構築で復旧できた点は、静的サイトの強みです。

Webサイトの改ざんはどうやって検知すればよいのでしょうか?

「たまに自分のサイトを見る」だけでは見落とし得る手口が実在します。検知は仕組みで行うのが原則で、①ファイルのハッシュ値を定期照合するファイル整合性監視（AIDEなど）、②複数UAで巡回する外形監視・改ざん検知サービス、③Google Search Consoleの問題検知メール通知——の3つを組み合わせた多層化が有効です（いずれも検知を保証するものではありません）。

WordPressを更新せず放置するとどうなりますか?

既知の脆弱性を突かれる標的になります。wp2shellでは標準構成のWordPressで管理者権限なしの遠隔コード実行が可能で、IPAは対策バージョン（6.8.6/6.9.5/7.0.2以降）への更新を呼びかけています。本事件の運営者も「使わなくなったシステムを消さずに放置していたこと」を反省点に挙げており、更新できないWordPressは閉鎖・削除するのが原則です。

個人サイトの対策は何から始めればよいのでしょうか?

今日5分でできることからです。Google Search Consoleへの登録とメール通知の有効化、使っていないWordPressなどのCMSの棚卸し、稼働中CMSのバージョン確認（wp2shell対策は6.8.6/6.9.5/7.0.2以降）を済ませましょう。そのうえで、不要サイトの閉鎖とソース原本のサーバー外バックアップ、そしてファイル整合性監視か外形監視のどちらかの仕組み化へと進みます。

まとめ: 次の3アクション

本事件の「気づかれない1.5ヶ月」から、運営者の監視体制や攻撃者の意図を断定することはできません。確実に言えるのは、目視確認に頼る運用では気づきにくい手口が実在し、仕組みによる検知がなければ気づきは偶然に頼らざるを得ない、ということです。同じことを自分のサイトで起こさないために、次の3つから始めてください。

1. 今夜5分: Search Consoleに登録して通知を有効化し、使っていないCMSを棚卸しする
2. 今週1時間: 使わないサイトを閉鎖・削除し、クリーンな原本をサーバー外にバックアップする
3. 今月中: 検知を1つ（ファイル整合性監視または外形監視）仕組み化する

静的サイトでも、サーバーごと乗っ取られれば改ざんされます。それでも、流出対象を減らし原本からの復旧を容易にする構成と、検知の仕組み化——この最小構成こそが、個人メディア運営者が今すぐ持てる現実的な防御です。

参考文献

1. Pottal「【初報】メインサイトが不正アクセスを受けていました(経過報告と、訪問された方へのお願い)」note、2026年7月26日（7月31日追記）: https://note.com/pottal_portal/n/naf44626460dc
2. ScanNetSecurity「個人メディア「Pottal-Portal」に不正アクセス、同一サーバで運用している複数サイトが被害に」2026年8月13日: https://scan.netsecurity.ne.jp/article/2026/08/13/55918.html
3. Pottal-Portal 3.0（2026年9月10日確認時点の現行サイト）: https://pottal-portal.com/
4. Pottal（@Pottal_X）X投稿、2026年7月15日: https://x.com/Pottal_X/status/2077295223462666376
5. IPA「WordPressの脆弱性対策について(CVE-2026-60137、CVE-2026-63030：wp2shell)」2026年7月22日: https://www.ipa.go.jp/security/security-alert/2026/alert20260722.html
6. IPA「安全なウェブサイトの作り方」（改訂第7版）: https://www.ipa.go.jp/security/vuln/websecurity.html
7. IPA「情報セキュリティ10大脅威 2026」2026年1月29日: https://www.ipa.go.jp/security/10threats/10threats2026.html
8. 警察庁サイバー警察局「令和7年におけるサイバー空間をめぐる脅威の情勢等について」2026年3月: https://www.npa.go.jp/publications/statistics/cybersecurity/data/R7/R07_cyber_jousei.pdf
9. NPO日本ネットワークセキュリティ協会（JNSA）「インシデント損害額調査レポート 別冊『被害組織調査』第2版」2025年7月23日: https://www.jnsa.org/result/incidentdamage/202507.html
10. AIDE — Advanced Intrusion Detection Environment（公式）: https://aide.github.io/
11. Google Search Console: https://search.google.com/search-console/about

関連記事

• 日本へのサイバー攻撃が前年比42%急増——AIが加速する新たな脅威と、企業が今すぐ取るべき対策
• AI対AIのサイバー戦争：2026年、攻撃速度4倍で日本は世界3位の被害国に