OSS

概要 AIコーディングエージェントなどの隔離実行環境として使われるDocker SandboxesのmacOS版に、サンドボックス境界を突破してホストファイルシステムへ不正アクセスできる重大な脆弱性が発見された。中心となるCVE-2026-77179はCVSSスコア9.4(Critical)と評価され、悪意あるゲストコードがサンドボックス外の任意のホストファイルを読み書きできる恐れがある。影響を受けるのはバージョン0.28.0から0.41.9で、9月7日リリースのv0.42.0で修正済みとなっている。 技術的詳細 CVE-2026-77179は、ゲストとホスト間のファイル共有を担うvirtio-fsホストサーバーの実装欠陥に起因する。削除されたファイルを再度開く際にシンボリックリンクを追跡してしまう挙動があり、攻撃者はサンドボックス内のプロジェクトディレクトリの親ディレクトリをシンボリックリンクに置き換えることで、本来アクセスできないプロジェクト外のホストファイルへ到達できてしまう。あわせて、CVSSスコア8.7(High)のCVE-2026-79994も公表されており、こちらはバージョン0.37.0から0.41.9に影響する。Unixドメインソケットのリレー機構におけるパス検証と実際の接続確立との間にタイミングウィンドウが存在し、この隙を突いたシンボリックリンク置換攻撃によって認可されていないソケットへのアクセスが可能になるというものだ。いずれも、正規のシンボリックリンク解決処理を悪用してサンドボックスの境界チェックを回避する点で共通している。 発見と対応、今後の影響 CVE-2026-77179はaccomplish.aiのOren Yomtov氏、CVE-2026-79994はThreatNotifyのJurre van Bergen氏がそれぞれ発見・報告した。Dockerは修正版v0.42.0のリリース(9月7日)から8日後の9月15日に脆弱性情報を公開している。報告を受けてから修正・公表までの具体的な猶予期間は記事内では明示されていない。現時点で実際の悪用報告は確認されていない。 Docker Sandboxesは、AIコーディングエージェントに安全な実行環境を提供する目的で設計された機能であり、今回の脆弱性はその前提そのものを揺るがすものだ。特に、マルウェアやプロンプトインジェクション攻撃によってエージェントが意図せず悪意あるコードを実行してしまうシナリオでは、サンドボックスの隔離が破られホスト環境が侵害されるリスクが現実的な脅威として浮上する。AIエージェントの実行基盤として同様のサンドボックス技術を採用している開発者は、速やかにv0.42.0以降へのアップデートを検討すべきだろう。

概要 Linux Foundation傘下のAgentic AI Foundation(AAIF)は9月9日、オープンソースのAIゲートウェイ「Agent Router」を独立プロジェクトとして迎え入れると発表した。BloombergとTetrateが共同開発してきた本プロジェクトは、これまでCNCFのEnvoyプロキシのサブプロジェクト「Envoy AI Gateway」として提供されてきたが、今回の移行に合わせてAgent Routerへとリブランドされた。発表時点でBloomberg、Tetrate、Tencent Cloud、Nutanix、LINEヤフー、National Research Platformなど11組織が採用を表明しており、開発には21組織が貢献。メンテナー9席はBloomberg、Nutanix、AMD、Tetrate、Netflixの5社が分担している。 Agent Routerが解決する課題と仕組み 開発の発端は2024年、Bloombergのエンジニアが直面した課題にある。OpenAI、Anthropic、Googleなど各モデル提供元はリクエスト形式や認証方式がそれぞれ異なり、AIエージェントを複数のモデルに接続する際の実装負荷が大きかった。Agent RouterはOpenAI互換APIのリクエストを各提供元に合う形式へ自動変換し、APIキーなどの認証情報も一元管理することで、エージェント側はモデル名を変更するだけで接続先を切り替えられるようにする。フェイルオーバー機能も備える。 外部ツール接続についてはModel Context Protocol(MCP)に対応し、複数のMCPサーバーから選んだツールを統一カタログにまとめて提供する。呼び出し元ごとに利用可能なツールを制限でき、アクセス制御はツール一覧取得時と実際の呼び出し時の両段階で実施される。さらにリクエスト件数だけでなく、モデルが処理するトークン数による使用量制限も可能で、呼び出し状況はログとトレースに記録される。基盤にはLyftが開発しCNCF傘下で維持されているプロキシソフトウェア「Envoy」を用い、管理者が指定した接続先や認証情報をEnvoy向け設定に変換して通信を処理させる仕組みだ。 リリース実績とAAIF移行の意義 プロジェクトはこれまでに安定版を15回リリースしており、2026年6月にバージョン1.0を、8月にはバージョン1.1を公開した。1.x系では互換性維持の方針を掲げている。AAIFは2025年12月に設立されたLinux Foundation傘下の団体で、AIエージェント向けのオープンな技術・標準の共同開発を支援する。EnvoyのサブプロジェクトからAAIFの独立プロジェクトへ移行することで、他のエージェント関連コミュニティとの結びつきが深まり、共同開発の機会が広がるとされている。 MCPを取り巻く動向と今後の展望 同発表と合わせて行われたAnthropicのDavid Soria Parra氏の講演によれば、Claude上でのMCPツール呼び出しは10億回を超え、Tier 1 SDKの月間ダウンロード数は約5億回に達している。2026年7月28日版の仕様では、プロトコルの中核をステートレス方式に変更し、リクエストを複数サーバーへ振り分ける大規模運用やキャッシング機構をサポートするようになった。今後の重点領域としては、数分から数週間に及ぶ長期タスクに対応する「MCP Tasks」の強化、企業内MCPサーバーでスキルを一元管理する「Skills over MCP」、エージェントの識別と権限確認を強化する認可・アイデンティティ機能、ツール呼び出し結果形式の整理などが挙げられている。利用範囲は2025年のコーディングエージェント実用化を起点に、2026年は知識労働・科学研究、2027年はOperations領域へと段階的に広がると予測されており、Agent Routerのようなゲートウェイ層の整備はこうしたエージェント活用の拡大を支える基盤技術として位置づけられる。

概要 Ottawaを拠点とするShopifyが、ユーティリティ・ファーストのCSSフレームワーク「Tailwind CSS」を開発するTailwind Labsを買収した。買収金額など金銭条件は非公表。Tailwind CSSおよび関連するオープンソースプロジェクト群は引き続きMITライセンスで提供され、既存の開発チームがShopifyの支援を受けながら開発とメンテナンスを継続する。Tailwind CSSは2025年のCSS調査で回答者の51%が使用すると回答した、最も普及したCSSフレームワークであり、創業者のAdam Wathanによれば週に1億1000万回以上インストールされ、ChatGPTやX、Cloudflareといった大手企業でも採用されている。 経営難の背景にあるAIの影響 今回の買収の背景には、Tailwind Labsが直面していた深刻な経営課題がある。同社の収益は2026年1月時点で前年比およそ80%減少し、主要な顧客獲得チャネルであったドキュメントサイトへのアクセス数も2023年比で40%落ち込んだ。この結果、エンジニアリングチームの75%にあたる3名をレイオフする事態に追い込まれていた。背景にあるのはAI技術の急速な普及だ。開発者がコード生成AIやAIアシスタントを介してTailwind CSSの使い方を学ぶようになったことで、公式ドキュメントサイトを直接訪れる必要性が薄れ、同社が収益源としていたドキュメントサイト経由の顧客獲得が構造的に細っていった。広く使われる人気オープンソースプロジェクトであっても、AIによる情報アクセスの変化がマネタイズの前提を崩しうることを示す事例といえる。 オープンソースとしての継続、今後の展望 Shopifyによる買収後も、Tailwind CSS本体とその周辺プロジェクトはMITライセンスの下でオープンソースとして提供され続ける方針が明言されている。Tailwind Labsとしては、Shopifyという事業基盤の下で「安定した長期的な拠点と拡大する成長機会」を得た形だ。ECプラットフォームを主力とするShopifyにとっても、フロントエンド開発で広く使われるツールチェーンを自社傘下に取り込むことで、開発者エコシステムへの関与を強める狙いがあるとみられる。AIによるトラフィック構造の変化で収益源を失ったOSSプロジェクトが、事業会社による買収という形で存続の道を見出した今回のケースは、他の主要オープンソースプロジェクトの持続可能性を考えるうえでも注目される。

概要 macOS/Linux向けパッケージマネージャHomebrewは9月13日、メジャーバージョン7.0.0を正式リリースした。目玉は公式グラフィカルインターフェース「BrewUI」と、OSV.devデータベースと連携する新しい脆弱性スキャンコマンド「brew vulns」の追加だ。あわせてLinux版のサンドボックス機構を刷新し、インストール処理の並行化による高速化も図られている。一方でIntel Mac向けのサポートは正式サポートから「Tier 3」へと格下げされ、2027年9月1日に打ち切られる予定であることも明らかになった。Homebrewは49,000以上のGitHubスターを持つ広く使われるパッケージマネージャであり、その知名度の高さから情報窃取マルウェアの配布やClickFixフィッシング詐欺の標的にもなりやすく、今回のセキュリティ機能強化は利用者保護の観点でも注目される。 新機能とパフォーマンス改善 BrewUIはmacOS Tahoe 26以降で利用可能な公式ネイティブGUIで、パッケージの閲覧・検索や依存関係の確認・管理をグラフィカルに行えるようにする。brew vulnsコマンドは、インストール済みパッケージやBrewfileで指定したパッケージをOSV.devの公開インデックスに照合し、重大度や修正可能性でフィルタリングできる。Homebrewが実際に出荷したフォーミュラのバージョンと改版に対して脆弱性情報を記録する方式のため、上流のバージョン番号が変わらないままパッチが適用された場合でも誤検知を抑えられる点が特徴だ。パフォーマンス面では、複数パッケージの準備とダウンロード処理を並行化し、brew configの情報収集も並行実行することでインストール全体の高速化を実現した。 セキュリティ修正とサンドボックス強化 7.0.0では8件のセキュリティアドバイザリーが修正された。最も深刻なのは「署名されていないcaskの削除メタデータを経由してsudo権限で任意のコマンドが実行できる」重大(High)な脆弱性で、これは既にバージョン6.0.12で解消済みだった。このほか、macOSインストーラーがroot権限で実行可能なGit設定を許してしまう問題や、悪質なcaskがmacOSのサンドボックス外でコードを実行できる問題(Moderate)も修正され、後者に対しては7.0.0でアプリケーション起動・Machサービス・Unixソケット接続を制限する対策が導入された。Linux環境では、従来のBubblewrapサンドボックスをLandlockに置き換え、Dockerの昇格権限や追加の依存関係を必要とせずにセキュリティを強化した。Landlock未対応のカーネルでも動作するよう配慮されている。さらにホームディレクトリへのアクセスをデフォルトでブロックし、ネットワーク接続を伴うダウンロード処理をオフラインインストールの処理から分離するなど、多層的な防御策が盛り込まれた。 Intel Macサポートの縮小と今後の展望 HomebrewはmacOS Intel(x86_64)サポートをTier 3へ移行し、2027年9月1日に完全に終了すると発表した。背景には、AppleとGitHubがIntel環境向けのサポートを縮小しており、ボランティア主導のプロジェクトとして代替のビルド環境を維持し続けることが困難であるという事情がある。既存のIntel Mac上でHomebrew自体は動作を継続できるが、新規のビルド済みボトル提供は行われなくなる見込みで、該当ユーザーにはMacPortsへの移行が推奨されている。一方で、新型のmacOS「Golden Gate 27」向けApple SiliconはTier 1サポートとして新たに加わった。このほかbrew install --dry-runの追加、非互換なcaskをスキップしつつ互換性のあるアプリのみをアップグレードする機能、GitHub ActionsのCalVerリリースピン留めやUbuntu 22.04イメージの廃止といったCI周りの刷新も行われている。Homebrewは非営利のボランティアプロジェクトであり、開発資金確保のためGitHub Sponsorsへの寄付も呼びかけている。

概要 JetBrainsは9月7日、Kotlinの最新マイナーバージョンとなる「Kotlin 2.4.20」を正式リリースした。今回のアップデートは特定の目玉機能に絞ったものではなく、標準ライブラリからKotlin/Native、Kotlin/Wasm、Kotlin/JS、そしてビルドツール周りまで、マルチプラットフォーム開発の各領域にまたがる改善を幅広く取り込んだ点が特徴だ。最新のIntelliJ IDEAやAndroid StudioにはすでにKotlin 2.4.20のサポートが組み込まれており、コマンドラインコンパイラも単体でGitHubのリリースページから入手できる。 標準ライブラリとデバッグ体験の改善 今回のリリースで開発者の日常的な生産性に直結するのが、コルーチンのスタックトレース復元機能への対応だ。非同期処理特有の「どこで例外が発生したのか追いづらい」という課題に対応するもので、コルーチン利用時のデバッグ効率を高める狙いがある。あわせて、コレクション要素の等価性や一意性をチェックする新しい関数が標準ライブラリに追加されたほか、kotlin.testのアサーション関数にも新しいオーバーロードが加わり、テストコードをより簡潔に書けるようになった。 Kotlin/NativeとSwift連携の強化 Kotlin/NativeまわりではSwiftエクスポート機能がさらに拡張された。特に、SwiftPM(Swift Package Manager)の依存関係向けにPackage.swiftファイルを自動生成できるようになった点は、AppleプラットフォームでKotlin Multiplatformを採用するチームにとって実務上のメリットが大きい。これまで手作業や追加ツールに頼っていたパッケージ定義の管理が簡素化され、Swift側のエコシステムとの統合がよりスムーズになる。あわせてインクリメンタルコンパイルの改善も行われ、ビルド時間の短縮が見込まれる。 Wasm・JS・ビルドツールの改善 Kotlin/Wasmでは、@JsFun宣言内でのトップレベルrequire()呼び出しの扱いが変更されたほか、コンパニオンオブジェクトの初期化順序が改善され、Kotlin GradleプラグインではWasmランタイムのwasmtimeサポートも追加された。Kotlin/JSでは、ブラウザテスト向けの新しいDSLが導入されたことに加え、サスペンドラムダをasync関数としてエクスポートできるようになり、データクラスのエクスポート性も向上している。開発ツール面ではGradle 9.7.0への対応が完了し、Problems APIのレポート内容が改善されたほか、kotlinrランナーコマンドが独立したネイティブイメージとして提供されるようになった。 一連の変更は派手な新機能というより、既存ワークフローの摩擦を一つひとつ取り除く地道なアップデートが中心となっている。特にSwiftPM連携やコルーチンのデバッグ改善は、Kotlin Multiplatformをすでに本番導入しているチームにとって実利のある内容であり、今後のKotlin 2.5系に向けた開発ツールチェーンの成熟が引き続き期待される。

概要 パッケージマネージャーpnpmは9月7日、v11.26を正式リリースした。今回のアップデートは依存関係管理の柔軟性向上と、サプライチェーンセキュリティの強化という2つの軸を中心に据えている。目玉となるのは、pnpm-workspace.yamlのカタログ機能がworkspace:範囲を保持できるようになった点と、remove・updateコマンドに信頼性検証用のフラグ群が追加された点だ。 カタログのworkspace範囲指定 これまでカタログはワークスペース全体で共通のバージョン番号を一元管理する仕組みだったが、モノレポ内部のパッケージ間依存を指定する際にworkspace:プロトコルとの併用がしづらいという制約があった。v11.26ではカタログエントリにworkspace:^のようなworkspace:範囲を直接記述できるようになり、内部パッケージのバージョン指定もカタログに一元化できる。パッケージを公開する際には、この記法が通常のセマンティックバージョンとworkspace参照の両プロトコルに適切に置換される仕組みになっており、開発時とパブリッシュ時でそれぞれ正しい依存関係表記が使われる。 サプライチェーン検証の強化 セキュリティ面では、pnpm removeとpnpm updateに--trust-lockfile・--no-trust-lockfile・--trust-policy・--trust-policy-exclude・--trust-policy-ignore-afterという一連のフラグが追加された。特筆すべきは、パッケージの削除であってもロックファイル全体を書き換える処理が発生するため、removeコマンド実行時にもロックファイル全体を対象としたポリシーチェックが走るよう設計されている点だ。単純な依存関係の削除操作であっても、意図しない改変や不正なパッケージの混入を検知できるようにする狙いがある。 また、CI環境での利用を想定したpnpm change checkコマンドも新設された。これはワークスペースに既にコミットされているバージョンをversioning.epicsのバンド定義と突き合わせて検証するもので、プルリクエストごとに実行する検証ステップとして位置づけられている。従来はリリース時にバージョニングの不整合が発覚するケースがあったが、このコマンドによって変更が取り込まれる段階、つまりより早いタイミングで問題を検出できるようになる。 その他の変更点 このほど、pnpm deployが注入依存関係(injected dependencies)を必要としない形に改善されたほか、ビルド承認メカニズムの見直し、pnpm auditでの無視済みアドバイザリの除外、シンボリックリンクされたロックファイルへの対応の復活、Windows環境における引数転送の改善なども盛り込まれている。これらは単体では小粒な修正だが、モノレポ運用やCI/CDパイプラインにおける日常的な摩擦を減らすものであり、大規模なワークスペースを運用する開発チームにとっては地道ながら実用的なアップデートといえる。

概要 オープンソースのメディアサーバー「Jellyfin」の開発チームは9月7日、バージョン12.0を正式にリリースした。これまで「10.12」になるはずだったバージョンが「12.0」へと名称変更されたことが象徴するように、今回はマイナーアップデートの枠を超えた大型リリースとなっている。開発チームは、これまでマイナーリリースの体裁を取っていた重大な変更を正確に表現するため、10.11.xを最後の「10.x」シリーズとし、以降は12.0、13.0のように先頭の数字が変動するバージョニング体系に切り替えたと説明している。 データベースバックエンドの刷新 今回の目玉は、v10.11から進めてきたライブラリデータベースの再設計が実を結んだ点にある。従来、プレイリストやコレクション、ボックスセットは一つの大きなリストとしてまとめて保存されていたが、12.0では各アイテムが独立したデータベース行として扱われるようになった。これにより、大規模なプレイリストやコレクションでアイテム数の確認や削除、ページング表示が大幅に高速化されている。あわせて、重いメンテナンス処理がライブラリスキャンを妨げなくなったほか、「Continue Watching」「Up Next」や音楽機能表示時のページ遷移でフリーズが発生しにくくなったという。ただし各記事とも、具体的なベンチマーク数値は示されておらず、体感的な改善として説明されている点は留意したい。 UIとメディア機能の変更 これまで実験的機能だった「Modern」レイアウトが、デスクトップおよびモバイル向けのデフォルトインターフェースとなった(テレビ向けは引き続き従来のレイアウトを使用)。従来のインターフェースは「Legacy」に改称され、ライブラリツールバーのアプリケーションバーへの統合、言語・スタジオによるフィルター追加、ポスター画像を実解像度で表示する変更なども加えられている。また、映画のみで対応していた複数バージョン管理機能がテレビシリーズにも拡張され、放送版と拡張版、あるいは1080pと4Kといった異なる品質のエピソードをグループ化し、実際に視聴したバージョンに応じて再生位置を追跡できるようになった。書籍・コミック機能も大幅に強化され、これまでサードパーティのBookshelfプラグインが担っていたOPF・ComicInfoファイルからのメタデータ読み込み、EPUBやコミックアーカイブのカバー自動生成、PDF・コミックのページ数抽出、オーディオブックの章抽出といった機能がサーバー本体にネイティブ統合された(Bookshelfプラグインは非推奨化)。新たにOpenLibraryプラグインも提供される。このほか、メディア処理基盤はFFmpeg 8.1へ移行し、CUDA・OpenCLサポートの強化、Dolby Vision処理の改善、テレビクライアント向けAV1直接ストリーミングにも対応した。 アップグレード時の注意点 データベーススキーマの大幅な変更に伴い、アップグレードには相応の準備が求められる。前提としてJellyfin 10.10.7または10.11.xからのアップグレードが必須で、完全なバックアップの取得が強く推奨されている。移行時にはユーザー名の大文字小文字の違いが重複と誤認され、移行に失敗する事例が報告されているため注意が必要だ。アップグレード後にはフルライブラリスキャンが必須となり、初回スキャンは通常より著しく長時間化するほか、一部の映画が新規追加として誤認識される可能性もあるという。サーバーの基盤が.NET 10に移行したことでサードパーティプラグインは再コンパイルが必要となり、10.11向けにビルドされたプラグインは12.0では読み込まれない。あわせて廃止予定だった認証メカニズムが無効化され、/emby/や/mediabrowser/アドレスに依存する旧式クライアントは動作しなくなる可能性がある。API面でもGetItemsエンドポイントの非同期化をはじめ複数のエンドポイントが廃止・変更されており、サードパーティ製クライアントやプラグインの開発者は対応状況を確認した上でアップグレードする必要がある。

概要 Julia言語の開発チームは9月10日、最新メジャーバージョン「Julia 1.13」のリリースハイライトを公開した。今回の目玉は開発体験に直結する速度改善で、パッケージのプリコンパイル時間はJulia 1.12比で約30%、LTS版の1.10比でも10〜20%短縮された。起動時間も1.12比で約20%高速化しており、実測値では平均69.1ms±1.0msから56.7ms±0.5msへと1.22倍の改善を確認している。これらの数値は39個の実世界ワークフローの計測に基づくもので、プリコンパイル・読み込み・実行時間のそれぞれを個別に最適化した結果だという。改善作業はJuliaの開発プロセスに継続的に組み込まれており、専用のトラッキングサイト（perf.julialang.org/ttfx）で今後も推移を追跡していく方針だ。 ガベージコレクションとハッシュ関数の刷新 今回のリリースで特に効果が大きいのが、ガベージコレクション(GC)まわりの最適化だ。イメージに組み込まれたオブジェクトのマーク処理をスキップする改善により、あるベンチマークでは0.035493秒から0.000528秒へと約67倍の高速化を達成した。実際の開発ワークフローでも効果は顕著で、Reviseパッケージ読み込み後のフルGC実行時間は50msから11msへ、GLMakie読み込み後は187msから68msへとそれぞれ大幅に短縮され、あるワークロード全体に占めるGC時間の割合も79.80%から44.32%に減少している。あわせてハッシュ関数もMurmurHash3から「RapidhashNano」へと刷新された。ストリーミング方式を採用したことで事前に長さを取得する必要がなくなり、実装もC言語からJulia純粋実装に置き換わった。長い文字列のハッシュ計算では1.12の8.555μsから1.13では1.742μsへと約4.9倍高速化している。なお新しいハッシュは非暗号学的なものであり、カスタム型向けのメソッドを実装する際は常にseedパラメータを受け取る設計になっている。 REPLと開発体験の強化 対話環境(REPL)にも複数の改善が加えられた。構文ハイライトが標準搭載され、保守的な配色をデフォルトにしつつMonokaiなどへのカスタマイズも可能になった。また履歴検索にはfzf風のファジー検索が導入され、複数候補からの選択やREPLモードの表示、構文ハイライトにも対応する。Windows環境では括弧の自動補完を意識したペースト処理が改善され、数百行規模の関数を貼り付ける際の使い勝手が大きく向上したという。このほか、再帰関数内で自分自身を参照できる@__FUNCTION__マクロや、トップレベル評価の進捗を表示してハングの診断に役立つ--trace-evalフラグ、型注釈付きで@whichのような内省をスタックトレースから直接利用できる機能なども追加された。ビルドツールのjuliac.jlも正式パッケージ「JuliaC.jl」として独立し、ファイナライザやmapreduceなどのさらなるコードトリミングに対応している。 パッケージ管理とインストーラの改善 パッケージマネージャPkgも複数の点で強化された。パッケージレジストリの圧縮方式がgzipからzstdに変更され、圧縮率と解凍速度が向上した(Plots・Makie・ModelingToolkitパッケージのダウンロードで307.99MBから239.31MBへ、解凍時間は8.77秒から5.50秒へ短縮)。レジストリ処理とリゾルバの最適化により、Plotsパッケージを追加する際の所要時間も1.257秒から0.745秒に短縮されている。また、使用したレジストリ情報がマニフェストファイルに記録されるようになり、他環境での自動インストールに手動設定が不要になったほか、スタック環境ではすでに読み込み済みのパッケージを優先することで不要なプリコンパイルを回避する仕組みも導入された。インストーラのJuliaupも1.22以降でGUIを搭載し、インストール済みチャネルの管理や利用可能チャネルの一覧表示、設定画面を提供する。今回のリリースはIan Butterworth氏やKristoffer Carlsson氏、Cody Tapscott氏らコアチームに加え、多くのコミュニティ貢献者の協力によって実現したとしている。

概要 Microsoftは9月9日、Visual Studio Codeのバージョン1.137をリリースした。今回の更新は、AIエージェントをより自律的かつ多様な方法で活用できるようにする機能が中心となっている。プレビュー機能として、決まったタスクを定期的にエージェントへ実行させる「Automations」が導入され、実験的機能としては音声でエージェントと対話できる「Voice Mode」、GitHubのIssueやPRをリポジトリを開かずにAgentsウィンドウ内で直接確認できる統合機能なども追加された。 Automationsによるエージェントタスクの自動化 Automations(設定項目chat.automations.enabled)は、変更内容の確認やIssueのトリアージ、バグ検出といった定型的な作業を、手動で都度指示せずにエージェントへ繰り返し実行させる機能だ。時間単位・日単位・週単位のスケジュール実行に加え、オンデマンドでの実行にも対応しており、あらかじめ用意されたテンプレートから目的に合わせたタスクを選べる。利用にはAgentsウィンドウのサイドバーから「Automations」を選択する。現時点ではプレビュー段階にあり、全ユーザーへ段階的に展開されている。 Voice ModeとGitHub統合 Voice Mode(設定agents.voice.enabledなど)は、チャット入力欄のボタンから起動し、音声でエージェントに指示を出したり、作業中のエージェントに話しかけて処理を中断・修正したりできる実験的機能だ。エージェントの発話に割り込むほか、プッシュトゥトーク方式での中断も可能で、発話内容のトランスクリプト表示切り替えやマイク選択、音声の変更にも対応する。組織単位でこのプレビュー機能を無効化する管理設定も用意されている。 GitHub連携では、GitHub Pull Requests拡張機能がインストールされていることを前提に、Issueやプルリクエストの詳細をAgentsウィンドウ内で直接確認できるようになった(設定extensions.experimental.enableAgentsWindowCapability)。チャットの「Add Context…」メニューからIssueやPRを添付できるほか、URLを貼り付けるだけで自動的にコンテキストとして取り込まれる。Markdownエディタ上のGitHubリンクにもタイトルと状態がライブ表示される機能(markdown.experimental.richLinks.enabled)が実験的に追加された。 その他のアップデートと展望 このほか、ワークスペースを開かずに始めた汎用チャットから、履歴を保持したままプロジェクト固有の作業へ引き継げる機能、複数の差分表示形式(インライン・サイドバイサイド・自動選択)を統一的に切り替えられるSmart diff editor layout、マルチファイル差分での画像などバイナリファイルのプレースホルダー表示、複数エージェントを並列実行するAgent-queued messagesなども追加された。基盤面では、Agent Host Protocol(AHP)に基づく専用プロセスとしてエージェントを実行する「Agent Host」が導入され、Copilot SDKとの統合によって他のCopilot製品との動作統一が図られている。今回の一連の更新は、単発の対話から定期実行・音声操作・外部連携まで、エージェントの活用範囲を広げる方向性を明確に示すものといえる。

概要 GitLabは9月10日、CE/EE(Community Edition/Enterprise Edition)を対象とした緊急パッチ19.3.2、19.2.6、19.1.8をリリースし、18件の脆弱性をまとめて修正した。中でも突出しているのが、最大深刻度となるCVSS10.0のパストラバーサル脆弱性CVE-2026-85706で、リポジトリコミットAPIにおけるパス制限の不備と認証の欠落により、未認証の攻撃者がサーバー上の任意ファイルを読み取れる状態にあった。さらにCVSS9.9の危険な逆シリアル化脆弱性CVE-2026-87719(GraphQLサブスクリプション機能に起因)も含まれており、いずれも自己管理(self-managed)環境に影響する。GitLab.comは既にパッチ適用済みで、Dedicated顧客の対応は不要とされる。 パッチ公開からわずか1日というスピードで実際の悪用の試みが観測され始めた点が、今回最も注視すべき事実だ。脅威インテリジェンス企業watchTowrは、2026年9月11日06:00 UTC以降、CVE-2026-85706を狙った野生下での探索活動を検知したと報告している。 CVE-2026-85706の技術的詳細と悪用条件 CVE-2026-85706は、/api/v4/projects/{id}/repository/commits/エンドポイントへのHTTPリクエストでfile_pathパラメータを細工することにより、認証なしでサーバー上の任意ファイルを読み取れるというものだ。watchTowrの脅威情報責任者Jake Knott氏は、悪用の最小要件について「少なくとも1つのパブリックプロジェクトが存在すれば悪用可能」と説明し、ログファイルや設定ファイルからの認証情報抽出につながりうると警告した。Knott氏はさらに、GitLabが攻撃者にとって魅力的な標的である理由として、ソースコード、CI/CDシークレット、認証情報へのアクセスに加え、ビルドパイプラインへのコード注入が可能になる点を挙げている。同氏は、これが数週間のうちに即座に悪用された2件目の重大GitLab脆弱性であるとも指摘しており、先行するGraphQL関連の脆弱性でも同様の即時悪用が確認されていたという。 影響を受けるバージョンはCE/EEの18.7以降19.1.8未満、19.2以降19.2.6未満、19.3以降19.3.2未満と広範囲に及ぶ。 残る17件の脆弱性と対応 今回のパッチではCVE-2026-85706、CVE-2026-87719以外にも、CVSS8.5のバッファオーバーフロー(Advanced Search機能のバッファ管理不備、CVE-2026-88765)や認可不備(CVE-2026-79708)、CVSS8.2のクロスサイトスクリプティング(CVE-2026-78252)など、深刻度の異なる脆弱性が計18件修正されている。多くはEE限定だが、パストラバーサルやXSS、サービス拒否など一部はCE/EE双方に影響する。 GitLabは自己管理環境の運用者に対し、直ちに19.3.2/19.2.6/19.1.8へアップグレードするよう強く推奨している。即時のアップグレードが難しい場合は、公開プロジェクトへのアクセスを一時的に制限するなどの緩和策も選択肢となる。侵害調査の観点では、Knott氏が推奨するように、/api/v4/projects/{id}/repository/commits/へのfile_pathパラメータを含むPOSTリクエストのログを確認することで、悪用の痕跡を検出できる可能性がある。公開直後から実悪用が確認された今回のケースは、自己管理型GitLabを運用する組織にとってパッチ適用の緊急性を改めて示す事例と言える。