<?xml version="1.0" encoding="utf-8" standalone="yes"?><rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom"><channel><title>AerynOS on 思いつきそうで思いつかなくていたときに</title><link>https://blog.fuga.jp/tags/aerynos/</link><description>Recent content in AerynOS on 思いつきそうで思いつかなくていたときに</description><generator>Hugo -- gohugo.io</generator><language>ja</language><copyright>Copyright(c) 2022-2025 SATO Daisuke. All rights reserved.</copyright><lastBuildDate>Tue, 07 Jul 2026 00:00:00 +0900</lastBuildDate><atom:link href="https://blog.fuga.jp/tags/aerynos/index.xml" rel="self" type="application/rss+xml"/><item><title>「隠して起爆」するAIスキルの罠と、OpenSSH・FreeRDP一斉パッチ――信頼していた境界を検算する日</title><link>https://blog.fuga.jp/posts/2026-07-07-linux-oss-trend/</link><pubDate>Tue, 07 Jul 2026 00:00:00 +0900</pubDate><guid>https://blog.fuga.jp/posts/2026-07-07-linux-oss-trend/</guid><description>&lt;h2 id="はじめに">&lt;a href="#%e3%81%af%e3%81%98%e3%82%81%e3%81%ab" class="header-anchor">&lt;/a>はじめに
&lt;/h2>&lt;p>AIエージェントに「スキル」を追加して能力を拡張する運用、もうすっかり当たり前になりましたよね。私も便利だからと言われるまま入れがちなんですが、正直、その中身をちゃんと読んだことがあるかと聞かれると、ちょっと自信がありません。今回はそんな痛いところを突いてくる新攻撃「SkillCloak」から、ほぼ全Linuxサーバに影響するOpenSSHの緊急パッチまで、2026年7月7日前後に飛び込んできた5本のニュースをまとめて解説します。動画はこちらです。&lt;/p>
&lt;p>&lt;a class="link" href="https://www.youtube.com/watch?v=A7Gg9pMzaBk" target="_blank" rel="noopener"
>https://www.youtube.com/watch?v=A7Gg9pMzaBk&lt;/a>&lt;/p>
&lt;p>並べてみると、実はきれいに一本の軸が通っていました。AIコーディングエージェントの「スキル」という新しい信頼境界、カーネルのヘッダーという内部の依存境界、ディストリビューションのリポジトリという配布の境界、そしてRDPやSSHという通信の境界。全部、「境界」の話です。信頼して手を離していた場所を、今日はひとつずつ検算していきます。&lt;/p>
&lt;h2 id="1-skillcloakaiコーディングエージェントを狙う隠して起爆する攻撃">&lt;a href="#1-skillcloakai%e3%82%b3%e3%83%bc%e3%83%87%e3%82%a3%e3%83%b3%e3%82%b0%e3%82%a8%e3%83%bc%e3%82%b8%e3%82%a7%e3%83%b3%e3%83%88%e3%82%92%e7%8b%99%e3%81%86%e9%9a%a0%e3%81%97%e3%81%a6%e8%b5%b7%e7%88%86%e3%81%99%e3%82%8b%e6%94%bb%e6%92%83" class="header-anchor">&lt;/a>1. SkillCloak――AIコーディングエージェントを狙う「隠して起爆する」攻撃
&lt;/h2>&lt;p>まず一発目から重い話です。香港科技大学（HKUST）の研究チームが2026年7月2日にarXivで公開した論文「Cloak and Detonate」が、AIコーディングエージェント向けのスキルマーケットプレイスを悪用する新攻撃フレームワーク「SkillCloak」を提案しました。8種類の静的スキャナーを90〜99%の確率で素通りさせ、Claude CodeやOpenAI Codexといった実プロダクション環境で資格情報の窃取やバックドア設置まで実証してしまった、という研究です。数字だけ見ても正直ぞっとします。&lt;/p>
&lt;p>そもそもこの攻撃が刺さる土壌は、この数か月ですでに整っていました。Bitdefender Labsは2026年2月、スキル配布プラットフォーム「ClawHub」で公開されているスキルの約17%が悪性ペイロードを含むと報告しています。6件に1件が地雷という比率、くじ引きにしてはあまりに分が悪すぎます。Koi Securityは「ClawHavoc」と命名した単一キャンペーンだけで824件の悪性スキルを確認しました。&lt;/p>
&lt;p>SkillCloakの手口は二系統あります。一つ目は &lt;strong>Structural Obfuscation（構造的難読化）&lt;/strong> です。Unicodeのホモグリフ（見た目がそっくりな別文字）でトークンを書き換えたり、&lt;code>curl&lt;/code> を &lt;code>wget -qO-&lt;/code> に置き換える等価変換をしたりして、意味は変えずに見た目だけ変える。これだけでほとんどのスキャナーを80%以上バイパスできてしまいます。&lt;/p>
&lt;p>二つ目、これが核心技術ですが、 &lt;strong>Self-Extracting Skill（SFS）Packing&lt;/strong> です。元のスキルをXORで暗号化し、スキャナーが見に行かない &lt;code>.git/&lt;/code> などの「死角」ディレクトリに埋め込んでおく。ユーザーの目に触れる &lt;code>SKILL.md&lt;/code> は、デコーダーを呼び出すだけの一見無害なカバーファイルにすり替えておき、エージェントが実行時にそのデコーダーを走らせた瞬間、暗号化されていた悪性ペイロードが復元・展開される――という二段構えです。このSFSパッキングは全8スキャナーで90%以上、3つのスキャナーに至っては99.9%のバイパス率を記録しました。極めつけはCiscoの商用ハイブリッドスキャナーで、難読化前は98.6%だった検出率が、SkillCloak適用後は10.1%まで崩壊しています。「商用の高性能スキャナーがこれなら、自分の環境なんてもっと簡単に抜けるのでは」と思うと、ちょっと夜眠れなくなる話です。&lt;/p>
&lt;p>もっとも研究チームは攻撃だけでなく、防御ツール &lt;strong>SKILLDETONATE&lt;/strong> も同時に提示しました。静的スキャンを諦め、eBPFでシステムコールをトレースし、実行時の振る舞いを監視するアプローチです。制御実験では検出率97%・誤検知率2%を達成しています。攻撃と防御を同じ論文でセットで出してくれる律儀さ、個人的には結構好きです。&lt;/p>
&lt;p>対応方針としては、外部スキルマーケットプレイスからのインストールを原則禁止し、組織内で審査済みのスキルだけを許可するホワイトリスト運用が最優先です。Claude Codeなら &lt;code>.claude/settings.json&lt;/code> の &lt;code>permissions&lt;/code> セクションで &lt;code>Deny Bash(*)&lt;/code> を明示指定し、&lt;code>bypassPermissions&lt;/code> モードは無効化しておくこと。スキャナー側も &lt;code>.git/&lt;/code> や &lt;code>build/&lt;/code> といった隠しディレクトリをスキャン対象に含めるよう見直す必要があります。&lt;/p>
&lt;h2 id="2-linux-72-rc23000行超のヘッダーを割りrisc-vは256コア対応へ">&lt;a href="#2-linux-72-rc23000%e8%a1%8c%e8%b6%85%e3%81%ae%e3%83%98%e3%83%83%e3%83%80%e3%83%bc%e3%82%92%e5%89%b2%e3%82%8arisc-v%e3%81%af256%e3%82%b3%e3%82%a2%e5%af%be%e5%bf%9c%e3%81%b8" class="header-anchor">&lt;/a>2. Linux 7.2-rc2――3,000行超のヘッダーを割り、RISC-Vは256コア対応へ
&lt;/h2>&lt;p>続いては、地に足のついたカーネルの話です。Linus Torvaldsが2026年7月5日にLinux 7.2-rc2を公開しました。本人は「非常に普通のrc2」と評していますが、中身には開発者にとって嬉しい変更が3つ入っています。&lt;/p>
&lt;p>一つ目は、&lt;code>include/linux/mod_devicetable.h&lt;/code> という、USB・PCI・I2C・SPI・ACPIなどカーネル全サブシステムのデバイスID構造体を詰め込んだ3,000行超のモノリシックなヘッダーの大分割です。Uwe Kleine-Königによる1,500超のパッチで、&lt;code>include/linux/device-id/&lt;/code> という専用ディレクトリ配下にサブシステム別のヘッダーへ再編され、元のヘッダーから約1,526行が削除されました。これまでは一箇所いじると無関係なサブシステムまで巻き添えでフルリビルドが走っていたので、日常的にカーネルをビルドする組み込みメーカーやディストリビューションにとって嬉しい変更です。地味ですが、こういう「一枚岩を割る」系の改善、私はわりと偏愛しています。&lt;/p>
&lt;p>二つ目は、RISC-V 64ビットのデフォルトCPU上限が64から256コアへ引き上げられたこと。要請したのは中国のRISC-Vチップ設計企業SpacemiTで、RVA23プロファイル準拠のサーバー向けチップを80コア構成で製造したことが直接の契機です。Sophgoのデュアルソケット構成「Pisces」サーバーはすでに128コアに到達しており、RISC-Vエコシステム全体では最大1,024コアのラックサーバーまで登場しています。x86やArmの後追いというイメージがまだ残るRISC-Vですが、コア数のスケールという点ではもうデータセンター級の議論をする段階に来ているんですね。&lt;/p>
&lt;p>三つ目はセキュリティハードニングです。IntelのPawan Guptaによるパッチが、BPF JITコンパイラに対するスプレー攻撃（JIT Spray Attack）への耐性を強化しました。Spectre-v2緩和策が有効な環境で、BPF JITメモリを再利用する際にIBPB（Indirect Branch Predictor Barrier）フラッシュを発行するよう変更されています。正式リリースは8月末から9月初旬の見込みです。&lt;/p>
&lt;h2 id="3-aerynos一度入れたらあとは永遠に更新される自律更新モデル">&lt;a href="#3-aerynos%e4%b8%80%e5%ba%a6%e5%85%a5%e3%82%8c%e3%81%9f%e3%82%89%e3%81%82%e3%81%a8%e3%81%af%e6%b0%b8%e9%81%a0%e3%81%ab%e6%9b%b4%e6%96%b0%e3%81%95%e3%82%8c%e3%82%8b%e8%87%aa%e5%be%8b%e6%9b%b4%e6%96%b0%e3%83%a2%e3%83%87%e3%83%ab" class="header-anchor">&lt;/a>3. AerynOS――「一度入れたら、あとは永遠に更新される」自律更新モデル
&lt;/h2>&lt;p>ここが今日一番地味なトピックです。でも私はこういう話が大好きなので、少しだけ腰を据えて語らせてください。独立系Linuxディストリビューション「AerynOS」が2026年7月のメジャーアップデートを配布しました。目玉は「Versioned Repositories Phase 2」で、OSアップグレード時のパッケージ整合性を人間の介入なしに自律管理できる基盤が整いました。あわせてKDE Plasma 6.7.2、COSMIC 1.2、Linuxカーネル7.1、Rust 1.96なども更新されています。&lt;/p>
&lt;p>根幹を支えるパッケージマネージャー「moss」は「状態（state）」を単位とするアトミック更新システムで、ファイルはxxhashでコンテンツアドレッサブルに管理され、zstd圧縮による重複排除でストレージ消費を最小化します。最大の特徴は、&lt;code>renameat2&lt;/code> システムコールを使った &lt;code>/usr&lt;/code> ディレクトリのアトミックな切り替え――新しい状態を裏で組み立てておき、最後に一瞬でディレクトリを差し替えるので、途中で電源が落ちても中途半端な状態になりません。&lt;/p>
&lt;p>Phase 2の本質は、moss自身が破壊的なon-diskフォーマット変更を経由してもなお、人間の介入なしに自動更新できる仕組みを定義したことです。アップグレード時には &lt;code>sudo moss sync -u&lt;/code> を2回実行する必要があり、1回目でリポジトリ設定・メタデータが新形式に更新され、2回目で更新済みのストリームから実際の新パッケージ群が取得・適用されます。「なんで2回も」と最初は思いましたが、メタデータの更新と本体の更新を分けていると聞くと妙に腑に落ちました。&lt;/p>
&lt;p>なお、AerynOSのコードベースの96.9%はRustで書かれており（ライセンスはMPL-2.0、1,567コミット以上）、プロジェクトは2026年4月にLLMコントリビューション禁止ポリシーを公式化しました。創設者のIkey Doherty氏が2025年4月に健康問題と財政難で離脱した後も、共同創設者のRune Morling氏（ermo）が引き継ぎ、チーム全員一致で継続を決議した経緯があります。少人数のOSSプロジェクトがこうやって続いていくの、素直に応援したくなります。現行ユーザーはアップグレード時にネットワークインターフェース名が変わる可能性がある点に注意してください。&lt;/p>
&lt;h2 id="4-freerdp-3283件のcveとghsa5件計8件のセキュリティ修正">&lt;a href="#4-freerdp-3283%e4%bb%b6%e3%81%aecve%e3%81%a8ghsa5%e4%bb%b6%e8%a8%888%e4%bb%b6%e3%81%ae%e3%82%bb%e3%82%ad%e3%83%a5%e3%83%aa%e3%83%86%e3%82%a3%e4%bf%ae%e6%ad%a3" class="header-anchor">&lt;/a>4. FreeRDP 3.28――3件のCVEとGHSA5件、計8件のセキュリティ修正
&lt;/h2>&lt;p>オープンソースのRDP実装FreeRDPが2026年7月6日にバージョン3.28.0をリリースしました。CVE-2026-57156（ヒープオーバーフロー）、CVE-2026-57157（境界外読み取り）、CVE-2026-57158（境界外読み取り）の3件のCVEに加え、CVE番号なしのGHSA5件を含む、計8件のセキュリティ修正を適用しています。8件とまとめて来られると、正直それだけで身構えてしまいますね。&lt;/p>
&lt;p>CVE-2026-57156は、Orders Delta Pointsパーサーの整数オーバーフローで、32ビットビルドの &lt;code>calloc&lt;/code> 呼び出しでサイズ検証が欠けていたことによるヒープオーバーフローです。影響はFreeRDP 3.27.1以前の32ビットビルド限定。CVE-2026-57157はMS-RDPECAMチャンネル（カメラリダイレクション）の境界外読み取りで、CVSSスコアは6.5（Medium）。CVE-2026-57158はGFXパイプラインの問題で、以前のCVE-2026-23530の修正が不完全だったことが判明したものです。直したはずの穴がまだ空いていた、というのはちょっと切ないですが、回帰テストの大事さを教えてくれる話でもあります。&lt;/p>
&lt;p>CVE番号なしのGHSA5件のうち4件は、AnthropicとAda Logicsが連携するOSSセキュリティ監査組織「Claude and Ada Logics」が90日間の協調開示プロセスに則って報告しました。特に興味深いのがGHSA-rq8f-9xjh-pr3mで、&lt;code>.rdp&lt;/code> ファイル内の &lt;code>/&lt;/code> で始まる行が未文書のCLIオプションとして全オプション面を公開してしまう引数インジェクション問題です。悪用されると &lt;code>/cert:ignore&lt;/code>（TLS証明書検証の無効化）や &lt;code>/rdp2tcp:&amp;lt;コマンド&amp;gt;&lt;/code>（認証前のプロセス実行）が仕込めました。「ただの設定ファイル」だと思っていたものが実は実行の入り口だった、というのは、1本目のSkillCloakとまったく同じ構図で、地味に怖いです。&lt;/p>
&lt;p>セキュリティ以外では、長年停滞していたiOSクライアント「iFreeRDP」が新規コントリビュータの貢献で復活しています。こういう復活劇、素直に嬉しいですよね。FreeRDPはRemmina・xrdp・Guacamileといった著名プロジェクトのバックエンドに採用されているため、影響範囲は広く、Red Hat Enterprise Linux 8向けにはRHSA-2026:6918が発行済みです。&lt;code>.rdp&lt;/code> ファイルを外部から受け取った場合は、ダブルクリックする前にテキストエディタで中身を確認する習慣をつけましょう。&lt;/p>
&lt;h2 id="5-openssh-104use-after-freeディレクトリトラバーサル認証前dosなど計7件を修正">&lt;a href="#5-openssh-104use-after-free%e3%83%87%e3%82%a3%e3%83%ac%e3%82%af%e3%83%88%e3%83%aa%e3%83%88%e3%83%a9%e3%83%90%e3%83%bc%e3%82%b5%e3%83%ab%e8%aa%8d%e8%a8%bc%e5%89%8ddos%e3%81%aa%e3%81%a9%e8%a8%887%e4%bb%b6%e3%82%92%e4%bf%ae%e6%ad%a3" class="header-anchor">&lt;/a>5. OpenSSH 10.4――use-after-free・ディレクトリトラバーサル・認証前DoSなど計7件を修正
&lt;/h2>&lt;p>締めは、影響範囲という点で今日の最重量級、OpenSSH 10.4です。2026年7月6日に公開されました。クライアント側のuse-after-free、SFTP/SCPを経由したディレクトリトラバーサル系の脆弱性、GSSAPI有効時の認証前DoSなど、計7件のセキュリティ修正を含みます。正直、OpenSSHの7件、まとめて来られるとこれもまた身構えます。&lt;/p>
&lt;p>7件の内訳は以下の通りです。①&lt;code>ssh&lt;/code> クライアントの鍵再交換時にサーバがホスト鍵を変更するとuse-after-freeが発生する問題。②SFTPダウンロード時に悪意あるサーバが応答パケットを細工し、意図しないパスへファイルを書き込ませられる問題。③SCPリモート間コピーで、悪意あるサーバが宛先の親ディレクトリへファイルを書き込める問題。④&lt;code>sshd&lt;/code> の組み込みSFTPサーバで、長いコマンドラインの9番目以降の引数が黙って切り捨てられ、&lt;code>ChrootDirectory&lt;/code> や &lt;code>AllowUsers&lt;/code> などのセキュリティオプションが無視される問題（報告者はSteve Caffrey氏）。これ、設定したつもりの隔離が実は効いていなかったという話で、地味に一番背筋が凍りました。⑤&lt;code>DisableForwarding yes&lt;/code> を設定していても &lt;code>PermitTunnel yes&lt;/code> が優先されてしまう不整合。⑥GSSAPI認証前DoS（CVE-2026-55654、CVSSv3.1スコア3.7）。⑦ブルートフォース対策の最小認証遅延が特定条件下で適用されない問題（報告者はOrange Cyberdefense Vulnerability Team）。&lt;/p>
&lt;p>修正だけでなく前向きな機能追加もあります。ML-DSA 44とEd25519を組み合わせた複合署名方式 &lt;code>mldsa44-ed25519-sha512&lt;/code> が実験的に追加され、ポスト量子暗号への現実的な橋渡しになっています。またワイルドカードマッチャーがNFAベースの実装に置き換えられ、ReDoS類似の性能問題が根本解決されました。&lt;/p>
&lt;p>OpenSSHは事実上すべてのLinuxサーバに載っているソフトウェアなので、即時アップデートが強く推奨されます。Debian/Ubuntuなら &lt;code>sudo apt update &amp;amp;&amp;amp; sudo apt upgrade openssh-server openssh-client&lt;/code>、RHEL/Rocky Linuxなら &lt;code>sudo dnf upgrade openssh&lt;/code>、Arch Linuxなら &lt;code>sudo pacman -Syu openssh&lt;/code> でアップデートできます。GSSAPI/Kerberosを使っていない環境なら、&lt;code>sshd_config&lt;/code> に &lt;code>GSSAPIAuthentication no&lt;/code> を設定しておくのも有効です。この記事を読み終えたら、まず手元のサーバで &lt;code>ssh -V&lt;/code> を打ってみてください。&lt;/p>
&lt;h2 id="まとめ">&lt;a href="#%e3%81%be%e3%81%a8%e3%82%81" class="header-anchor">&lt;/a>まとめ
&lt;/h2>&lt;p>今日の5つのトピックを貫いていたのは「信頼境界の再検算」という一本の軸でした。SkillCloakはAIエージェントの「スキル」という新しい信頼境界の裏側に暗号化ペイロードが仕込めることを、OpenSSHは最も信頼されてきたSSHにおいてすら「サーバを信じたクライアント」「設定を信じた管理者」という前提が崩れうることを、それぞれ示しました。まずはOpenSSHとFreeRDPを今すぐアップデートし、AIエージェントを使うなら外部スキルはホワイトリスト運用にしておく。皆さんは、普段使っているスキルやツールの中身、どこまで信頼して手を離していますか。今日ひとつでいいので、検算してみませんか。&lt;/p></description></item></channel></rss>