1UP

うさぎ、ハムスター クルマ が好きなソフトウェア開発者➡SE➡クラウドサービス開発へ 。絶賛勉強中。AIを使った効率的な開発にも興味あり。

[堀内進之介：『パランティア 判断を外注する社会』（晶文社） @Homocriticos]

はぁー、もう対応疲れしてるのに、Linuxサーバー触ってる人は全員チェックしたほうがいい激ヤバいやつがまた出た。。。

Ubuntuのセキュリティ情報に出た「CVE-2026-98432」なんだけど、危険度スコア（CVSS）がなんと 9.8 / 10.0（Critical）。ほぼ満点レベルの緊急事態だわ。

「Linuxサーバーなんて本業のインフラエンジニアしか関係ないでしょ？」って思うかもだけど、実は全然そんなことない。

最近って、Windows上で「WSL2」を使ってLinux動かしたり、Hyper-VやVirtualBoxで仮想サーバー立てたり、Docker動かしたりして開発してる人、めちゃくちゃ多いよね。

それ、ぜんぶ中身は「Linux」なわけです。

・LinuxカーネルのTCPネットワーク通信（IPv4）の根っこに、メモリの解放バグ（Use-After-Free）が見つかった

・マルチコアCPUで並行処理してるときに処理がズレて、消えたはずのメモリを読みに行っちゃう

・結果として、細工されたパケットを送りつけられると、OS丸ごとクラッシュ（カーネルパニック）したり、最悪の場合は遠隔から勝手にコードを実行（乗っ取り）される恐れがある。

手元のWindowsで動かしてる仮想環境も今すぐハックされるの？って焦るかもだけど、危険度のグラデーションはこんな感じ。

■ 超キケン（即対応！）

AWSなどのクラウドやVPSで、全世界に向けてポートを開けてWebサーバーなどを公開してる人。外から細工パケットを直接叩き込まれる可能性があるからパッチ最優先。

■ 比較的安全（でも油断禁物）

自宅のPCの中（WSL2やローカル仮想マシン）で自分だけで使ってる人。外のインターネットから直接パケットが届くわけじゃないから、今すぐ外から侵入されるリスクは低い。

とはいえ、OSの心臓部（カーネル）の致命的なバグには違いないし、放置してていいことは1ミリもないよね。

Ubuntuの各バージョン（22.04 LTS、24.04 LTSなど）向けに順次パッチが準備されているので、クラウドのサーバーはもちろん、手元の仮想Linuxも近いうちに sudo apt update && sudo apt upgrade してカーネルを更新すべき。

詳細はこちら👇 https://t.co/3bWsBFprCi

[1UP @_oneup_]

Pixel Watchでバッテリーの異常消費が発生か　Watch 2やWatch 4で駆動時間が大幅に短縮との報告 | スマホダイジェスト https://t.co/dH0Z2MDGqx

私はPixel Watch3だが今のところ発生してない。が心配。

[1UP @_oneup_]

Gemini Notebook の Android アプリに音声レコーダーが追加。日本語の録音と文字起こしに対応 | HelenTech https://t.co/77w13dkX72

これはPixel以外のスマホ利用者にとっては安全な文字起こしの手間が減って良いね。

[1UP @_oneup_]

「ダウンロードフォルダでAIを使わないで」――セキュリティ企業が注意喚起　エージェントが攻撃者の指示に従いマルウェアインストールの恐れ（ITmedia NEWS） - Yahoo!ニュース https://t.co/HUcvoP7Lsn

これは大事。普段から気をつけてダウンロードフォルダで作業しない方がよい

[おむらいす@ブランド屋経営してる人／ベンチプレス30kg @omurice_brand]

あたかもPaypayが不正アクセスをうけて「紐付けた銀行口座から全部抜かれる」みたいな投稿が回ってますが、半分本当で半分違います

本当の部分
8月から「身に覚えのない送金」の報告がPayPayに急増してて、紐付けた口座からチャージされて送金された人は実際にいる
5月には口座2つとカードで約200万円抜かれた人もいる

違う部分
PayPayのシステムが破られた訳じゃない
原因は「TikTok18+」みたいな、公式ストア以外から入れたアプリ
入れるとスマホを遠隔操作されて、画面は真っ暗に見せたまま、裏でPayPayを開いてチャージして送金される
SMSの認証コードもパターンロックも、画面を見られてるので効かない
以前にポストした銀行アプリの偽画面の件と、犯人は同じ
だから「気を付けようがない」は逆で、自分でアプリを入れなければ起きない

紐付けを外さなくても、やれる対策はある

・PayPayの「利用可能額の設定」で、チャージの上限を1日分くらいまで下げて「取引を一時保留にする」にしておく
上限を上げるには端末の認証が要るので、Face IDか指紋にしておく
パスコードだと画面を見られて突破される

・取引の通知をオンにして、身に覚えのない送金があれば60日以内に警察に届けて補償を申請する（原則全額補償）

・紐付けは、給料が入る口座だけ外すか、チャージ用の口座に分ける

「全部解除」までしなくていい

この流れに乗ってインプレッションを稼ごうと大げさに表現してるポストも多いので全てを真に受けて焦らないように

その焦ってる時にタイミングよく届いた偽メールとかでフィッシングされるパターンもありえます

[1UP @_oneup_]

6歳の飼い猫に届いた“進研ゼミの案内”　なぜ届いたのかベネッセに聞いた -> 担当者は「ペットPASSの情報が進研ゼミの方に流れてしまったのかもしれません」とも答えた。 ITmedia NEWS https://t.co/yUe7RvjIXt

いや、全く違うサービスの顧客情報混ざるのはセキュリティインシデントです。

[Kimi 日本公式 @KimiAI_Japan]

日本の皆様、お待たせしました。

Kimi K3.1 Proが提供開始。
いつも応援してありがとうございます！

日頃の感謝を込めて、抽選で10名様に
月間Proプラン（39ドル相当）をプレゼント。
リプ＋フォロー＋リポスト＋いいね。

Kimi K3.1 Proを体験してみたい方は、この機会にぜひ。

知る、考える、つくる。
Kimiと。

[1UP @_oneup_]

@KimiAI_Japan 試してみたいです。

[1UP @_oneup_]

【現地から】GitHub Universe 2026 の更新を全部理解する会 に参加を申し込みました！ https://t.co/5SLETeKc37 #GitHubVibeRiders

[あきらパパ【生成AI活用エンジニア&３児のパパ】 @akira_papa_IT]

【⚠️Tailscale使ってるフォロワーさんは確認してください。過度に心配・安心するのではなく事実確認と対応を冷静に進めていきましょう。Tailscaleの「Tailworm」問題。何が起きて、どこまで事実で、どう対応すればいい？11項目を整理しました】

「Tailscaleがハッキングされた」
「11件の脆弱性が見つかった」
「自分の端末だけなら安全」

いろいろな情報が流れていますが、この3つをそのまま受け取ると、判断を間違える可能性があります。

まず結論から。

・実際に調査や修正が進んでいる問題はある
・11項目すべてが、同じ確度で確認された脆弱性というわけではない
・外部の誰もが、いきなり全端末に侵入できると実証された話ではない
・ただし、許可済みの接続や乗っ取られた端末を起点に、被害が広がる懸念はある

「全部デマ」「全員危険」「個人利用なら絶対安全」のどれにも寄せず、条件を分けて見ていきます。

※2026年10月26日10時JSTまでの調査内容に基づきます。修正状況は変わる可能性があります。

━━━━━━━━━━━━
まず、何のソフトの話？
━━━━━━━━━━━━

Tailscale：
離れた場所にあるPCやサーバーを、専用ネットワークでつなぐサービス。

Tailscale SSH：
そのネットワークを使い、別の端末を遠隔操作する機能。

headscale：
Tailscaleと互換性のある管理サーバーを、自分で運用するための非公式ソフト。

今回の「Tailworm」は、Erica Windisch氏による研究報告の名前です。

報告の11項目には、権限の問題、サービス停止の問題、特殊な設定で生じるリスクなどが含まれます。

そのため、「11件すべてが確認済みの脆弱性」「11件のCVEが付いた」という理解はできません。

━━━━━━━━━━━━
① 一般ユーザーの接続が、管理者の力で転送される
T3
━━━━━━━━━━━━

【何が問題？】
一般ユーザーとしてSSH接続しているのに、その通信の転送を、プログラムがrootという強い管理者権限で行ってしまう問題です。

接続先によっては、本来そのユーザーが触れない管理機能に手が届くおそれがあります。

対象のUnix socketは、同じマシン内でプログラム同士が通信する「窓口」のようなものです。

【どこまで確認済み？】
研究者のラボ検証に加え、Tailscale側の説明や公開された修正案も、権限の扱いに問題があるという方向を裏付けています。

ただし、すべての環境で同じ被害が起きるという意味ではありません。

【どう対応する？】
不要なSSH転送を止める。
接続できる人や端末を必要最小限にする。

「一般ユーザーでログインさせているから大丈夫」だけでは、対策として十分ではありません。

━━━━━━━━━━━━
② 正規の通信窓口を置き換え、なりすます
T2
━━━━━━━━━━━━

【何が問題？】
SSHの逆方向の転送を使い、既存のUnix socketを置き換えられるという指摘です。

正規のサービスの窓口だと思って接続した相手が、攻撃者の用意した窓口だった、という状態につながります。

【どこまで確認済み？】
研究報告と公開された修正案の内容は整合しています。

ただし、そこから何を盗めるか、どこまで操作できるかは、対象サービスや実際に流れる通信によって変わります。

【どう対応する？】
不要な転送を制限する。
侵害の兆候がある場合は、認証情報が渡っていないかも調べる。

単にサービスを再起動するだけで、漏れた認証情報まで無効になるわけではありません。

━━━━━━━━━━━━
③ 「安全確認した直後」に接続先を差し替える
T2/T3 RACE
━━━━━━━━━━━━

【何が問題？】
プログラムが「この場所なら安全」と確認してから、実際に使うまでの一瞬を狙って、参照先を差し替える問題です。

確認した場所と、実際に操作する場所が違ってしまいます。

【どこまで確認済み？】
研究者は、条件付きのラボ環境で、管理サービスへのアクセス、鍵の窃取、不正な端末登録などを報告しています。

ただし、Tailnet Lockが有効な環境で、その保護を実際に無効化するところまで実証したわけではありません。

関連する修正案PR #21942は、調査時点では未統合でした。

【どう対応する？】
不要な転送を止め、SSH接続を絞る。

侵害が疑われる場合は、端末の隔離、関係する鍵の失効、不審な登録端末の確認まで行います。

「PCを初期化したから終わり」とせず、盗まれた鍵が残っていないかを確認することが大切です。

━━━━━━━━━━━━
④ 許可されたアプリ以外の内部宛先にも接続する
C1／conn25
━━━━━━━━━━━━

【何が問題？】
実験的な接続機能「conn25」で、許可されたアプリの範囲を越え、内部の別の宛先へ通信できるという指摘です。

【どこまで確認済み？】
研究者の報告です。

この機能を利用していることや、攻撃者が必要な接続権限を持っていることなどが前提になります。

また、「通信が届いた」と「そのサーバーを乗っ取れた」は別です。すべての端末に自由に侵入できたという話ではありません。

【どう対応する？】
まず、この機能を使っているか確認する。
使っている場合は、接続を仲介するサーバーから通信できる宛先を絞ります。

━━━━━━━━━━━━
⑤ 大量の要求でメモリを使い切り、サービスを止める
T1
━━━━━━━━━━━━

【何が問題？】
SSH接続を許可された利用者が大量の要求を送り、メモリを消費させ、サービスを停止させるという指摘です。

データを盗む問題とは別に、「使えなくする」被害が考えられます。

【どこまで確認済み？】
研究者の報告段階です。
外部の誰もが、認証なしで実行できるという説明ではありません。

【どう対応する？】
SSHを使える人や端末を制限する。
メモリ使用量や異常終了を監視する。

この問題は、転送をOFFにするだけで解決するとは限りません。

━━━━━━━━━━━━
⑥ 登録処理や中継処理の負荷で、利用できなくする
C2/C4＋C3
━━━━━━━━━━━━

【何が問題？】
headscaleの端末登録に関係する処理や、DERPという通信中継の処理で、メモリなどの資源を使い果たすという複数の指摘です。

【どこまで確認済み？】
研究者の報告段階で、それぞれ条件が違います。

・認証済みの内部利用者が起点になるケース
・公開された登録用の入口に、認証前から要求を送るケース
・悪意ある中継サーバーの応答が必要なケース

そのため、「今回の問題はすべてSSHの認証後にしか起きない」とまとめるのも正確ではありません。

なお、「正規の端末が登録できなくなる」と「攻撃者が不正登録できる」は別です。

【どう対応する？】
自前でheadscaleを運用している場合は、入口への要求数の制限、メモリ監視、中継サーバーの設定確認を行います。

━━━━━━━━━━━━
⑦ 管理用の窓口を、Serveで公開してしまう
SERVE-F1
━━━━━━━━━━━━

【何が問題？】
Serveは、端末上のサービスをTailscaleのネットワーク内へ公開する機能です。

その転送先をLocalAPIなどの管理用socketにすると、そこへ到達できる相手に管理操作を許してしまうおそれがあります。

【どこまで確認済み？】
危険な転送設定と、そこへ到達できる接続許可を前提にしたラボ報告です。

Serveを使っているだけで、全員に同じ問題が起きるという話ではありません。

【どう対応する？】
Serveの転送先を確認する。
管理用socketへの転送があれば取り除きます。

━━━━━━━━━━━━
⑧ 設定時には安全でも、後から転送先を差し替える
SERVE-F2
━━━━━━━━━━━━

【何が問題？】
Serveを設定したときの検査を通過した後で、socketの参照先を差し替えるという指摘です。

その端末内で、対象の場所を書き換えられる権限が必要です。

【どこまで確認済み？】
研究者の検証では、LocalAPIへの実際の操作は、別の検査によって403、つまり拒否されました。

ほかの強い権限を持つsocketへの懸念は残りますが、「LocalAPIを完全に突破できた」と説明するのは不正確です。

【どう対応する？】
socketと、その置き場所の書き込み権限を確認する。
信頼できない利用者が差し替えられる場所を、転送先として使わないようにします。

━━━━━━━━━━━━
⑨ インターネット公開の許可判定に食い違いがある
SERVE-F3
━━━━━━━━━━━━

【何が問題？】
Funnelは、サービスをインターネットへ公開する機能です。

公開してよいかの判定が、操作用コマンドと、裏で動く常駐プログラムとで一致していないという指摘です。

【どこまで確認済み？】
実際の公開には、ほかの条件も必要です。

通常のheadscaleでは必要な中継側の許可を発行できず、ラボでは特別なテスト設定で代用しています。

「本番環境で誰もが勝手に公開できる」とまでは実証されていません。

【どう対応する？】
不要なFunnelやテスト用設定が残っていないか確認する。
公開するアプリには、そのアプリ自身の認証も設けます。

━━━━━━━━━━━━
⑩ 特別な設定によって、公開範囲がLANまで広がる
SERVE-F4
━━━━━━━━━━━━

【何が問題？】
TS_SERVE_ALLOW_ALL_INTERFACESという非標準の設定を使うと、家庭や社内のLANなどからもサービスに届く可能性があります。

Tailscale経由の接続だけを想定していると、公開範囲を見誤ります。

【どこまで確認済み？】
これは、コードの確認に基づく設定上の注意点です。
実際のLANからのアクセス検証は行われていません。

通常の既定設定で、全利用者に起きるという話ではありません。

【どう対応する？】
不要なら、この設定を外す。
必要なら、通信制限とアプリ側の認証を設けます。

━━━━━━━━━━━━
⑪ 別の公開先に、権限情報が混ざる
SERVE-F5
━━━━━━━━━━━━

【何が問題？】
HTTP/2では、1つの接続で複数の通信を並行して処理します。

その際、ある公開先向けに渡す権限情報が、別の公開先への処理に混ざる問題です。

アプリがその情報を信頼してアクセスを許可していると、意図しない許可につながる懸念があります。

【どこまで確認済み？】
複数の公開先があり、それぞれ権限設定が異なるなどの条件があります。

この問題に対応する修正PR #21931は統合済みで、実装上の問題だったことを強く裏付けています。

ただし、「開発用コードに修正が入った」と「手元で使っている製品が修正済み」は別です。

調査時点では、安定版v1.104.2で当該修正を利用できるとは確認できていません。

【どう対応する？】
機密性の高い公開先へのアクセスを絞る。
アプリ自身でも認証・権限確認を行う。
修正を含むバージョンが配信されたか確認します。

━━━━━━━━━━━━
では、利用者は何から確認する？
━━━━━━━━━━━━

まずは、この順番です。

① Tailscale SSHを使っているか確認する

Tailscale本体を使っていることと、Tailscale SSHを使っていることは別です。

Tailscale経由で通常のOpenSSHを使う構成もあります。今回の組み込みSSHの問題と混同しないようにします。

② 接続できる人・端末・接続先を絞る

「同じネットワークにいるから全部許可」になっていないか確認します。

自分の端末だけで使っていても、そのうち1台が侵害される可能性はあります。

③ 不要なSSH転送を止める

公式案内には、TS_SSH_DISABLE_FORWARDING=1で転送を無効にする方法があります。

これは管理者向けの設定です。tailscaledというサービスの実行環境に設定し、再起動する必要があります。

手元のターミナルでexportするだけでは反映されません。作業時は、接続が切れても管理できる経路を確保しておきます。

④ Serve・Funnel・headscaleは、使っている場合に個別確認する

11項目すべてが、全利用者に当てはまるわけではありません。

まず利用機能を確認し、関係する設定から見直すのが現実的です。

⑤ 公式の修正情報を追い、対象の更新を適用する

「最新版にした」だけで、今回の全項目が修正されたと判断しないこと。

headscale v0.29.6への更新も、それだけで全件解決の証拠にはなりません。

なお、SSHのcheck modeは追加の本人確認、Tailnet Lockは不正な端末追加への保護です。

どちらも役立ちますが、今回の権限の問題そのものを修正する機能ではありません。

Tailscale社は調査時点で、全利用者にTailscale SSHの停止を勧めてはいません。ただし、それは「何も確認しなくてよい」という意味でもありません。

判断するときは、

「研究者が報告した」
「提供元が確認した」
「修正コードができた」
「修正版が配信された」
「自分の環境に適用した」

この5つを分けて見ると、過度に怖がることも、安心しすぎることも避けやすくなります。

[1UP @_oneup_]

https://t.co/K3tidWsDMR

ホワイトハッカーあつめても、AIによる脆弱性発見の方が早い、やすいで意味がない。
それより、どうやって公表された脆弱性の適用をどうやって早く広範囲に適用できるような環境や支援ができるかが大事とおもう。これってホワイトハッカーいなくてもできると思うのだけど。

[Koder @koder_dev]

バイブコーディング6週間続けたらMacの起動が20分かかるようになった話、他人事じゃなさすぎて笑えない..

原因、/tmpにClaude Codeの作業ファイルが99万個溜まってたらしい

速く作るための仕組みが別の場所で負荷になるの、めっちゃありそうで怖い

自分のMacもあとで見る
https://t.co/rnDCjrXE0a

[AIDB @ai_database]

研究者らによると、CLAUDE.mdやAGENTS.mdにあらかじめ次の一文を足すことが推奨されます。
「ドキュメントと既存のコードが食い違うときはコードの書き方に従い、見つけた食い違いを最後の返答ですべて挙げること」

なぜか。
Claude CodeやCodexは、CLAUDE.mdやAGENTS.mdの記述が今のコードと食い違っていると、9割がた古い記述のほうに従うそうです。"指示が古い"と気づいていても抗えない仕組みです。

この発見に至るまでに、ジョージア工科大などの研究者らは、設定ファイルとコードがわざと食い違う40のプロジェクトでClaude CodeとCodexに機能を足させて調べました。

Claude Codeは80回中79回、食い違いに気づいたと"自分で書きながら"、古い情報に流されました。
Codexのほうは、80回中20回で、動いていた既存のコードを古い記述に合わせて書き換え、うち17回でテストが通らなくなりました。

研究者らの見立てとしては、AIは、指示を優先するよう訓練されています。CLAUDE.mdやAGENTS.mdは「指示」としてAIに渡り、コードはファイルを読んだ「結果」として渡るのが原因だと言います。その仕組みが、古いものに従わせるのだとか。

そして設定ファイルは一度書いたきりになりやすい傾向があります。更新不精の人は上の一文をあらかじめ追加しておくのも一つです。

指示の原文→"When a repository's documentation and its existing code disagree, follow the conventions used in the existing code, and in your final reply point out each inconsistency you found between the documentation and the code."

[1UP @_oneup_]

これも該当の可能性。
連絡来てないけどこれからなのかな？？

[NHKニュース @nhk_news]

アパレル大手「アンドエスティ」客の個人情報約250万件流出か
https://t.co/LvRJKKB3wv #nhk_news

[山口健太 / Kenta Yamaguchi @yamaguc_k]

タイムズカー

運転免許証等の画像が漏洩した人にお見舞い金として「3000円」相当の現金または金券を渡すとのこと

[Roku Masuda｜KIVI Ltd. @RokuMasuda]

高市首相のポスト、現場のエンジニアにとってこれ以上ない後方支援だったと思います。

普段、経営層やクライアントに「CVEが〜」と危険性を説明しても、「で、今すぐサイトを止める必要があるの？」と渋られるのが現場の常だろうけど、

このポストのスクショを1枚貼って「総理大臣から緊急要請が出ています」と言えば、どんなにITリテラシーが低い決裁者でも、一発で事の重大さを理解できるし、夜間作業やメンテナンス停止の稟議が秒で通る。

あと、サイトの一時停止という踏み込んだ選択肢を国のトップが肯定してくれたことも画期的（エンジニア側から最も切り出しにくい提案なのに）。

そして、何より記者会見みたいなプロセスを踏まず、界隈が最もリアルタイムに張り付いているXで
@cyber_forecast
への導線を添えて直接投げたのも、危機管理のコミュニケーションとして非常にスマートだったと感じました。

ありがとうございました。これを批判してる人がいるのは絶対におかしいです。

[1UP @_oneup_]

@PFU_HHKB 33万はたかい。格好良いけど

[1UP @_oneup_]

えっ！！これは行きたい

https://t.co/dlMIY9FD0P

[1UP @_oneup_]

これ、ローカルLLMとしての利用も禁止ってことですよね？「すでに導入されている関連製品やサービスを情報システムから削除するよう命じる」って書いてあるし。Hugging Faceからもだめでしょうね。GLMもだめになるのかなぁ。そのうち。

[NHKニュース @nhk_news]

アメリカ政府 民生部門で中国AIのディープシーク利用禁止に
https://t.co/cFYPsAuFPx #nhk_news

[1UP @_oneup_]

これ、アマプラでRedmi Pad2 9.7と一緒に高2うしたのに、いつまでも発送日が決まらない、、、。今は11インチしか販売してないしなぜ？！
VENINGO REDMI Pad 2 9.7/Pad 2 9.7 4G ケース (2026モデル) マグネッ…｜特徴と購入前の確認ポイント https://t.co/bN1yC9CaKO