200-800倍
ClaudeによるAES(7ラウンド)攻撃の高速化
9.8
TeamCity未認証RCEのCVSSスコア
68.4%
DMARC未強制ドメインの割合(67,336件調査)
🔥 Top Stories
Anthropicは7月28日、自社モデル「Claude Mythos Preview」を使った暗号解読研究の成果を公開した。対象は2つの暗号系で、ひとつは耐量子暗号の候補方式HAWKに対する新しい鍵回復攻撃、もうひとつは10ラウンド版AES-128を7ラウンドに縮小した変種への攻撃である。HAWKでは60時間の計算とAPI利用料約10万ドルをかけ、HAWK-256の実効的な鍵強度を2^64から2^38相当まで引き下げる攻撃を発見した。ただしHAWKはまだ標準化前の候補方式であり、実運用に投入された暗号ではない。AES-7ラウンド攻撃では、Claudeがほぼ自律的に「メビウス橋」と呼ばれる指紋照合アルゴリズムを考案し、3日間で数億トークンを生成、人間からの実質的な指示はわずか3回のプロンプトにとどまった。攻撃速度は既知の最良手法に対して200倍から800倍向上したという。研究チームは学術機関と共同で、LLMの暗号解読能力を測る標準ベンチマーク「CryptanalysisBench」も開発した。人間の研究者2名がAES-7ラウンド攻撃の正しさを検証するのに約1カ月を要しており、AIが発見を加速する一方で検証コストは依然として重いことも示している。LEA(13ラウンド)やSerpent-128(6ラウンド)への実用的な攻撃も予備的に確認されており、Salsa20・Poseidon・SHA-1への適用は継続中とされる。
🧠 AES-7ラウンドへの200〜800倍という数字は明確だが、対象は10ラウンドの本番AES-128ではなく研究用の縮小版であり、直ちに実運用の暗号が破られるわけではない。それでも「メビウス橋」のような新手法をAIがほぼ自律的に考案した点は見過ごせない。一方でHAWKの鍵強度低下は候補方式内の話に留まり、標準化前に脆弱性が見つかったこと自体はむしろ健全な結果とも言える。検証に人間の研究者が1カ月を要した事実は、AIによる発見の速さと、それを裏付ける検証コストの非対称性を示している。
- HAWK-256への鍵回復攻撃で実効的な鍵強度を2^64から2^38相当へ低下、60時間・API費用約10万ドルで発見(HAWKは標準化前の候補方式)
- AES-7ラウンド変種への攻撃は「メビウス橋」指紋アルゴリズムにより既知最良手法比200〜800倍高速化、3日間・実質3プロンプトでほぼ自律的に発見
- 学術機関と共同でLLM暗号解読ベンチマーク「CryptanalysisBench」を開発、LEA(13ラウンド)・Serpent-128(6ラウンド)への攻撃も予備確認
💡 AI支援の暗号解読が実用速度に達しつつあるため、縮小ラウンド版で実証された手法が将来フルラウンドの実装や関連プリミティブに転用されないか、暗号設計者は継続的な監視が必要になる。
Anthropic
⏱ 7 min read
2026-07-28
Google CloudはAIエージェントがコードベースの脆弱性を自律的に検出し、サンドボックス内で実際にエクスプロイトを再現して実害を検証したうえで修正パッチまで生成する「CodeMender」のプレビューを公開した。対応言語はC/C++・Go・Java・Python・Ruby・Rust・TypeScriptの7つで、メモリ破壊やインジェクション、暗号実装の欠陥など静的解析ツールが見落としやすい問題を対象にする。生成した修正案は別のAI評価者が既存機能を壊していないか確認したうえで、開発者にはコードとしてレビュー用に提示される。CI/CDパイプラインやVS Code、CLIから呼び出せるほか、組織のコーディング規約に適応する設計になっている。
- C/C++・Go・Java・Python・Ruby・Rust・TypeScriptの7言語に対応、サンドボックスでエクスプロイトを実行し脆弱性の実害を検証してから修正を生成
- 生成した修正パッチは別のAI評価者が既存機能への影響をチェック、CI/CD・VS Code・CLI・Antigravityから呼び出し可能
- 組織のコーディング規約に適応する設計で、修正案は自動適用ではなく開発者レビュー用のdiffとして提示
💡 静的解析で見逃されがちな脆弱性をエージェントが自律的に検出・実害検証・修正まで行うため、CI導入すればレビュー前の一次フィルタとして開発フローに組み込める可能性がある。
Publickey
⏱ 3 min read
2026-07-28
JetBrainsは7月27日、TeamCity On-Premisesの全バージョンに影響する未認証のリモートコード実行脆弱性CVE-2026-63077を公開し修正版を提供した。原因はエージェントポーリングプロトコルにおける安全でないデシリアライズで、HTTP(S)でサーバーに到達できる攻撃者が認証を経ずに任意のOSコマンドを実行できる。CVSS v3.1のスコアは満点に近い9.8。研究者Antoni Tremblay氏が7月10日に非公開で報告し、責任ある開示の合意に基づき修正版公開後の7月27日にアドバイザリが公開された。2025.11.7と2026.1.3で修正済みで、アップグレードできない環境向けにセキュリティパッチプラグインも提供される。TeamCity Cloudの利用者は対応不要。
- エージェントポーリングプロトコルの安全でないデシリアライズが原因、認証不要でOSコマンドを実行可能、CVSS v3.1で9.8
- 2025.11.7・2026.1.3で修正、アップグレード不可の環境向けにセキュリティパッチプラグインを提供、TeamCity Cloudは対応不要
- 研究者Antoni Tremblay氏が7月10日に非公開で報告、責任ある開示の合意に基づき修正版公開後の7月27日にアドバイザリを公開
💡 TeamCity On-Premisesを運用している組織は、パッチ適用の可否にかかわらずエージェントポーリングのアクセスログを確認し、7月10日以降の不審なOSコマンド実行の痕跡がないか点検すべきだ。
JetBrains Blog
⏱ 3 min read
2026-07-27
⚡ Dev & Engineering
Zig開発者のmlugg氏は、インクリメンタルコンパイルの内部実装を解説する記事を公開した。ファイル単位でのZIRキャッシュ、変更の影響範囲だけを再解析する依存関係追跡、関数ごとに独立実行できるコード生成、バイナリを直接メモリマップして関数コードを再配置する`MappedFile`という4段階のパイプラインで構成される。コンパイラ自身のコードベースを対象にした計測では、初回ビルドが約5秒に対し、変更後の再ビルドは50〜70msに収まるという。
- ファイル単位のZIRキャッシュはコンパイラ全体で約920ms、依存関係追跡により変更の影響範囲だけを再解析
- `MappedFile`がバイナリを直接メモリマップし関数コードを再配置、Fizzyの再ビルドは初回約5秒から50〜70msへ短縮
mlugg.co.uk
⏱ 5 min read
2026-07-27
▲ 152
Pythonパッケージマネージャーuvの0.12.0が7月28日に公開された。`uv init`で作成するプロジェクトは既定でsrc/レイアウトと`uv_build`によるパッケージ構成になり、生スクリプト形式は使われなくなる。セキュリティ面では、Python.exeなど大文字小文字違いを含む実行ファイルを置き換えうるホイールや、bzip2・LZMAなど非対応の圧縮形式を拒否する。requirements.txtの`--require-hashes`指定も、これまでの警告表示から強制適用に変わった。
- `uv init`の既定構成がsrc/レイアウト+uv_buildのパッケージ形式に変更、生スクリプト形式から移行
- Python.exe等を置き換えうる悪意あるホイールを拒否、requirements.txtの`--require-hashes`は警告から強制適用へ
GitHub
⏱ 2 min read
2026-07-28
セキュリティ企業ciphercueは、67,336ドメインを調査しDMARCの強制設定率を分析した記事を公開した。DMARCは2012年から利用可能だが、68.4%のドメインがレコード未設定か強制力のない設定のままだった。内訳はレコード自体がない45.1%、監視のみのp=noneが23.3%、緩やかな強制のp=quarantineが15.2%で、完全強制のp=rejectは16.3%にとどまる。原因として、集約レポートに列挙される送信元IPやハッシュ化されたメールボックス名を「実在する正規の送信者」に突合する作業が後回しにされ続ける構造的な問題を指摘している。
- 67,336ドメイン調査で68.4%がDMARC未設定または非強制、レコード自体の欠如が45.1%を占める
- 強制力ゼロのp=noneが23.3%に対し完全強制のp=rejectは16.3%、集約レポートの送信元突合作業が移行の障壁と指摘
ciphercue.com
⏱ 4 min read
2026-07-28
著者はeBPFプログラムがカーネル空間の処理に与えるオーバーヘッドを定量的に測定する手順を解説する。`net.core.bpf_jit_kallsyms=1`を設定してperfにシンボル名を表示させ、ファイルオープン処理を繰り返すC製の計測ハーネスで`clock_gettime`によるベースラインを取得したうえで、`perf -g --call-graph fp -e cycles:k -F 997`によりカーネル空間のコールスタックを997Hzでサンプリングする。フレームグラフ化した結果、`bpf_lsm_file_open`内の`bpf_probe_read_kernel`呼び出しがボトルネックであることを特定できたという。
- `bpf_jit_enable`と`bpf_jit_kallsyms`を有効化しperfでシンボル名を解決、`-F 997`で周期パターンを避けたサンプリング
- フレームグラフ解析で`bpf_lsm_file_open`内の`bpf_probe_read_kernel`呼び出しがボトルネックと判明
naveensrinivasan.com
⏱ 4 min read
2026-07-22
▲ 99
KDEのファイル操作フレームワークKIOは、大量の小ファイルコピーが極端に遅いという2014年来の課題を抱えていた(300万ファイルのコピーにrsyncの20分に対し5〜10時間)。開発チームはワーカーを別プロセスからアプリ内スレッドへ移し、さらにスレッド・アプリ間のソケット通信をインメモリ転送に置き換えた。4KBファイル5,000個のコピーは、KIO 6.28.0の1,616msからソケット排除後の6.29-devで396ms、検討中のバッチコピー適用後は88msまで縮み、`cp -r`の81msにほぼ並んだ。
- 5,000ファイル(4KB)のコピーがKIO 6.28.0で1,616ms、ソケット通信をインメモリ転送に置き換えた6.29-devで396msに
- 検討中のバッチコピー機能を適用すると88msまで短縮、約18倍の高速化で`cp -r`の81msに匹敵
KDE Blogs
⏱ 3 min read
2026-07-28
▲ 13