WEBサイトIPAは、外部に公開しているアプリ・利用中の外部サービス・保有データの3つを速やかに点検するよう呼びかけた ── 管理画面の利用者・ログの保持日数・不要なデータを台帳にして確かめる13項目（2026年10月時点）
IPAは、外部に公開しているアプリ・利用中の外部サービス・保有データの3つを速やかに点検するよう呼びかけた ── 管理画面の利用者・ログの保持日数・不要なデータを台帳にして確かめる13項目（2026年10月時点）
目次
01 何が書いてあるか — IPAは、外部に公開しているアプリ・利用中の外部サービス・保有データの3つを、速やかに点検するよう呼びかけた
引用について
この記事の引用は、IPA（情報処理推進機構）の注意喚起と、JPCERT/CC（JPCERTコーディネーションセンター）の注意喚起の本文からの、日本語の文である。ブロックで示した文は、原文のとおりに写した。各ページは2026年10月26日に開いて、本文を取り直して確かめた。
IPAの注意喚起は、2026年10月9日に掲載された
IPAは、「不正アクセスによる漏えい等の事案を踏まえ、速やかに実施すべき対策等について」という注意喚起を、2026年10月9日に掲載した。ページの冒頭には、次の注釈がある。
注釈：追記すべき情報がある場合には、その都度このページを更新する予定です。
2026年10月26日にページの更新履歴を開くと、載っていたのは「2026年10月9日 掲載」の1行だけだった。追記は、この日の時点では無い。追記が出たら、この記事に日付つきで足す。
注意喚起の対象は、経営者である。ただし、点検の中身は、サイトの管理画面、ログ、外部サービスのアカウントといった、WEBディレクターの手元にあるものである。この記事は、その点検を、担当サイトの台帳に落とす。
点検は3つの見出しに分かれ、最後に情報収集が添えられている
IPAは、この事案の傾向を次のように書く。
現段階では、特定のプロダクトやサービスの脆弱性を狙った攻撃とは断定されておらず、公表事例の傾向から、外部公開しているアプリケーションやサービスの侵害、アカウントの侵害が起点となっていることがうかがえます。
そのうえで、「速やかに行うべき点検」を、見出し3つで示す。1つ目は外部に公開しているアプリケーションの精査、2つ目は自組織が利用している外部サービスの洗い出し、3つ目は保有データの再点検である。3つ目の本文のあとに、「当面情報収集を強化してください」という文が続く。不審なIPアドレスやログの痕跡などの情報を、公的機関やセキュリティ事業者が公表する可能性があるから、という理由が書かれている。
JPCERT/CCの注意喚起は、2026年10月23日に更新された
JPCERT/CCは、「直近で相次いでいる国内組織における不正アクセスに関する注意喚起」（JPCERT-AT-2026-0030）を、2026年10月8日に公開し、10月23日に更新した。ページには「最終更新: 2026-10-23」と書かれている。10月23日の更新では、攻撃の例の一覧に、「ケースE：AIを用いたペネトレーションテスト基盤を悪用した攻撃試行」が加わった。ペネトレーションテストは、攻撃を模擬して弱い所を探す検査のことである。この記事は、攻撃の手口には立ち入らず、原文が勧める対策と、確かめる項目だけを扱う。
IPAのページが並べる、ほかの公的機関の注意喚起
IPAのページには、「（ご参考）政府機関等からの注意喚起」として、同じ事案への注意喚起が並ぶ。内閣官房の国家サイバー統括室の不正アクセスによる漏えい等の事案を踏まえた対応について（2026年10月9日）、経済産業省の注意喚起と協力依頼、金融庁の現下の情勢を踏まえたサイバーセキュリティ対策の強化と各種取引申込等における対応について、警察庁のサイバー警察局便り「情報流出に注意」、個人情報保護委員会の大規模な漏えい等事案を踏まえた対応について（注意喚起）、そしてJPCERT/CCの注意喚起である。
この記事は、点検の分け方はIPAに、台帳に入れる具体的な項目は、国家サイバー統括室とJPCERT/CCの対策の一覧に合わせた。
既存の記事との分担
点検の対象のうち、PHPはPHPの修正版が出た日に「どのサイトが当たるか」を数分で答えるには、担当サイトの一覧が要る ── 台帳の8列を埋めて確かめる13項目（2026年10月時点）、公開の場所に残った控えは公開の場所に残った控えファイルは、名前で探して状態コードで確かめ、外へ移す ── 自社と担当サイトの.bak・.old・日付付きの写しを棚卸しする13項目（2026年10月時点）、アプリのAPIはスマホアプリを解析してAPIを直接使う攻撃が報告されている。署名や難読化に頼らず、サーバー側で守る ── WebとアプリのAPIの台帳を作って確認する13項目（2026年10月時点）で扱った。この記事は、残る3つ、管理画面の利用者、ログの保持日数、不要なデータに絞る。
02 なぜ・背景 — 被害の入口は、管理する側のシステムにもある
JPCERT/CCは、管理側のシステムも被害に遭うと書いた
JPCERT/CCは、概要の中で、次のように書く。
一般利用者向けのアプリのほか、BI（ビジネスインテリジェンス）ツールや従業員向け管理システムなど、管理・運用側で不特定多数の利用者からのアクセスを想定していないシステムが被害に遭い、内部に保存していた情報が漏えいするケースもあります。
サイトの管理画面は、まさに「不特定多数の利用者からのアクセスを想定していない」場所である。利用者を限っているから安全、とは言えない。誰が入れるかを数えていなければ、限っているのか分からない。
アカウントは、サービスごとに別々の場所にある
WEBディレクターが関わるアカウントは、サイトの管理画面のほかに、計測、広告、メール配信、フォーム、ドメインの管理など、サービスごとに別の画面にある。記事サイトにつながる外部ツールと権限は、サービスごとに別々の画面で管理されている ── 計測・CMS・広告の連携を棚卸しする14項目（2026年9月時点）と、記事GoogleアナリティクスのユーザーグループがAPIで管理できるようになったが、まだAlphaの段階 ── 人の出入りのたびに権限を確認する13項目（2026年10月時点）は、その画面の側から、権限を確かめる項目を挙げた。この記事は、IPAの原文の分け方に合わせて、サイトの管理画面と外部サービスを、1つの台帳にまとめる。
ログの保持日数は、サービスごとに違い、見られる人も違う
IPAは、ログについて、次のように書く。
サービス単位でログの保有期間はそれぞれ異なることが想定されますので、その整理も必要です。また、サービス提供者と利用者で確認できるログにも違いがある可能性があります。誰がいつどのように確認できるかについて整理してください。
「保持日数」は、サービスの契約や設定で決まる。事業者に預けているサイトでは、自分では見られないログがある。ログを調べる日に、ログが残っていなければ、点検そのものができない。保持日数を先に知っておく意味は、そこにある。
「不要な情報は持たない」は、台帳の最後の列になる
IPAは、保有データの点検の理由を、次のように書く。
不要な情報は持たない、という基本原則のもと、自らが保有する情報資産を正確に把握し、必要最小限にする等、保有情報の再点検も必要です。
この文は、長い1文の後半である。前半は、情報を盗まれると、悪用のほか、「窃取した情報を公開する」と脅されたり、不正に売買されたりする、二次被害が広がる傾向がある、と書いている。持っていなければ、盗まれない。サイトが集めている個人情報（問い合わせ、会員登録、応募など）の置き場と、持つ理由、消す日を、台帳に書く。
03 この記事に出てくる用語
アカウントの棚卸し
利用者のアカウントを全部書き出し、いまも要るかを確かめることである。IPAの注意喚起の「その後取り組むべき対策」にも、「アカウント棚卸の運用見直し」が載っている。
ログの保持日数（保有期間）
ログを消さずに残している日数のことである。IPAの原文では「保有期間」と書かれている。この記事では、台帳の列の名前を「保持日数」にする。意味は同じである。
外部サービス
自社のサーバーの外で動く、クラウドのサービスのことである。IPAは、クラウドサービス、VPNサービスなど、様々な分類があると書く。サイトの計測、メール配信、フォームなども、この記事では外部サービスに入れる。
セキュリティインシデント
情報漏えいや不正アクセスなど、セキュリティの事故のことである。IPAは、異常なログやアカウントが見つかったときは、速やかにセキュリティインシデントと判定し、対応を進めるよう書く。
管理画面の公開
サイトを管理するための画面に、インターネットのどこからでも、入口のページが開ける状態のことである。入口が開けることと、中に入れることは別である。ただし、JPCERT/CCは、業務に必要のない管理機能が公開されていれば、公開を止めるよう書く。
04 型別 — 3つの台帳を作り、サイトごとに数えて書く
🅰 この作業が当てはまる人
サイトに、管理画面、会員、問い合わせフォームのどれかがある人は、全員が当てはまる。外部サービスを使っているサイトは、すべて当てはまる。事業者や制作会社にサイトを預けている人は、確認の多くが「聞く」ことになる。
🅱 この作業が測っていないこと
- 異常があるかどうか — 台帳は、見る範囲を決めるための表で、異常を見つける道具ではない。IPAは、異常が見つかったときは、専門のセキュリティベンダーに詳細な調査を依頼することを強く推奨している
- 脆弱性の修正が済んでいるか — IPAは、未適用の修正パッチが無いかの確認も点検に入れている。PHPの版の確認は、01章で挙げた台帳の記事で行う
- 攻撃の手口の見分け方 — この記事は、IPアドレスや手口を書かない。JPCERT/CCのページの一覧は、原文で確かめる
🅲 手順: 3つの台帳を、1つの表計算ファイルに作る
台帳は、1つのファイルの中に、3枚のシートで作る。3枚とも、1列目に「サイト名とURL」、最後に「更新する人と連絡先」と「最後に確かめた日」を置く。この3列は、記事PHPの修正版が出た日に「どのサイトが当たるか」を数分で答えるには、担当サイトの一覧が要る ── 台帳の8列を埋めて確かめる13項目（2026年10月時点）の台帳と、同じ名前にする。PHPの台帳と同じファイルに、シートを足してもよい。
| 台帳 | 列（1列目と最後の2列は共通） | IPAの原文の見出し |
|---|---|---|
| 利用者の台帳 | 名前・権限・最後にログインした日・追加した人・いまも要るか | 外部に公開しているアプリケーションの精査／外部サービスの洗い出し（アカウントの異常） |
| ログの台帳 | ログの種類・置き場所・保持日数・見られる人・延ばせる人 | 外部に公開しているアプリケーションの精査／外部サービスの洗い出し（ログの異常） |
| データの台帳 | データの種類・置き場所・持つ理由・消す日 | 保有データの再点検 |
IPAの3つの点検と、添えられた情報収集ごとに、誰が・何を見て・どこに書くかを、次の表に整理する。「誰が」の列は、筆者の整理である。
| 点検 | 誰が | 何を見て | どこに書くか |
|---|---|---|---|
| 外部に公開しているアプリケーションの精査 | サイトの担当者。画面から見られないときは、事業者 | 管理画面の利用者の一覧、最後にログインした日、ログの保持日数 | 利用者の台帳、ログの台帳 |
| 外部サービスの洗い出し | サイトの担当者 | 契約書、カードの明細、通知メール。サービスごとの管理者の数とログの日数 | 利用者の台帳、ログの台帳 |
| 保有データの再点検 | サイトの担当者と、データを使う部署 | 問い合わせ・会員・応募などの個人情報の置き場、持つ理由、消す日 | データの台帳 |
| 当面の情報収集 | サイトの担当者 | IPAとJPCERT/CCのページの追記 | 台帳の1行目の、見直し日の欄 |
手順1: サイトと、管理画面の入口を書き出す
契約書、請求書、ドメインの管理画面から、担当サイトの名前とURLを書き出す。サイトごとに、管理画面の入口のURLも書く。サイトの外にある管理画面（計測、広告、メール配信など）は、手順5で書く。
手順2: 管理画面の利用者を、全員書き出す
各管理画面で、利用者の一覧を開き、利用者の台帳に写す。名前、権限、最後にログインした日、追加した人を書く。IPAが挙げる異常は、2つである。
作ったはずのないアカウントが存在しないか、削除・無効化されているはずのアカウントが有効化されていないか等の異常を確認してください。
国家サイバー統括室の対策の一覧にも、アカウントについての項目がある。
退職者、異動者や利用されていないもの等の不要なアカウントを速やかに無効化する
書き出した利用者のうち、「見覚えがない」「担当を外れた」の2つに当てはまる人を数え、「いまも要るか」の列に「要確認」と書く。権限を持つ人と、その人を削除・無効化できる人は、別のことが多い。
手順3: 共有のアカウントと、見られない一覧を書く
複数の人で1つのアカウントを使っている場合は、共有している人の名前と、共有している理由を書く。誰が操作したかが、ログから分からなくなる。一覧が画面から見られない管理画面は、「見られない」と書き、事業者に聞く文を作る（手順7）。
手順4: ログの保持日数を書き、段階的に広げて見る
ログの台帳に、アクセスログ、エラーログ、管理画面の操作の記録を、種類ごとに書く。保持日数、置き場所、見られる人を書く。IPAは、ログの確認の進め方を、次のように書く。
異常の見わけ方としては、たとえばエラーの出力量、平時との差異等が挙げられます。また、直近１ヵ月、その後３ヵ月といったように、段階的に対象範囲を広げて確認してください。さらに、今後複数回調査を行う可能性も踏まえ、誰がどのように調査できるかについても把握しておいてください。
原文は、「直近１ヵ月、その後３ヵ月といったように」と、段階的な広げ方の例として書いている。3か月までと決めた期限ではない。筆者の読みでは、保持日数が1か月に満たないログは、この例の最初の範囲にも届かない。足りない日数と、延ばせる人を、ログの台帳に書く。ログの数え方は、記事PHPの脆弱性の「痕跡」は、ログに無いこともある ── 圧縮されたログ・エラーの出る先・回転の直後を落とさずに、件数で数える13項目（2026年10月時点）に書いた。
保持日数を決めるときの進め方を、4つに分ける（筆者の進め方）。
- ログの種類ごとに、いま何日残っているかを、契約・設定・事業者の答えから確かめて書く
- 1か月に満たないログに、足りない日数と、延ばせる人の名前を書く
- 延ばすときの費用や置き場所の条件は、事業者に聞く
- ログには、利用者の名前や連絡先が入ることがある。延ばす前に、入っている情報の種類を、データの台帳へ書く
実務のヒント
「平時との差異」を見るには、平時の数字が要る。直近1か月のログから、1日あたりの行数と、エラーの行数を、日ごとに書き出しておく。件数の多い日と少ない日を1日ずつ選び、普段と違う日がないかを見る。当サイトの無料ツールの🔧 IPA提供 攻撃兆候検出ツール iLogScanner で簡単ログ分析ツールは、アクセスログを渡すと、攻撃の兆候を調べて、結果をExcelなどのファイルで出す会員限定の道具である。台帳を作ったあとの、最初の1回に使える。
手順5: 外部サービスを洗い出し、アカウントとログを書く
IPAは、外部サービスの洗い出しについて、次のように書く。
クラウドサービス、VPNサービス等様々な分類があること、また組織全体、部署単位での利用がありうることを踏まえ、できる限り網羅的に把握してください。
契約書、クレジットカードの明細、サービスからの通知メールを探して、使っているサービスを書く。サービスごとに、管理者の数、ログを見られる人、サービスが残すログの日数を、ヘルプで確かめて書く。外へつなぐ先の一覧づくりは、ブログ認証局の中間証明書8枚の秘密鍵が漏れた週、当サイトのサーバーの中からつなぐ通信は、漏れた証明書を通していた ── AIの知らせを自分で測り直して、塞いだ記録でも扱った。
洗い出しの手がかりは、3つある。筆者の整理では、次のように使い分ける。
- 契約書 — 契約したサービスは拾える。契約書を交わさないサービスは、載らないことがある
- カードの明細 — 支払いのあるサービスは拾える。無料のサービスは、載らない
- 通知メール — 無料のサービスも拾える。通知を止めているサービスは、載らない
3つとも見て、見つかったサービスを足し合わせる。1つだけで足りると考えない。
手順6: 使っていない機能と、不要なデータを書く
JPCERT/CCは、汎用的な対策として、次の2つを挙げる。
業務上必要のないサービスや機能（管理機能など）がインターネットに公開されている場合、公開を停止する
法令や契約等で定められた保存期間を過ぎたデータや利用目的を終えたデータを残さない
1つ目は、古い管理ページや、テスト用の画面が、外から開けないかを、URLを1つずつ開いて確かめる。当サイトの無料ツールの🔧 WEBサイトの外からできるセキュリティ対策監査ツールは、URLを渡すと、外から集められる情報をまとめる。外からの見え方を、1回通しておく助けになる。公開の場所に残った控えの探し方は、ブログ控えファイルを外から確かめた日 ── 当サイトで読めたのは25本。「403でも置かない」理由と、次から積もらない手順に書いた。2つ目は、データの台帳に、置き場所、持つ理由、消す日を書く。
ほかの公的機関も、同じ項目を挙げた
国家サイバー統括室の資料は、データの管理の項目として、「利用目的や保存期間を明確にする」「定期的に情報資産の棚卸しを実施する」「利用目的を終えた情報は速やかに削除する」を挙げる。ログの項目には、「ログを一定期間保管する」がある。IPAとJPCERT/CCの項目と、言い方は違うが、台帳の列に落とせる。保存期間と消す日は、データの台帳の列になる。
手順7: 誰が・いつ見直すかを書き、異常のときの連絡先を決める
台帳は、作った日が最も新しい。見直す日を、月に1回にして、カレンダーへ入れる。異常が見つかったときの連絡先（社内の担当、事業者、専門のセキュリティベンダー）も、台帳の1行目に書く。IPAは、見つかったときは、速やかにセキュリティインシデントと判定して対応を進めるよう書くので、連絡先は平穏な日に決めておく。
異常を見つけたとき
IPAは、異常を見つけたら、速やかにセキュリティインシデントと判定して対応を進めるよう書く。そのとき、見つけたログは、消さずに残す（筆者の目安）。相談先は、IPAのサイバーセキュリティ 相談・届出窓口一覧と、コンピュータウイルス・不正アクセスに関する届出のページにある。
台帳の置き場所に注意
利用者の名前、権限、ログの保持日数は、そのまま攻撃者の手がかりになる。台帳は、公開の場所に置かない。見られる人は、担当者と、その代わりに動く人に限る。
05 明日、自社のサイトで確認できることチェックリスト
以下は、IPAの点検を、管理画面の利用者・ログの保持日数・不要なデータの3つの台帳で確かめる13項目である。1〜5番目は利用者、6〜8番目はログ、9〜10番目は外部サービス、11〜12番目は使っていない機能と不要なデータ、13番目は見直しの仕組みの確認である。1項目は5分を目安にする（サイトが多いときは、1サイトあたり5分）。チェックの状態はブラウザに保存され、サーバーには送られない。
- 担当サイトを書き出し、サイトごとに管理画面の入口（URL）を1つずつ書いて、全部で何本あるか数える
- 各管理画面を開き、利用者の一覧を、名前・権限・最後にログインした日の3つで書き出す。一覧が見られない画面は「見られない」と書く
- 書き出した利用者のうち、見覚えのない人と、担当を外れた人を数えて、台帳の「いまも要るか」の列に「要確認」と書く
- 1つのアカウントを複数の人で使っている画面を探し、共有している人の名前と、共有している理由を書く
- 「要確認」の利用者ごとに、削除か無効化を依頼する文を書いて、権限のある人へ送り、依頼した日を台帳へ書く
- サイトごとに、アクセスログ・エラーログ・管理画面の操作の記録の3種類について、保持している日数を書く（分からないものは「不明」）
- 保持日数が1か月に満たないログを探し、足りない日数と、保持日数を延ばせる人の名前を、ログの台帳へ書く
- 直近1か月のアクセスログとエラーログから、1日あたりの行数を日ごとに書き出し、多い日と少ない日を1日ずつ選んで、普段と違う日がないかを見る
- 使っている外部サービス（計測・メール配信・フォーム・広告・クラウド保存・VPN）を書き出し、サービスごとに管理者のアカウント数を書く
- 外部サービスごとに、ログを見られる人の名前と、サービスが残すログの日数を、ヘルプで確かめて台帳へ書く
- 使っていない管理機能や古い管理ページを、URLを1つずつブラウザで開いて確かめ、開けたものは公開の停止を、権限のある人へ依頼する
- サイトが集めている個人情報（問い合わせ・会員・応募）の置き場を3つまで書き出し、置き場ごとに、持つ理由と消す日を書く
- 見直す人と、月に1回の見直し日を台帳の1行目へ書いてカレンダーへ入れ、異常を見つけたときの連絡先（社内・事業者・専門ベンダー）を同じ行へ書く
06 代替・他の選択肢 — 台帳の作り方と、IPAが挙げた次の段階
台帳を作る方法は、4つある
台帳を作る方法は、1つではない。次の表に、4つの方法と、向く場面を整理する。
| 方法 | 向く場面 | 限界 |
|---|---|---|
| 表計算ソフトで手書き | 担当サイトが10本以下で、管理画面が数種類のとき | 見直す日を決めないと、すぐ古くなる |
| 管理画面の書き出し機能 | 利用者の一覧をCSVで書き出せる画面があるとき | 書き出せる項目は、画面ごとに違う。ログの保持日数は、一覧に出ないことがある |
| 事業者や制作会社に聞く | サイトを預けていて、自分では見られない画面があるとき | 答えが事業者の側の事情で変わる。依頼文に「Webの管理画面の利用者」と範囲を書く |
| 外部の診断を頼む | 異常が疑われるとき。IPAは専門ベンダーへの依頼を強く推奨する | 費用が掛かる。台帳は、診断の前に自分で作っておくと、依頼が早い |
IPAが挙げた、点検のあとの対策
IPAは、点検で異常が無くても、より強固な対策を取るよう書き、対象ごとに項目を挙げた。ウェブ担当者の台帳に関係するのは、次のものである。外部に公開しているアプリケーションでは、外部公開範囲の見直し、認証機能（多要素認証・パスワード）の強化、アカウントへの権限付与の見直し、ログ取得内容と保持期間の見直し。外部サービスでは、認証機能の強化、アカウント付与の範囲の見直し、アカウント棚卸の運用見直し、ログ取得内容と保持期間の見直し。保有するデータでは、データ保有の是非の再検討、データ保管場所の再検討、データへのアクセスのログと保持期間の見直し、データの暗号化である。
この記事の台帳は、それらの前提になる。利用者を数えていなければ、権限の見直しはできない。保持日数を書いていなければ、保持期間の見直しはできない。IPAの同じページは、中小企業向けの診断として「5分でできる！情報セキュリティ自社診断」（25個の診断項目）も紹介している。これは、IPAの中小企業の情報セキュリティ対策ガイドラインのページから入れる。取り組みを宣言する制度としては、SECURITY ACTION セキュリティ対策自己宣言もある。台帳を作ったあとに、組織全体の状態を見るときに使える。
攻撃の手口は、この記事では書かない。JPCERT/CCは、注意喚起の参考情報に、公式ブログの連続不正アクセス事案の攻撃手法に関する調査を挙げている。ログを見る担当者は、そちらを原文で読む。
07 当サイトで確かめたこと — この記事の根拠にした公式のページと、確かめていないこと
2026年10月26日に取り直して照らしたページ
この記事の引用は、2026年10月26日に、IPAの注意喚起、JPCERT/CCの注意喚起、国家サイバー統括室の資料を開いて、本文を取り直して確かめた。金融庁、警察庁、個人情報保護委員会、IPAの各ページは、題名と開けることを確かめた。経済産業省のページは、この日は開けなかったので、リンクを付けていない。ブロックで示した文は、本文の文と照らして、一致を確かめてある。IPAのページに、更新の履歴が1行（2026年10月9日 掲載）だけであること、JPCERT/CCのページに、更新日（2026年10月23日）があることも、同じ日に確かめた。
確かめていないこと
- 台帳の使いやすさ — 列は、IPAの原文の分け方から筆者が組んだ。複数の人で回した記録は無い
- 各管理画面で、利用者の一覧やログの日数が見られるか — 画面ごとに違う。調べていない
- IPAが書いた対策の効果 — 注意喚起に書かれた内容を並べただけで、効果の数字は書いていない
- JPCERT/CCのページの、攻撃元の一覧 — この記事では扱わない。ログとの突き合わせは、原文のページで行う
当サイトの対応
サーバーの設定やアカウントの数は、攻撃の材料になるので、この記事には書かない。当サイトの控えファイルの対応は、ブログ控えファイルを外から確かめた日 ── 当サイトで読めたのは25本。「403でも置かない」理由と、次から積もらない手順に書いてある。この記事は、2026年10月26日の時点のものである。IPAのページに追記が出たときは、日付つきで足す。
08 このテーマは、ここまで
2026年10月8日と9日 — JPCERT/CCの公開と最初の追記
JPCERT/CCが、注意喚起（JPCERT-AT-2026-0030）を10月8日に公開し、10月9日に概要と攻撃の例を追記した。
2026年10月9日 — IPAの注意喚起の掲載
IPAが、経営者向けの注意喚起を掲載した。点検は、外部に公開しているアプリケーション、外部サービス、保有データの3つである。
2026年10月23日 — JPCERT/CCの更新
JPCERT/CCが、攻撃の例にケースEを加え、ケースBの記載を足した。参考情報の欄にも、情報が追記された。
現在の貴方のIPアドレス
このサイトで書いている人
