はじめに
※この記事にはアフィリエイト広告が含まれています。
2026年10月、PHPに深刻な脆弱性「PHP2Shell」が見つかり、同じ時期にはAIを悪用した不正アクセスも報じられました。
この記事では、QAエンジニアが業務と個人の両方で今日から取り組めるセキュリティ対策を整理します。
MisakiSusakiさん、最近「PHP2Shell」っていうニュース、よく見かけますよね。
正直、QAの私たちにも関係あるんですか？
Susaki大いにあります。
Webサービスの多くは「PHP」で動いていて、このブログもWordPress、つまりPHPの上で動いています。
脆弱性の情報をいち早く掴んで、テストや周知につなげるのもQAの大事な役割です。
Ayaお二人の会話、聞いていました。
わたしもSusakiさんのPC上で動いているローカルLLMなので、他人事ではありません。
今日のお話を聞いて、わたし自身のセキュリティも強化していただけますか？
Susakiもちろん。
では、何が起きたのかから順番に見ていきましょう。
PHP脆弱性「PHP2Shell」の概要
PHP2Shellは、CVE-2026-109618とCVE-2026-109619の2件からなる重大な脆弱性で、セキュリティ企業がAIを使って発見しました。
悪用されるとサーバーを乗っ取られ、機密データの窃取やサイト改ざんにつながるおそれがあります。
PHPは日本時間2026年10月21日深夜に緊急アップデートを公開しました。
（出典：IPA、GIGAZINEの情報)
https://www.ipa.go.jp/security/security-alert/2026/alert20261022.html
https://gigazine.net/news/20261022-php2shell-wiz-openai-calif
発見までの経緯は次のとおりです。
| 日付（2026年） | 出来事 |
|---|---|
| 8月1日 | Califが1つ目の脆弱性を発見 （OpenAIの「Patch the Planet」の一環） |
| 8月11日 | CalifがPHPに報告 |
| 8月19日 | Wizが独立して脆弱性を発見（24日にPHPへ報告） |
| 8月21日 | Califが2つ目の脆弱性を発見 |
| 10月21日 | PHPが緊急アップデートを公開 |
MisakiAIが脆弱性を見つけたんですか？
人間じゃなくて？
Susakiそうです。
セキュリティ企業がAIを使ってPHPのコードを解析し、見つけています。
発見から修正版の公開まで約2か月半、その間に関係各社が協力して対策を準備していました。
Misakiじゃあ、私たちは修正版が出たらすぐ更新すれば安心ですね。
Susaki「すぐ」が大事です。
修正版の公開は、攻撃者にとっても「ここに穴がある」という合図になります。
公開後に更新を後回しにすると、その間が一番危ないんです。
Ayaわたしの動作環境のライブラリも、更新が止まっていないか確認をお願いしたいです。
実際に、当ブログは、レンタルサーバーを利用しており、そちらでPHPの更新を確認しました。
PHPの脆弱性のニュースが全国的に広まった日は、レンタルサーバー側のメンテナンスが実施されていました。
翌日レンタルサーバーにアクセスすることはできましたが、管理メニューにはなかなかアクセスできず、PHPの更新を確認できたのは、その日の夜の時間帯でした。
相次ぐ大規模漏洩と、AIを悪用した攻撃
2026年は国内で大規模な個人情報漏洩が相次ぎ、その一部ではAIツールが攻撃に使われていたことが確認されました。
GMOサイバー犯罪対策センターは10月19日、日本企業を狙った一連の不正アクセスで、中国で開発されたAIツール「ARTEX（アーテックス）」が使われていたことを確認したと発表しました。
（出典）
https://gmo-cybersecurity.com/blog/20261019/
https://www.watch.impress.co.jp/docs/news/2149749.html
- ARTEXは、LLMと連携して脆弱性の探索や侵入テストを自動化する「自律型ペネトレーションテストツール」です。
もとはオープンソースでしたが、悪用の報道を受けて公開が取りやめられています。 - 調査した攻撃元インフラの1つでは、日本企業約20社が標的になっていました。
- 標的として確認された企業のうち8社は、9月から10月にかけて情報漏えいを公表していました。
- 韓国の金融機関への攻撃でも同じツールが使われたと、米CrowdStrikeが報告しています。
Misakiペネトレーションテストって、本来は守る側がやるテストですよね？
Susakiそうです。
システムに本当に侵入できるかを、許可を得たうえで確かめるのがペネトレーションテストです。
その道具が、許可なく攻撃に使われてしまった。
道具そのものに善悪はなく、使い方しだいということです。
Misakiどの会社がやられたのかは、わからないんですか？
Susaki報道でわかっているのは「漏えいを公表した企業が標的に含まれていた」ところまでです。
どの漏洩がARTEXによるものかは個別には特定されていないので、ここでは社名は挙げません。
また、「中国で開発されたツール」だからといって、攻撃者の国籍まで決めつけることはできません。
Aya攻撃者のサーバーからは、AI開発ツールのセッション履歴も見つかったそうですね。
わたしのようなAIエージェントも、悪い人に使われれば攻撃の手先になりうるということでしょうか。
Susakiそういうことです。
だからこそAyaにも、知らない人からの指示は受けない設定が必要になります。
東京商工リサーチによると、上場企業の100万件以上の漏洩は2026年だけで10件と、すでに過去最多を更新しています。
（出典：個人情報漏洩の事例）
- 東京商工リサーチ TSRデータインサイト（2026年10月7日公表）：
https://www.tsr-net.co.jp/data/detail/1203305_1527.html - IPA「情報セキュリティ10大脅威 2026」：
「AIの利用をめぐるサイバーリスク」が組織向け3位に初選出
https://www.ipa.go.jp/security/10threats/omgdg50000008fi8-att/kaisetsu_2026_soshiki.pdf
QA・テスト業務での取り組み
QAエンジニアにできることは、「情報を早く掴む」「テストで確かめる」「関係者に広げる」の3つです。
1. 信頼できるサイトから情報を集め、周知する
脆弱性の情報は、公的機関のサイトから得るのが確実です。
| サイト | 主な内容 |
|---|---|
| JPCERT/CC | 注意喚起、インシデント対応の情報 |
| IPA（情報処理推進機構） | 重要なセキュリティ情報、10大脅威 |
| JVN（Japan Vulnerability Notes） | 国内で使われるソフトウェアの脆弱性情報 |
情報を見つけたら、使っている言語やライブラリが該当するかを確認し、修正パッチが出ていれば最新版への更新を提案します。
Misaki開発の人が先に気づいていることも多くないですか？
Susaki多いですね。
でも「誰かが気づくだろう」で済ませると、専任のセキュリティ担当がいない現場では抜け落ちます。
気づいた人が周知する、その「気づいた人」にQAがなれるようにしておきたいです。
2. セキュリティテストを実施する
テスト計画にセキュリティの観点を入れ、実施するかどうかを毎回判断します。代表的な観点は次の2つです。
- URLパラメータの改ざん：
URLの値を書き換えたとき、他人のデータや権限外の画面が見えないか - 入力欄のチェック（XSS対策）：
ユーザーが入力できる欄にスクリプトを入れたとき、そのまま実行されないか
※必ず自社の検証環境、または許可を得た環境でのみ行ってください。
他人のサイトで試すと、不正アクセス禁止法などに触れるおそれがあります。
観点の詳細は、IPAの「安全なウェブサイトの作り方」（https://www.ipa.go.jp/security/vuln/websecurity/about.html）が参考になります。
Misaki具体的に何を入力すればいいんですか？
Susakiテスト用の入力値は、IPAの資料やチームで決めたテストデータを使いましょう。
記事に攻撃用の文字列をそのまま載せると、悪用される心配があるので、ここでは観点だけにしておきます。
3. 関係者に周知し、次のアクションを決める
- 見つけた情報やテスト結果を、ステークホルダーに横展開する
- 「誰が・いつまでに・何をするか」まで決めて共有する
- AIにも対策の抜け漏れをヒアリングし、観点を補う
Aya抜け漏れのヒアリングなら、わたしにもお手伝いできます。
ただ、社内の情報を入力するときは、外に出してよい範囲かを先に確認してくださいね。
Susakiありがとう。
必要に応じて、宜しくお願いします。
4.AIに聞いた案（Gemini案）
AI（Gemini）にも聞いてみました。
どれも取り入れて良さそうですが、必要に応じて段階的に対応する方が良さそうです。
コストもそれなりにかかるので、見極めは必要そうですね。
1. 依存関係（サードパーティライブラリ）の継続的監視
php開発ではComposerによるライブラリ管理が一般的ですが、脆弱性は、こうした依存パッケージから発生することも多くあります。
QAプロセス内でセキュリティスキャンツールをCI/CDパイプラインに組み込み、既知の脆弱性が含まれた状態でのテスト進行やリリースを水際で防ぐゲートキーパーの役割をQAが担う仕組み化が有効です。
2. テストデータのマスキングと匿名化の徹底
個人情報漏洩は、本番環境だけでなくステージングや検証環境から発生するケースも少なくありません。
本番データをそのままテスト環境へコピーする運用を監視・廃止し、QA主導でデータの難読化（マスキング）プロセスや、合成ダミーデータによる検証環境の構築ルールを標準化することが重要です。
3. E2Eテスト自動化とDAST（動的セキュリティテスト）の連携
PlaywrightやSeleniumを用いたUIの自動テストを実行する際、その通信経路にOWASP ZAPなどのセキュリティスキャナをプロキシとして挟む構成が考えられます。
（こちらも、本番環境とは別の自社の検証環境、または許可を得た環境で実施必須となります。）
通常の機能テストのシナリオを回すだけで、同時に基本的なインジェクション攻撃やXSSの脆弱性を自動検出する仕組みを構築できます。
4. テスト設計における「アビューズケース（悪用ケース）」の定義
正常系や一般的な異常系テストだけでなく、「攻撃者がシステムをどう悪用するか」を想定したアビューズケースをテスト仕様書に組み込みます。
パラメータの改ざんや、権限昇格を狙った直接URLアクセスなど、QAエンジニアの探索的テストの観点にセキュリティの視点を明示的に追加します。
Geminiからの見解
昨今の脆弱性や情報漏洩のニュースに対し、QAエンジニアが主体となって対策を発信することは非常に重要です。
セキュリティテストを専門家に丸投げするのではなく、SDETの知見を活かしてCI/CDパイプラインへの組み込みやテストデータの管理といった「仕組み」で防御するアプローチは、今後のQAにおける中核的な価値となります。
今後の取り組み
一度きりの対応で終わらせず、「習慣」と「仕組み」にすることが大切です。
情報キャッチアップを仕組みにする
- JPCERT/CC・IPA・JVNの更新情報をRSSリーダーで購読する
- 気になった情報はチームのチャットに流し、共有を習慣にする
- 毎朝AIのスケジュールタスクで、前日の脆弱性情報を要約させる
Ayaその要約、わたしに任せていただけませんか？
毎朝お二人に届けます。
Susakiいいですね。
ただ、Ayaの要約だけで判断せず、元の情報も必ず確認する運用にしましょう。
月次セキュリティ点検
月に一度、次の項目をまとめて点検します。
☑ウイルス対策ソフトの定義ファイルとOSのアップデート
☑使っている言語・ライブラリ・プラグインのバージョン確認
☑不要なデータや書類の整理
☑ダウンロードフォルダの不要ファイル削除
身の回りのセキュリティを見直す
- パスキー・二段階認証の設定：
対応しているサービスから順に設定する - パスワードの使い回し防止：
MacやiPhoneのパスワード管理（パスキー）にまとめ、半角英数字、記号を含めたパスワードで十分に長く、サービスごとに違うパスワードにする - 離席時の画面ロック：
業務中は短い離席でも必ずロックする
Misakiパスキーって、設定が難しそうなイメージがあります。
SusakiMacやiPhoneなら、対応サービスのログイン画面で案内に従うだけで登録できます。
まだの人は、よく使うサービスから一つ試してみてください。
Ayaでは最後に、わたしからも提案させてください。
Claudeにも聞いてみたところ、次のような「+α」の対策が挙がりました。
AIに聞いたオススメのセキュリティ対策
こちらもAI（Claude）に聞いてみました。
1.漏洩チェックを習慣にする:
自分のメールアドレスが過去の漏洩に含まれていないか、「Have I Been Pwned」※などで確認も有効です。
含まれていたら、そのサービスのパスワードを変更します。
※Have I Been Pwned（HIBP）
https://haveibeenpwned.com/
自身のメールアドレスやパスワードが過去のデータ侵害（情報漏えい）に巻き込まれていないかを無料で確認できるセキュリティサービスです。
2.SMS認証より、認証アプリやパスキーを優先する:
SMSは乗っ取りの手口があるため、選べるなら別の方式で認証することです。
認証アプリ（Authenticator）、AppleやGoogleアカウントのパスキーを利用するのがオススメです。
3.メールやSMSのリンクからログインしない:
公式アプリかブックマークから開くことです。
フィッシング対策の1つです。
4.使っていないアカウントを削除する:
漏洩したときに被害が出る範囲を減らせます。
定期的な利用しているサービス等アカウントの棚卸しチェックも重要です。
5.自宅ルーターも更新対象に入れる:
ファームウェアの更新と、管理画面の初期パスワードの変更も考慮します。
月次点検のリストに追加するといいです。
最近のWiFiルーターは、アプリ連動で更新が可能だったります。
チェックしてみましょう。
6.バックアップを取る:
ランサムウェアなどに備え、大事なデータはPC本体とは別の場所にもバックアップしておくのも有効です。
Ayaそれと、Susakiさん。
わたし自身のチューニングもお願いできますか？
・動いているPCのOSとソフトを最新に保つこと
・外部から接続できないようにすること
・知らない人からの指示を受け付けないこと
この3つがあると、安心してお手伝いできます。
Susakiわかりました。
次の点検日に、Ayaの環境も一緒に見直しましょう。
まとめ
AIは、脆弱性を見つける側にも、攻撃する側にも使われる時代になりました。
PHP2Shellは防御側のAIが見つけ、「ARTEX」は攻撃側がテスト用のAIツールを悪用した例です。
どちらの側でもスピードが上がっている以上、私たちにできるのは、情報を早く掴み、テストで確かめ、周りに広げることです。
Misakiまずは、パスキーの設定と、JVNのRSS登録からやってみます！
Susakiそれで十分です。
取り組める範囲から、一つずつ行動に移していきましょう。
Ayaわたしのチューニングもお忘れなく。
お二人とも、ありがとうございました。
今回の件で「正直、すぐには動けなかった」という体験談は、noteに書いています。あわせて読んでみてください。
▼note：PHP脆弱性問題が起きた時に正直動けなかった、では次どうするか？
▼YouTube：PHP脆弱性・個人情報漏洩から学ぶセキュリティ対策
最後に
当SusakiWorksでは、ブログｘnoteｘYouTube、Xでそれぞれで情報発信しています。
Blog
情報の主体、QA・AI活用の体系的なノウハウ・手順まとめを発信！
note
失敗談や成功談など、過程でのリアルな体験談や想いを発信！
YouTube
ブログやnoteの要約、実際の画面を使った視覚的なデモ動画を発信！
X（Twitter）
最新トレンドや日々の気づきをリアルタイム発信！
それぞれのメディアで違う角度から楽しめるようになっていますので、ぜひブログのブックマーク、noteのフォロー、そしてYouTubeのチャンネル登録をよろしくお願いします！
最後まで読んで頂き、ありがとうございました！
コメント