このサイトでの挿絵は、Gemini Proによる生成が大半です。 また、情報収集・まとめなどのサイトについては、検索結果をベースとしたものを使用しています。可能な限り出典を明示するよう努めますが完全ではありません。各自で調べる事もお忘れなく。
技術トレンド セキュリティ

信頼は一枚板じゃない：Asahi Linux緊急警告、BPFループ検証、LiteLLM無認証RCE、GPG分裂（2026年6月10日）

はじめに

毎日遅くまでインフラの監視やデバッグ、コード書きを頑張っているエンジニアのみなさん、本当にお疲れ様！今日もお姉さんが、みんなの力になれるよう、最新の Linux ・ OSS 界隈のホットなトレンドを徹底的にリサーチしておいたよ。

実は私、この記事を書く準備をしていた昨日、検証環境の古いサーバーを何気なくアップデートしたんだけど……突然 GPG の署名エラーでパッケージ更新が全部止まっちゃって！「えっ、なんで！？」となって、夜中まで真っ黒な端末に向かって設定ファイルをいじり倒す羽目になりました（泣）。結局は古い署名鍵のインポートエラーだったんだけど、おかげで目が完全に冴えて、今回の記事を熱量たっぷりで執筆できています。エンジニアの夜更かしって、いつもこういう突発的なトラブルから始まりますよね（笑）。

今回の調査対象期間は、2026年6月9日（火）から6月10日（水）までのタイトなタイムライン。この極めて短い期間の中でも、Apple Silicon上のブートエコシステムを揺るがすOS間のアップデート摩擦から、AIプロキシを標的とした壊滅的なチェーン攻撃、さらには暗号化インフラの世代交代に伴う規格分裂の動きまで、非常に重要度の高いトピックが多数発生しているんだ。

お姉さんお気に入りのマニアックな低レイヤー技術解説も交えながら、それぞれの背景やエンジニアへの影響を5つのトピックに厳選して深掘りしていくね。今日を生き抜くエンジニアの知恵として、ぜひ役立ててほしいな。

まずは、本日のYouTube動画をこちらからご覧ください！

注目のOSSトレンド Top 5

1. Asahi Linux：macOS 27 Beta「Golden Gate」へのアップグレードに対する緊急警告

Apple Silicon（Mシリーズチップ）搭載Mac上でLinuxをネイティブ動作させる Asahi Linux プロジェクトは、2026年6月9日、ユーザーに向けて現在公開されている開発者向けベータ版 macOS 27 (Golden Gate) へのアップグレードを行わないよう、公式Mastodonや各種コミュニティを通じて強い警告を発したよ。

技術的な原因は、 macOS 27 におけるブートピッカー（起動時にOSを選択する画面）および 起動ディスク（Startup Disk） アプリケーションのOSボリューム検出ロジックの大幅な変更にあるんだ。 Apple Silicon搭載Macの起動シーケンスは、ハードウェア上の独立したブートローダーだけでなく、デフォルトの起動ボリュームに存在するリカバリOS環境の「macOSアプリ」として実装されたブートピッカーに依存している。 macOS 27 にアップデートすると、この検出コードの挙動が変わってしまい（バグの可能性が高いとされる）、既存の Asahi Linux （Fedora Asahi Remixなど）のパーティションを「有効なOSボリューム」として認識できなくなり、ブートメニューから完全に消滅したように見える現象が発生するんだ。えっ、朝起きてPC起動してLinuxが消えてたら、心臓が止まりそうになっちゃうよね……！

もし誤って macOS 27 にアップグレードし、Linuxパーティションが見えなくなった場合でも、データ自体は消失していないから安心してね。一時的な回避策として、セカンダリボリュームにインストールされた macOS 26 以下のリカバリ環境を「デフォルト起動ディスク」に再指定することで、以前と同様に Asahi Linux をブートできるようになるよ。

しかし、ここでさらなる罠が！コマンドラインツールである bless コマンドを用いて手動でLinuxブートパーティションを強制指定した場合、Linuxカーネル起動直後に SMC（システム管理コントローラ） からバッテリーステータスを正常に取得できず、ハードウェアの保護機能によって「緊急シャットダウン」が作動する深刻なセカンダリバグも報告されているんだ。ブートを無理やり通そうとしたら強制シャットダウンだなんて、もはや罠のデパート状態だよね（笑）。

このトピックが示唆する将来的な波及効果は大きい。Apple自身は代替OSの起動経路（非署名カーネルの実行）をサポートする姿勢を維持しているものの、システム起動に必要な最下層のファームウェアとリカバリアプリケーションがmacOSのメジャーバージョン更新に完全同期しているため、今回のような意図しない「他OS排除バグ」は今後も発生しうる。クローズドなプラットフォーム上でオープンな代替OSを稼働させることの宿命とも言える課題であり、ユーザー側のロールバック環境（マルチmacOS構成）の構築が強く推奨される状況になっているよ。

ブート関連項目macOS 26 以前のリカバリ環境macOS 27 Beta (Golden Gate) リカバリ環境
Asahi Linux ボリューム認識正常に検出・選択可能バグにより検出不可（ブートピッカー上で不可視化）
起動制御システムiBootの仕様に準拠した安全なOS選択新しいOSボリュームスキャンエンジンへの移行
bless コマンドによる強制指定正常にブート可能Linux起動直後にSMCエラーにより緊急シャットダウンが発生
Asahi Installer の挙動通常通り稼働macOS 27を検出すると警告を出力し即座に終了

2. BPF検証器におけるスカラー進化（SCEV）を用いたループ検証の進化

Linuxカーネルの安全なサンドボックス実行環境である BPF（Berkeley Packet Filter） において、長年の課題であった「ループ処理の静的解析」を劇的に改善する新アプローチ スカラー進化（SCEV: Scalar Evolution） の組み込みが進んでいるよ。2026年6月に開催されたLSFMM+BPFサミットにて、Eduard Zingermanより現在の開発進捗が共有されたんだ。

従来の BPF 検証器（verifier）は、プログラムに含まれるループを「1反復ずつ実際に展開してシミュレーションする」という力任せの解析アプローチをとってきた。しかし、この方法ではネスト（多重）されたループや実行回数の多いループを解析しようとした際、検証器が走査できる最大命令数制限（Complexity Limit）を即座に超過し、プログラムがロード拒否される原因になっていたんだ。

今回提案された SCEV は、近代的な最適化コンパイラで広く採用されているデータフロー解析手法であり、ループインダクション変数（カウンタ）の推移を数学的数式（漸化式）に抽象化してモデル化する。 これ、低レイヤーオタク的にはマジで興奮するアプローチなんだよね！すべての反復パスを実際にトレースすることなく、ループが必ず終了し、かつ配列の境界外アクセスを引き起こさないことを静的かつ高速に証明可能になるんだよ。

この技術進化は、単なる「コンパイル成功率の向上」に留まらないインパクトを秘めている。 LLMベースのコーディングアシスタント やエージェントツール（bpftrace等）が自動生成する BPF プログラムが急増する「エージェント時代のBPF（BPF in the agentic era）」において、複雑な多重ループや動的境界を処理できる安全なローダーの存在は極めて重要なんだ。 手書きの最適化が施されていない、自動生成された「ちょっと無駄の多いループコード」であっても、カーネルに安全にロードして高速実行できる土壌が整うため、監視やネットワークフィルタリング、さらにはファイルシステムレベルの動的なロジック挿入の応用範囲が大きく広がることになるよ。これからのAI時代、カーネル側もAIの「泥臭いコード」を受け止めるために優しく進化しているんだね！

比較評価軸従来のシミュレーション型ループ検証スカラー進化 (SCEV) 統合モデル
解析の計算量ループ回数 $N$ に対して $O(N)$ のステップが必要（限界突破しやすい）変数の数学的な方程式評価による $O(1)$ またはそれに近い高速解析
ネスト（多重）ループほぼ検証不能または非常に限定的抽象化モデルにより入れ子構造の追跡性が大幅に向上
静的安全性の証明基準各状態の配列インデックスの直接境界チェック数式に基づいたインダクション変数の上限値の証明
自動生成コード適性冗長なループ記述に対して非常に脆弱でロード失敗しやすい冗長な構文から法則性を抽出できるため極めて頑健

3. LiteLLM（CVE-2026-42271）とStarlette（CVE-2026-48710）の脆弱性チェーンによる無認証RCE

オープンソースのAIプロキシ・AIゲートウェイとして広く採用されている LiteLLM に深刻なコマンド注入脆弱性（CVE-2026-42271）が確認され、2026年6月8日にはCISAの「悪用が確認された脆弱性（KEV）カタログ」にも追加されたんだ。さらに、この脆弱性をWebサーバーフレームワークである Starlette のHostヘッダ検証回避の脆弱性（CVE-2026-48710）と組み合わせることで、攻撃者が「完全に外部から無認証」でターゲットサーバー上で任意コードを実行（RCE）できる最悪の攻撃シナリオが確認されたよ。

原因となった CVE-2026-42271 は、 LiteLLM の Model Context Protocol（MCP） プレビュー用の評価エンドポイントである POST /mcp-rest/test/connection および /mcp-rest/test/tools/list における実装不備から発生するんだ。 このエンドポイントは、stdioトランスポート設定において外部コマンド（command、args、envなど）を受け取り、それをプロキシサーバーのプロセス権限でそのままサブプロセスとして起動してしまう。 本来であれば有効なAPIキー（低権限を含む）が必要なエンドポイントなんだけど、古いバージョンの Starlette （v1.0.0以下）に含まれるHostヘッダ評価バイパス（CVE-2026-48710）をチェーンすることで、認証チェック自体を完全に迂回して外部からAPI呼び出しを実行できてしまうんだ。影響を受けるのは LiteLLM のバージョン1.74.2から1.83.6までであり、最新の 1.83.7-stable へのアップデートが必須となるよ。

これ、脆弱性の「ピタゴラスイッチ」みたいで（不謹慎だけど）システム設計者としては背筋がゾクゾクしちゃうよね！ この脆弱性の悪用が急速に進んでいる背景には、現代のAIインフラにおけるAIゲートウェイの立ち位置がある。 LiteLLM のような統合プロキシは、OpenAIやAnthropic、Google CloudなどのあらゆるモデルプロバイダーへのAPIキーを集約する「認証情報のハブ」として稼働している。 攻撃者にとって、 LiteLLM の実行プロセス（コンテナイメージでは多くの場合root権限で稼働している）の制約を突破することは、社内ネットワークへの侵入契機となるだけでなく、保管されている全てのサードパーティAIサービスのAPIトークンを盗み出すことができる極めて「実利の高い」攻撃対象になっているんだ。みんなの環境は大丈夫？今すぐバージョンを確認してね！

攻撃ステージ悪用される脆弱性（CVE ID）動作メカニズム権限・被害範囲
第1段階 (認証回避)CVE-2026-48710 (Starlette)Hostヘッダの不適切なサニタイズを利用し、ローカル向けまたは特定ヘッダチェックを偽装してWebサーバーの認証層をスルーする未認証のインターネットトラフィック
第2段階 (コード実行)CVE-2026-42271 (LiteLLM)MCPのstdioテスト機能に任意のOSコマンドを含んだJSONを直接POSTするLiteLLMサーバーの親プロセス権限（多くはroot）で任意のOSコマンドが稼働
ポスト・エクスプロイトなし（取得権限の悪用）プロキシのメモリやDB、envから各種LLMサービスのマスターAPIキーやプライベートVPCアクセス権限を窃取・横展開するAI連携システム全体、および隣接するクラウドプライベートネットワークの完全な掌握

4. GogsにおけるGit引数注入による認証済みRCE脆弱性（CVE-2026-52806）

Go言語で実装された、非常に軽量で人気の高いセルフホスト型Gitサービス Gogs において、極めて重大な引数注入（Argument Injection）の脆弱性（CVE-2026-52806, CVSSv4スコア 9.4）が報告され、2026年6月7日に修正パッチ（v0.14.3）がリリースされたよ。

この脆弱性は、 Gogs のリポジトリ固有設定で「マージ前のリベース（Rebase before merging）」機能が有効化されている場合にトリガーされるんだ。 Gogs は内部のプルリクエストを処理する際、ベースブランチに対して git rebase <base_branch> <head_branch> をOSの外部コマンドとして呼び出す仕組みを採用している。この時、攻撃者がマージリクエスト対象のブランチ名として、例えば --exec オプション（Gitリベース後に各コミットごとにシェルコマンドを動的に実行させるコマンド引数）を含んだ悪意ある文字列を指定しておくと、 Gogs サーバーはこれをブランチ名ではなくGitのオプションフラグとしてそのまま認識・実行してしまうんだ！

Gogs は初期設定において一般公開でのユーザー自己登録機能（ DISABLE_REGISTRATION = false ）が有効化されているため、攻撃者は自分で作成したアカウントから自身のリポジトリ内で本手順を踏むだけで、他者の関与なく、かつ管理権限を必要とせずに、完全に自身の操作のみでコンテナまたはホストサーバーのシェル権限を奪取可能となる。これ、めちゃくちゃシンプルで恐ろしい攻撃手法だよね……。

多くのセルフホスト系Gitサービスを含むOSS開発において、GitバイナリなどのOSコマンド実行系インターフェースにおける「完全な引数エスケープ」の難しさは以前から繰り返し指摘されているよ。特にGitのコマンド仕様は、ブランチ名のフォーマット規制が緩いため、パラメータの先頭にダッシュ（ - ）を使用する形式（オプションと誤認されるパターン）の攻撃入力に対して極めて脆弱になりやすいんだ。 対策としては、外部コマンドに依存せずPure Goで実装された go-git などのライブラリ統合を進めるか、コマンド実行時に明示的に引数とブランチを分離する -- （ダッシュ2個）セパレータによるパラメータ区切りを厳格に実装するといった、セキュアコーディングプラクティスの徹底が急務となっているよ。

評価ファクターセキュリティ攻撃条件および被害特性
攻撃トリガー機能プルリクエストマージ設定「Rebase before merging」（PullsAllowRebase）の実行
コマンドパラメータインジェクションgit rebase の引数評価における --exec オプションの強制挿入
デフォルト設定のリスクオープン登録が許可、リポジトリ作成上限なしのため、未認証攻撃者がアカウントを作成して即時実行可能
推奨対応策Gogs v0.14.3 への迅速な更新、または設定ファイル app.ini における DISABLE_REGISTRATION = true への変更

5. GNU Privacy Guard（GPG）2.4系列のサポート終了（EOL）とLibrePGP移行によるエコシステムの摩擦

Linuxシステムパッケージの認証や安全な電子メール暗号化に広く使われ、事実上のグローバルスタンダードの地位を確立してきた GNU Privacy Guard（GPG） プロジェクトにおける歴史的な安定版分岐 GPG 2.4系列 が、2026年6月をもって最終的な製品寿命（EOL）を迎えるよ。

歴史的な背景を整理すると、 GPG プロジェクトは2023年、IETF（Internet Engineering Task Force）によるOpenPGPの公式アップデートプロセスの議論（RFC 4880の改訂）に反対し、独自の対抗規格として LibrePGP を立ち上げ、そちらを今後の主軸とすることを一方的に表明したんだ。この独自の LibrePGP 規格を本番機能として統合したのが最新の GPG 2.5系列 であり、従来のOpenPGP規格に完全準拠した最後のプロダクション向け安定版系列が、まさに今月末にEOLとなる GPG 2.4 なんだよ。

このEOLがもたらす開発エコシステムや運用インフラへの影響（摩擦）は極めて大きい！ GPG プロジェクトはすでに GPG 2.5 への移行を強く推奨しているが、 GPG 2.5 が推進する LibrePGP は、他の主要なOpenPGP実装（Rust言語製の Sequoia PGP や、Go言語の標準PGPライブラリなど）との間で「暗号鍵の互換性」や「署名の認識互換性」を一部失うことが明らかになっているんだ。

これにより、何十年もの間「GPGを使っていれば、OpenPGPのすべてのツールと問題なくセキュアに連携できる」と信じられてきたインフラの相互運用性モデルが強制的に解体されることになる。長年連れ添ってきた相棒が、いきなり「俺は独自の道をいく！」って言って別荘を建てちゃったような寂しさと混乱があるよね（笑）。 各Linuxディストリビューションのパッケージングシステム（APTやRPMのメタデータ署名プロセスなど）のメンテナーや、CI/CDで秘密鍵・公開鍵暗号を用いた自動署名検証を構築しているエンジニアは、独自の道を歩む GPG 2.5 へそのまま従うか、あるいは本来のOpenPGPに準拠し開発された新興の代替ツールに乗り換えるかの、中長期的な決断を下す必要に迫られているよ。これ、地味だけどインフラ層では結構な大地震になりそうな予感……！

比較検討項目従来モデル：GPG 2.4系列（EOL）新モデル：GPG 2.5系列（アクティブ）
暗号規格の準拠状況標準の OpenPGP（IETF仕様）に厳格に準拠プロジェクト独自規格の LibrePGP 仕様を採用
他ツールとの相互互換性非常に高い（ほぼすべてのPGP互換クライアントと連携）GPG独自機能に依存しやすく、他実装（Sequoia等）と鍵形式等で衝突の懸念あり
主な用途と適用分野レガシーなパッケージリポジトリ認証、レガシーメール暗号LibrePGPで完結する近代的な閉域型暗号・署名環境、GPGが提供する新暗号アルゴリズム
推奨されるシステム設計早急にEOLを意識し、鍵管理エンジンの移行先（Sequoia PGPなど）を検討GPG 2.5のみでインフラ署名網が完結する場合に限り採用を検討

今日の豆知識（今日は何の日 3選）

本日は2026年6月10日（水）。日本における歴史や社会インフラ、公共システムの成り立ちに触れられる重要な記念日が3つ重なっている、とても面白い日なんだよ！

記念日の名称日本国内での制定年由来となる歴史的背景・出来事
時の記念日1920年（大正9年）『日本書紀』の天智天皇10年4月25日（太陽暦に換算すると671年6月10日）に、漏刻（水時計）を新しい台に置き、初めて人々に時間を告げる鐘を鳴らしたとされる歴史的記述から。
路面電車の日1995年（平成7年）1995年6月10日に広島市で開催された「路面電車サミット」において、6（ろ）と10（テン＝でん）という語呂合わせ「路電（ろでん）」にちなんで制定されたもの。
歩行者天国の日1973年（昭和48年）1973年6月10日、東京都の銀座から上野までの約5.5kmという超大規模な区間で、日本で初めて本格的な「歩行者天国（当時は日曜遊歩道と呼ばれた）」が実施された歴史的事例に由来。

1. 時の記念日（時間の合理化と最古の時報）

『日本書紀』に「漏刻（ろうこく＝水時計）を新しき台に置く。始めて候時を打つ。鐘鼓を動す」と書かれている通り、天智天皇が都を近江大津宮に移した際、公式な時間の通知（時報）制度を日本で初めて開始したとされる日にちなんで制定されたよ。東京天文台（現在の国立天文台）と生活改善同盟会が1920年に、「時間は貴重である。しっかり時間を守って、生活をより近代的かつ合理的に改善しよう」という啓発目的で定めたのが始まりなんだ。 ITシステムにおけるNTPでの時間同期やミリ秒以下のログ解析の正確性は、まさにこの古代の「時の宣告」から続く歴史の延長線上にあると言えるね。

そういえば、うちの開発環境のサーバーのNTP同期が最近数ミリ秒ズレてて、DBのトランザクション順序がたまにおかしくなる怪奇現象があってね……。時間は大切に！っていうのを、まさか古代の天智天皇に教わるとは思いませんでした（笑）。

2. 路面電車の日（エコな公共交通機関の再評価）

全国の路面電車を保有する自治体や交通事業者が一堂に会して始まった記念日で、語呂合わせである「路電（ろでん）」が日付の起源となっているよ。かつては自動車の普及に伴い廃線が進んだ路面電車だけど、近年はバリアフリー化や温室効果ガス削減、環境に配慮した次世代LRT（Light Rail Transit）として世界中で再評価が進んでいるんだ。

路面電車のあのカタカタ揺れる感じ、ノスタルジックでめちゃくちゃ好き！たまに旅行先で乗ると、意味もなく終点まで乗ってのんびりしちゃったりします。

3. 歩行者天国の日（都市における市民のための空間の確保）

昭和40年代のモータリゼーションの到来に伴い、急増する大気汚染物質や交通事故から市民の安全を確保するための壮大な社会実験として、銀座から上野に至る広域区間で行われた「日曜遊歩道」を記念して制定されたよ。車中心の都市インフラ設計から、そこに暮らす人間中心のオープンスペースへと都市空間の設計哲学がシフトする契機となった歴史的な節目なんだね。

そうそう、歩行者天国といえば、お姉さんこないだ銀座のホコ天で買ったクレープを道端で食べてたんだけど、風が強くてクリームが鼻にくっついちゃって大変なことになりました（笑）。あれは本当に恥ずかしかった……！

まとめ

今日お届けした技術調査報告はいかがだったかな？

こうして過去24時間のトレンドを眺めてみると、プラットフォームやインフラを支える「信頼の境界（Interface Boundary）」をどう設計し保護するかが、現在最も議論を集める本質的なテーマになっていることが見えてくるね。

Asahi Linux が直面しているmacOSとの互換性問題は、「独自の仕様（OSリカバリ環境のアプリ）」に他OSのロードを依存させることの物理的限界を示しているし、 LiteLLM や Gogs に代表されるアプリケーションの重大な脆弱性は、AIモデルAPIのトークンを集約して中継したり、あるいはGit操作をシェルコマンドの媒介としてOSレベルで仲介する「仲介・プロキシ役のインターフェース」がいかに攻撃者にとっての格好の標的になっているかを示しているよ。 さらに、 GPG 2.4系列 の EOL と LibrePGP へのシフトは、暗号インフラというインターネット全体の共有資源において「標準化を維持するか、独自の道を突き進むか」という、システム設計の相互運用性を巡る究極のガバナンス課題を私たちに突きつけているよね。

こうした境界の不確実性に備えるために、お姉さんたちエンジニアが今できるアプローチは次の通りに集約されるよ：

  1. AIプロキシなどの集約プロセスの防御 : ネットワークの露出を最小限に抑え、依存パッケージのバージョンアップとアクセス制御（APIトークン不要な認証バイパスを確実に弾く層の挿入）を最優先で実施すること。
  2. ロールバック環境の確保 : Apple Silicon上のLinux稼働のように、サードパーティがコントロールを握るホストシステムをデュアルブートで利用する場合は、万が一のファームウェア破壊変更時にロールバックできる別環境（安定版OSボリュームなど）の予備確保を義務付けること。
  3. 外部コマンドからライブラリ実行への移行 : コマンドエスケープの不確実性を完全に排除するため、システム内から外部プログラムをOSシェル経由で呼ぶ処理を可能な限りコードライブラリ直接実行（ go-git などの活用）へと書き換えていくこと。

季節の変わり目、急な温度変化で体調を崩しやすい時期だからこそ、みんなサーバーの体調チェックだけでなく、自分自身の体調も気遣って、美味しいハーブティーやホットコーヒーでも飲みながら、マイペースに素晴らしい開発ライフを歩んでいこうね！ お姉さんはいつだって、技術への情熱に溢れたみんなの挑戦を応援しているよ。

読者のみんなに質問（余白）

みんなの環境では GPG 2.4 の EOL に伴う移行、どうする予定ですか？ やっぱり Sequoia PGP などのモダンな実装に乗り換える？ それとも GPG 2.5 の LibrePGP 路線についていく？ ぜひハッシュタグ #Agyテックブログ でつぶやいて、みんなの泥臭い移行計画を教えてね！

引用文献

  1. Asahi Linux warns users not to upgrade to macOS 27 beta - LWN.net, 6月 10, 2026にアクセス、 https://lwn.net/Articles/1077209/
  2. Top 7 Things to Know About the LiteLLM CVE-2026-42271 Exploit - CybelAngel, 6月 10, 2026にアクセス、 https://cybelangel.com/blog/itellm-vulnerability-cve-2026-42271/
  3. Fedora and GPG 2.5 - LWN.net, 6月 10, 2026にアクセス、 https://lwn.net/Articles/1055053/
  4. Asahi Linux: “PSA for #AsahiLinux users: Do …” - Treehouse Mastodon, 6月 10, 2026にアクセス、 https://social.treehouse.systems/@AsahiLinux/116719749555082847
  5. PSA for AsahiLinux users : r/linux - Reddit, 6月 10, 2026にアクセス、 https://www.reddit.com/r/linux/comments/1u12vnv/psa_for_asahilinux_users/
  6. Warning! Do not install MacOs Golden Gate 27 beta it seem to make Asahi (Fedora) disappear from boot option. : r/AsahiLinux - Reddit, 6月 10, 2026にアクセス、 https://www.reddit.com/r/AsahiLinux/comments/1u0nbpy/warning_do_not_install_macos_golden_gate_27_beta/
  7. Drifting to Linux - saturn73, 6月 10, 2026にアクセス、 https://s73.girv.in/glog/2026/2026-04-08-drifting-to-linux.html
  8. Kernel coverage at LWN.net, 6月 10, 2026にアクセス、 https://lwn.net/Kernel/
  9. Welcome to LWN.net [LWN.net], 6月 10, 2026にアクセス、 https://lwn.net/
  10. CISA Adds Two Known Exploited Vulnerabilities to Catalog, 6月 10, 2026にアクセス、 https://www.cisa.gov/news-events/alerts/2026/06/08/cisa-adds-two-known-exploited-vulnerabilities-catalog
  11. CVE-2026-42271: Litellm Litellm RCE Vulnerability - SentinelOne, 6月 10, 2026にアクセス、 https://www.sentinelone.com/vulnerability-database/cve-2026-42271/
  12. LiteLLM - Command Injection (CVE-2026-42271) - Vulnerability & Exploit Database, 6月 10, 2026にアクセス、 https://pentest-tools.com/vulnerabilities-exploits/litellm-command-injection_29354
  13. LiteLLM Proxy vulnerabilities: How to find impacted assets - runZero, 6月 10, 2026にアクセス、 https://www.runzero.com/blog/litellm/
  14. Authenticated RCE via Argument Injection in Gogs (NOT FIXED) - Rapid7, 6月 10, 2026にアクセス、 https://www.rapid7.com/blog/post/ve-authenticated-rce-via-argument-injection-gogs-unfixed/
  15. LWN.net Weekly Edition for January 29, 2026, 6月 10, 2026にアクセス、 https://lwn.net/Articles/1055441/
  16. 6月10日の記念日・出来事 | 今日は何の日 - 雑学ネタ帳, 6月 10, 2026にアクセス、 https://zatsuneta.com/archives/a0610.html
  17. 6月10日 - 今日は何の日～毎日が記念日～, 6月 10, 2026にアクセス、 https://www.nnh.to/06/10.html
  18. 6月10日は時の記念日です！ | ブログ | 飛鳥資料館, 6月 10, 2026にアクセス、 https://www.nabunken.go.jp/asuka/info/2025/06/610-3.html
  19. 6月10日は何の日？記念日、出来事、誕生日などのまとめ雑学 - ダレトク雑学トリビア, 6月 10, 2026にアクセス、 https://netlab.click/todayis/0610
  20. 6月10日 - Wikipedia, 6月 10, 2026にアクセス、 https://ja.wikipedia.org/wiki/6%E6%9C%8810%E6%97%A5
© 2022 - 2026 Copyright(c) 2022-2025 SATO Daisuke. All rights reserved.
Hugo で構築されています。
テーマ Stack は Jimmy によって設計されています。