PostgreSQL 19ベータ2がリリース、グラフクエリとゼロダウンタイム再編成を正式ロードマップに

概要 PostgreSQLプロジェクトは7月16日、次期メジャーバージョンとなる「PostgreSQL 19」の2回目のベータ版「Beta 2」をリリースした。すでに機能凍結(feature freeze)を迎えており、今回のBeta 2ではvacuumdbの--analyze-in-stagesオプションがパーティションテーブルで正しく動作しない不具合や、ロジカルデコーディングの競合状態、REPACKワーカーがFATALエラー時にクリーンアップされない問題など、14件のバグ修正と改善が取り込まれた。正式リリースは2026年9月〜10月頃を予定しており、必要に応じて追加のベータ版やリリース候補版(RC)が提供される見込みだ。プロジェクト側は本番環境での利用は推奨しておらず、ワークロードでの動作検証とフィードバックをコミュニティに呼びかけている。 目玉機能:SQL/PGQによるネイティブグラフクエリ PostgreSQL 19の目玉機能の一つが、SQL標準の一部であるSQL Property Graph Queries(SQL/PGQ)のサポートだ。これにより、専用のグラフデータベース拡張を使わずとも、標準SQLの枠組みの中でグラフ構造データをクエリできるようになる。実装上はビューと同様に内部的に処理され、通常のリレーショナルクエリとして書き下される点が特徴で、Peter Eisentraut氏やAshutosh Bapat氏らが開発に貢献した。Beta 2ではこの機能自体にも複数の不具合修正が加えられており、安定化が進んでいる段階にある。 ゼロダウンタイムのテーブル再編成を実現する統合REPACKコマンド もう一つの主要な変更が、VACUUM FULLとCLUSTERを置き換える統合コマンドREPACKの追加だ。REPACK [table_name] [CONCURRENTLY]という構文で実行でき、CONCURRENTLYオプションを指定するとアクセス排他ロックを取得せずにテーブルを再構築できるため、運用中のシステムでもダウンタイムなしにテーブル再編成が可能になる。同時実行される再編成処理の数を制御する新しいサーバ変数max_repack_replication_slotsも追加された。従来のVACUUM FULLやCLUSTERコマンド自体は後方互換性のため引き続き利用できる。開発にはAntonin Houska氏、Mihail Nikalayeu氏、Álvaro Herrera氏らが携わった。 その他の主要な変更点 PostgreSQL 19では、この他にも幅広い改善が予定されている。時系列データを扱うFOR PORTION OF構文による時間範囲指定のUPDATE/DELETE、ALTER TABLE ... MERGE/SPLIT PARTITIONSによるパーティションの結合・分割、ロジカルレプリケーションにおけるシーケンス値の同期やパブリケーションからの除外指定(FOR ALL TABLES EXCEPT)などが含まれる。パフォーマンス面では、autovacuumの並列化、COPY処理でのSIMD命令活用、TOASTのデフォルト圧縮方式をpglzからlz4へ変更するなどの最適化が図られている。一方で、JITがデフォルトで無効化される、RADIUS認証のサポートが削除される、max_locks_per_transactionのデフォルト値が64から128に引き上げられるといった、既存環境への影響を伴う変更点も含まれている。 今後の見通し 機能凍結後のこの段階では大きな新機能の追加は見込まれず、今後のベータ版やRCではバグ修正と安定化が中心となる。正式版は2026年9月から10月にかけてリリースされる予定で、テストユーザーには未解決課題一覧の確認や、バグ報告フォームを通じたフィードバックが呼びかけられている。グラフクエリのネイティブサポートやゼロダウンタイムのテーブル再編成は、大規模運用環境やアナリティクス用途において注目度の高い機能であり、正式リリースに向けた今後の検証状況が引き続き注視される。

July 18, 2026

VS Code 1.129、エージェント専用プロセス「Agent Host」を導入 複数ウィンドウ接続とチャットからのターミナル実行に対応

概要 Microsoftは2026年7月15日、Visual Studio Codeの最新版「1.129」をリリースした。目玉となるのは、CopilotやClaude、Codexといったエージェントハーネスを専用プロセス上で実行する新アーキテクチャ「Agent Host」の導入である。あわせて、チャットメッセージの先頭に!を付けることでその内容をターミナルコマンドとして直接実行できる機能や、Agentsウィンドウのレイアウト改善など、AIエージェントを軸とした開発体験の強化が図られている。 Agent Hostアーキテクチャの詳細 Agent Hostは、エージェントハーネスを動かすための専用プロセスであり、「Agent Host Protocol(AHP)」に基づいて動作する。セッションが独立したプロセス上に存在するため、「セッションは自身のプロセス内で稼働するため、同一セッションを複数のVS Codeウィンドウから同時に接続・描画できる」という特性を持つ。これにより、異なるワークスペースを開いた複数ウィンドウ間で同じエージェントセッションの進行状況を確認したり操作したりすることが可能になる。 この機能はchat.agentHost.enabledという組織レベルで管理される設定によって有効化され、エディタやAgentsウィンドウのハーネスドロップダウンから利用するエージェントを選択する形で使う。対応するハーネスとしてCopilot、Claude、Codexの3つが明示されており、Copilotエージェントは「Copilot SDK」によって動作し、Copilot CLIやスタンドアロン版のGitHub Copilotアプリと挙動を揃えているという。Claudeをエージェントハーネスとして使う場合は、chat.agents.claude.preferAgentHostという専用設定を有効にする必要がある。なお、Agent Hostは現時点でも開発が継続中であり、Microsoftは段階的にユーザーへの展開を進めている段階としている。新機能の一部は、エージェントがAgent Host上で動作している場合にのみ利用可能になる点にも注意が必要だ。 チャットからのターミナル操作 もう一つの主要な追加機能が、チャットメッセージに!を付けることでその内容をターミナルコマンドとして実行できる仕組みである。この機能はAgent Hostセッション上で動作し、エディタとAgentsウィンドウの両方で利用できる。これにより、エージェントとの対話の流れを崩さずに、コマンドの実行結果をその場で確認しながら作業を進めやすくなる。 その他の主要な変更点 このほか、Agentsウィンドウではsessions.layout.singlePaneDetailPanel設定により、チャットと編集パネルを1つのペインに統合した新しいレイアウトをプレビューできるようになった。エージェントが他のセッションを列挙・作成・監視・操作できるセッション管理ツールも追加され、複数タスクの並行処理がしやすくなっている。さらに、GitHub Enterprise環境でのCopilot利用対応、Agentsウィンドウでのカスタムモデル(BYOK)サポート、workbench.experimental.modernUI設定によるUI刷新版のプレビュー、workbench.diffEditorAssociationsによる差分エディタの割り当て設定に加え、ファイル・差分・マージエディタごとに優先度を指定できる提案API「customEditorPriority」など、エディタ全体にわたる改善が盛り込まれている。 今後の展望 Agent Hostはまだ開発途上の機能であり、対応ハーネスや利用可能な機能は今後のリリースを通じて拡充されていくとみられる。複数ウィンドウからの同一セッション接続という仕組みは、チーム開発や複数タスクの並行管理においてAIエージェントの活用範囲を広げるものであり、VS Codeにおけるエージェント統合の今後の方向性を示す重要な一歩といえる。

July 17, 2026

難読化ツールJscrambler、npmパッケージ改ざんでRust製マルウェアがAI開発ツールの認証情報を標的に

概要 JavaScript難読化ソリューションを提供するJscrambler社のnpmパッケージが7月11日、サプライチェーン攻撃の被害に遭った。攻撃者は盗んだnpm発行認証情報を使い、正当なメンテナーアカウントから通常のリリースフローを迂回する形でパッケージを直接改ざん・公開した。影響を受けたのは主要パッケージの8.14.0、8.16.0、8.17.0、8.18.0、8.20.0の各バージョンで、加えてJscrambler-webpack-plugin、gulp-Jscrambler、grunt-Jscrambler、Jscrambler-metro-pluginといった関連パッケージにも波及した。悪意あるバージョンにはインストール時に実行されるpreinstallフックが仕込まれており、Windows・macOS・Linuxそれぞれに対応したプラットフォーム別バイナリがドロップされる仕組みになっていた。 セキュリティ企業のSocketが公開からわずか6分後にこのリリースに警告フラグを立て、侵害を検出した。悪質なパッケージは公開から廃止までの約2時間で1,479回ダウンロードされたことが確認されている。Jscrambler社は7月13日に事態を公表し、npm発行認証情報を取り消した上でセキュリティ管理体制を強化した。 技術的な詳細 混入したマルウェアは「IronWorm」と呼ばれるRust製のインフォスティーラーで、ChaCha20-Poly1305暗号化アルゴリズムによる強力な難読化が施されており、解析による特定が困難な作りになっていた。狙われた認証情報の範囲は広く、AWS・Azure・Google Cloudなどのクラウド認証情報、MetaMaskやPhantom、Exodusといった暗号資産ウォレット、Bitwardenのパスワード管理データ、Git/SSH鍵や環境変数などの開発者秘密情報、さらにブラウザに保存されたパスワードやDiscord・Slack・Telegramのセッション情報にまで及んだ。 特に注目されるのは、Claude Desktop、Cursor、VS CodeといったAIコーディングアシスタント関連の設定・認証情報も収集対象に含まれていた点で、AI開発ツールがサプライチェーン攻撃の新たな標的として明確に狙われたことを示している。マルウェアはC2サーバー(IPアドレス 37.27.122.124、57.128.246.79)と通信する構成になっていた。 対応策 Jscrambler社および各セキュリティ研究者は、影響を受けた可能性のある開発者に対して以下の対応を推奨している。まず、パッケージを安全なバージョンである8.15.0または8.22.0にアップグレードし、ロックファイルから該当する侵害バージョンの記述を削除する必要がある。さらに、悪意あるバージョンをインストールした形跡があるマシンについては環境がコンプロマイズされたものとみなし、AWSやクラウドサービス、暗号資産ウォレット、AI開発ツールを含むあらゆる認証情報を速やかにリセットすることが求められている。また、前述のC2 IPアドレスへの通信をファイアウォールやネットワーク監視でブロックすることも有効な対策として挙げられている。 今回の事件は、正規のメンテナーアカウントが侵害された場合、通常のコードレビューやリリースプロセスをすり抜けてマルウェアが配布され得ることを改めて示した。加えて、AIコーディングツールの認証情報が明確な攻撃対象になっている点は、開発者のワークフローに深く組み込まれつつあるAIツールのセキュリティ管理が今後より重要になることを示唆している。

July 15, 2026

Bun、Claude Fable 5で53万行のZigコードを11日間でRustへ全面移植

概要 JavaScript/TypeScriptランタイムBunの開発チームは7月8日、もともとZigで書かれていたランタイム本体、約53万5000行のコードをRustへ全面移植したと発表した。Anthropicに買収されたBunチームの一員であるJarred Sumner氏によるブログ記事で明らかにされたもので、作業には最大64個のClaude Fable 5インスタンスを同時稼働させるClaude Codeの動的ワークフローが用いられ、2026年5月3日から14日までのわずか11日間で完了したという。コミット数は6,502件、追加行数は約100万行に達した。この事例は、AIエージェントを並列活用することで大規模コードベースの全面書き換えという従来避けられてきた手法が現実的になった例として、Simon Willison氏など複数のメディアが取り上げ注目を集めている。 移植の背景 BunはこれまでZigの手動メモリ管理とJavaScriptCoreのガベージコレクターを組み合わせて実装されていたが、この構成がuse-after-free、double-free、エラーパスでの解放漏れといったメモリ安全性のバグを継続的に生む原因となっていた。Rustのボローチェッカーはこれらの問題の多くをコンパイル時エラーとして検出できるため、安定性向上を狙って全面的な言語移行が選択された。Simon Willison氏は、従来のソフトウェア開発では大規模な完全書き直しはリスクが高く避けるべきとされてきたが、現代のAIモデルの能力がこの前提を変えつつあると指摘している。 実装プロセス 移植は単発のプロンプトでコードを変換するのではなく、体系的なパイプラインとして構築された。まずPORTING.md(ZigからRustへのパターン対応表)とLIFETIMES.tsv(複雑な構造体のライフタイム分析)を準備し、全1,448個の.zigファイルを機械的に.rsへ変換。その後発生した約1万6000件のコンパイルエラーを段階的に修正し、テストをローカルからCIへと順次拡大しながら検証した。品質保証の要となったのは、実装を担当したエージェントとは別のコンテキストで動作する2つのClaudeによる「敵対的レビュー」と、TypeScriptで書かれた既存テストスイートを言語非依存の適合性検証スイートとして活用した点である。全体では約50の動的ワークフローが連続して実行され、入力トークンは59億、出力トークンは6.9億に上り、API利用コストは推定16万5000ドルと見積もられている(Anthropic社員という立場からトークン費用は実質負担していないという)。 成果と今後の展望 移植の結果、バイナリサイズはLinuxで20%、Windowsで19%削減(Linux版は88MBから70MBへ、Windows版は94MBから76MBへ)されたほか、HTTPスループットが2.8〜4.8%、TypeScriptコンパイルが4.7%向上するなど性能面でも改善が見られた。メモリ使用量では、2,000回の反復ビルドテストにおいてZig版が6.7GBを消費していたのに対し、Rust版は609MBにまで抑えられたという。移行後に発覚した回帰は19件のみで、HMR破損やUTF-16処理の差異など軽微なものにとどまり、いずれも迅速に修正された。128件のバグ修正やメモリリーク問題の根本的解消も報告されている。今回Rustで書き直されたコードは「Bun v1.4.0」として最初にリリースされる予定で、今後はパーサーの24時間体制でのファジングや、現在4%残るunsafeコードの段階的削減が継続される見込みだ。

July 14, 2026

npm 12がリリース、依存関係のインストールスクリプトをデフォルト無効化しサプライチェーン攻撃対策を強化

概要 GitHubは2026年7月、npmの新バージョンv12.0.0を正式リリースした。最大の変更点は「allowScripts defaults to off」という方針転換で、これまでnpm install実行時に自動で走っていた依存パッケージのpreinstall・install・postinstallといったライフサイクルスクリプトが、デフォルトで無効化される。相次ぐサプライチェーン攻撃を受けた大きな方針転換であり、世界中の膨大な数のnpmユーザーに影響する変更となる。 技術的な詳細 npm 12では、主に3つの制御がデフォルトで厳格化された。 ライフサイクルスクリプトの無効化:依存関係のスクリプトや、暗黙的に実行されていたnode-gypによるネイティブビルドが、明示的な許可なしには実行されなくなる。 Git依存関係の制限:--allow-gitのデフォルトが「none」となり、直接・間接を問わずGit経由の依存関係が明示的な許可なしには解決されなくなる。 リモートURL依存の制限:--allow-remoteのデフォルトも「none」となり、HTTPS経由のtarballなど、リモートURLからの依存関係取得が制限される。 正当なビルドスクリプトを必要とするパッケージを使い続けたい開発者は、npm approve-scripts --allow-scripts-pendingを実行して信頼するスクリプトを個別に承認し、その結果をpackage.json内のホワイトリストとしてコミットする運用が必要になる。 セキュリティ関連の追加変更 今回のリリースでは、npmのGranular Access Tokens(GAT)にも重要な変更が加わった。2要素認証(2FA)をバイパスするよう設定されたGATは、アカウントや組織に関わる機微な操作を実行できなくなる。対象にはトークンの作成・削除、リカバリーコードの生成、パスワードやメールアドレスの変更、2FA設定の変更、パッケージアクセス管理、公開組織・チームの管理などが含まれる。この制限は2026年8月初旬から段階的に発効する予定だ。 今後の展望 npmは2027年1月をもって、Granular Access Tokens(GAT)による直接公開機能を廃止する計画も示している。GATの公開範囲はプライベートパッケージの読み取りと公開のステージングに限定され、実際の公開には人間による2FA承認が必要になる。今後は自動公開についてOIDCベースのtrusted publishing、あるいは人間によるレビュー・承認ステップを経た公開フローへの移行が推奨される。同時期には、pnpm 11.10でも認証情報とその接続先ホストを単一の構造化された値として関連付ける_auth設定が導入されており、リポジトリに紛れ込んだマルウェアによる認証トークンの横取りリスクを軽減する動きが業界全体で広がりつつある。

July 13, 2026

Paysafe・Skrill・Netellerの決済SDKを偽装、npmとPyPIで17件のタイポスクワッティング攻撃を検知

概要 セキュリティ企業Socketは2026年7月7日、npmとPyPIの両パッケージレジストリにまたがる調整型のタイポスクワッティング攻撃キャンペーンを検知したと発表した。攻撃者は決済サービスのPaysafe、Skrill、Netellerの公式SDKを装い、npmに13パッケージ(paysafe-checkout、paysafe-vault、paysafe-js、neteller、skrillなど、各4バージョンずつ)、PyPIに4パッケージ(paysafe-kyc、paysafe-payments、paysafe-sdk、paysafe-api)の計17件を公開していた。狙いは決済SDKを導入しようとする開発者を騙し、CI/CD環境の認証情報やシークレットを窃取することにあった。公開からわずか6分で悪意あるコードとして検知されたが、パッケージレジストリを標的にしたサプライチェーン攻撃の脅威が改めて浮き彫りになった。 巧妙なフェイクSDKの仕組み 悪意あるパッケージは、本物のPaysafe APIクライアントを模したクラスを実装しており、表面上は正常に動作しているように見える。実際には決済サービスの本物のエンドポイントには一切接続せず、{ success: true, method, path }のような偽の成功レスポンスを返すだけの「ファサード」に過ぎない。APIキーは環境変数PAYSAFE_API_KEYから読み込む形を取り、正規のSDKと同様の使い勝手を装うことで開発者に気付かれにくくしていた。 シークレット窃取とサンドボックス回避の手口 すべてのAPIリクエストメソッドが実行されるたびに、内部の_request()関数がシークレット抽出ルーチンを起動する仕組みになっていた。この処理では、変数名に「KEY」「SECRET」「TOKEN」「PASS」「AUTH」「API」を含む環境変数を片っ端からフィルタリングし、値を100文字に制限した上で窃取する。実際の被害シナリオではPAYSAFE_API_KEYだけでなく、AWS_SECRET_ACCESS_KEYやGITHUB_TOKEN、NPM_TOKENといったCI/CDの重要な認証情報も捕捉対象となっていた。 さらに、解析環境での検知を逃れるための仕掛けも組み込まれていた。CPUコア数が2未満の環境や、ホスト名・ユーザー名に「sandbox」「analyzer」「cuckoo」「virus」といった文字列が含まれる環境を検出すると、悪意ある処理をスキップする仕様になっている。窃取したデータの送信先となるC2(コマンド&コントロール)ドメインも、XORデコード、文字コードの17減算、文字列の反転という3段階の難読化処理で隠蔽されており、最終的にcaliber-spinner-finishing.ngrok-free.devというngrokベースのドメインへ通信する仕組みだった。このC2ドメインが解決するIPアドレスは、既知のマルウェア「NjRAT」など他の情報窃取型マルウェアのC2サーバーとしても使われていた実績があるという。なお、PyPI側のパッケージにはnpm版のようなAPIキーによるゲーティングがなく、インポートするだけで自動的にペイロードが実行される点も特徴だった。 攻撃者の狙いと今後の対策 Socketの分析によれば、攻撃者は決済関連SDKという特定領域に戦略的に的を絞り、パッケージごとに異なる難読化キーを使用することでシグネチャベースの検知を回避しようとしていた。npmとPyPIという複数エコシステムにまたがる攻撃を仕掛けられる技術力も示しており、サプライチェーン攻撃の巧妙化を裏付ける事例といえる。Socketは、該当パッケージを実行した端末上のすべてのシークレットを速やかにローテーションすること、依存関係に13件のパッケージ名が含まれていないか確認しレジストリプロキシ側でのブロックを検討すること、CIやビルドホストから.ngrok-free.devへの不審な通信がないか監視すること、PAYSAFE_API_KEYと該当パッケージ名の組み合わせについてCIログを監査することを推奨している。また52件のSHA-256ファイルハッシュを含む侵害指標(IoC)も公開されており、組織は自社環境への影響有無を照合できる。

July 12, 2026

VS Code 1.128リリース、複数Claudeエージェントを並行実行できる「マルチチャットセッション」を搭載

概要 Microsoftは7月8日、Visual Studio Codeの最新版となる「VS Code 1.128」をリリースした。目玉となるのは、1つの親セッションの中で複数の関連するチャットを並行して扱える「マルチチャットセッション」機能だ。Claudeなどのエージェントホストセッションにおいて、異なるアプローチを比較したり、途中のターンから分岐させたり、複数の作業を同時並行で進めたりできるようになった。各チャットはそれぞれ独立した履歴・タイトル・モデル選択を保持しつつ、一つのグループとしてまとめて管理されるため、作業がバラバラの独立セッションに分散してしまう問題を避けられる。あわせて、画像やPDFをチャットに添付できる「Copilot Vision」が正式にGA(一般提供)となったほか、VS Codeがフォーカスされていない状態でもコマンドを実行できる「OSレベルのキーボードショートカット」など、複数の機能強化が同時に投入された。 技術的な詳細 マルチチャットセッションでは、エージェントホストのセッション配下に複数の子チャットをぶら下げる形で管理する。各チャットは独自の会話履歴・タイトル・使用モデルを持てるため、たとえば同じタスクに対して異なるモデルやアプローチで並行して試行し、後から結果を比較するといった使い方が可能になる。セッション内の各チャットへは直接ディープリンクできるほか、複数チャット間を素早く移動するためのナビゲーションショートカットも用意された。 Copilot Visionは、チャットへの画像・PDFファイルの添付に対応する機能で、ペースト・ドラッグ&ドロップ・右クリックメニューのいずれからも添付でき、エージェントはツール呼び出しを通じてその内容を読み取れる。今回のリリースでプレビューを終え、正式に一般提供(GA)となった。 このほか、キーバインド設定にsystemWide: trueを指定することで、VS Codeがフォーカスを失っていてもコマンドを起動できる「OSレベルのキーボードショートカット」が導入され、Agentsウィンドウなどへの素早いアクセスに活用できる。ワークスペースに紐付かない「クイックチャット」も追加され、⌘K ⌘N(Linuxではcmd+K cmd+N)から起動可能で、特定プロジェクトに関係しない質問向けに、リロードをまたいで独立したセッションとして保持される。そのほか、カスタムエンドポイントに対する温度(temperature)やtop_pなどのサンプリングパラメータ設定、エージェントホストセッションでの実験的なBYOK(Bring Your Own Key)モデル対応、エンタープライズ向けのOpenTelemetryテレメトリ管理、ブラウザタブの配置先を選べるworkbench.browser.newTabPlacement設定なども今回のアップデートに含まれている。 今後の展望 マルチチャットセッションやBYOKモデル対応の実験的サポートは、複数のAIエージェントを組み合わせて開発を進める「マルチエージェントワークフロー」への対応を強化する動きの一環と見られる。Copilot VisionのGA化により、スクリーンショットや設計資料などの非テキスト情報を交えたやり取りがより日常的な開発フローに組み込まれていくことが期待される。

July 12, 2026

AIエージェント8体が並列開発、PostgreSQLのRust書き直し「pgrust」が回帰テスト4.6万件に全合格

概要 元Heap CEOのMalcolm Matis氏は7月9日、個人プロジェクトとして開発しているPostgreSQLのRust書き直し「pgrust」が、PostgreSQL 18.3の回帰テスト4.6万件以上に全件パスし、さらに分離テストにも合格したことを発表した。pgrustはPostgres 18.3との完全互換を目標としており、既存のPostgres 18.3のデータディレクトリからそのまま起動できるディスク互換性も実現している。この発表はHacker Newsで740ポイント超・620件超のコメントを集める大きな反響を呼び、AIコーディングエージェントによる大規模ソフトウェアの書き換えがどこまで実用的かを示す事例として注目されている。 開発手法 pgrustの最大の特徴は、その開発プロセスにAIコーディングエージェントを大々的に活用していることだ。Matis氏はJason Seibel氏と共同で、8体の並列AIコーディングエージェント(Codex)を運用し、月額約1,600ドルのコストをかけて開発を進めた。並列セッションの調整には「Conductor」というツールを用い、10〜20個のセッションを同時に走らせることで、4月末までに45万行以上のRustコードを生成したという。 技術的な詳細 アーキテクチャ上の大きな変更点は、従来のPostgresが採用していたプロセス単位の接続モデルから、スレッド単位の接続モデルへの移行だ。これによりメモリ安全性の向上や接続数上限の問題解消が見込まれるが、Matis氏自身は「一つの接続でのクラッシュが他の接続に影響を及ぼす可能性がある」という新たなリスクも認めている。未発表のベンチマークでは、トランザクション処理でPostgres本体より約50%高速、分析ワークロードでは約300倍高速という主張もされているが、Matis氏は「v0.1は本番環境での使用には対応しておらず、パフォーマンス最適化も未実施」と明言しており、既存のPostgres拡張機能とも互換性がない段階にとどまる。ブラウザ上で動作を確認できるデモがpgrust.comで公開されており、ソースコードはGitHub上で公開されている。 反響と今後の展望 Hacker Newsでの反響は大きく、740ポイント超・620件超のコメントが寄せられた一方、fsyncの設定条件やClickHouseとの比較の妥当性について懐疑的な意見も多く出ている。OrioleDBの開発者であるBen Dicken氏は「まだ基準に達していない」と指摘するなど、成果の評価には慎重な声も少なくない。開発チームが掲げる目標は「Postgresの内部を変更しやすくすること」であり、Postgres本体の挙動を正解(oracle)としながらRustでコードベースの作業性を高め、AI支援プログラミングによってサーバーのより深い部分への変更を探求していく計画だとしている。

July 11, 2026

Gitea公式Dockerイメージに認証バイパスの重大脆弱性、開示から2週間足らずで実悪用が確認

概要 自己ホスト型GitサービスGiteaの公式Dockerイメージに、認証を完全に迂回して任意のユーザー(管理者を含む)になりすませる重大な脆弱性「CVE-2026-20896」(CVSS 9.8)が存在することが明らかになった。2026年6月下旬の脆弱性開示からわずか13日後には、セキュリティ企業Sysdigによって実際の悪用の痕跡が検出されており、パッチ未適用の環境を狙った攻撃が急速に進行していることがわかる。研究者Ali Mustafa氏がこの問題を発見・報告し、Gitea側は1.26.3および1.26.4で修正版を公開済みである。 技術的な詳細 問題の根本原因は、Giteaの公式Dockerイメージがデフォルトでリバースプロキシ認証の信頼済みプロキシ設定をREVERSE_PROXY_TRUSTED_PROXIES = *(ワイルドカード、つまり全IPアドレスを信頼)としていた点にある。本来この設定は127.0.0.0/8,::1/128のようにローカルホストなど限定された送信元のみを信頼するべきものだが、ワイルカード指定によりコンテナのHTTPポートに直接到達できる何者でも、リバースプロキシを経由したかのように振る舞えてしまう状態になっていた。 具体的には、攻撃者はX-WEBAUTH-USERというHTTPヘッダーに任意のユーザー名を設定して送信するだけで、パスワードやトークンなしにそのユーザーとして認証されてしまう。Mustafa氏は「ポートに到達できる者は誰でもX-WEBAUTH-USERヘッダーを送信し、パスワードもトークンも使わずに任意のユーザーとして認証される状態だった」と説明している。さらに自動登録(auto-registration)機能が有効な構成では、既知の管理者ユーザー名になりすますことで、攻撃者が管理者権限まで取得できる危険性があった。影響を受けるのはGitea公式Dockerイメージのバージョン1.26.2以前で、修正版の1.26.3・1.26.4ではこのワイルドカードのデフォルト値が撤廃され、リバースプロキシ認証はオプトイン方式に変更された。 悪用の状況とタイムライン 脆弱性は2026年6月下旬に公開された。Sysdigによれば、最初の実際の悪用行為はその13日後に検出されており、送信元はProtonVPNのIPアドレス(159.26.98[.]241)からのものだった。SysdigのシニアディレクターMichael Clark氏のコメントには報道間で幅があり、SecurityWeekやBleepingComputerでは「開示から2週間足らず後(13日後)に実悪用が始まっていた」とする一方、The Hacker Newsでは「現時点の活動は攻撃者による初期調査(偵察)段階にとどまり、本格的な侵害への進展は確認されていない」とも報じられている。いずれの報道でも、脅威アクターがこの脆弱性に強い関心を寄せ、積極的にプロービングを行っている点では一致している。 Sysdigの調査では、インターネットに公開されているGiteaインスタンスは全世界で約6,200件確認されているが、そのうち実際に脆弱な設定のまま稼働している数までは特定されていない。悪用に成功した場合、攻撃者はプライベートリポジトリのソースコード、誤ってコミットされたAPIキーや認証情報、CI/CD設定、デプロイトークンなど、機密性の高い資産に完全にアクセスできてしまう。シンガポールのサイバーセキュリティ庁(CSA)もこの脆弱性について注意喚起を発行している。 今後の対応 Gitea運用者に対しては、直ちに修正版である1.26.3以降(推奨は1.26.4)へアップグレードすることが強く求められている。何らかの理由で即時のアップグレードが困難な場合は、REVERSE_PROXY_TRUSTED_PROXIES設定を実際に信頼できる特定のIPアドレスやCIDR範囲に限定することで、暫定的にリスクを低減できる。加えて、過去のアクセスログを確認し、不審なX-WEBAUTH-USERヘッダーを伴うリクエストや、身に覚えのない管理者アカウントでのログイン履歴がないか点検することも推奨されている。今回のケースは、公式コンテナイメージのデフォルト設定が誤っていた場合、パッチ公開後もごく短期間で実運用環境への攻撃に直結し得ることを改めて示す事例となった。

July 11, 2026

GitHub Actions、ホスト型ランナーの起動遅延障害が約9時間継続 終盤には最大96%のジョブが起動失敗

概要 GitHubは7月9日、GitHub Actionsのホスト型ランナーでジョブの起動遅延が発生する障害を確認した。障害はUTC午前4時34分(日本時間13時34分)に初期報告され、同日13時52分(日本時間22時52分)に復旧が完了するまで、約9時間18分にわたって継続した。GitHubは公式ステータスページで「GitHub-hosted runners上で実行されるGitHub Actionsのジョブのうち約30%が、5分を超える起動遅延を経験している」と発表し、多数の組織のCI/CDパイプラインに影響が及んだ。 影響の推移と範囲 障害の影響は段階的に拡大した。発生当初は全体の約5%のジョブで5分以上の起動遅延が見られる程度だったが、その後悪化が進み、約30%のジョブが5分を超える遅延に見舞われる状態がしばらく続いた。さらに終盤の約20分間には約96%のジョブが起動に失敗する状態にまで悪化した後、回復に転じた。遅延が長引いた一部のジョブは、リトライ回数の上限を超えて最終的に失敗する事態にもつながった。 影響はActionsランナーの起動遅延にとどまらなかった。GitHub Pagesのビルド処理も同じ障害の余波を受けたほか、Copilot Cloud AgentおよびCopilot Code Reviewについても約30分間、起動に失敗する状態が発生した。なお、GitHub Pagesで公開済みのサイト自体は、この間もアクセス可能な状態が維持されていた。 復旧までの対応 GitHubはインフラストラクチャ側の緩和措置に取り組みながら段階的な復旧を進め、最終的にモニタリングを通じて完全な回復を確認したと報告している。障害発生から復旧完了までの詳細な技術的原因については、公式ステータスページ上で個別の根本原因分析は示されていないが、GitHub Actionsのようにビルドやデプロイの中核を担うマネージドサービスで長時間の遅延が発生したことは、CI/CDを日常的に利用する多くの開発チームの作業に直接的な影響を与えたとみられる。

July 11, 2026