攻撃される前に、 塞ぐ。
セキュリティ診断・保守は、Webサイトや社内システムを運用する企業向けの「脆弱性診断＆修正」と「保守プラン」です。AIがコードを診断し、エンジニアが検出結果を1件ずつ確認したうえで、修正と回帰テストまで行ってお渡しします。2026年10月のPHP2Shellでは、PHPに10年以上潜んでいた欠陥に対し、修正版の公開より前に攻撃の試行が確認されました。同種の古い欠陥は、PHPに限らず他の技術にも潜んでいる可能性があります。
お見積りは短い打ち合わせの後にご案内します。ソースコードをお送りいただく前にご相談いただけます。
6つの工程
- ✓ソースコードの読み込み
- ✓依存ライブラリの確認
- ✓設定と公開口の点検
- ✓エンジニアが全件を確認
- ✓修正と回帰テスト
- ✓深刻度順にレポート
検出結果 6
- 高app/Orders/Search.php:88
ユーザー入力がそのままSQLクエリに渡っている
対応 クエリをパラメータ化し、テストを追加
- 緊急composer.lock · image-lib
画像処理ライブラリに公開済みのリモートコード実行の脆弱性
対応 修正版へ更新し、テストを再実行
- 中Dockerfile · PHP 7.4
サポート終了のランタイム。公式パッチが出ない
対応 バージョンアップ計画を策定
- 高admin.example.com
管理画面がインターネットに直接公開され、オリジンIPも露出
対応 Cloudflare/WAFの背後へ移し、許可IPのみに限定
- 中.env.bak
APIキーがgit履歴に残っている
対応 キーを失効させ、新しいキーを発行
- 誤検知vendor/dev-tools
テスト専用ライブラリ内のeval()。本番には届かない
エンジニアが除外
このデータは診断の流れを示すためのもので、特定のお客様の結果ではありません。
Webサイト外部簡易チェック
攻撃を行わない受動的な方法のみで、御社のWebサイトを外部から確認し、攻撃者にも見えている情報をレポートにまとめます。
3営業日以内
ご契約の義務はありません。結果はそのままお使いいただけます。
お送りいただくもの
- チェック対象のドメイン
- 所有者確認のため、そのドメインのメールアドレスからのお申し込み
お届けするもの
- 1〜2ページのレポート
- 外部から見えるソフトウェアのバージョンと、公開済みCVEとの照合
- TLS設定とセキュリティヘッダー
- オリジンIPの露出有無、メールのSPF/DMARC設定
次のステップ（ご希望の場合）: 脆弱性診断＆修正（ソースコードと社内システム）へ。
最初の攻撃の試行は、 修正版の公開より4日早く起きました。
PHP2Shellは、PHPの中核に見つかった2つの重大な脆弱性（CVE-2026-109618とCVE-2026-109619、CVSS 4.0で9.2）の通称です。原因はメモリ安全性の問題です。リクエスト処理の途中でメモリ不足などの致命的エラーが起きると、作りかけのデータや解放済みのデータが再利用されることがあり、攻撃者はこれを悪用して、ログインなしでサーバー上のコードを実行できます。W3Techsによれば、サーバー側言語が判明しているサイトの69.2%がPHPで動いています。
- 2012
問題のコードはPHP 5.4の時点からすでに存在していました。
- 2024
監査結果への対応中に、PHPの開発者が最初の兆候を発見しました。現実的な攻撃手法を示せる人がおらず、互換性を壊さずに直すことも難しかったため、修正は数か月止まりました。
- 2026年8月11日
セキュリティ企業のCalifが、同じ原因によるリモートコード実行を報告しました。WizとOpenAIも別の攻撃経路を報告し、Wizは最先端のAIモデルを使ったと述べています。ここから修正版の公開まで71日。
- 10月17日
Amazonのハニーポットに攻撃の試行。公表の4日前で、修正版はまだ公開されていません。攻撃者が情報を得た経路は不明だとAmazonは述べています。
- 10月20日
15:00 UTC頃、CVE番号がネット上で出回り始めました（技術的な詳細は含まれず）。数時間後には、概念実証の動画が誤って公開されました。
- 10月21日 朝
公開予定の6時間以上前に、ある配布元が修正済みビルドを先に公開しました。これ以降は、誰でも比較して修正箇所を調べられる状態になりました。
- 10月21日
修正版が公開（8.2.35・8.3.36・8.4.27・8.5.12）。この日のうちに、Cloudflareのネットワークで数百万件の試行が観測されました。
- 10月21日
同じ日、Node.jsもリモートコード実行につながり得る脆弱性（CVE-2026-111497）を修正。AIを活用したチームが発見しました。
“AIを活用した分析によって、パッチの差分やセキュリティ勧告を実際に動く攻撃コードに変えるコストは下がっている。”Amazon Threat Intelligence（PHP2Shell後の傾向について）（英語原文より翻訳）
数値は、iPlusブログのPHP2Shell解説記事と、PHP Foundation・Amazon・Wizの一次情報に基づきます。
昔からあるバグでも、攻撃のコストは 大きく下がりました。
PHP2Shellは珍しい種類のバグではありません。変わったのは道具です。信頼できない入力に近い部品すべてに、同じ圧力がかかります。言語ランタイム、圧縮・画像ライブラリ、Webサーバー、ファームウェアなどです。
「悪用は難しい」とされた欠陥を、AIが悪用可能にした
2024年の時点では、攻撃手法を示せる人がおらず、この欠陥は仮説にとどまっていました。2026年、Wizは最先端のAIモデルを使ってWordPress、Drupal、Joomlaで動く攻撃コードを作り、かつて一流チームが数か月かけた作業を研究者1人が1週間で終えたと述べています。
技術情報が出てからの猶予はごくわずか
修正版の公開後、新たな概念実証コードは数時間で現れました。AmazonはAIによって修正差分やセキュリティ情報を攻撃コードに変えるコストが下がり、より多くの攻撃者が早く動けるようになると指摘しています。これは傾向についての見解であり、今回の攻撃者がAIを使ったと確認した情報はありません。それでも、7日や30日周期のパッチ適用は、もう存在しない猶予を前提にしています。
同じ日に、別の技術も名指しされた
Node.jsは10月21日にCVE-2026-111497を修正しました。PHPのセキュリティチームは7月1日以降に15件のCVEを公表し、100件を超える無効な報告を処理したと述べています。AIが報告数を押し上げているためです。「悪用は難しい」と見送られてきた古いバグが、再び俎上に載っています。
バグの発見と武器化が安くなり続ける世界に、恒久的な解決策はありません。あるのは、より速いサイクルだけです。自分が何を動かしているかを把握し、数時間でパッチを当て、侵入済みを前提にし、リアルタイムで監視し、攻撃者が使うのと同じ種類のAIを自社のコードに先に使うことです。
6つの工程。どの工程も、 手元に残る成果物で終わります。
速さと広さは機械が、判断が要る部分はエンジニアが担います。各工程は約束ではなく、具体的な成果物で締めくくります。
- 01
AIがソースコードと依存ライブラリを診断
AIがコードと依存ライブラリを読み、脆弱性を探します。エンジニアが検出結果を1件ずつ確認して誤検知を除き、御社システムへの実際の影響で深刻度を判定します。
お渡しするもの深刻度順に並べた検出レポート - 02
脆弱性を修正
確認できた脆弱性を、深刻なものから順に修正します。変更は小さく分けて、御社のチームが読んで承認できる形にします。
お渡しするものプルリクエスト形式の修正コード - 03
回帰テスト
重要な動作を再実行し、修正が他の箇所を壊していないか確かめます。テストが足りない箇所は、修正した範囲について追加します。
お渡しするもの回帰テストレポート - 04
バージョンアップと設定の堅牢化
ランタイムとライブラリをサポート中の版へ上げ、不要なポートや権限を閉じ、漏れたキーを失効させます。
お渡しするものアップグレード記録と設定変更の一覧 - 05
Cloudflare/WAFの背後にオリジンIPを隠す
WAFの背後に置くことで、直接攻撃を防ぎ、サーバーの本当のアドレスを隠します。リスクを下げる層であって、パッチの代わりにはなりません。
お渡しするものWAFとDNSの設定、引き継ぎドキュメント - 06
保守プラン
新しい脆弱性が公表されたら、お問い合わせをいただく前に、御社システムへの影響を確認して修正します。詳細は次のセクションで。
お渡しするものアラート、月次レポート、専用の連絡チャネル
まず一度で整えるか、 継続して安心を保つか。
多くのお客様は、現状を知るために単発プランから始めます。範囲とお見積りは、短い打ち合わせの後に決めます。
脆弱性診断＆修正
始まりと終わりがはっきりした単発のプランです。現状を知り、いちばん深刻な問題を片付けたいときに向いています。
お渡しするもの
- 深刻度順の検出レポート
- プルリクエスト形式の修正コード
- 回帰テストレポート
- バージョンアップと設定の記録
- オリジンIPを隠すWAF・DNS設定
完了時点ではシステムはクリーンな状態です。その後に公表される脆弱性には、保守プランか再診断が必要です。
こんなときに
- 自社システムが今どの状態にあるか分からない
- お使いの技術に新しい脆弱性が公表されたばかり
- 取引先やお客様に聞かれる前に、重い問題を片付けておきたい
保守プラン
機械が常時見張り、必要な場面で人が動きます。誰が何をするのか分かるよう、この2つをはっきり分けています。
機械・24時間365日
- WAFによる直接攻撃の遮断
- 異常を検知したときのアラート
- お使いのランタイムとライブラリに関する脆弱性情報の監視
人・お約束の範囲
- 重大インシデント：夜間・休日・祝日を含め、4時間以内にエンジニアが対応開始
- 通常のご依頼：契約で定めた営業日カレンダーに沿って、翌営業日に対応
- 専用チャネル：Slack、LINE、Zalo、電話
- 月次レポート：何を防ぎ、何を修正し、何が残っているか
PHPだけではありません。 誰も覚えていないシステムも。
日頃から扱っている技術と、作った人がいなくなったまま何年も動き続けているシステムが対象です。
誰も保守していない古いシステム
最もリスクが大きいのに、誰も触りたがらない場所です。まず全体像を描き直します。何が動いていて、どこに公開され、何に依存しているか。そのうえで修正し、まだ更新できない部分はWAFで外側から守ります。
私たちがやらないこと
- 第三者としてのペネトレーションテスト認証は発行しません。
- コンプライアンス監査（ISO 27001、PCI DSSなど）は行いません。
- デジタルフォレンジックや法的手続きの支援は行いません。
- 御社のSOC、EDR、端末のセキュリティの代わりにはなりません。
- 「攻撃を一切受けない」とは約束しません。それを約束できる人はいません。
認証が必要な場合は、第三者機関をご利用ください。指摘された内容の修正は、当社で対応します。
始める前に、 多くの方が最初に確認されること。
ソースコードを渡す必要はありますか。
修正でシステムが止まりますか。
明日、新しい脆弱性が公表されたらどうなりますか。
「重大インシデント」とは何ですか。4時間はどう数えますか。
御社の開発チームの代わりになるのですか。
コードの機密性はどう守られますか。NDAは結べますか。
Cloudflareの背後にIPを隠せば十分ですか。
ペネトレーションテストの認証やコンプライアンス監査は行いますか。
他の誰かに知られる前に、 自社の現在地を知る。
動かしているシステムを教えてください。短い打ち合わせの後に、最初の診断の範囲とお見積りをご案内します。