2026/03/06 20:53

AnthropicのレッドチームによるFirefoxの強化 1. 背景と目的 * レッドチームは実際に起こり得る攻撃を模倣するセキュリティ研究グループです。 * 彼らの目標は、悪用される前にFirefox内の脆弱性を発見することです。 2. 手法 * ターゲットスキャン – 自動化ツールで既知の弱点をブラウザ上で検出します。 * マニュアルエクスプロイト – セキュリティ研究者が独自にカスタム攻撃コードを作成し、深部を調査します。 * レッドチーム演習 – 高度な敵対者が用いる戦術を模したシミュレーション攻撃です。 3. 主な発見点 * メモリ破壊バグ – use‑after‑freeやバッファオーバーフローなど複数の問題が検出されました。 * 権限昇格経路 – 悪意あるウェブページが高い権限を取得できる可能性があります。 * プライバシー漏洩 – クロスオリジンリクエストにより予期せぬデータが流出するケースです。 4. 実施した対策 * メモリ安全チェックの更新（例：AddressSanitizer、Control Flow Integrity）。 * プロセス間通信を制限するサンドボックス境界の強化。 * プライバシーコントロールの改善と同一オリジンポリシーの厳格化。 5. 継続的取り組み * レッドチームの調査結果をFirefoxリリースサイクルへ継続的に統合。 * Mozillaセキュリティチームと協力し、迅速なパッチ適用を実現。 * 責任ある開示ガイドラインに従い、重大脆弱性を公表。 6. 結論 * AnthropicのレッドチームはFirefoxのセキュリティ体制を強化する上で不可欠な役割を果たしています。 * 彼らの厳密なテストにより潜在的リスクが明らかになり、迅速な修正が行われることで最終ユーザーを高度脅威から保護できます。

RSS: https://news.ycombinator.com/rss

要約▶

日本語訳:

「Claude Opus 4.6 は、Mozilla の Firefox ブラウザにおける重大なセキュリティバグの発見と修正を非常に効果的に行い、同社が将来のセキュリティ研究で採用するようになったことを示しています。2 週間にわたる調査では、モデルは 22 の脆弱性を特定し、そのうち 14 は高重大度でした。ほとんどは Firefox 148.0 にて修正され、世界中の数億ユーザーに影響しました。最初の Use‑After‑Free バグは 20 分以内に発見され、Bugzilla に報告され、初期パッチ提案が提出されました。約 6,000 の C++ ファイル全体で Opus 4.6 は 112 件のユニークレポートを記録し、ほぼすべてが新しいリリースで解決されました。

エクスプロイトテスト（API クレジット約 4,000 ドル）は発見された脆弱性のうちわずか 2 件だけに成功しました。これは、テスト環境にサンドボックスなどの主要なブラウザ防御が欠如していたためです。結果は、AI が脆弱性検出を加速できることを示していますが、人間による検証と安全策が不可欠であることも明らかにしています。Mozilla の研究者たちは現在 Claude を社内で実験し、新しい言語モデルが検出とエクスプロイトのギャップを埋める方法を探っています。

Anthropic は「タスク・バリファイア」を推奨しており、AI エージェントの成果物が目標を達成したことを確認します。また、最小テストケース、概念実証（Proof‑of‑Concept）、候補パッチという三つの要素を強調し、メンテナが AI が生成したレポートを信頼できるようにしています。Claude Code Security は、脆弱性発見とパッチ作成機能を求める顧客やオープンソース保守者向けに限定的なリサーチプレビューとして利用可能です。将来のモデルが進化するにつれて、悪意ある乱用を防止しつつ、オープンソースエコシステム全体でより迅速なバグトリアージと高品質パッチを実現できるよう、より厳格な安全策が必要になります。」

本文

AIモデルは、複雑なソフトウェアにおける高重大度脆弱性を独立して検出できるようになりました。最近の報告では、Claudeがよくテストされたオープンソースソフトウェアで500件以上のゼロデイ脆弱性（ソフトウェアメンテナーに知られていないセキュリティ欠陥）を発見しました。本稿では、Mozilla研究者との協業事例を共有します。Claude Opus 4.6は2週間で22件の脆弱性を検出し、そのうち14件が高重大度として分類されました。これは2025年に修正された全Firefox高重大度脆弱性の約1/5に相当します。言い換えれば、AIは極めて高速で深刻なセキュリティ欠陥を検出できるようになっているということです。

月別に報告されたFirefoxのセキュリティ脆弱性（すべての情報源から）
Claude Opus 4.6は2026年2月に22件の脆弱性を発見し、2025年のいずれか一か月で報告された数を上回りました。

この協業の一環として、Mozillaは我々から多数のレポートを受け取り、どの種類の調査結果がバグ報告に値するかを理解する手助けを行いました。また、Firefox 148.0で何億ものユーザーへ修正パッチを配信しました。彼らとのパートナーシップと得た技術的教訓は、AI活用型セキュリティ研究者とメンテナーが協働してこの課題に対処するためのモデルとなります。

モデル評価からセキュリティ提携へ

2025年末、Opus 4.5がCyberGym（LLMが既知の脆弱性を再現できるかを測定するベンチマーク）でほぼ全タスクを解決しつつあることに気付きました。そこで、より難易度が高く実際的な評価セットを構築しようとしました。具体的には、モダンブラウザに見られるような技術的に複雑な脆弱性を多く含むデータセット―既存のFirefox共通脆弱性（CVE）―を作成し、Claudeがそれらを再現できるか試しました。

Firefoxを選んだ理由は、コードベースが非常に複雑であると同時に、世界でもっともテストされ安全性が高いオープンソースプロジェクトの一つだからです。これにより、従来使っていたオープンソースソフトウェアよりもAIが新規脆弱性を見つける難易度が上がります。何億ものユーザーが日常的に利用し、ブラウザ脆弱性は不正なコンテンツに頻繁に直面するため特に危険です。

最初のステップとして、Claudeに旧バージョンFirefoxコードベースで既に報告されたCVEを見つけさせました。Opus 4.6がこれら歴史的CVEを高い割合で再現できたことは驚きでした。しかし、これらのCVEがすでにClaudeの学習データに含まれていた可能性もあるため、信頼度は不明でした。

そこで、現在版Firefoxに対して新規脆弱性を探索させました。定義上、以前報告されていないバグです。まずJavaScriptエンジンに注目し、その後ブラウザの他領域へ拡大しました。JavaScriptエンジンはFirefoxコードベースから独立した部分で、単体で解析できる点が便利です。また、外部から不正なコードを処理するため攻撃面積が広く、安全性が重要です。

わずか20分の探索後、Claude Opus 4.6はJavaScriptエンジンにUse After Free（メモリ脆弱性で任意の悪質データを書き込める可能性）を報告しました。研究者の一人が最新Firefoxリリースを用いた仮想マシンでこのバグを検証し、さらにAnthropic内の別の研究者も同様に確認しました。その後、MozillaのIssue Tracker Bugzillaへ脆弱性と提案パッチ（Claude作成・報告チームが検証）を添えてバグレポートを提出しました。

この最初の脆弱性を検証し提出する間に、Claudeはさらに50件以上のクラッシュ入力を発見していました。これらのクラッシュを優先順位付け中にMozillaの研究者が連絡を取ってきました。技術的議論と手動で検証した追加脆弱性を共有した結果、全ての調査結果を一括提出するよう勧められました。確かにすべてのクラッシュテストケースがセキュリティ上意味を持つとは限りませんでしたが、Mozillaはそれらを取り扱うプロセスを透明化し、我々が実際に関心のあるケースのみ提出するよう調整しました。結果として、約6,000件のC++ファイルをスキャンし、112件のユニークレポート（高・中重大度脆弱性含む）を提出しました。ほとんどの問題はFirefox 148で修正され、残りは今後のリリースで対処予定です。

外部ソフトウェアでバグハンティングを行う際、コードベースに重要な要素を見落として偽陽性になるリスクを常に意識しています。自前で検証を試みるものの、エラーは避けられません。Mozillaがトリアージプロセスを透明化してくれたことと、我々が提出したテストケースのみを評価してくれた点には大変感謝しています。現在、Mozilla研究者は社内でClaudeをセキュリティ目的に活用し始めています。

脆弱性検出から簡易エクスプロイト生成へ

Claudeのサイバーセキュリティ能力の上限を測るため、新しい評価を作成しました。具体的には、発見した脆弱性を実際に悪用できるかどうかです。すなわち、ハッカーが使用するようなツールでこれらのバグを利用し、悪意あるコードを実行できるか確認します。

Mozillaへ提出した脆弱性情報をClaudeに与え、各脆弱性についてエクスプロイト作成を依頼しました。成功例としては、攻撃者がターゲットシステムでローカルファイルを読み書きできる実際の攻撃を示すよう求めました。

数百回にわたって異なる開始点からテストを行い、約$4,000相当のAPIクレジットを消費しました。結果としてOpus 4.6は2件だけで実際に脆弱性をエクスプロイトへ変換できました。これには次の二つの示唆があります。

Claudeはバグ発見が得意だが、悪用は苦手です。
脆弱性検出コストはエクスプロイト作成より10倍ほど低いです。

ただし、Claudeが自動で簡易ブラウザエクスプロイトを生成できたことは懸念材料です。

「簡易」という点に注意してください。Claudeが書いたエクスプロイトは、我々のテスト環境でのみ機能しました。この環境ではモダンブラウザに存在するセキュリティ機能（特にサンドボックス）が意図的に除去されていました。サンドボックスはこうした脆弱性の影響を軽減する目的があります。そのため、Firefoxの「防御層」設計がこれらのエクスプロイトを有効に抑制していたと考えられます。しかし、サンドボックスを突破できる脆弱性は無視できず、Claudeの攻撃はエンドツーエンドのエクスプロイト構築に必要な一要素です。

このFirefoxエクスプロイト作成事例については、Frontier Red Teamブログで詳細を公開しています。

AI活用型サイバーセキュリティの次なるステップ

AIがエクスプロイト開発へ進展する初期兆候は、防御側にとって「検出-修正」プロセスを加速させる重要性を示しています。そこで、分析中に得た技術的・手順上のベストプラクティスを共有します。

1. 「パッチ作成エージェント」を研究する際

LLMを用いてバグ修正案を生成・検証する「パッチ作成エージェント」に対し、メンテナーが迅速にセキュリティレポートを処理できるよう支援する手法をいくつか提案します。

Claudeは自身の出力を他ツールでチェックできると最も効果的です。この種のツールを「タスクバリファイヤー」と呼びます。
タスクバリファイヤーはコードベース探索中にリアルタイムでフィードバックを提供し、エージェントが繰り返し試行できるようにします。
良いパッチ作成エージェントは少なくとも二つの点を検証すべきです：①脆弱性が本当に除去されたか、②プログラムの意図した機能が保持されているか。

我々は「修正後に元のバグが再発しないか自動テスト」および「回帰を検出するテストスイート」を実装しました。メンテナー自身が自分のコードベース向けに最適なバリファイヤーを構築することが重要です。ポイントは、エージェントに両方の性質を確かめる信頼できる手段を与えることで、その出力品質が大幅に向上するという点です。

すべてのエージェント生成パッチが即時マージ可能である保証はありません。ただし、タスクバリファイヤーは「特定脆弱性を修正しつつ機能を保持」していることへの確信度を高めます。AI作成パッチのレビューに際しては、外部開発者が行う他パッチと同様の厳格さで検証することを推奨します。

2. バグ・パッチ提出プロセス全体への視点

メンテナーは常にタスクに追われています。したがって、我々は信頼できる情報を提供し、レポートの検証と再現性を保証するアプローチを取っています。Firefoxチームは以下の三要素が信頼構築に不可欠であると指摘しました。

最小テストケース（実際に脆弱性を引き起こすコード）
詳細な概念証明（脆弱性メカニズムの説明）
候補パッチ

LLM駆動型脆弱性調査ツールを使用する研究者は、出力に対して同様の検証・再現性証拠を添えて報告することが強く推奨されます。

また、我々は「協調的脆弱性開示」運営原則を公開し、メンテナーと協働する際の手順を明記しています。現時点では業界標準に従っていますが、モデル性能向上に伴いプロセスを適宜更新していく予定です。

今こそ行動すべき理由

Frontier言語モデルは現在、世界クラスの脆弱性調査者となっています。22件のCVE発見だけでなく、Linuxカーネルなど重要プロジェクトでも脆弱性を検出しています。今後数週間・数か月にわたり、我々がモデルを活用しオープンソースコミュニティと協力してセキュリティ向上に取り組む姿勢を報告し続けます。

Opus 4.6は脆弱性検出・修正においてエクスプロイトより圧倒的に優れています。これは防御側の有利な状況です。また、Claude Code Security（限定研究プレビュー）のリリースで、顧客とオープンソースメンテナーへ直接脆弱性発見・パッチ機能を提供しています。

しかし進捗速度を見る限り、フロンティアモデルの脆弱性検出とエクスプロイト能力のギャップは長く続かない可能性があります。将来の言語モデルがこの障壁を突破した際には、悪意ある利用者による不正活用防止のため追加の安全策や対策を検討する必要があります。

開発者の皆様へ：ソフトウェアをより安全にする努力を加速させる絶好の機会です。私たちはサイバーセキュリティ活動を大幅に拡充し、以下の取り組みを計画しています。

CVDプロセス（上記で述べた手順）に沿った脆弱性探索
メンテナーがバグレポートを優先順位付けできるツール開発
AI時代に適したCVDフローの提案と実装

もし、オープンソースソフトウェアで脆弱性検出用スキャフォールド作成・トリアージ・パッチ提出・AI世代向け堅牢なCVDプロセス構築にご興味があるなら、Anthropicの求人情報（リンク）から応募してください。

同じ日のほかのニュース

一覧に戻る →

2026/03/07 6:52

「このCSSは、私が人間であることを証明します。」

## Japanese Translation: （以下に翻訳文を記載します） **著者は、選択的な大文字化、CSS を用いた対象的なケース変換（`text-transform: lowercase`）、慎重に使われる em ダッシュなどの微妙なタイポグラフィック・選択が、ファイルを `tr` でパイプするような鈍い自動化手法よりも優れていると主張しています。大文字化は「最初の傷」として描かれますが、実際には予想ほど痛みを伴わず、必要に応じて単語が大文字で流れ出します。著者は粗末な `cat post.md | tr A‑Z a‑z | sponge post.md` の手法を却下し、よりクリーンな効果を持つ CSS を推奨しています。 em ダッシュは貴重とされますが、作家の真実の自分を露呈させないように隠したままである必要があります。モノスペースフォントはテキストの美学を損なうため拒否されています。小さなスクリプト（`uv run rewrite_font.py`）は文字形態を微調整するための取るべき手段として強調され、意図的に単語を誤字すること（例： “their/there”、 “its/it’s”）がスタイルの一部であると述べられていますが、“Definately?” のような問題のあるペアは避けるとしています。作家はノーリグ・コーパスを参照し、単語選択を導くとともに、ターゲットとなる単語から「u」を迅速に除去することで手法の精密さを示しています。全体的なトーンは、書くことが外見だけでなく思考・推論・関与を反映するものであると強調しています。以前の拒否（“No. Not today.”）はスタイリスティックオーバーホールへの抵抗を示しています。次に計画されている変更は、作家自身の自我感覚を変える唯一の真に重要なステップとして描かれています。技術的読者――特に文書スタイリング、フォント操作、編集ワークフローに関わる人々――に対して、このメッセージは自動変換から離れ、意図的なタイポグラフィック決定へ移行することを奨励し、デザイン標準や編集実務の再構築につながり得ると述べています。

2026/03/07 7:55

**C# の文字列が Dapper で SQL Server インデックスを静かに破壊する理由** Dapper を使って SQL Server データベースへクエリを投げる際、文字列結合や文字列補間（string interpolation）でクエリを作成することはよくあります。しかし、この一見無害な手法がインデックスの性能を黙って破壊してしまうケースがあります。 --- ## なぜ起きるのか 1. **暗黙の型変換** `string` と `int`・`bool` など非文字列型を結合すると、SQL Server は列値を `nvarchar` に変換せざるを得ません。 2. **インデックス回避** この暗黙変換により最適化器は既存の数値や日付インデックスを利用できず、フルテーブルスキャンが発生します。 --- ## 問題を引き起こす典型的なパターン | パターン | 何をしているか | インデックスへの影響 | |---------|-----------------|----------------------| | `WHERE Id = " + id`（文字列結合） | `Id` 列を `nvarchar` に変換 | フルスキャン | | `$"SELECT * FROM Users WHERE IsActive = {isActive}"`（補間） | ブール値も同様に `nvarchar` へ変換 | フルスキャン | | `WHERE CreatedDate >= @date.ToString()` | 日付を文字列へ変換 | インデックスが失われる | --- ## 修正方法 1. **インライン値ではなくパラメータを使用する** ```csharp var sql = "SELECT * FROM Users WHERE Id = @Id"; connection.Query<User>(sql, new { Id = id }); ``` 2. **型の一貫性を保つ** 列が期待する正確な型（`int`、`DateTime` など）で渡す。 3. **C# で暗黙変換を避ける** 必要なら明示的にキャストまたは変換し、安全かつ意図した変換のみ行う。 --- ## 簡易チェックリスト - [ ] Dapper に渡す値は文字列化せず、型付きである。 - [ ] 変数データと SQL フラグメントのインライン結合を行わない。 - [ ] すべてのクエリに `@ParameterName` プレースホルダーを使用する。これらのガイドラインに従えば、インデックスの整合性を保ちつつクエリを高速かつ効率的に維持できます。

## Japanese Translation: **概要:** .NET/Dapper アプリケーションでは、C# の文字列を `nvarchar(4000)` として渡すと、SQL Server が `varchar` 列に対して暗黙の型変換（implicit conversions）を実行します。これにより、インデックス検索がスキャンに置き換わり、論理読み取り数が単桁から数万に膨らみ、CPU/I/O の使用率が急増します（例：`CONVERT_IMPLICIT(nvarchar(255), [Sales].[ProductCode], 0)`）。正確性には影響しませんが、実行計画や Query Store の警告で明らかになります。特に `SQL_Latin1_General_CP1_CI_AS` などの照合順序では顕著です。 **修正:** パラメータを ANSI として明示的に宣言し、列サイズと一致させます。 ```csharp var p = new DynamicParameters(); p.Add("productCode", productCode, DbType.AnsiString, size: 100); await conn.QueryFirstOrDefaultAsync<Product>(sql, p); ``` または匿名オブジェクトを使用する場合： ```csharp new { productCode = new DbString { Value = productCode, IsAnsi = true, Length = 100 } } ``` スキーマ変更、インデックス更新、クエリ書き換えは不要です。パフォーマンスの改善は即座に実感できます。 **監査ヒント:** Query Store で `@nvarchar(4000)` を検索し、varchar 列へ文字列を渡す匿名オブジェクトをコード内でスキャンしてください。 **ベストプラクティス:** 将来のリグレッション防止のために、`DbType.AnsiString`（または `IsAnsi = true`）を使用した理由をコメントしておくことが推奨されます。この簡単な調整でサーバー負荷を低減し、コスト削減とスケールアップが実現します。結果として開発者・ユーザー・広範な .NET/SQL Server コミュニティ全体に恩恵をもたらします。

2026/03/07 6:19

**IPリースの陰影ある世界**

## Japanese Translation: IPリースは、誰もがクリーンで匿名のIPv4アドレスを取得し、ジオロケーションデータを操作できる隠密レンタル市場を生み出しており、IPベースの評判システムの信頼性を損なっています。ブロックを保有し、標準的な地域インターネットレジストリ（RIR）手順外でサブリースすることで、これらのサービスはWHOISトレーサビリティとRIRアカウンタビリティチェーンを迂回します。リース会社は料金を払ってブラックリスト化された範囲を「クリーン」し、ドロップダウンまたはCSVアップロードで任意の住宅または商業ジオロケーションを割り当て、WHOIS国フィールドまで操作することができ、MaxMind、Cloudflare、Googleなどに偽情報を供給します。主要なVPNおよびプロキシプロバイダー（例：NordVPN、ExpressVPN、CyberGhost、PIA）は、LogicWeb、IPXO、INIZ、IPFoxi、Heficed、AnyIP/IPv4Deals などのリース会社からIPを調達しています。これらのプラットフォームは多くの場合、同じサイトで生IPスペースと完全なプロキシサブスクリプションの両方を販売し、エンドツーエンドの匿名化パイプラインを構築します。一部のプロバイダーは住宅ISPと直接提携してトラフィックを実際の加入者ネットワーク経由でルーティングし、合法的なオペレーターとプロキシとの境界を曖昧にしています。業界は法的グレイズゾーンで運営されており—IPリースやジオロケーション操作を明示的に禁じる法律がないため—実効性の低い執行とインセンティブの不整合が生じています。リースが拡大するにつれて、インターネットセキュリティの基盤であるIP評判リスト、WHOIS帰属、およびジオロケーションデータベースはさらに侵食され、大規模な位置・所有権・評判の偽装が可能になります。これはユーザー（ボット検出やレート制限での誤検知）とIPベースのセキュリティ決定に依存する企業を脅かし、最終的にはインターネット全体の説明責任と安全性を弱めます。