「apt list --upgradableを実行して何も出なければ大丈夫」と思っていませんか。実はunattended-upgrades（自動更新の仕組み）が動いていても、対象外のパッケージや設定ミスで重要な更新が取り残されていることがあります。2026年7月には、Linuxカーネルのroot権限昇格の脆弱性「RefluXFS」（CVE-2026-64600）がAIの支援で発見され、世界で1,640万台以上に影響しうると報告されました。修正済みカーネルはすでに配布されていますが、「配布されている」ことと「自分の環境に当たっている」ことは別問題です。この記事では、apt list --upgradableの出力と/var/log/unattended-upgrades/のログを突き合わせて、自動更新が本当に機能しているかをコマンドだけで点検する手順を、Ubuntu/Debian初心者向けに解説します。

なぜ「自動更新が有効」なだけでは安心できないのか

2026年はLinux界隈でパッチ管理まわりの話題が続きました。Linux Foundationは2026年6月26日、AWS・Google・Microsoft・Red Hat・Anthropicなど主要企業が参加する脆弱性対応の共同イニシアチブ「Akrites」を発足させています。背景には、AIによる脆弱性発見が急増しているという事情があります。Qualysは2017年のカーネル4.11から9年間も見過ごされていたRefluXFS（CVE-2026-64600）をAI（Anthropic「Claude Mythos」の支援）で発見したと報告しました。

こうした脆弱性が報道されるたびに「うちのサーバーは大丈夫か」と不安になりますが、確認すべきは「パッチが出たかどうか」ではなく「自分の環境に実際に適用されたかどうか」です。unattended-upgradesを入れているから安心、ではなく、次の手順で実際の状態を見ていきます。

まず自動更新の仕組みが動いているかを確認する

タイマーが有効か・最後にいつ動いたか

unattended-upgrades本体は、systemdのタイマーから定期的に呼び出されます。まずこのタイマーが生きているかを見ます。sudoは不要です。

systemctl list-timers apt-daily-upgrade.timer apt-daily.timer

何を見ているか：自動更新を起動するタイマーが「次にいつ動くか（NEXT）」「最後にいつ動いたか（LAST）」を表示します。

NEXT                        LEFT     LAST                        PASSED   UNIT
Thu 2026-09-04 07:41:23 JST 5h left  Wed 2026-09-03 07:32:10 JST 22h ago  apt-daily-upgrade.timer
Thu 2026-09-04 06:12:05 JST 4h left  Wed 2026-09-03 06:08:55 JST 23h ago  apt-daily.timer

判断のポイント：LASTが1〜2日以内なら正常に動いています。LASTが1週間以上前だったり、コマンド自体が「見つかりません」となる場合は、タイマーが無効化されているかunattended-upgradesパッケージ自体が入っていない可能性があります。その場合はsudo apt install unattended-upgradesで導入し、sudo dpkg-reconfigure unattended-upgradesで有効化してください（設定ファイルを作るだけで、既存の環境を壊す変更ではありません）。

自動更新の設定ファイルを確認する

cat /etc/apt/apt.conf.d/20auto-upgrades

何を見ているか：パッケージ一覧の自動更新と、実際のアップグレードそれぞれが有効（"1"）か無効（"0"）かの設定です。

APT::Periodic::Update-Package-Lists "1";
APT::Periodic::Unattended-Upgrade "1";

判断のポイント：どちらかが"0"になっている、またはファイル自体が存在しない場合は自動更新が止まっています。編集前にsudo cp /etc/apt/apt.conf.d/20auto-upgrades ~/20auto-upgrades.bakでバックアップを取ってから、sudo dpkg-reconfigure -plow unattended-upgradesで設定し直すと元に戻しやすい形で修正できます。

apt list --upgradableで「今止まっている更新」を洗い出す

apt list --upgradable

何を見ているか：手元のパッケージ一覧（apt update済みの情報）と比べて、まだ適用されていない更新の一覧です。sudo不要で、この時点ではシステムに何も変更を加えません。

Listing... Done
libssl3/jammy-updates,jammy-security 3.0.2-0ubuntu1.15 amd64 [アップグレード可: 3.0.2-0ubuntu1.16 から]
openssh-server/jammy-updates,jammy-security 1:8.9p1-3ubuntu0.7 amd64 [アップグレード可: 1:8.9p1-3ubuntu0.10 から]
linux-image-generic/jammy-updates 5.15.0.135.135 amd64 [アップグレード可: 5.15.0.136.136 から]

判断のポイント：出力に「-security」が付いたパッケージ（上の例だとjammy-security）があれば、それはセキュリティ修正が待機中という意味です。件数が多いこと自体より、-securityが数日〜数週間残り続けているかどうかが重要です。自動更新が正常なら、-security付きのパッケージは次のタイマー実行までに消えるはずだからです。

/var/log/unattended-upgradesのログと突き合わせる

「apt list --upgradableには残っているのに、自動更新のログでは何も処理されていない」という食い違いが、まさに取り残しのサインです。

ls -la /var/log/unattended-upgrades/

何を見ているか：自動更新の実行記録が残るディレクトリです。主にunattended-upgrades.log（判断ログ）とunattended-upgrades-dpkg.log（実際にdpkgが行った処理）の2つがあります。

grep "Starting unattended upgrades" /var/log/unattended-upgrades/unattended-upgrades.log | tail -5
tail -n 30 /var/log/unattended-upgrades/unattended-upgrades.log
2026-09-03 07:32:03,558 INFO Starting unattended upgrades script
2026-09-03 07:32:04,201 INFO Allowed origins are: origin=Ubuntu,codename=jammy-security
2026-09-03 07:32:05,880 INFO No packages found that can be upgraded unattended and no pending auto-removals

判断のポイントは2つです。

  • 実行日時がapt list --upgradableを見た日から極端に離れていないか（1〜2日以内が目安）
  • 「No packages found」なのに、apt list --upgradableには-security付きの更新が残っていないか（残っていれば、そのパッケージがAllowed originsの対象外になっている可能性が高い）

Allowed originsの対象は/etc/apt/apt.conf.d/50unattended-upgradesのUnattended-Upgrade::Allowed-Originsで決まります。${distro_id}:${distro_codename}-securityの行がコメントアウトされていないかを確認してください（先頭に//が付いていると無効です）。ここも編集前にバックアップを取れば元に戻せます。

異常が見つかったときにやること・ディストリごとの違い

手動で当てる・再起動が要るか確認する

取り残しを見つけたら、まず手動で追いつかせます。

sudo apt update
sudo apt upgrade

実行前に更新対象の一覧が表示され、確認を求められるので内容を見てから進められます。カーネル（linux-image-*）が含まれていた場合は、適用後に再起動が必要かどうかを次のコマンドで確認できます。

cat /var/run/reboot-required 2>/dev/null
cat /var/run/reboot-required.pkgs 2>/dev/null

このファイルが存在すれば再起動待ちの状態です。RefluXFSのようなカーネルの権限昇格脆弱性は、パッケージを更新しただけでは実際には直っておらず、再起動して新しいカーネルで起動し直すまで有効になりません。すぐに再起動できない場合は、Ubuntuならsudo canonical-livepatch statusでLivepatch（再起動なしでカーネルの脆弱性修正を当てる仕組み）が有効か確認できます。Ubuntu 26.04 LTSではArm系サーバー向けにもLivepatchの対応が広がっています。

Ubuntu/Debianでの違い

項目

Ubuntu（22.04/24.04/26.04）

Debian（12/13）

自動更新パッケージ

unattended-upgrades（既定で導入済みのことが多い）

unattended-upgrades（手動導入が必要な場合あり）

ログの場所

/var/log/unattended-upgrades/

同じ

ポイントリリース

26.04 LTS "Resolute Raccoon"（2026年6月）

13.6（2026年7月11日、Debian 13のセキュリティ修正まとめ）

2026年時点の注意点

sudo等の一部コマンドがRust実装（sudo-rs等）に置き換わりつつあるが、通常操作の出力形式は互換

ブラウザ系パッケージの対応状況はdebian-security-supportで別途確認が必要

Debianを使っている場合は、現在のポイントリリースを次のコマンドで確認できます。

cat /etc/debian_version

「13.6」のように表示されれば7月時点までのセキュリティ修正を含んだインストールメディア相当ですが、それ以降に出た更新は別途apt側の点検が必要です。バージョン番号が古い場合も、日々のapt upgradeが正常に効いていれば内容は最新に追いついているので、この記事の手順の方が実態に近い確認になります。

今回のようにroot権限昇格が絡む脆弱性が話題になったタイミングでは、更新の取りこぼしだけでなく、すでに侵入や不審な操作の痕跡がないかも合わせて見ておくと安心です。SSHへの総当たり攻撃の兆候はSSH総当たり攻撃をjournalctlで即検知2026年9月版、不審なSUID/Capability付きファイルの有無はSUID/Capability権限昇格チェック2026年8月版で具体的な手順を紹介しています。

週1回、この2行を合言葉にする

apt list --upgradableと/var/log/unattended-upgrades/のログ、この2つを見比べる習慣があれば、「自動更新を入れているから安心」という思い込みに気づけます。特に-security付きのパッケージが何日も残っていたり、ログの実行日時が数日以上前で止まっていたりする場合は、設定ファイル（20auto-upgrades・50unattended-upgrades）の見直しどきです。編集前にバックアップを取っておけば、いつでも元の状態に戻せます。カーネルの更新は再起動して初めて有効になる点も忘れず、/var/run/reboot-requiredもあわせて確認してください。