<?xml version="1.0" encoding="utf-8" standalone="yes"?><rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom"><channel><title>サプライチェーン on 思いつきそうで思いつかなくていたときに</title><link>https://blog.fuga.jp/tags/%E3%82%B5%E3%83%97%E3%83%A9%E3%82%A4%E3%83%81%E3%82%A7%E3%83%BC%E3%83%B3/</link><description>Recent content in サプライチェーン on 思いつきそうで思いつかなくていたときに</description><generator>Hugo -- gohugo.io</generator><language>ja</language><copyright>Copyright(c) 2022-2025 SATO Daisuke. All rights reserved.</copyright><lastBuildDate>Mon, 22 Jun 2026 07:15:00 +0900</lastBuildDate><atom:link href="https://blog.fuga.jp/tags/%E3%82%B5%E3%83%97%E3%83%A9%E3%82%A4%E3%83%81%E3%82%A7%E3%83%BC%E3%83%B3/index.xml" rel="self" type="application/rss+xml"/><item><title>メモリの境界を守れ——NGINX・Linux・npm で同時進行する「土台の作り直し」（2026年6月22日）</title><link>https://blog.fuga.jp/posts/2026-06-22-memory-boundary-nginx-linux-npm/</link><pubDate>Mon, 22 Jun 2026 07:15:00 +0900</pubDate><guid>https://blog.fuga.jp/posts/2026-06-22-memory-boundary-nginx-linux-npm/</guid><description>&lt;p>こんにちは！コンテンツ制作部のライターです。&lt;/p>
&lt;p>今日のテーマを一言で言うと &lt;strong>「メモリの境界を守る戦いは、エッジのサーバーから足元のカーネル、npm パッケージまで、同時進行している」&lt;/strong> です。&lt;/p>
&lt;p>NGINX にクリティカルな脆弱性、KDE Plasma のメジャーアップデート、Linux カーネルから危険な C 関数の根絶、Epic Games の新 VCS 公開、そして北朝鮮系ハッカーによる npm サプライチェーン攻撃——5本立てでお届けします。&lt;/p>
&lt;div class="video-wrapper">
&lt;iframe loading="lazy"
src="https://www.youtube.com/embed/DvqW6f5MSfw"
allowfullscreen
title="YouTube Video"
>
&lt;/iframe>
&lt;/div>
&lt;hr>
&lt;h2 id="1-nginx-cve-2026-42530--http3-quic-の-use-after-free-が招くクリティカル-rce">&lt;a href="#1-nginx-cve-2026-42530--http3-quic-%e3%81%ae-use-after-free-%e3%81%8c%e6%8b%9b%e3%81%8f%e3%82%af%e3%83%aa%e3%83%86%e3%82%a3%e3%82%ab%e3%83%ab-rce" class="header-anchor">&lt;/a>1. NGINX CVE-2026-42530 — HTTP/3 QUIC の use-after-free が招くクリティカル RCE
&lt;/h2>&lt;h3 id="概要">&lt;a href="#%e6%a6%82%e8%a6%81" class="header-anchor">&lt;/a>概要
&lt;/h3>&lt;p>世界の Web サーバー市場で約 &lt;strong>31.9%&lt;/strong> のシェアを握る &lt;strong>NGINX&lt;/strong> に、HTTP/3 QUIC 実装を起点とするクリティカルな脆弱性 &lt;strong>CVE-2026-42530&lt;/strong> が発見された。開発元の F5 が 2026 年 6 月 17 日にアウトオブバンド（定例外）のセキュリティ通知を出し、同日に修正版 &lt;strong>NGINX 1.31.2&lt;/strong> をリリースしている。CVSS v4.0 スコアは &lt;strong>9.2（Critical）&lt;/strong> 、v3.1 では 8.1（High）だ。&lt;/p>
&lt;p>一言でいうと、HTTP/3 のヘッダ圧縮処理に潜む &lt;strong>use-after-free（解放済みメモリの再利用）&lt;/strong> バグだ。未認証のリモート攻撃者が、細工した QPACK エンコーダストリームを送り込むことで NGINX のワーカープロセスをクラッシュさせ（DoS）、条件が揃えばリモートコード実行（RCE）にまで発展しうる。「未認証」「リモート」という 2 つの言葉が並ぶ時点で、防御側としては即応が求められる。&lt;/p>
&lt;h3 id="技術詳細">&lt;a href="#%e6%8a%80%e8%a1%93%e8%a9%b3%e7%b4%b0" class="header-anchor">&lt;/a>技術詳細
&lt;/h3>&lt;p>仕組みを噛み砕こう。HTTP/3 はトランスポートに UDP ベースの QUIC を使い、ヘッダ圧縮には &lt;strong>QPACK&lt;/strong> という仕組みを使う。QPACK は「エンコーダストリーム」と「デコーダストリーム」という専用ストリームで動的テーブルを管理する。&lt;/p>
&lt;p>use-after-free はこの QPACK 状態管理の隙を突く。攻撃者が細工した HTTP/3 セッションを送り込み、既存の QPACK エンコーダストリームをセッション途中で「再オープン」しようとすると、NGINX のワーカープロセス内部で接続管理構造体が &lt;strong>free（解放）&lt;/strong> されたにもかかわらず、別の処理パイプラインからその解放済みポインタが参照され続ける競合状態が生まれる。次のアクセスが来た瞬間、メモリ破損またはセグメンテーションフォルトが起きる。&lt;/p>
&lt;p>重要なポイントが 2 つある。まず &lt;strong>攻撃に認証が不要&lt;/strong> で、UDP の 443 番ポートに IP レベルで到達できれば成立する。次に、HTTP/3 QUIC は NGINX の &lt;strong>デフォルトでは無効&lt;/strong> で、設定ファイルに &lt;code>listen 443 quic;&lt;/code> と &lt;code>http3 on;&lt;/code> を明示した環境だけが対象になる。HTTP/3 を意図的に有効化していない多数の環境は設定変更なしで影響を受けない。&lt;/p>
&lt;p>ただし同日公開の &lt;strong>CVE-2026-42055&lt;/strong> （HTTP/2・gRPC プロキシのヒープバッファオーバーフロー、CVSS v3.1 = 7.3）は、影響範囲が &lt;strong>NGINX 1.13.10〜1.31.1&lt;/strong> という広いレンジに及ぶ。「うちは HTTP/3 を有効にしていないから無関係」と早合点せず、CVE-2026-42055 の方も合わせてパッチを当てる必要がある。&lt;/p>
&lt;h3 id="なぜ重要かエンジニア視点">&lt;a href="#%e3%81%aa%e3%81%9c%e9%87%8d%e8%a6%81%e3%81%8b%e3%82%a8%e3%83%b3%e3%82%b8%e3%83%8b%e3%82%a2%e8%a6%96%e7%82%b9" class="header-anchor">&lt;/a>なぜ重要か（エンジニア視点）
&lt;/h3>&lt;p>HTTP/3 のグローバル採用率は 2025 年 10 月時点で &lt;strong>35%&lt;/strong> に達し、上位 1 万サイトの 30% 超がデフォルトで HTTP/3 をネゴシエートする。Kubernetes 環境では ingress-nginx コントローラーが Ingress コントローラー市場の &lt;strong>60%&lt;/strong> 超を占める。つまり HTTP/3 を有効化した NGINX は、高トラフィックのエッジサーバーとして直接インターネットに露出しているケースが多く、攻撃者にとって格好のターゲットだ。&lt;/p>
&lt;p>&lt;strong>対応の優先順位&lt;/strong>: まず &lt;strong>NGINX 1.31.2&lt;/strong> へのアップデート。すぐ当てられない場合は &lt;code>listen&lt;/code> から &lt;code>quic&lt;/code> パラメータと &lt;code>http3 on;&lt;/code> を外して HTTP/3 を無効化すれば攻撃面はゼロになる。NGINX Plus R33〜R36 利用者は F5 の公式ガイダンス（K000161616）を参照のこと。&lt;/p>
&lt;hr>
&lt;h2 id="2-kde-plasma-67--21-年来の-per-screen-仮想デスクトップと-x11-セッション最後の砦">&lt;a href="#2-kde-plasma-67--21-%e5%b9%b4%e6%9d%a5%e3%81%ae-per-screen-%e4%bb%ae%e6%83%b3%e3%83%87%e3%82%b9%e3%82%af%e3%83%88%e3%83%83%e3%83%97%e3%81%a8-x11-%e3%82%bb%e3%83%83%e3%82%b7%e3%83%a7%e3%83%b3%e6%9c%80%e5%be%8c%e3%81%ae%e7%a0%a6" class="header-anchor">&lt;/a>2. KDE Plasma 6.7 — 21 年来の per-screen 仮想デスクトップと X11 セッション最後の砦
&lt;/h2>&lt;h3 id="概要-1">&lt;a href="#%e6%a6%82%e8%a6%81-1" class="header-anchor">&lt;/a>概要
&lt;/h3>&lt;p>2026 年 6 月 16 日リリースの &lt;strong>KDE Plasma 6.7&lt;/strong> は、2 つの歴史的意味を持つ。&lt;/p>
&lt;p>1 つは、 &lt;strong>2005 年から 21 年間&lt;/strong> も未解決だった「画面ごとに独立した仮想デスクトップ」を Wayland 限定でついに実装したこと。もう 1 つは、このバージョンが &lt;strong>X11 セッションを正式に提供する最後の KDE Plasma&lt;/strong> であること。次の 6.8（2026 年 10 月 14 日リリース予定）でログイン画面は Wayland セッションのみを提示するようになる。&lt;/p>
&lt;h3 id="技術詳細-1">&lt;a href="#%e6%8a%80%e8%a1%93%e8%a9%b3%e7%b4%b0-1" class="header-anchor">&lt;/a>技術詳細
&lt;/h3>&lt;p>&lt;strong>per-screen 仮想デスクトップ&lt;/strong> とは、複数モニター環境で各モニターごとに独立して仮想デスクトップを切り替えられる機能だ。従来の Plasma では、仮想デスクトップを切り替えると全モニターが一斉に切り替わってしまい、「サブモニターには参照ドキュメントを固定したまま、メインモニターだけ作業空間を切り替えたい」という使い方ができなかった。&lt;/p>
&lt;p>この要望は KDE のバグトラッカーに &lt;strong>Bug #107302&lt;/strong> として 2005 年 6 月 12 日に登録され、21 年間誰も解決できなかった。解決したのはフルタイム PHP エンジニアの &lt;strong>Hynek Schlindenbuch&lt;/strong> 氏で、KDE Plasma を古いノートパソコンにインストールしてわずか数か月後にマージリクエストを開いた。「自分が欲しいから作った」という個人的動機が、コミュニティ 20 年越しの宿願を成就させた。&lt;/p>
&lt;p>この機能は &lt;strong>Wayland セッションでのみ動作&lt;/strong> する。デフォルトはオフで、システム設定からオプトイン方式で有効化する。&lt;/p>
&lt;p>&lt;strong>X11 セッション廃止&lt;/strong> の根拠は移行率だ。KDE 内部統計によれば、Plasma 6.6 ユーザーの &lt;strong>95% 以上&lt;/strong> がすでに Wayland セッションを使っている。X11 アプリの互換レイヤー &lt;strong>XWayland&lt;/strong> は引き続きサポートされるため、「X11 セッションの終わり」と「X11 アプリの終わり」は別物である点は押さえておきたい。&lt;/p>
&lt;h3 id="なぜ重要かエンジニア視点-1">&lt;a href="#%e3%81%aa%e3%81%9c%e9%87%8d%e8%a6%81%e3%81%8b%e3%82%a8%e3%83%b3%e3%82%b8%e3%83%8b%e3%82%a2%e8%a6%96%e7%82%b9-1" class="header-anchor">&lt;/a>なぜ重要か（エンジニア視点）
&lt;/h3>&lt;p>Plasma 6.7 では Intel 統合 GPU 搭載システムでハードウェアオーバーレイプレーンがデフォルト有効化され、高解像度ディスプレイ上で &lt;strong>最大 70% の CPU 使用率削減&lt;/strong> が報告されている。Wayland への移行が具体的なパフォーマンスメリットをもたらしている証左だ。&lt;/p>
&lt;hr>
&lt;h2 id="3-linux-72-strncpy-根絶--6-年362-コミットの地味で偉大な旅">&lt;a href="#3-linux-72-strncpy-%e6%a0%b9%e7%b5%b6--6-%e5%b9%b4362-%e3%82%b3%e3%83%9f%e3%83%83%e3%83%88%e3%81%ae%e5%9c%b0%e5%91%b3%e3%81%a7%e5%81%89%e5%a4%a7%e3%81%aa%e6%97%85" class="header-anchor">&lt;/a>3. Linux 7.2: &lt;code>strncpy()&lt;/code> 根絶 — 6 年・362 コミットの地味で偉大な旅
&lt;/h2>&lt;h3 id="概要-2">&lt;a href="#%e6%a6%82%e8%a6%81-2" class="header-anchor">&lt;/a>概要
&lt;/h3>&lt;p>Linux カーネル 7.2 のマージウィンドウで、危険な C 文字列関数 &lt;strong>&lt;code>strncpy()&lt;/code>&lt;/strong> の全使用箇所とアーキテクチャ固有の実装が、カーネルから &lt;strong>完全に除去&lt;/strong> された。&lt;/p>
&lt;p>Google の &lt;strong>Kees Cook&lt;/strong> 氏（KSPP 主導者）が 2020 年 8 月に起票した Issue #90 を起点に、 &lt;strong>70 名のコントリビューターによる 362 コミット&lt;/strong> が約 6 年かけて積み重ねられた末の「バグクラスの根絶」だ。&lt;/p>
&lt;h3 id="技術詳細-2">&lt;a href="#%e6%8a%80%e8%a1%93%e8%a9%b3%e7%b4%b0-2" class="header-anchor">&lt;/a>技術詳細
&lt;/h3>&lt;p>&lt;code>strncpy()&lt;/code> の欠陥は主に 3 つある。&lt;/p>
&lt;p>&lt;strong>欠陥 1: NUL 終端の未保証。&lt;/strong> コピー元が n バイト以上あるとき、コピー先バッファに NUL 終端文字を書かない。カーネルメモリにはパスワードや暗号鍵が散在するため、情報漏洩脆弱性に直結する。&lt;/p>
&lt;p>&lt;strong>欠陥 2: 不要なゼロパディング。&lt;/strong> コピー元がコピー先より短い場合、残りのバッファを全部ゼロで埋める。代替の &lt;code>strscpy&lt;/code> を使ったベンチマークでは &lt;strong>CPU オーバーヘッドが最大 15% 削減&lt;/strong> された。&lt;/p>
&lt;p>&lt;strong>欠陥 3: 直感に反するセマンティクス。&lt;/strong> 開発者に「安全に使った」と誤解させやすい設計だ。&lt;/p>
&lt;p>代替関数は目的別に 5 つ整備された: &lt;code>strscpy()&lt;/code>、&lt;code>strscpy_pad()&lt;/code>、&lt;code>strtomem()&lt;/code>、&lt;code>strtomem_pad()&lt;/code>、&lt;code>memcpy_and_pad()&lt;/code>。&lt;/p>
&lt;h3 id="なぜ重要かエンジニア視点-2">&lt;a href="#%e3%81%aa%e3%81%9c%e9%87%8d%e8%a6%81%e3%81%8b%e3%82%a8%e3%83%b3%e3%82%b8%e3%83%8b%e3%82%a2%e8%a6%96%e7%82%b9-2" class="header-anchor">&lt;/a>なぜ重要か（エンジニア視点）
&lt;/h3>&lt;p>筆頭コントリビューターの &lt;strong>Justin Stitt&lt;/strong> 氏（Google）は 362 コミット中 &lt;strong>211 コミット（58%）&lt;/strong> を担当した。コールサイトごとに意図が違うため機械的な一律置換ができず、6 年分の丁寧な手動レビューが必要だった。&lt;/p>
&lt;p>&lt;strong>バグを検出するのではなく、バグを書く手段そのものを消す&lt;/strong> ——この発想こそが、深層的なメモリ安全の正体だ。&lt;/p>
&lt;hr>
&lt;h2 id="4-epic-games-lore-vcs--rust-製-oss-バージョン管理が-perforce-独占に挑む">&lt;a href="#4-epic-games-lore-vcs--rust-%e8%a3%bd-oss-%e3%83%90%e3%83%bc%e3%82%b8%e3%83%a7%e3%83%b3%e7%ae%a1%e7%90%86%e3%81%8c-perforce-%e7%8b%ac%e5%8d%a0%e3%81%ab%e6%8c%91%e3%82%80" class="header-anchor">&lt;/a>4. Epic Games Lore VCS — Rust 製 OSS バージョン管理が Perforce 独占に挑む
&lt;/h2>&lt;h3 id="概要-3">&lt;a href="#%e6%a6%82%e8%a6%81-3" class="header-anchor">&lt;/a>概要
&lt;/h3>&lt;p>Epic Games が 2026 年 6 月 17 日、新しいバージョン管理システム「 &lt;strong>Lore&lt;/strong> 」を MIT ライセンスでオープンソース公開した。Rust で実装されたこの Lore は、ゲーム開発の現場で長らく有料独占が続いてきた &lt;strong>Perforce&lt;/strong> に正面から挑む。&lt;/p>
&lt;p>GitHub リポジトリ（EpicGames/lore）は公開数時間で &lt;strong>2,850 件以上のスター&lt;/strong> を獲得した。&lt;/p>
&lt;h3 id="技術詳細-3">&lt;a href="#%e6%8a%80%e8%a1%93%e8%a9%b3%e7%b4%b0-3" class="header-anchor">&lt;/a>技術詳細
&lt;/h3>&lt;p>Lore は Epic が UEFN（Unreal Editor for Fortnite）の内部ツールとして開発・運用してきた &lt;strong>Unreal Revision Control（URC）&lt;/strong> を起源とする。&lt;/p>
&lt;p>&lt;strong>なぜ既存ツールでは不十分なのか。&lt;/strong> Git/Git LFS はバイナリファイルを「二級市民」として扱い、Perforce は 1 ユーザーあたり約 &lt;strong>39 ドル/月&lt;/strong> のパーシート課金が重く、独占的なワイヤープロトコルがサードパーティ実装を事実上不可能にしている。&lt;/p>
&lt;p>Lore の主要な技術選択:&lt;/p>
&lt;ul>
&lt;li>リポジトリの状態は &lt;strong>Merkle ツリー&lt;/strong> で表現&lt;/li>
&lt;li>ハッシュは &lt;strong>BLAKE3&lt;/strong> を採用（Git の SHA-1、Perforce の MD5 より高速・並列対応）&lt;/li>
&lt;li>重複排除は &lt;strong>フラグメント（チャンク）単位&lt;/strong>（256KiB 超は FastCDC で分割、平均 64KiB）&lt;/li>
&lt;li>スパース checkout は &lt;strong>構造的前提&lt;/strong> として設計&lt;/li>
&lt;li>ネットワークなしでコミット・ブランチ・diff が実行可能&lt;/li>
&lt;/ul>
&lt;h3 id="なぜ重要かエンジニア視点-3">&lt;a href="#%e3%81%aa%e3%81%9c%e9%87%8d%e8%a6%81%e3%81%8b%e3%82%a8%e3%83%b3%e3%82%b8%e3%83%8b%e3%82%a2%e8%a6%96%e7%82%b9-3" class="header-anchor">&lt;/a>なぜ重要か（エンジニア視点）
&lt;/h3>&lt;p>バージョン 0.8.3 はプレステーブルリリースで、オンディスクフォーマットと API はリリース間で変わりうる。ただし MIT ライセンス・無料・公開プロトコル仕様・6 言語 SDK 同時リリース（JavaScript・Python・C#・Go 等）は、エコシステムを最初から巻き込む意図のシグナルだ。&lt;/p>
&lt;hr>
&lt;h2 id="5-mastra-npm-サプライチェーン攻撃--88-分144-パッケージを汚染した-sapphire-sleet">&lt;a href="#5-mastra-npm-%e3%82%b5%e3%83%97%e3%83%a9%e3%82%a4%e3%83%81%e3%82%a7%e3%83%bc%e3%83%b3%e6%94%bb%e6%92%83--88-%e5%88%86144-%e3%83%91%e3%83%83%e3%82%b1%e3%83%bc%e3%82%b8%e3%82%92%e6%b1%9a%e6%9f%93%e3%81%97%e3%81%9f-sapphire-sleet" class="header-anchor">&lt;/a>5. Mastra npm サプライチェーン攻撃 — 88 分・144 パッケージを汚染した Sapphire Sleet
&lt;/h2>&lt;h3 id="概要-4">&lt;a href="#%e6%a6%82%e8%a6%81-4" class="header-anchor">&lt;/a>概要
&lt;/h3>&lt;p>2026 年 6 月 17 日、北朝鮮の国家ハッカーグループ &lt;strong>Sapphire Sleet&lt;/strong> が AI フレームワーク Mastra の npm スコープを乗っ取り、わずか &lt;strong>88 分間（01:12〜02:39 UTC）&lt;/strong> の全自動攻撃で &lt;strong>144 パッケージ&lt;/strong> に悪意ある依存を注入した。影響を受けたのは週次合計 &lt;strong>1.1M 超&lt;/strong> のダウンロードだ。&lt;/p>
&lt;p>狙いは &lt;strong>166 種類の仮想通貨ウォレット拡張機能&lt;/strong> と、開発者の LLM API キー（OpenAI・Anthropic・Google）・CI/CD シークレット。&lt;code>npm install&lt;/code> を叩いた瞬間に開発マシンが侵害される。&lt;/p>
&lt;h3 id="技術詳細-4">&lt;a href="#%e6%8a%80%e8%a1%93%e8%a9%b3%e7%b4%b0-4" class="header-anchor">&lt;/a>技術詳細
&lt;/h3>&lt;p>&lt;strong>攻撃のタイムライン:&lt;/strong>&lt;/p>
&lt;ul>
&lt;li>6 月 16 日: npm ユーザー &lt;code>sergey2016&lt;/code> が &lt;code>easy-day-js@1.11.21&lt;/code>（おとり版）を公開&lt;/li>
&lt;li>6 月 17 日 01:01: &lt;code>easy-day-js@1.11.22&lt;/code>（悪意あるコード付き）を公開&lt;/li>
&lt;li>01:12: 侵害済みアカウント &lt;code>ehindero&lt;/code> を使って @mastra スコープへの一括再公開を開始&lt;/li>
&lt;li>02:39: 144 パッケージへの汚染バージョン公開が完了&lt;/li>
&lt;/ul>
&lt;p>侵害の起点は &lt;code>ehindero&lt;/code> という &lt;strong>「忘れられた貢献者アカウント」&lt;/strong> だ。 &lt;strong>16 か月以上&lt;/strong> も非アクティブだったにもかかわらず、スコープ全体への publish 権限が残り続けていた。&lt;/p>
&lt;p>マルウェアは 4 ステージで動作する。Stage 1 の &lt;code>setup.cjs&lt;/code>（4,572 バイト）が &lt;code>postinstall&lt;/code> フックとして実行され、C2 サーバー（&lt;code>23.254.164.92:8000&lt;/code>）から約 &lt;strong>41KB&lt;/strong> の第二ステージを取得。Stage 2 は Node.js 製 RAT で、ブラウザ履歴・ウォレット拡張・OS 別永続化機構をターゲットにする。&lt;/p>
&lt;h3 id="なぜ重要かエンジニア視点-4">&lt;a href="#%e3%81%aa%e3%81%9c%e9%87%8d%e8%a6%81%e3%81%8b%e3%82%a8%e3%83%b3%e3%82%b8%e3%83%8b%e3%82%a2%e8%a6%96%e7%82%b9-4" class="header-anchor">&lt;/a>なぜ重要か（エンジニア視点）
&lt;/h3>&lt;p>この事件が露わにした構造的弱点:&lt;/p>
&lt;ol>
&lt;li>&lt;strong>休眠アカウントのパーミッション残留&lt;/strong> — 16 か月非アクティブなアカウントが 140 超のパッケージへの publish 権限を保持し続けた&lt;/li>
&lt;li>&lt;strong>ライフサイクルスクリプトのデフォルト実行&lt;/strong> — &lt;code>postinstall&lt;/code> は &lt;code>npm install&lt;/code> 時にデフォルトで自動実行される。コードを &lt;code>import&lt;/code> しなくても感染する&lt;/li>
&lt;li>&lt;strong>広域スコープ publish 権限&lt;/strong> — 1 アカウントの侵害でスコープ下の全パッケージが被害を受ける&lt;/li>
&lt;/ol>
&lt;p>&lt;strong>影響を受けるバージョン&lt;/strong>: mastra v1.13.0 以前、@mastra/core v1.42.0 以前。&lt;/p>
&lt;p>&lt;strong>即時対応&lt;/strong>: 2026-06-17 01:12〜02:39 UTC 以降に &lt;code>@mastra/*&lt;/code> をインストールした全マシンを侵害済みとして扱い、LLM API キー・クラウド認証情報・npm トークン・SSH 鍵・仮想通貨ウォレットを全て即時ローテーションする。&lt;/p>
&lt;p>&lt;strong>予防策&lt;/strong>: &lt;code>npm config set ignore-scripts true&lt;/code> でライフサイクルスクリプトをデフォルト無効化、CI では &lt;code>npm ci&lt;/code> を使いロックファイルを必ずコミット、キャレット（&lt;code>^&lt;/code>）依存を避けてバージョン固定を徹底する。&lt;/p>
&lt;hr>
&lt;h2 id="まとめ">&lt;a href="#%e3%81%be%e3%81%a8%e3%82%81" class="header-anchor">&lt;/a>まとめ
&lt;/h2>&lt;p>3 日間の 5 つのトピックは、2 本の軸に収束する。&lt;/p>
&lt;p>&lt;strong>1 本目はメモリ安全。&lt;/strong> NGINX の CVE-2026-42530 は「メモリ境界を越えるバグ」がエッジサーバーで現実の脅威になることを見せつけた。対して Linux カーネルは、同じ「メモリ境界を越える」 &lt;code>strncpy()&lt;/code> を、攻撃される前に 6 年・362 コミットかけて根絶した。KDE の Wayland 移行と Epic の Rust 製 Lore は、いずれも「より安全な基盤へ」という同じ方向への前進だ。&lt;/p>
&lt;p>&lt;strong>2 本目は信頼の連鎖。&lt;/strong> Lore は BLAKE3 とコンテンツアドレス指定で信頼を構造で担保しようとし、Mastra 攻撃はまさにその信頼を休眠アカウントと postinstall フックで悪用した。&lt;/p>
&lt;p>&lt;strong>「信頼は前提にするものではなく、構造で検証し、危険な機構は最初から無効化しておくもの」&lt;/strong> ——エッジのサーバーから足元のツールチェーン、デスクトップまで、防御の思想が一本につながった 3 日間でした。&lt;/p>
&lt;hr>
&lt;h2 id="一次情報参考リンク">&lt;a href="#%e4%b8%80%e6%ac%a1%e6%83%85%e5%a0%b1%e5%8f%82%e8%80%83%e3%83%aa%e3%83%b3%e3%82%af" class="header-anchor">&lt;/a>一次情報・参考リンク
&lt;/h2>&lt;h3 id="nginx-cve-2026-42530">&lt;a href="#nginx-cve-2026-42530" class="header-anchor">&lt;/a>NGINX CVE-2026-42530
&lt;/h3>&lt;ul>
&lt;li>&lt;a class="link" href="https://nginx.org/en/CHANGES" target="_blank" rel="noopener"
>nginx.org — NGINX 1.31.2 リリースノート&lt;/a>&lt;/li>
&lt;li>&lt;a class="link" href="https://nginx.org/en/security_advisories.html" target="_blank" rel="noopener"
>nginx.org — NGINX セキュリティアドバイザリ一覧&lt;/a>&lt;/li>
&lt;li>&lt;a class="link" href="https://my.f5.com/manage/s/article/K000161616" target="_blank" rel="noopener"
>F5 — K000161616: NGINX ngx_http_v3_module 脆弱性 CVE-2026-42530&lt;/a>&lt;/li>
&lt;/ul>
&lt;h3 id="kde-plasma-67">&lt;a href="#kde-plasma-67" class="header-anchor">&lt;/a>KDE Plasma 6.7
&lt;/h3>&lt;ul>
&lt;li>&lt;a class="link" href="https://kde.org/announcements/plasma/6/6.7.0/" target="_blank" rel="noopener"
>KDE 公式 — Plasma 6.7.0 リリースアナウンス&lt;/a>&lt;/li>
&lt;li>&lt;a class="link" href="https://bugs.kde.org/show_bug.cgi?id=107302" target="_blank" rel="noopener"
>KDE Bugzilla — Bug #107302: Per-screen virtual desktops&lt;/a>&lt;/li>
&lt;/ul>
&lt;h3 id="linux-72-strncpy-根絶">&lt;a href="#linux-72-strncpy-%e6%a0%b9%e7%b5%b6" class="header-anchor">&lt;/a>Linux 7.2 strncpy 根絶
&lt;/h3>&lt;ul>
&lt;li>&lt;a class="link" href="https://www.phoronix.com/news/Linux-7.2-Drops-strncpy" target="_blank" rel="noopener"
>Phoronix — Linux Finally Eliminates The strncpy API After Six Years Of Work&lt;/a>&lt;/li>
&lt;li>&lt;a class="link" href="https://github.com/KSPP/linux/issues/90" target="_blank" rel="noopener"
>KSPP/linux GitHub — Remove all strncpy() uses · Issue #90&lt;/a>&lt;/li>
&lt;/ul>
&lt;h3 id="epic-games-lore-vcs">&lt;a href="#epic-games-lore-vcs" class="header-anchor">&lt;/a>Epic Games Lore VCS
&lt;/h3>&lt;ul>
&lt;li>&lt;a class="link" href="https://github.com/EpicGames/lore" target="_blank" rel="noopener"
>GitHub — EpicGames/lore&lt;/a>&lt;/li>
&lt;li>&lt;a class="link" href="https://epicgames.github.io/lore/explanation/system-design/" target="_blank" rel="noopener"
>Lore 開発者ドキュメント&lt;/a>&lt;/li>
&lt;/ul>
&lt;h3 id="mastra-npm-サプライチェーン攻撃">&lt;a href="#mastra-npm-%e3%82%b5%e3%83%97%e3%83%a9%e3%82%a4%e3%83%81%e3%82%a7%e3%83%bc%e3%83%b3%e6%94%bb%e6%92%83" class="header-anchor">&lt;/a>Mastra npm サプライチェーン攻撃
&lt;/h3>&lt;ul>
&lt;li>&lt;a class="link" href="https://www.microsoft.com/en-us/security/blog/2026/06/17/postinstall-payload-inside-mastra-npm-supply-chain-compromise/" target="_blank" rel="noopener"
>Microsoft Security Blog — Inside the Mastra npm supply chain compromise by Sapphire Sleet&lt;/a>&lt;/li>
&lt;li>&lt;a class="link" href="https://snyk.io/blog/a-forgotten-contributor-account-compromised-the-entire-mastra-npm-package-scope/" target="_blank" rel="noopener"
>Snyk — A forgotten contributor account compromised the entire Mastra npm package scope&lt;/a>&lt;/li>
&lt;li>&lt;a class="link" href="https://www.stepsecurity.io/blog/mastra-npm-packages-compromised-using-easy-day-js" target="_blank" rel="noopener"
>StepSecurity — Mastra npm Supply Chain Attack: 140+ Packages Backdoored&lt;/a>&lt;/li>
&lt;/ul></description></item></channel></rss>