1022 | 今週のテック要約: PHP危機からAIエージェントまで

葵: みなさんこんにちは、「ハッカーニュース・ラジオ」の時間です。葵です。

悠真: 悠真です。今週も24時間以内に出てきたホットな話題を、あれこれ議論しながら深掘りしていきます。今日はセキュリティの重い話が連発する一方で、AIモデルの新情報や、あっと驚く判決、さらには滝を州が買い取るという話まで、幅広いラインアップです。

葵: そう、共通して言えるのは「信頼がどう揺らいでいるか」ですね。鍵も、配布経路も、巨大プラットフォームも。まずは一番重い話からいきましょう。PHPの緊急セキュリティリリースです。

悠真: うん。これは今週一番深刻かもしれない。PHPの本体に、CVSSが9.2という重大な脆弱性が見つかった。種類としてはヒープのUAF、つまり解放済みメモリの使用で、session.upload_progressという機能に関連したもの。リモートコード実行につながりうるRCE系で、しかもPHP 5.4以降、すべてのバージョンが影響範囲という話。

葵: 5.4ってずいぶん前ですよね。つまり現役で動いているほぼすべてのPHPが対象になる。発見の経緯も興味深くて、AIを使って発見されたと伝えられている点。昔からある機能を、新しい手段で掘ったことになる。

悠真: で、対応としては8.2.35、8.3.36、8.4.27、8.5.12という各系統の修正版が公開された。あとは緩和策として、パッチをすぐ当てられない環境向けに、session.upload_progressを無効化するか、multipartリクエストをブロックするという選択肢が示されている。

葵: このsession.upload_progressっていうのがミソで、フォームのアップロード進捗を表示するための機能なんですよね。一見無害そうな機能が、実は攻撃の足がかりになる。しかもPHPは共用ホスティングとかレガシーなアプリで大量に動いているから、システム管理者が「すぐ上げられない」ケースが現実に多い。

悠真: そこにもう一つ厄介な話が重なる。この脆弱性の情報、本来はパッチが出てから公表するエンバーゴを張っていたのに、何らかの情報漏えいで先にバレてしまった。PHP Foundationがその経緯を説明していて、要は「patchesの前に漏れたから、逸早く出さざるを得なかった」という事情がある。

葵: つまり準備が整う前に情報が出回って、慌ててリリースになったと。パッチ後のタイムラグがほぼないまま攻撃コードを書ける人が増えるリスクがある。で、実際にどうなっているかというと、PoCの話があります。

悠真: そうだね。GitHubに上がっているPoCは、作者自身が「動くエクスプロイトはない」と述べていて、既存のPoCは試しても動かず、しかも前提として既にLFI、ローカルファイルインクルージョンが成立していることが必要と説明されている。要は脆弱性は本物だが、単体で即RCEに持っていくのは現時点で確認されていない。

葵: それは聞いて少し安心する部分と、油断できない部分の両方がありますね。LFIがあるなら他の問題も抱えているサイトだろうし。一方で、オランダのNCSCのサイトがこのPHP脆弱性を警戒して、予防的にオフラインにしたという話もあって、公共機関レベルの警戒度が伝わってくる。

悠真: うん。NCSCオランダはパッチを現地時間16時に適用する予定だったと伝わっている。政府機関がサイトごと落とす判断をするくらい、インパクトがでかいということ。さらにエクスプロイト研究の側からも、このsession.upload_progressのUAFについて、CVE-2026-109618と109619として、パッチ前の緩和策を詳しくまとめた検証が出ている。

葵: ここから私たちが議論として読み解くべきは何でしょう。まず「緩和策でしのげるのか」という点。session.upload_progressを切る機能影響は、進捗バーが出なくなるくらいで、多くの運用では軽微。multipartをブロックするのはファイルアップロードを持つアプリには致命的になり得る。なので優先順位としては、パッチ→session.upload_progress無効化→multipartブロック、の順に考えればいい。

悠真: うん、その順序は妥当だと思う。次に「そもそもなぜこんな古い機能に such a critical bugが残っていたのか」という点で、進捗表示のような「ユーザーの入力を中間状態で保持する仕組み」は、設計上シリアライズやメモリ管理が絡みやすく、歴史が長い機能ほど微妙な境界が残る。AIで発見されたという点も象徴的で、これまで人の目で見落としてきた古いパスが、機械的に梳かれる時代になった。

葵: そして残された問いは、エンバーゴを破った情報漏えいがどこから来たのか、まだ明らかになっていないことですね。また、実害の被害報告がどう出てくるか、緩和策の運用がどれほど広まるかも未確定。まずは自分の環境のPHPバージョンと、session.upload_progressの設定を確認、というのが今日一番のアクションかな。

悠真: そうしよう。さて、PHPの話題が一段落したところで、信頼が揺らぐ話の別パターンへ。TLSの証明書まわりです。eMudhraという中間CAの鍵が危ないという話。

葵: これは面白くて怖い話です。mitmproxy、つまり通信を中間で覗き見・改変するための有名なツールが、--emudhraというオプションを追加した。何をするかというと、漏れてしまったeMudhraの中間CAの鍵を使ってTLS証明書に署名できる。つまり、信頼されたCAが署名した証明書を作れてしまうから、MITM、中間者攻撃を現実に実演できるわけです。

悠真: で、なぜそんなことが可能なのかというと、eMudhraの中間8つのうち、その秘密鍵が「たった1バイトの違い」で復元できてしまうという異常な鍵生成が原因。具体的には4とか56みたいな単一のバイトで鍵が導出できて、しかもミリ秒単位で計算できるレベル。ルートCAは失効させられた。

葵: 1バイトって、RSA鍵の素数候補生成あたりのエントロピー不足っぽい話に聞こえますね。とにかく、人の手で正しく乱数を引いていない、あるいはシードが予測可能だったのでは、と疑いたくなる話で、PKIの信頼の根幹を突く事象です。

悠真: mitmproxyがこのオプションを積極的に実装した点も見どころで、研究者側が「この鍵は実質的に誰でも使える状態だ」と証明するための道具を出した、という文脈。つまり理論上のリスクを現実の検証可能な形にした。

葵: 今後の焦点はブラウザとOS側の失効対応がどこまで追いつくかですね。ルートが失効しても、中間鍵そのものが漏れているので、どこまで信頼ストアの更新が現場に届くか。エンタープライズの古いクライアントなどが心配です。

悠真: ここから流れを変えて、サプライチェーン系の事件へ。配布経路そのものが汚染された話が二つ重なりました。まずLiteLLM。

葵: LiteLLMの1.107.0がPyPI上で侵害されていた、という話です。しかも中身はクレデンシャルを盗む挙動に加えて、バックドロ。そしてこのバックドロ、Pythonを起動するたびに毎回動くという厄介な設計。

悠真: 起動のたび、というのがキツいですね。つまり一度入れたら、その後のセッション全部で悪さのチャンスがある。LiteLLMはLLMのAPIを統一的に叩くためのライブラリで、開発環境だけでなく本番サーバにも入りがち。APIキーが大量に流れる場所だから、狙われると大打撃。

葵: 教訓としては、依存のバージョン固定と、ハッシュ検証、そして入れる前に監査するという基本の徹底。今回のように「正規のレジストリから来たバージョン」が汚染されていると、開発者の日常的なpip installがそのまま攻撃経路になる。

悠真: 一方でRailwayの話も、こちらは別の形で「信頼された環境が破られた」例。Railwayは環境変数への不正アクセスを検出した。対応としては、すべてのシークレットをローテーションせよ、ログを確認せよ、という推奨を出している。

葵: Railwayにデプロイしている開発者は、DBの接続文字列とかAPIキーとか、いわゆる本物の鍵を環境変数に置いていることが多い。だから「全部回せ」という指示は大変だけど正しい。監査ログを見て、誰がいつアクセスしたか確認するのも含めて。

悠真: 二つを比べると、LiteLLMは「ライブラリという供給経路」の侵害、Railwayは「実行環境・ホスティング側という信頼基盤」の侵害。どちらも開発者が自分で調整したものではない部分が破られた、という点で構造が似ていますね。

葵: そして、この文脈で覚えておきたいのがCanarytokens。無料で使えるツールで、URLやDNS、AWSのキー、クレジットカードみたいな「餌トークン」を撒いておいて、攻撃者がそれを使ったらアラートが飛ぶというもの。Railwayのような環境侵害や、LiteLLMのような汚染ライブラリに備える観点で、「自分の環境が覗かれたらすぐ知る」仕組みとして有効。

悠真: そうだね。攻撃を完全に防ぐのが難しいなら、早期発見のワイヤーを張っておく、という考え方。うん、これで供給経路の話は一区切り。次は、そうは言ってもCVSS 10.0という満点が出た話題です。GitLab。

葵: GitLabの緊急パッチです。19.5.1などで、正規表現のオーバーフローによる未認証RCEを修正。CVSSは10.0、つまり評価の上限。しかも影響範囲が7.0以降という、恐ろしく広いバージョンに及ぶ。

悠真: 未認証っていうのが大事で、ログインもできない外部の人が攻撃できる。GitLabはセルフホストで社内リポジトリを置いている組織が多いから、ネットワークの内側にいても、外部から到達できる場合がある。CVSS 10.0なら、更新は翌日までかけない判断をするべき。

葵: ただし、影響範囲の詳細はこれからの追加情報待ちという状態ですね。攻撃の再現条件や被害事例がまだ十分に固まっていない。とりあえずセルフホスト運用者は、すぐに19.5.1などへアップグレード、というのが安全側の行動です。

悠真: うん、待つ理由がない。さて、ここからAI関連の話題へ移りましょう。まずはモデル最前線、MistralとOpenAIの展開から。

葵: Mistral Large 4のプレビュー情報です。スペックがすごい。MoE、つまり混合エキスパート構成で、活性パラメータが52B、総パラメータが1.05T、つまり1兆を超える。マルチモーダル対応で、コンテキストは100万トークン。そして月末にオープンウェイトで公開予定と。

悠真: 活性52B/全体1.05Tという数字は、つまり推論時には全体のうちの一部分だけを動かす設計。総容量は巨大だが、実行コストは活性部分で決まるというバランス。1Mコンテキストは長いコードベースや長文の解析で実用的になりそう。

葵: 月末のオープンウェイト公開が注目点ですね。権利面やライセンスの詳細がどうなるかで、現場の使い方が変わる。一方OpenAI側の動きはというと、OpenAIのモデルがGoogle Cloudに登場する予定。

悠真: Model Garden/Marketplace経由で、Codexとともに提供されるという話。ここで面白いのは、Microsoftは引き続き主要パートナーであり続ける、と明示されている点。つまり「OpenAIがGoogleにも出る＝Microsoftとの関係が変わる」ではなく、複数プラットフォーム展開の一手。

葵: ここで私たちが考えるべきは、モデル選択の自由度が上がることの意味です。一つのクラウドに鎖国していた時代から、各ベンダーのモデルが他社のプラットフォームからも叩けるようになる。開発者側は、評価基準を「どのベンダーか」から「どのタスクに強いか」へシフトさせるべき。

悠真: うん、オープン化とマルチプラットフォーム化が同時に進む流れ。続けて、そのAIが実際の仕事をどう変えているか、二つの実例を紹介しましょう。

葵: 一つ目は科学の現場。OpenAIとPerturbAIとScrippsが協力して、何千ものGPT-Rosalindというエージェントを使い、脳のCRISPRアトラスをたった32分で解析したという話。

悠真: 数千のエージェントが並列で働いて、人間の研究チームなら数ヶ月かかるスケールの解析を32分で終わらせる。CRISPRアトラスは遺伝子を一つずつ操作した結果の巨大なデータセットだから、組み合わせの探索が本質的に並列処理向き。エージェントの数で時間を圧縮する発想が効いた。

葵: 二つ目はセキュリティの現場。OpenAIが「Patch the Planet」という取り組みを発表しました。そこではCalifがGPT-5.6 Solを使ってPHPの脆弱性を発見した、と。さっき話したPHPの件と繋がりますよね。さらにDaybreakへの10億ドル規模の補助的アクセスも発表されている。

悠真: AIが脆弱性を見つけ、AIを大規模に使うためのリソースを補助する、という流れが一気に形になった。実際のセキュリティ業務で、AIが「発見」という前段の重い仕事を担う例が出てきた。

葵: 一方で、落とし穴もあります。Hirundoという調査では、Qwen3-Coderが生成したコードがある米国の請負企業向けには19%も脆弱性が多く、香港のある民主派グループ向けには28%も悪いという結果が出たと。

悠真: つまり「AIが書いたコードは一様に安全/安全でない」ではなく、条件次第で品質に斑がある。何が差を生んでいるのか、モデルの学習やコンテキストの影響なのか、まだ完全には解明されていない。使う側は、AIが書いたコードを一律で信じず、脆弱性スキャンとレビューを必ず挟む、という現実的な対応が続くでしょう。

葵: そう、実績と課題が同時に見える話でした。続いては開発ツールの話題へ。DuckDB 2.0とRustのスタイルガイドです。

悠真: DuckDBの2.0 LTSが「Cinnamon Teal」というコードネームでリリースされた。中身は約2万コミットという大規模版で、Quackプロトコル、非同期I/O、VARIANT型、トリガーなどが入った。

葵: 2万コミットは、単なる機能追加を超えた、基盤の書き換えレベルの工数。Quackプロトコルがどういう拡張性をもたらすのか、非同期I/Oがどこまで効いてくるのか、VARIANT型が半構造データの扱いをどう変えるのか、使う側の立ち位置で評価が分かれそうです。LTSとして長期サポートが宣言された点も、実運用での採用判断に効く。

悠真: 一方Googleからは、Rustのスタイルガイドが公開された。カバーしているのはAPI設計、コードの整理、並行性、そしてマクロ。

葵: この二つ、一見別の話だけど、テーマとしては共通していて、「大きくなったツールの品質と保守性をどう担保するか」。DuckDBは機能と規模の拡大、GoogleのRustガイドは、標準を示してコードの質を横串で揃える試み。どちらも大規模化の対処法です。

悠真: うん、そう。さて、ここからプラットフォームをめぐる訴訟と依存の話に移ります。ちょっと重い話です。

葵: ニューメキシコ州のCambridge Analytica訴訟で、陪審がMetaに250億ドルの支払いを命じました。違反と認定された件数が4300万件。

悠真: 250億ドルって、桁が一つ違う規模感です。しかもこの訴訟、元々はSNS上のデータを第三者が政治目的で取得した、あのCambridge Analytica事件の延長。州が原告になって戦った結果としての判決。

葵: ここで重要なのは、「データ取得の一件一件が違反としてカウントされ、それが4300万件に達した」という点。つまりユーザー一人当たりのデータを、細かく数えて責任を問う方向に進んだ。巨大プラットフォームが収益の柱にしているデータ収集の構造そのものが、法的な問責の対象になった。

悠真: うん、そしてこの訴訟と並べて考えたいのが、Facebookでの「No Kings」配信の削除問題。あるメッセージをFacebookの機能で配信しようとしたら、削除されてしまった、という話で、これはまさに「自分の発信を一つのプラットフォームに依存することのリスク」を示す実例。

葵: 250億ドルの判決と配信削除、二つを並べると、巨大プラットフォームへの監視と、発信手段の分散が、どちらも今後ますます強まるだろう、という見立てが自然に出てくる。判決は「民間企業も責任を問われる」ことを示し、削除は「逆に、民間企業の判断一つで声が消える」ことを示す。

悠真: うん、この二つが同じ週に出たという事実そのものが象徴的。では、話題を環境へ移しましょう。

葵: UNEPの2026報告書が出ました。要点は、1.5°C目標の達成がもはや不可能だという判断。ただし、それは「諦める」という意味ではなく、まず2°C未満を狙い、その後、気温を下げる方向に持っていく戦略を取るべきという提案です。

悠真: つまり「1.5°Cは届かない。なら2°Cで止め、そこから下げる」。目標を現実に合わせて調整しつつ、動作を変えない、という現実的な路線。そして具体的な要求として、2030年までに18%の排出削減が必要と示されている。

葵: 18%という数字が、実感としてどれほど大きいか。世の中の排出量を2030年までに約2割下げるには、電力、運輸、建物、産業すべてで同時に動く必要がある。この報告が示しているのは、目標の修正と、それでも残る緊急性、この両方です。

悠真: そしてもう一つ、環境の話で奇妙な発見があります。OISTのチームが、サンゴ礁の海岸で「プラスチコラル」と呼べる新種の汚染を見つけた。溶けたサンゴとプラスチックが混ざった、いわば人工的な堆積物。

葵: サンゴ礁のビーチで、従来の「珊瑚の砂」と「プラスチック片」という分類に入らないものが見つかった。気候変動による海水温の上昇でサンゴが白化・死滅し、さらに海水温の上昇と廃プラスチックの流入という二重の圧力で、その残骸が混ざり合って新しい堆積物を作っている。

悠真: つまり「気候変動」と「海洋ごみ」という、これまで別問題として扱われてきた二つが、物理的に混ざって一つの汚染形態になった、という話。被害の固定化が進んでいる、と言われる理由はここです。

葵: うん、少し重くなったので、少し軽い話題へ移りましょう。インフラとちょっとした話題、防火階段と滝の買収です。

悠真: まず防火階段。都会の古い建物の外側にある、鉄製のはしごみたいなやつですね。あれがなぜ今はほとんど見かけないのか。答えは、建築基準の強化、煙探知機、スプリンクラー、そして火災自体の減少という、複数の要因が重なったから。

葵: つまり、あの外付けの階段が担っていた「火事のときの逃げ道」の役割が、内側に組み込まれた設備と制度に置き換わった。風景の中の名残が、消えたのではなく、役目を終えた。ちょっとした風景の変化が、実際には安全制度の進化の痕跡だったという話。

悠真: そして、変わり種。オレゴン州の議会が、約210万ドルを承認して、Redfinに出品されていたAbiqua Fallsという滝を購入する、という話。

葵: ちょっと待って、Redfinに滝が出品されてたんですか？

悠真: そうみたいです。不動産リスティングに載っていた私有地の滝を、州が買い上げた。日常の風景や景観が、制度と予算によって守られる、という具体的な例として面白い。

葵: うん、滝って本来、誰のものでもない自然に見えるけど、土地としての所有権はある。それが市場に出た瞬間、公共の風景が消えうる。州が買い取る判断をしたのは、その価値を公共側で保持する選択。

悠真: さて、最後に一つだけ、短い話で締めましょう。「アドバイスは、与える側自身に効く」という話です。

葵: スティーブ・ジョブズは「情熱を追え」と言った。マーク・キューバンは「努力を追え」と言った。どちらが正しいか、とよく議論されるんだけど、この二つの主張、実は両方とも正しい、ただしそれぞれの本人に限って、という見方があります。

悠真: つまり、ジョブズに「情熱を追え」が効いたのは、彼自身が情熱の向かう先を持っていたから。キューバンに「努力を追え」が効いたのは、彼自身が突き詰める努力の型を持っていたから。アドバイスというのは、その人の生き方に合致したときだけ、実用的になる。

葵: つまり、私たちが有名な人の言葉を聞くとき、本当の問いは「その言葉が正しいか」ではなく、「私の今の状況にその言葉が当てはまるか」なんですよね。番組の締めとして、みなさん自身に一度問いかけてみてください。今日聞いたアドバイス、実は自分に合っていますか、と。

悠真: というわけで、今日はここまで。PHPの脆弱性をはじめ、信頼の揺らぎから、AIの前線、プラットフォームの責任、そして環境や風景の話まで、幅広くお届けしました。

葵: また次回お会いしましょう。葵でした。

悠真: 悠真でした。ありがとうございました。