Using AWS WAF to apply mitigations for PHP2Shell RCE vulnerabilities (CVE-2026-109618 and CVE-2026-109619) aws.amazon.com/blogs/securit…

【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 の総力戦が必要です。ボードがセキュリティに向かって一致団結する必要があります。 ・結構これらロールの間にサイロがあるケースがありますが、そんなことを言っている場合ではありません。 ・団結を！

皆様に、今夜に対応して頂きたい大至急のお願いです。   多くのウェブサイトで使用されているPHPに関し、PHPのセキュリティチームが、重大な２件の脆弱性に関する注意喚起を行っています。   公開しているウェブサイトでPHPを使用しているか確認し、今夜、10月21日午後11時（日本時間）に公開される修正パッチについて、可及的速やかに適用できるよう準備をお願いします。   修正パッチを速やかに適用することが困難な場合は、例えばウェブサイト等を一時的に停止させることも、リスクを低減させるための有効策の一つと考えられます。   国家サイバー統括室のXアカウントでも関係する情報を発信していますので、そちらも参考にして下さい。 国家サイバー統括室(注意・警戒情報)（@cyber_forecast） / X

メドレーの医療システムに不正アクセス　最大787機関で情報漏洩か nikkei.com/article/DGXZQOUC1…

To mark the 10th anniversary of the Google SRE book, we are excited to announce a completely rewritten second edition that reflects a decade of lessons and offers fresh guidance for today's operational challenges. Check it out → goo.gle/4zv9do9

AWS Lambda が「Lambda ウェブ関数」を発表しました AWS Lambdaは、新たなサーバーレスコンピュートプリミティブである「Lambda Web Functions」を発表しました。この新しい機能では、コードが直接HTTPリクエストを処理します。コードはポートでリッスンし、あらゆるHTTPサーバーと同じようにリクエストを処理します。ExpressやHonoなどの既存のフレームワークを、アダプターやカスタム設定なしで利用できます。これにより、AI推論エンドポイント、サーバーサイドレンダリング（SSR）ウェブアプリ、ストリーミングAPIエンドポイント、マイクロサービス、ウェブフックなどのワークロードを提供できます。アクティブなCPU時間と環境が保持しているメモリに対してのみ料金が発生し、コードがデータベースやダウンストリームサービスを待っている間無駄に経過したアイドルCPU時間に対しては料金が発生しません。この発表に伴い、既存のLambda関数を「Lambda Event Functions」に改名しました。これは名前のみの変更であり、既存の関数に対してコード変更や再デプロイは必要ありません。 開発者は、イベント駆動のパイプライン、リクエストとレスポンスのAPI、データ処理にわたって、サーバーを管理することなくコードを迅速に本番環境にデプロイするためにLambdaを使用しています。AI主導の開発が加速する中、開発者はローカルで構築し、よく知っているプログラミングモデルでデプロイし、アクティブなCPU使用量に基づいてワークロードに対して料金を支払い、低遅延でユーザーにサービスを提供したいと考えています。Lambda Web Functionsがこれを実現します。現在、Lambda Web FunctionsはNode.jsランタイムをサポートしています。1つのウォームな実行環境が複数の同時リクエストを処理できるため、コールドスタートが大幅に減少します。ネイティブなHTTPストリーミングにより、クライアントに結果をインクリメンタルにストリームできます。 Lambda Web Functionsは、AWS Lambda API、Agent Toolkit for AWS、AWSマネージメントコンソール、AWS CLI、AWS CloudFormation、AWS SAM、AWS CDK、またはAWS SDKを使用して作成および構成できます。マルチリージョンルーティングにより、一度デプロイして、各リクエストをエンドユーザーに最も近いリージョンから提供できます。Web FunctionsはAmazon VPC（仮想プライベートクラウド）の接続をサポートし、関数でVPC内に存在するリソースにアクセスできます。 Lambda Web Functionsは、現在以下のAWSリージョンで利用可能です：US East（バージニア北部）、US East（オハイオ）、US West（オレゴン）、アジア太平洋（東京）、ヨーロッパ（アイルランド）。現在のリストについては、AWSリージョン別の機能ページをご覧ください。詳細については、Lambda Web Functions開発ガイドを参照してください。価格の詳細については、AWS Lambda価格をご覧ください。Lambda Web Functionsの実際の動作については、AWSニュースブログの発表をご覧ください。

Amazon CloudFront は、AWS Lambda Web Functions をオリジンとしてサポートするようになりました。 本日より、AWS Lambda Web Functionsで構築されたウェブアプリケーションをCloudFrontのグローバルエッジネットワークを通じて配信できます。 Lambda Web Functionsの前にCloudFrontを配置することで、エッジでTLS終結が実現され、レイテンシの低減とより高速な接続、パフォーマンス向上のためのキャッシュ機能、カスタムドメインと管理されたTLS証明書が提供されます。アプリケーションコードの変更は必要ありません。CloudFrontオリジンアクセスコントロール（OAC）により、Lambda Web FunctionsがCloudFront経由でのみアクセス可能となり、セキュリティ保護を回避した意図しないリクエストがオリジンに届くことを防ぎます。OACが適用されている場合、CloudFrontのエッジネットワークがネットワークレイヤーのDDoS攻撃からLambda Web Functionsを保護し、AWS WAFをアタッチしてアプリケーションレイヤーのセキュリティをさらに強化できます。自分自身でユーザーを認証するアプリケーションの場合、OACにより元の認証情報が変更されずにアプリケーションに届くため、既存のサインインフローがそのまま機能します。 AWS Lambda Web Functionsに対するCloudFrontのサポートは、中国のCloudFrontリージョン以外の世界中で利用可能です。始めるには、CloudFrontコンソール、SDK、CLI、またはCloudFormationを使用してLambda Web FunctionsをCloudFrontオリジンとして設定してください。詳細については、CloudFront開発者ガイドを参照してください。この機能には追加料金はかかりません。

NewsPicksユーザーの個人情報漏えいか　勤務先やカード番号下4桁も……管理ツールに不正アクセス itmedia.co.jp/news/article/2…

IDCFかから白旗いただきました。

‼️🇯🇵Japan - 𝗜𝗗𝗖 𝗙𝗿𝗼𝗻𝘁𝗶𝗲𝗿 Hackers claim responsibility for the cyberattack against IDC Frontier’s IDCF Cloud East Japan Region 1, alleging that it severely damaged the region’s virtualization and storage infrastructure. Full details and impact assessment on HackRisk.io

I sympathize with programmers who worked on systems they never cared about, for customers they didn't connect with, and took all their working joy from the mechanical act of turning tickets into code. You have to care about the software to be excited about making it w/ agents!

SRE as a job title shouldn't exist. Reliability is either everyone's job or it's nobody's. The moment you hire a team specifically for reliability, every other team quietly stops thinking about it.

Cloudflare wants to become the internet’s everything company. Now it wants developers to build the next Git platform on Cloudflare. Cloudflare thinks GitHub was built for a world where humans write, review and merge code. That starts to look very different when hundreds or thousands of AI agents are coding at the same time. So Cloudflare built Artifacts, a Git-compatible system designed to create, fork and manage repositories at massive scale. Now it’s giving developers that infrastructure and asking them to rethink what Git hosting should look like for AI agents. They're even running a competition to see who can build the next Git platform on top of it. Announcement here blog.cloudflare.com/next-git…