2026年10月の気になるインターネット記事をピックアップ
2026年10月の気になった記事を読んでみる
今だから白状しますと、去年「XXXX年XX月の気になるインターネット記事をピックアップ」という記事を複数回投稿した背景は、セキュリティで書くネタが不足していた苦肉策でした。しかし見てくださいよ、先月は毎週どころか２日連続の投稿。如何にセキュリティ界隈が大変なことになっているかが分かります。度々言っていますが、セキュリティ担当が慌ただしいということは、世が乱れていることを意味しています。乱世です。この乱世はいつまで続くのだろうかーと思っていたのですが、それについて回答している興味深いツイートを見つけたのでまずはそちらの共有から。
【PHP脆弱性対応の「後」にむけて】 みなさん、昨晩からのPHP対応お疲れ様です。一晩中連絡鳴り止んでおらず、一部の個別メッセージに返せてなくて申し訳ないです。 一括して、今、世の中の CTOs/CISOs に届いてほしいことを４つ書き残しておきます↓ （まとまりない部分もあるのですが、投稿しないよりマシかなと、このまま投げちゃいます） Point 1: これからは、ソフトウェア業界全体で、高負荷の続くタイミングになります。意図してセキュリティに時間をあて、チームが「休息」が取れる体制を。 ・我々は脆弱性リサーチに数年間継続的に取り組んできてました。だからこそ感じますが、ここ一年（体感では GPT-5.6 Sol 以後）が、最も「本当に？」みたいな脆弱性が掘り出されていく一年になると思います。こんなのまだあったの？という驚きとともに。 ・特に複雑なメモリバグの類（memory safe でない言語製のものを中心に）、あるいは認可バグの類が中心になると思われます。 ・少なくともここから年末までは、このクラスの脆弱性がまだまだ出てくると考えておく必要があります。（僕が読み外しているかもしれませんが、恐らく高い確度でこうなります。直近のPHP脆弱性すら、いま世界中の研究者が Variant Analysis をしていて、多分まだ出てくるでしょう） ・このご時世では、新規機能の開発に割く時間を明確に落とすしかありません。あくまで経営者である CTO には取りにくい判断なのは重々承知です（僕もそうなので）。 ・「対応AIで」と思うかも知れません。これは技術的には正しいです。ただ、組織的には正しくないです。確実になんとかならず、組織は疲弊していきます。 ・なんせセキュリティ対応は大抵自分にタイミングが御せないからです。深夜の対応、急な対応、計画の変更、デグレへの不安、脆弱性情報過多（そもそも自社に影響があるかも分からないものが大半なのに）… と、ストレスの強度がぐんぐん高まっていきます。昨日〜今朝のPHP対応のようなものが、毎週あれば、チームは比較的簡単に壊れてしまうでしょう。 ・敢えてリーダーが、セキュリティへの、時間・お金（・トークン）にアロケしてください。これは経営者にしか取れない択で、かついま技術経営者に求められることです。 Point 2: 「必要なら予防的にサービス停止」の覚悟を決め、予めできる調整を重ねたい。止められない場合は、仮想パッチ・監視へのリソースアロケを。 ・前提、今回のPHPの件のような脆弱性の対応では、「顧客の保護のためならサービスを止めざるを得ない場面」が訪れます。今回も様々なビジネスがそれに直面しました。今後も訪れるでしょう。 ・今回の経験を旨に、本当に止めてはならないのか、止めらるのか、止めうる期待値調整がお客様と出来ているか、を徹底的に見直しておきましょう。 ・直近の流れをうけての、お客様への事前連絡（スタンス表明）も有効だと思います。（弊社 GMO Flatt Security 製品についても、これからそれをし、リリースノートとして掲示予定です。我々のサービスの侵害、特に Takumi Guard の侵害は、ソフトウェサプライチェーンの最悪な侵害につながるからです。） ・勿論、止めてはならないビジネスも様々存在します。ビジネスドメインに由来する規制/制約（特に金融・医療セグメント）もあれば、顧客とのSLAもあるでしょう。ただし、現代においては、それらに反するリスクと、セキュリティ被害にあうリスクを天秤にかける必要がでてきています。少し前まではサービス停止でのデメリットは容易に考えられても、セキュリティ侵害など考えにくい、という時代でしたが、今はそうではありません。この天秤を再考する必要があります。（なお、「もう何がなんでも止めてはならない」ビジネスは、相当に限定的だと思います。） ・どうしても止めてはならない（もう何がなんでも止めてはならないもの。限定的であれ存在。人命に関わるもの中心）という場合、厳しい戦いになりますが、WAFレイヤなどで緩和策を施しては祈り、監視する、という流れになります。必要なコンポーネント（WAFなど）と運用リソースがあるならば、苦しい時代ですが、休息うまく取りながらやっていきましょう。なければ、これもしんどいですが、整えましょう。 Point 3: もし平時があれば、システムのモダナイズ（Rebuild and Retire）を検討されたい。 ・もし自社での緊急対応が落ち着いているならば、レガシーコンポーネント（数年塩漬けのシステム）、誰がメンテできるのか分からないオーパーツ的存在から順に、作り直し（Rebuild）と旧システムの廃止（Retire）を試みてください。新規開発の代わりに、ここにリソースを充てることが CTO/CISO の仕事です。（他の誰もそれを決められないので。）これは追々自分たちを助けてくれる（ついでにAI-native 開発に移行できて改善しやすくなる）とも思料。 ・どのシステムからモダナイズしていくかですが：「XXXで書かれているとまずい」というのは燃えるし言いにくいものの、memory unsafe な言語、type safety があまり確保されていない言語の実装は、モダナイズを検討すべきでしょう。（僕はPHP好きですが、C/C++ で書かれた php-src は、やはりメモリバグ類に対して見通しに限界がありますね。好きなんですが…） ・また経験上、開発当時に DevOps プラクティスすら整っていなかった時代のソフトウェアも、モダナイズを検討したほうがよいです。「セキュリティ診断」をしても、取り返しのつかない量の脆弱性が出てきて、作り直したほうが早い、となる傾向にあります。（弊社でも診断/ペネトレしてますが、こうなると、どうしようもありません。） ・ただし Rebuild には、強いソフトウェア開発力が必要で、AI-native なスタイルに移行することは必須です。この意味で CTO の力がいります。かつ、どこからレガシーの追い出しをするか、どうレキュリティ的なレジリエンスを確保するかは、CISO 的な感性が求められます。既製品（とくに SaaS）を買って処理したほうがいいな、というような判断には CIO 的センスが求められます。総力戦だと思ってください。 Point 4: CTO/CISO の総力戦を。 ・Point 3でも述べた通り、直近のくだりには、CTO/CISO の総力戦が必要です。ボードがセキュリティに向かって一致団結する必要があります。 ・結構これらロールの間にサイロがあるケースがありますが、そんなことを言っている場合ではありません。 ・団結を！
— YONEUCHI, Takashi | GMO Flatt Security (@lmt_swallow) October 22, 2026
今回のphp2shellにおいて価値ある情報発信をおこなってくれたGMO flatt Securityの取締役のツイート。長文ですが価値あるコメントが書かれています。 まずセキュリティエンジニアに対しては
・少なくともここから年末までは、このクラスの脆弱性がまだまだ出てくると考えておく必要があります。
・自社での緊急対応が落ち着いているならば、レガシーコンポーネント（数年塩漬けのシステム）、誰がメンテできるのか分からないオーパーツ的存在から順に、作り直し（Rebuild）と旧システムの廃止（Retire）を試みてください
SNSでは黙っていましたが、ここは僕の日記帳なので、自分の考えを書きます。 このブログに来る方は認識されていると思いますが、今回のPHP狂騒の原因は、脆弱性の対象となるPHPバージョンが膨大なこともあったのですが、それだけではありません。深刻さ大きく、影響範囲は広かったものの、普段通り公式からリリースされる予定通り公開されるパッチを当てれば良い話でした。しかしながら、公式で説明があったように、この脆弱性と攻撃手法が事前に漏れてしまいました。これによりパッチが出るまでの間、世界中のサーバが無防備な状態にさらされることとなりました。以下がタイムラインとなります。
- 8月中旬: セキュリティ企業のCalifなどがAIを用いて脆弱性を発見し報告。パッチ一斉適用のための情報公開禁止期間（エンバーゴ）が設定される。
- 10月17日: 公式発表の4日前に、Amazonの監視網等で攻撃者による悪用試行がすでに観測され始める。
- 10月20日: フリーランスの技術者が「エンバーゴの存在を知らされていなかった」としてHacker NewsでCVE番号を暴露。同時期にCalifが誤って攻撃手法の動画を公開してしまい、SNSで一気に拡散される。
- 10月21日朝: 動画を元にした攻撃手法が広まり攻撃が急増。さらに一部ベンダーが公式より6時間早く修正版コンテナを公開したため、差分から脆弱性の詳細が特定されやすくなる。
- 10月21日 23:00: 事態の悪化を受け、PHP公式が予定を前倒しして緊急パッチを公開。パッチ適用が間に合わない各国の政府機関や企業サイトが一時閉鎖に追い込まれる。
今回高市総理が緊急に投稿をおこない対応できない場合はサーバを止めろ、とアナウンスしたのは、状況が急変し、パッチの公開まで待ったなしの状態になってしまったためです。とはいえ、平時からPHPのバージョンアップを行っている組織・ゼロデイの脆弱性が出た場合の対応手順を決めている組織にとっては、今回の騒ぎは比較的冷静に対応できたのではないでしょうか。関係者に（総理大臣も言っているよ、と）連絡したうえで承諾を得てサーバをメンテナンス状態にして、パッチ公開後にアップデートするだけで対応できました。つまりこのブログのタイトルにあるように事なきを得る為の対応を普段から継続している組織こそがセキュリティを立派に行っている組織と言えます。備えあれば患いなし、です。
自分も他人のことを批判できません。今回自分も10/21の夜にいろんな会社が緊急メンテナンスを行っているのを見て、急ぎ社内であれこれ対応を行いました。古いPHPが危険であることは分かっていたのですが、「仕事が忙しいから」「このサーバは利益を上げていないから」など言い訳を付けてメンテナンスを行っていた結果が、今回のドタバタの原因。自業自得と言えます。 今回仮に自社で大きなセキュリティインシデントが起きなかったとしても、この対応自体が本来の業務にはない異常な対応、それも高負荷。くたくたです。それが今後も立て続けに起こると言われたら、現場は耐えられないでしょう。セキュリティ担当として、今回の原因と改善策を練り、経営層に提示することが必要と思いました。
また、上記のツイートはCTOs(最高技術責任者)/CISOs(最高情報セキュリティ責任者)に向けて書かれています。
・新規機能の開発に割く時間を明確に落とすしかありませんここに。ここにリソースを充てることが CTO/CISO の仕事です。（他の誰もそれを決められないので。）
・敢えてリーダーが、セキュリティへの、時間・お金（・トークン）にアロケしてください。これは経営者にしか取れない択で、かついま技術経営者に求められることです。
これまでセキュリティはかけたお金に見合った効果が見えにくいと軽視されがちでした。昔から海外の企業に比べて日本企業はセキュリティにお金をかけていないとされていました。
- セキュリティ予算を獲得する方法 経営層の納得を引き出す4つのポイント
- 【サイバーセキュリティ】「セキュリティ予算はいくらが正解？」がわかるようになる
- 日本のセキュリティ投資、アメリカの「9分の1」だって知ってましたか？
”セキュリティ企業のポジショントーク”といえば身も蓋もないのですがw
しかしGMOクラウドに対するサイバー攻撃ではユーザのアカウントで勝手に取引がされたりと、サイバー攻撃が企業の死活にかかわるレベルになってきてしまっています。
こんなニュースばかりだと、「もうWebサービスを提供したくない・・・」という暗澹たる気持ちになります。ただここでこそセキュリティ専門家の役割。”セキュリティ専門家の仕事の９割はお金を出すマネージャー層との交渉にある”なんて言葉があります。お金の交渉は苦手なうえ、好きではないやつなのですが、経営層と意識がかみ合っている今こそ、会社に必要なセキュリティ対策の進言を行うときではないでしょうか。
国内で相次ぐWebシステムからの情報漏えい～ラックの観測から見える変化と、企業が今とるべき対策
2026年7月から9月のサイバー攻撃における手口や傾向について分析した内容。図で分かりやすいです。先日JPCERT/CCが緊急声明で出した気を付ける点と被っています。「まず確認すること」の３点「社内情報資産の棚卸」「侵入されていないかをチェック」「いらなくなった過去データの削除」始めていますか？
ニュース、セキュリティ専門メディア、公式発表から収集した、日本の組織に影響する公表済みサイバーインシデントを一覧でまとめたサイト。今日でフィルタしただけでも10組織くらい不正アクセスを受け、情報を漏洩しているのですが…信じられない。RSSフィードもありますし、今後もチェックし続けたいサイトです。
「侵入経路塞いだが、バックドアから……」不正アクセス105時間の攻防、分単位で報告 防災メールのアルカディア
行政の防災メールシステムで利用されているシステムのため、警察や市役所などの業務に影響が出ています。情報漏洩の可能性もあるとされています。 本件の特徴として被害側のアルカディアが不正アクセスに対する詳細な報告書が公開されたことです。特に、時間単位でどのような攻撃をされたかが分単位で報告されていることは珍しく、攻撃側のスピード感、と同時に防御側が必死に対応したことが伝わります。
攻撃側はAIを活用して攻撃してきた可能性がありますが、その手法は徳丸本で紹介されているような典型的なWebアプリケーション攻撃手法のオンパレードです。後から言えば、徳丸本にもあるような基本的なセキュリティ対策をやっておけばよかった、と現場も悔やんでいるのではないでしょうか。
- ディレクトリトラバーサル対策でサニタイジング
- パストラバーサル対策にアクセスされたら困るファイルはドキュメントルート配下には配置しない
- シークレットはファイルに直接書かずにAWSでいうシークレットマネージャのように外から変数で取得する
- シークレットキーは有効期限を短くする
などなど。報告書にあるようにAIによるコードチェックや（それこそ攻撃側が使ったかもしれない）ペネトレーションテスト用AIを使うなど、これからはAIの力を借りて脆弱性をつぶしてからリリースする時代だと思います。つくづくBefore AIとAfter AIでソフトウェア開発の分野は一変した感があります。
この報告書から、自分も知らなかった知識をたくさん得ることができました。本事故の詳細な報告書を公開してくれたアルカディアさんには感謝しかありません。
- APIに直接アクセスされることなくフロントエンド側から確実に認証認可してAPIを呼び出すOAuth 2.0 や 相互TLS (mTLS)の実装や
- AWS WAFのbot ControlやIPレピュテーションルールの適用により、不審なアクセスの多発を検知してブロックすることの重要性
最後に紹介するのはご存じの人も多いであろうポッドキャスト「セキュリティのアレ」。セキュリティに関するポッドキャストにおいて質・量とも日本随一です。 僕も毎週楽しみにしていますが、今回は特に首を縦に振るシーンが多かったです。今毎日のようにセキュリティインシデントが起こっています。しかしこれをちゃかしたり、ランキング形式で面白がったりするものではありません（一般の人はともかく、「自分はセキュリティに詳しいんだ」と自負する人なら絶対にいけません）明日は我が身。みんなでセキュリティ意識を高め、この大嵐を乗り切らなければいけないのですから。