OSS

概要 複数人のチームでAIエージェントを共同利用できるオープンソースのセルフホスト型プラットフォーム「OneCLI」が公開された。これまでのAIコーディングエージェントの多くは個人利用を前提とした設計だったが、OneCLIはチーム単位での運用管理を重視しており、認証情報やアクセス制御を一元管理しながら、メンバーそれぞれに独立したAIアシスタントを配置できる点が特徴だ。メインシステムはApache License 2.0で公開されており、商用ライセンスの取得なしでセルフホストによる本番運用が可能。ただし一部のエンタープライズ機能については別ライセンス扱いとなっており、本番利用時には別途契約が必要になる。 主な機能 OneCLIでは、個別の会話画面・独立したサンドボックス環境・メモリ機能・スキル設定を備えた複数のエージェントを並行して運用できる。セキュリティ面では、外部サービス連携に使うAPIキーをAI本体に直接渡すのではなくOneCLI側で管理する設計になっており、認証情報の漏洩リスクを抑えている。BitwardenやIパスワード管理サービスの1Passwordとの統合にも対応する。 実行環境としては、隔離されたファイルシステムとシェルを備えたサンドボックスをユーザーごとに用意できるほか、Slackからの直接操作、スケジュール実行による定期タスクの自動化、重要な操作を実行する前に人間の承認を挟むフロー、SSH経由でのサンドボックスアクセス、Identity Providerとの連携といった、チームでの本格運用を意識した機能群を備える。 技術要件と評価 セットアップにはDocker・Node.js・Git Bashが必要で、Docker Composeを用いた構築が推奨されている。ローカルホストのポート10254でアクセスする構成だ。 公開後の議論の場となったHacker Newsでは、ネットワークレベルでの実行制御を評価する声がある一方、サンドボックスの隔離方式についてDocker-in-DockerやFirecrackerといった選択肢の重要性を指摘する意見も出ており、セキュリティ設計の詳細が今後の実運用における焦点になりそうだ。

概要 Unstablebuildは9月25日、Go言語で実装したネイティブアプリケーションのIDE「Rune」をオープンソースとして公開した。GPUアクセラレーションによる描画を採用した高速なユーザーインターフェイスが特徴で、ターミナルとコマンドプロンプトの操作を中心に据えた設計となっている。複数ターミナルを同時に扱えるマルチプレクサ機能も搭載し、コマンドライン中心の開発ワークフローを重視するユーザーに向けた選択肢として登場した。 技術的な詳細 Runeは Language Server Protocol に対応し、TypeScript、Go、Python、Rust、Zigをティア1言語として優先的にサポートする。AI統合機能も備えており、APIキーを設定することでOpenAI Codex、Anthropic Claude、Google Geminiといったコーディングエージェントを利用できるほか、ローカル実行のAIモデルにも対応する。 もう一つの柱がリモート開発機能の「SSH workspace」で、SSH経由で複数のマシンをまるでローカル環境であるかのように操作できる。鍵管理などの複雑な設定を必要とせず、通信はエンドツーエンドで自動的に暗号化され、NAT環境を越えた接続にも対応するという。 料金体系とオープンソース化の狙い 利用形態は無料枠と有料プランに分かれており、無料版ではリモート接続が最大2ノードまでに制限される。有料版は月額10ドルで最大10ノードまで利用可能になり、チーム向けの「Rune for teams」は個別見積もりとなる。オープンソース化にあたり、コントリビューターはRuneの売上の一部を受け取れる仕組みが導入される予定であることも明らかにされており、開発への外部参加を促す狙いがうかがえる。

概要 Kubernetesプロジェクトはコードネーム「Garhwal」を冠したバージョン1.37を正式リリースした。今回のリリースは安定性、セキュリティ、そしてAI/MLワークロードの最適化を重点テーマに据えており、合計67件のエンハンスメントが盛り込まれている。内訳はアルファ機能が27件、ベータへの昇格が23件、GA(一般提供)に到達したものが16件、非推奨・削除が1件となっており、クラスタ運用の基盤機能から先進的な機能まで幅広く手が入った形だ。次期バージョンの1.38は2026年12月にリリースされる予定である。 Metrics APIの安定化とAPIサーバーの堅牢化 今回のリリースで特に注目されるのが、metrics.k8s.ioとして提供されるMetrics APIが正式に安定版(Stable)へ到達したことだ。このAPIはノードやPodのヘルス監視の基盤であり、Horizontal Pod Autoscaler(HPA)やVertical Pod Autoscaler(VPA)、kubectl topコマンドなど、リソース監視・自動スケーリングに関わる主要機能が依存している。安定版化により、これらの機能を支えるインターフェースの互換性が長期的に保証されることになる。 あわせてGAに到達した「Resilient Watchcache Initialization」は、kube-apiserverの再起動時にetcdへリクエストが殺到して負荷が集中する問題を防ぐ機能で、再起動直後は限定的なリクエストのみを安全に処理し、それ以外はHTTP 429を返して制御する仕組みを備える。大規模クラスタにおけるコントロールプレーンの回復性を高める改善といえる。また、外部のmTLSブートストラップツールなしにPod間の安全な通信を実現する「Pod Certificates」もGAに到達し、サービスメッシュ導入のハードルを下げるものとして位置づけられている。 セキュリティとAI/MLワークロード向けの新機能 セキュリティ面では、Linuxのユーザー名前空間を活用してコアのノードコンポーネントを非rootで実行する「Rootless Kubelet」(フィーチャーゲートKubeletInUserNamespace)がベータに昇格した。コンテナエスケープが発生した際の影響範囲を縮小する狙いがあり、マルチテナント環境でのセキュリティ強化に直結する。 AI/MLワークロードの効率化という観点では、GPUに依存するワークロードのクラウドコストを削減する「HPA Scale to Zero」がベータへ進んだ。需要がない時間帯にPodのレプリカ数をゼロまで縮退させることで、高価なGPUリソースの遊休コストを抑制できる。このほかアルファ機能として、InPlacePodVerticalScalingSchedulerPreemptionによるワークロード認識型スケジューリング、デバッグやセキュリティ分析向けのPodチェックポイント・リストア機能、StatefulSetのローリング更新における「Recreate」戦略も導入されており、今後のベータ・GA昇格が注目される。 ストレージ管理の改善:未使用PVCの自動検出 ストレージ分野では、PersistentVolumeClaim(PVC)がどのPodからも参照されていない状態を自動検出するPersistentVolumeClaimUnusedSinceTime機能がベータに昇格し、デフォルトで有効化された。PVC保護コントローラーがPVCにUnusedという条件(Condition)を自動的に付与する仕組みで、そのPVCが現在いずれかの稼働中Podから参照されているかどうかを、手動でのトラッキングやカスタムツールを用意することなく可視化できる。 これまで大規模クラスタでは、孤立した(orphaned)ストレージリソースを特定するためにPodとPVCを手作業で突き合わせたり、独自のスクリプトを運用したりする必要があった。標準のCondition機構を通じてこの情報が提供されることで、未使用ストレージの削除によるコスト最適化や、利用状況に基づくキャパシティプランニング、さらにはこの条件を利用した自動削除ポリシーの構築が容易になる。運用コストの削減に直結する地味ながら実用的な改善であり、ストレージリソースが肥大化しがちな大規模環境ほど恩恵が大きいといえるだろう。

概要 プログラミング言語Zigの作者Andrew Kelley氏へのインタビューが9月23日に公開され、同氏がAIによるコード貢献を正式に禁止した経緯と、ZigプロジェクトをGitHubからCodebergへ移行した背景が明らかになった。Kelley氏はAI生成のコードを「負の価値を持つ」と断言し、レビュアーの貴重な時間を浪費するだけでなく、初心者がコードを書きながら成長していくというプロジェクトの教育的使命そのものに反すると説明している。 AIコード貢献を禁止した理由 Kelley氏によれば、AIを使った貢献者の多くはツールの使用を隠しながら、生成された出力をあたかも自分自身の成果であるかのように提出してくるという。プロジェクトのレビュー体制には限られたリソースしかなく、Kelley氏はそのリソースを、将来コアチームに加わりうるエンジニアの育成に振り向けたいと考えている。同氏は「AIを使っている人たちは、常に後者のカテゴリに入る。彼らは何も学んでいないし、後でコアチームに加わることもない」と述べ、AI利用がプロジェクトの教育的使命と根本的に相容れないとの立場を示した。この方針は、ZigからRustへの全面書き換えをAIエージェントを用いて行った最近のBunの事例とは対照的であり、Kelley氏はこれを「価値観の相違」を象徴する出来事だと評している。 GitHubからCodebergへの移行 技術面では、GitHub Actions上での継続的インテグレーションが繰り返し停止するなど、CI/CD基盤の不具合が開発の障害になっていたことが移行の直接的なきっかけとなった。加えてKelley氏は、非営利団体であるCodebergの組織構造がZigの価値観により合致すると判断した。同氏は「企業は常に次の収益源を追い求めているが、非営利団体はただ今やっていることを続けようとしているだけだ」と述べ、四半期ごとの収益成長を追い求める営利企業よりも、長期的な安定性を重視する非営利モデルを選好する理由を説明した。今回の移行は、技術的な信頼性の問題と、組織のあり方に関するイデオロギー的な一致という二つの側面を併せ持つ決断だったといえる。 背景と今後 ZigはGhostty(ターミナルエミュレータ)やTigerBeetle(金融向けデータベース)、UberのARM64クロスコンパイル基盤など、実運用のプロジェクトで採用が進んでいる言語である。Kelley氏は2018年に職を辞してZigの開発に専念しており、JavaScriptの低レベルアクセスの欠如、Goのストップ・ザ・ワールド型ガベージコレクション、Rust(1.0以前)の借用チェッカーによる制約、C++のメモリ破壊バグといった既存言語の限界を踏まえてZigを設計した経緯も語られている。AIコード貢献の禁止という方針は、こうしたZigの設計哲学や教育的な運営方針の延長線上にあるものであり、AIエージェントによる開発が急速に広がる中で、オープンソースプロジェクトの人材育成のあり方を問う事例として注目される。

概要 Googleは、自律型AIエージェントの実行とスケーリングを担うオーケストレーター「AX」をApache 2.0ライセンスでオープンソース公開した。AXはGoogleの「Agent Substrate」上で動作し、エージェントを従来のマイクロサービスのようにではなく、状態を保持し続ける「ステートフルアクター」として扱う点が最大の特徴だ。Kubernetesの設計思想を色濃く受け継いでおり、Task（実行ライフサイクル）、Workspace（環境構築）、Gateway（ネットワークセキュリティ）、Model（LLMパラメータ管理）という4つの宣言型プリミティブを、ax.io/v1alpha1というAPIグループの下でKubernetesのCRD（カスタムリソース定義）さながらに提供する。ユーザーはax applyのようなkubectlライクなコマンドでこれらのリソースを操作できる。 gVisorサンドボックスとサブ秒復帰によるコスト最適化 AXの技術的な核心は、gVisorによるサンドボックス分離と、サブ秒単位のタスク一時停止・再開機能にある。各エージェントセッションは隔離された「アクターサンドボックス」として実行され、CPUとメモリに厳密なリソース境界が設定されることで、障害や誤動作が及ぼす影響範囲（ブラスト半径）を抑え込む設計だ。さらに、エージェントがモデル推論の応答待ちやツール呼び出しの完了待ちといったアイドル状態に入ると、実行状態がチェックポイントとして保存され一時停止する。再開時にはコールドスタート遅延がほぼゼロのサブ秒間隔で復帰できるため、数十のタスクを少数の共有ホストワーカー上に多重化することが可能になる。従来型のKubernetes運用では、アイドル中も専用サンドボックスを起動したままにしておく必要がありコンピュートリソースが無駄になりがちだったが、AXのこの仕組みはモデルAPIや人間の判断待ちで長時間アイドル状態になりやすいエージェントワークロード特有の無駄を大きく削減できるとされる。 位置づけと運用面への懸念 AXは、LangGraphやCrewAIのようなアプリケーションレベルの高水準オーケストレーターとは異なり、より低レイヤーの「基盤実行ランタイム」として位置づけられている。想定利用者も個人開発者というよりは、大規模かつ長時間稼働するエージェント群を管理する必要があるエンタープライズだ。一方で技術コミュニティからは、Kubernetesクラスタやコンテナレジストリ、koによるCRD管理を前提とすることへの懸念も上がっている。Googleが掲げる「エルゴノミックなワークフロー」という謳い文句に対し、実際の導入・運用に伴う複雑性を疑問視する声だ。エグレスプロキシ接続のドロップや、シークレット管理機能がまだ初期段階にとどまっている点も課題として指摘されている。 今後の展望 こうした課題を抱えつつも、AXは自律型AIエージェントを本番環境で大規模運用するための「本質的なコンピュートプリミティブ」として位置づけられている。エージェントワークロードの実行基盤という新しい領域において、Kubernetesが果たしてきた役割をAIエージェント向けに再構築しようとする試みであり、今後エンタープライズでの採用が進むかどうかは、運用オーバーヘッドの解消とセキュリティ機能の成熟度にかかっていると言えそうだ。

概要 Oracleは9月16日、非LTS(Long-Term Support)版となる「Java 27」を正式リリースした。JDK 25以降では2回目の非LTSリリースにあたり、9件のJEP(JDK Enhancement Proposal)を収録している。目玉はガベージコレクタのG1 GCが全環境でデフォルトになったことと、TLS 1.3向けに耐量子暗号のハイブリッド鍵交換が追加されたことで、パフォーマンスとセキュリティの両面で将来を見据えた強化が図られている。なお非LTS版であるため、サポート期間は次期リリースであるJava 28が予定される2027年3月までの半年間に限られる。現行のLTS版はJava 25(2025年9月リリース)のままだ。 パフォーマンス関連の強化 JEP 523「G1 GCを全環境でデフォルトに」では、これまでCPUコア数が1以下、あるいはメモリが2GB以下といった小規模環境ではSerial GCがデフォルトとして使われていたが、G1 GC自体の改善によって制約の大きいハードウェアでも同等の性能を発揮できるようになったため、全環境でG1 GCがデフォルトに統一された。あわせてJEP 534「Compact Object Headers」もデフォルト化に向けて前進しており、64ビット環境におけるオブジェクトヘッダーを96ビットから64ビットへ削減することで、ヒープの利用効率とデータの局所性を改善する。現時点ではコマンドラインでの明示的な有効化が必要とされている。またJEP 536「JFR In-Process Data Redaction」により、Java Flight Recorderが収集するデータのプロセス内での秘匿処理にも対応した。 セキュリティ:耐量子暗号への対応 セキュリティ面での中心的な変更がJEP 527「Post-Quantum Hybrid Key Exchange for TLS 1.3」だ。これはIETFで策定中のハイブリッド鍵交換仕様を用いてRFC 8446(TLS 1.3)の実装を拡張するもので、既存コードを変更することなく耐量子暗号による鍵交換の恩恵を受けられる点が特徴となっている。Oracleは、標準化されたアルゴリズムを現行のLTS版にも展開し、「Javaエコシステム全体で耐量子暗号を広く利用可能にする」ことをロードマップとして掲げており、今回のJEP 527はその一環に位置づけられる。あわせてJEP 538「PEM Encodings of Cryptographic Objects」が3回目のプレビューを迎え、暗号鍵や証明書、証明書失効リストをPEM形式でエンコードするAPIの整備が進んでいる。 言語機能のプレビュー・インキュベータ 将来の言語進化に向けた実験的機能も複数プレビュー段階を重ねている。JEP 531「Lazy Constants」は3回目、JEP 532「Primitive Types in Patterns, instanceof, and switch」は5回目、JEP 533「Structured Concurrency」は7回目のプレビューとなり、JEP 537「Vector API」は12回目のインキュベータ段階に入った。これらの反復的な改善は、6か月ごとのリリースサイクルの中でイノベーションと企業利用における安定性のバランスを取るJavaの方針を反映したものだ。 エコシステムとの連携・今後の見通し Java Verified Portfolioにも新たな顔ぶれが加わった。OpenJDKのバージョニングにTip & Tailモデルで初めて足並みを揃えた「Helidon 27」、macOS向けにMetalレンダリングパイプラインやテキストコントロールの改善、アクセシビリティ強化を盛り込んだ「JavaFX 27」、そしてJDK 17・21・25・27への対応を拡張したFIPS 140-3準拠の暗号サービスプロバイダー「Oracle Jipher 20」が新たに加わっている。次期JDK 28(2027年3月予定)では6件のJEPが予定されており、Project Valhalla関連のJEP 539「Strict Field Initialization in the JVM」やJEP 401「Value Classes and Objects」のプレビュー入りが見込まれる。これによりVector APIもインキュベーションからプレビューへの昇格が視野に入るなど、Javaの長期的な言語進化が着実に進んでいることがうかがえる。

概要 WordPress Coreに、研究者Paulos Yibelo氏(pwn.ai)によって「Click2Shell」と名付けられたCSRF(クロスサイトリクエストフォージェリ)脆弱性が発見された。ログイン中の管理者に細工したリンクをクリックさせるだけで、WordPress.org上の任意のテーマを本人の意図なく強制インストールでき、さらにそのテーマ自体に別の脆弱性が存在する場合はサーバー上での任意のPHPコード実行(RCE)にまで発展しうる。単体でのCVSSスコアは7.1(高)だが、実際の攻撃チェーンとして評価すると9.6(緊急)に達する。脆弱性は8月22日にWordPressへ報告され、9月17日リリースのWordPress 7.1.1で修正済みだ。現時点でCVE番号は未採番だが、概念実証(PoC)コードと詳細な技術情報はすでに公開されており、悪用可能な状態にある。 脆弱性の仕組み Click2Shellの核心は、テーマのスラッグ(識別名)がサーバー側とブラウザ側で異なる方法で処理されるという「不一致」にある。管理画面がテーマプレビュー用のURLを読み込むと、WordPress.orgのAPIはテーマスラッグをサニタイズした上で実在するテーマ情報を返す一方、フロントエンドのJavaScriptは同じ文字列をサニタイズせずそのままjQueryセレクタに挿入してしまう。この処理の食い違いがセレクタインジェクションを引き起こし、攻撃者が用意したテーマの「インストール」ボタンを、閲覧中の管理者のセッション権限でJavaScript経由で自動的にクリックさせることが可能になる。インストールされたテーマは有効化されないため一見無害に見えるが、Patchstackなどの分析によれば、続けてWordPress Customizer経由でテーマを有効化し、そのテーマのAJAXハンドラの脆弱性を悪用して攻撃者のZIPファイル(プラグインを偽装)を実行させることで、最終的なコード実行に至る。研究者らは実際に「Mobile Repair Zone」という実在のテーマに存在した未認証コード実行の脆弱性と組み合わせ、このチェーン全体を実証している。攻撃の成立にはWordPressアカウントもインストール用nonceも不要で、管理者が悪意あるリンクを踏むか、あるいはサイト上にXSS脆弱性がありそれを閲覧するだけで条件が満たされる点が特徴だ。なお、テーマのインストール権限を持つのは管理者のみであるため、編集者や投稿者権限のアカウントではこの攻撃チェーンを引き起こせない。 影響範囲と対策 影響を受けるのはWordPress 6.0から7.1.1未満までの幅広いバージョンで、7.1.1では修正パッチがバージョン4.7系までさかのぼって提供されている。修正内容は、テーマ一覧の.theme要素にセレクタのスコープを限定し、$.escapeSelector()を適用してスラッグを常にリテラルなテキストとして扱うようにするというものだ。悪用に成功した場合、ファイルの改ざんやコンテンツの削除、ユーザーデータへのアクセス、wp-config.phpからのデータベース資格情報の窃取、不正な管理者アカウントの作成、悪意あるスクリプトの埋め込みなど、サイトを完全に掌握される深刻な被害につながりうる。現時点で野放しの悪用は確認されていないものの、PoCが公開済みであることから今後の攻撃増加が懸念される。Patchstackは、即時のアップデートが困難な場合の一時的な緩和策としてDISALLOW_FILE_MODS定数を有効化することを推奨しているが、根本的な対策としては全ユーザーが速やかにWordPress 7.1.1へアップデートすることが強く求められる。

概要 Node.js開発チームは9月16日、最新のCurrentリリースとなる「Node.js 26.9.0」を公開した。今回のリリースの目玉は、これまで--experimental-ffiフラグを指定しないと使えなかった外部関数インターフェース(FFI)モジュールがデフォルトで有効化されたことだ。JavaScriptからネイティブライブラリの関数を直接呼び出せるFFIが標準機能となったことで、C言語などで書かれた既存資産をNode.jsから利用するハードルが下がる。あわせてFFI周りでは、メモリヘルパー引数が欠けている場合に例外を投げる修正や、SharedArrayBufferをエラーメッセージに含める改善など、堅牢性を高める細かな修正も複数取り込まれている。 暗号・パフォーマンス計測まわりの強化 node:cryptoモジュールには、メッセージ認証コード(MAC)を統一的な方式で扱う「Generic MAC API」が新設されたほか、これまでハードコードされていた利用可能な暗号アルゴリズムやハッシュアルゴリズムの一覧を、OpenSSLプロバイダーから動的に検出する仕組みが導入された。あわせてFIPS関連では、--force-fipsに厳密モードを追加し、FIPS準拠状況を診断チャネル経由で通知する機能も加わっている。パフォーマンス計測領域では、ベンチマークを標準化して実行するための新モジュールnode:benchが実装された。ただし同モジュールは開発途中で挙動が調整され、最終的に--experimental-benchフラグの背後に置かれており、現時点では明示的な有効化が必要な実験的機能という位置づけになっている。またperf_hooksのヒストグラムには、平均値の信頼区間を計算するmeanCI APIや、計測データをプロセス間でやり取りするためのCBOR形式でのエクスポート・インポート機能が追加された。 DTLS・VFS・Web Workersなど実験的機能の拡充 ネットワーク領域では、UDP上でセキュアな通信を実現するDTLS(Datagram TLS)の実験的APIが実装された。TLSやQUICと証明書検証のロジックを共通化する取り組みも並行して進められており、IoT用途などUDPベースの暗号化通信を必要とする場面での活用が見込まれる。また、CommonJSおよびESMのモジュールローダーと統合される仮想ファイルシステム(VFS)機能も追加され、ZIPアーカイブをファイルシステムとしてマウントするZipProviderや、マウントされたファイルシステムからネイティブアドオンを読み込む機能が実装された。Single Executable Applications(SEA)機能でも、バンドルされたアセットをこのVFS経由でマウントするよう変更されている。さらに、ブラウザ互換のWeb Workers APIのサポートも今回のリリースで加わり、ワーカーのref/unref制御も可能になった。 そのほかの修正と非推奨化 バグ修正では、Buffer.prototype.indexOfにlone surrogateを検索語として渡した際のクラッシュ、Hmac.digest()が未初期化メモリを返す可能性があった問題、RSA-PSSの過大なsalt処理エラー、HTTP/2で大きなウィンドウサイズ時に発生していた書き込みデッドロックなど、セキュリティやデータ整合性に関わる複数の不具合が修正された。HTTP/2に関しては、RSTによる不完全な読み取りに対するエラー処理と自動ドレインが導入されるのに合わせて、abortedイベントが非推奨となっており、今後はエラーハンドリングベースの実装への移行が推奨される。今回のリリースは実験的機能が多く、FFIのようにデフォルト有効化されたものがある一方、node:benchのように依然としてフラグが必要なものも混在しているため、利用する際はドキュメントで各機能の安定度を確認しておくとよいだろう。

概要 Microsoftは9月16日、Visual Studio Codeの月例アップデート「1.138」をリリースした。今回の更新は全体としてAIエージェントを日常的な開発ワークフローに組み込むことを強く意識した内容になっており、隔離された開発環境でのエージェント実行、外部AIツールとのセッション連携、増え続けるセッション履歴の管理自動化など、エージェントを「使い続ける」ことを前提にした機能が中心となっている。単発の機能追加というより、これまで積み上げてきたエージェント関連機能を運用面から補強するアップデートといえる。 Dev Containers内でのエージェントセッション実行 目玉機能は、ローカルフォルダをDev Container環境内でエージェントに実行させられるようになった点だ。設定chat.agentHost.devContainer.enabledを有効にした上でワークスペースピッカーから「Use Dev Container」を選択すると、プロジェクトが定義する依存関係やツールチェーンに揃った隔離環境の中でエージェントが作業するようになる。ホストマシンを直接汚さずに済むため、依存関係の衝突やエージェントによる意図しない変更のリスクを抑えつつ、リポジトリごとに再現性のある実行環境を確保できる。なお本機能の利用にはDockerのインストールが前提となる。 Codexセッションの拡張とセッション管理の自動化 Codexセッションまわりの機能も拡充された。GitHub CopilotとChatGPTのいずれのサブスクリプションを使うか切り替えられるようになったほか、ChatGPTアプリとVS Codeの間でセッションを継続できるようになり、ChatGPTアプリ側のコンピュータ操作機能や、VS Codeに組み込まれたツール・拡張機能・MCPツールへのアクセスも統合された。複数のツールを横断してエージェントを使う開発者にとって、作業の起点をアプリ間で行き来しやすくなる変更だ。 あわせて、プレビュー機能として完了済みセッションの自動整理が導入された。マージ済みのプルリクエストに紐づくセッションをchat.agentSessions.autoMarkAsDoneMergedSessionsAfterDaysで指定した日数後に自動的に「Done」としてマークし、さらにchat.agentSessions.autoDeleteArchivedMergedSessionsAfterDaysで指定した期間が経過すると自動削除できるようになっている。エージェントを並行して多用するほどセッション一覧が肥大化しやすいため、この自動整理は運用上の負担を軽減する狙いがあるとみられる。あわせて、エージェントセッションから直接プルリクエストを作成できるようになり、タイトルや説明、ドラフト状態、マージオプションを1つのフォームでまとめて編集できるようになった。 その他の改善点 このほか、複数セッションの中で入力待ちや確認が必要なものをタスクバーのバッジで知らせる「セッション注意バッジ」がプレビューとして追加された。オートメーション機能はデフォルトで有効化され、チーム間での共有も可能になっている。音声モードには並列で動くエージェント作業間をナビゲーションする機能が加わったほか、ローカルフォルダ・リポジトリ・リモート環境を一つの検索可能なリストにまとめる実験的な統一ワークスペースピッカーも登場した。なお、従来のチャット背景設定chat.agentSessions.backgroundImageLayoutはテーマ別設定に置き換えられ、「Chat: Clear Background」コマンドは「Chat: Set Background…」内の「No Background」オプションに統合されるなど、細かな整理も行われている。今回の一連の変更から、VS Codeがエディタとしての機能拡張だけでなく、複数のAIエージェントを日常的に運用するためのハブとしての性格を強めていることがうかがえる。

概要 Rymera Web Co提供のWordPress向けプラグイン「WooCommerce Wholesale Lead Capture」に存在する未認証ファイルアップロードの脆弱性(CVE-2026-27540、Wordfence評価でCVSS 9.8、Patchstack評価では9.0)が悪用され、攻撃者がPHP製ウェブシェルを設置する攻撃が急拡大している。同プラグインは6,000件以上のサイトで稼働しており、セキュリティ企業Wordfenceは今年6月以降だけで10万件超の攻撃を検知したと報告した。攻撃のピークは6月4日から17日にかけて、また7月1日と8月30日にも急増が観測されている。パッチはすでに2月20日リリースのバージョン2.0.3.2で提供済みだが、約4か月が経過した現在も多数のサイトが未更新のまま被害に遭っている。 技術的な詳細 脆弱性の本質は、卸売登録フォームのファイルアップロードを処理するAJAXアクション「wwlc_file_upload_handler」にある。本来はサーバー側の設定で許可ファイル形式を管理すべきところ、ユーザーが送信するリクエストパラメータ「file_settings」からその許可リストを直接読み込んでしまう実装上の欠陥があり、攻撃者はこのパラメータを改ざんして「php」を許可拡張子リストに追加できてしまう。これにより未認証のままでも、細工したリクエストと「shell.php」といった名前の悪意あるPHPファイルを送信するだけでサーバー上にウェブシェルを設置できる。設置されたウェブシェルはホスト情報を攻撃者に送信し、さらなる悪意あるファイルを追加アップロードできるブラウザベースのフォームを提供する仕組みになっている。脆弱性を発見したのはセキュリティ研究者のTeemu Saarentaus氏で、影響を受けるのはバージョン2.0.3.1以下のすべてのリリースとなる。 攻撃の規模と対応 Wordfenceのファイアウォールはこれまでに10万件を超える悪用の試みをブロックしており、直近24時間だけでも99件の攻撃を記録した。攻撃元は複数のIPアドレスから確認されており、Wordfenceは代表的な発信元IPアドレスのリストを公開している。管理者への推奨対応としては、プラグインを直ちにバージョン2.0.3.2以降へ更新するとともに、アップロードディレクトリ内の予期しないPHPファイルの有無を確認し、「/wp-admin/admin-ajax.php」に対する「wwlc_file_upload_handler」アクションを含む不審なリクエストがないかサーバーログを精査することが挙げられる。侵害が確認された場合は、不正な管理者アカウントやバックドアの削除、あるいはクリーンなバックアップからの復元が必要になる。 背景と展望 WordPressのプラグインエコシステムを狙った同種の攻撃は今回に限らない。The Hacker Newsは、60万サイト以上で利用される「The Events Calendar」プラグインでも同様に深刻な脆弱性(CVE-2026-78159、CVE-2026-78006)が発見され、開発元StellarWPがバージョン6.17.3.1および6.17.4.1で修正した事例を伝えている。パッチ公開から数か月が経過してもなお大規模な悪用が続く今回のケースは、サードパーティ製プラグインの更新遅延がWordPressサイト運営における恒常的なリスクであることを改めて示しており、管理者にはプラグインの棚卸しと迅速なパッチ適用の徹底が求められる。