この記事の監修：宮崎智広（Linux実務・教育歴20年以上・受講者3,100名超）
私は20年以上Linuxサーバーの現場にいますが、OpenSSLの一斉修正で毎回つまずきやすいのは脆弱性の理解ではなく「upstream版数とディストリのパッケージ版数が一致しない」点と「更新しても再起動するまで古いライブラリがメモリに居座る」点の2つです。この記事はそこを運用手順とコマンド中心で整理します。
この記事のポイント
- OpenSSL公式advisoryのCVEは16件（High 1、Moderate 6、Low 9）。報道では18件とする集計もあるが、即時対応の判断軸はHighの1件に絞ってよい。
- 最重要はCVE-2026-45447（High、PKCS7_verify()のheap use-after-free、S/MIME署名処理経路でRCEリスク）。影響は4.0.0～1.0.2の全系列。
- upstream版数（4.0.1等）を直接見るのではなく、
rpm -q openssl/dpkg -l openssl＋RHSA/USNで「ディストリが当てたか」を判断する。 - 動的リンクのため、
libssl/libcryptoを使う常駐プロセス（httpd / nginx / postfix / dovecot / openvpn / sshd等）はパッケージ更新後に再起動が必要。needs-restarting -r/checkrestart/lsofで判定する。
でも安心してください。プロのエンジニアはコマンドを暗記していません。
「現場で使える型」を効率よく使いこなしているだけです。
何が起きたか――16件の位置づけとHigh 1件への絞り込み
OpenSSL公式のvulnerabilitiesページと2026年6月9日付のセキュリティアドバイザリで、16件のCVEがまとめて修正されました。内訳はHigh 1件、Moderate 6件、Low 9件。日本の一部報道ではこれを18件と数える集計もありますが、これは重大度や派生CVEの数え方の差で、公式advisoryの正式掲載は16件です。件数の枝葉に振り回されず、即時対応はHighの1件を主役に据えるのが現場の判断として正解です。最重要はCVE-2026-45447（High）。
PKCS7_verify()でのheap use-after-freeです。PKCS#7 / S/MIME署名メッセージを処理する際、SignedDataのdigestAlgorithmsフィールドが空のASN.1 SETとして渡されると、OpenSSLが呼び出し元アプリケーション所有のBIOを誤って解放し、その後アプリがそのBIOを使った時点でuse-after-freeになります。条件次第ではクラッシュ・ヒープ破壊、最悪はリモートコード実行に至り得ます。影響範囲は4.0.0～1.0.2と全系列にまたがり、今回すべての系列で修正されました。なお、署名処理にCMS APIを使っているアプリは影響対象外です。Moderate級では、QUICの
PATH_CHALLENGEハンドラでの無制限メモリ増加によるDoS（CVE-2026-34183、影響4.0.0～3.4.0）、CMSのAuthEnvelopedData処理の入力検証不備によるkey-equivalent forgery（CVE-2026-34182、影響4.0.0～3.0.0）あたりが気に留めておく対象です。ただし、外向きにS/MIME署名検証やメール経路でOpenSSLを通すサーバーでなければ、まずHighの45447を塞ぐことを最優先にして問題ありません。各CVEの一次情報はOpenSSL公式のvulnerabilities一覧で確認してください。まず「自分のサーバはどの版か」をrpm/dpkgで確認する
脆弱性対応の最初の一手は、上流のリリースノートを眺めることではなく、手元のサーバーが今どのパッケージ版数を持っているかを実測することです。# RHEL / AlmaLinux / Rocky / CentOS Stream 系 $ rpm -q openssl openssl-libs $ openssl version -a # Ubuntu / Debian 系 $ dpkg -l | grep -E 'openssl|libssl' $ openssl version -a
opensslパッケージに修正だけをバックポートします。Ubuntu / Debianも同様です。openssl versionが「3.0.13」と出ているからといって「3.0.21より古いから未対策」と早合点してはいけません。「当たったか」を判断する正しい軸は、ディストリのセキュリティアドバイザリ番号です。RHEL系ならRHSA、Ubuntu系ならUSN。次のコマンドで、自分のパッケージにCVE修正が含まれたかを直接確認できます。
# RHEL系: CVE単位でパッケージが当たっているか $ dnf updateinfo info --cve CVE-2026-45447 $ rpm -q --changelog openssl | grep -i 'CVE-2026-45447' # Ubuntu系: changelogでCVE出現を確認 $ apt changelog openssl 2>/dev/null | grep -i 'CVE-2026-45447'
PR / サーバー防衛の基本を体系で押さえたい方へ
Linuxサーバーセキュリティ徹底入門 オープンソースによるサーバー防衛の基本 中島 能和 / 翔泳社
暗号の基礎・OS設定・サービス設定までを横断し、「なぜそのパッチを当てるのか」「何を守っているのか」を腰を据えて学べる一冊。OpenSSLの当て方を手順だけで終わらせず、防御の地図として腹落ちさせたい人に向きます。
RHEL / AlmaLinux / Rocky系の当て方
RHEL系はdnf（旧yum）で当てます。最小手数はopensslとopenssl-libsを更新するだけですが、セキュリティ単位で当てたい場合は--securityやupdateinfoを使います。# 利用可能なセキュリティ更新の一覧（OpenSSL関連を確認） $ dnf updateinfo list security available | grep -i openssl # OpenSSLパッケージのみ更新 $ sudo dnf update openssl openssl-libs # セキュリティ更新だけまとめて当てる場合 $ sudo dnf update --security # CVE指定で当てる（RHSAが出ている前提） $ sudo dnf update --advisory=RHSA-2026:xxxx
rpm -q --changelog openssl | headで該当CVEがchangelogに入っているかを再確認します。RHSA番号はRed Hatのセキュリティアップデート一覧、AlmaLinuxはAlmaLinux Errata、RockyはRocky Linux Errataで確認できます。ディストリごとにRHSAの取り込みタイミングが数時間～1日ずれることがあるため、本番反映前にステージングで先に当てて検証するのが安全です。EPEL等のサードパーティリポジトリから別系列のopensslを入れている場合は、ディストリ標準パッケージとは更新経路が別になります。
dnf list installed 'openssl*'でリポジトリ列を確認し、どこから来たパッケージかを把握しておきます。Ubuntu / Debian系の当て方
Ubuntu / Debian系はaptで当てます。libssl3（24.04等）やlibssl1.1（古い系列）といったライブラリパッケージが実体なので、opensslコマンドパッケージだけでなくライブラリ側も上がっているかを見ます。$ sudo apt update # 何が上がるか先に確認 $ apt list --upgradable 2>/dev/null | grep -E 'openssl|libssl' # OpenSSL関連だけ当てる $ sudo apt install --only-upgrade openssl libssl3 # セキュリティ更新をまとめて当てる場合 $ sudo apt upgrade
dpkg -l libssl3）を突き合わせます。apt changelog openssl | grep CVE-2026-45447でchangelogにCVEが出ていれば、そのパッケージは対策済みです。ESM（Expanded Security Maintenance）対象の古い系列を使っている場合は、Ubuntu ProのアタッチがないとUSNが降ってこないことがあります。
sudo pro statusでESMが有効かを確認しておきます。DebianはDebian Security Advisory（DSA）が一次情報です。
動的リンク先プロセスの再起動判断――ここが一番抜けやすい
ここがOpenSSL更新の最重要かつ最も抜けやすいポイントです。libssl / libcryptoは動的ライブラリなので、パッケージを更新してもすでに起動済みの常駐プロセスはメモリ上に古いライブラリを抱えたまま走り続けます。apache（httpd）、nginx、postfix、dovecot、openvpn、sshdあたりはほぼ確実にlibsslをリンクしています。更新しただけで「対策完了」と報告するのは事故のもとです。「どのプロセスを再起動すべきか」は推測せず実測します。
# RHEL系: 再起動が必要なサービスを列挙（dnf-utils / yum-utils） $ sudo needs-restarting -r ; echo "exit=$?" # 1ならカーネル更新で再起動推奨 $ sudo needs-restarting -s # 再起動が必要なサービス一覧 # Ubuntu / Debian系: 古いライブラリを掴んだプロセスを列挙（debian-goodies） $ sudo checkrestart # ディストリ非依存: 解放済み(deleted)のlibsslを掴んでいるプロセス $ sudo lsof -n 2>/dev/null | grep -E 'libssl|libcrypto' | grep -i deleted
lsofで(deleted)付きのlibsslを掴んでいるプロセスが出てきたら、それが「古いOpenSSLでまだ動いている」プロセスです。該当サービスを再起動して掴み直させます。# 例: 検出されたサービスだけを順に再起動 $ sudo systemctl restart httpd # または nginx $ sudo systemctl restart postfix dovecot $ sudo systemctl restart openvpn-server@server # sshd は restart でも既存セッションは維持される（安全） $ sudo systemctl restart sshd
sshdの再起動は既存のSSHセッションを切らないので、自分のPCから入っている接続が落ちる心配は基本ありません。ただし設定ミスがあると次回ログインが弾かれるため、再起動前に別の端末でログインできることを確認してから当てるのが鉄則です。postfix / dovecotのようなメール系は再起動タイミングで瞬断するため、メールキューを確認しつつ低トラフィック時間帯に回します。プロセス単位で個別に直すのが面倒で、計画的にメンテ枠が取れるなら、
sudo rebootで一括リフレッシュするのが確実です。再起動判断は「needs-restarting / checkrestart / lsofで実測 → 該当サービスのみ再起動か、まとめてreboot」の二択で組み立てます。検証――本当に当たったか、再起動後に確認する
当てて再起動したら、必ず効果を確認します。確認は「パッケージ版数」「changelogのCVE」「掴み直しの有無」の3点です。# 1) パッケージ版数とビルド日 $ openssl version -a $ rpm -q openssl openssl-libs # RHEL系 $ dpkg -l libssl3 # Ubuntu系 # 2) changelogにCVEが入ったか（ディストリ基準の真偽） $ rpm -q --changelog openssl | grep -i CVE-2026-45447 # RHEL系 $ apt changelog openssl | grep -i CVE-2026-45447 # Ubuntu系 # 3) 古いlibsslを掴んだプロセスが残っていないか（ゼロが正常） $ sudo lsof -n 2>/dev/null | grep -E 'libssl|libcrypto' | grep -i deleted # 4) 主要サービスが新しいライブラリで動いているか $ sudo needs-restarting -s # 何も出なければOK
(deleted)付きが残っていれば、再起動し忘れたサービスがあるということです。ここがゼロになって初めて「OpenSSL更新が完了した」と言えます。本番機ではこの4ステップをチェックリスト化し、サーバーごとに記録を残しておくと、次回の一斉修正のときに同じ手順で淡々と回せます。
今回の教訓――版数の暗算をやめ、再起動まで含めて1セットにする
OpenSSLの一斉修正は今後も定期的に来ます。今回の16件対応を通して、運用者として持ち帰るべき型は2つです。1つ目は「upstream版数の暗算をやめる」こと。4.0.1や3.0.21というupstreamの数字とディストリのパッケージ版数は一致しません。
rpm -q --changelog / apt changelogのCVE出現と、RHSA / USNを真偽の判断軸にします。2つ目は「パッケージ更新と再起動を分けて考えない」こと。動的リンクである以上、更新だけでは古いライブラリがメモリに残ります。
needs-restarting / checkrestart / lsofで掴み直しを実測し、該当サービスの再起動までを必ず1セットにします。この2つを型にしておけば、次の一斉修正でも「確認 → 当てる → 再起動 → 検証」の同じ流れで安全に処理できます。一次情報は必ず公式（下記参考リンク）を開いて確認してください。PR / あわせて読みたい本
- ［試して理解］Linuxのしくみ 増補改訂版 武内 覚 / 技術評論社
- Linuxサーバーセキュリティ徹底入門 オープンソースによるサーバー防衛の基本 中島 能和 / 翔泳社
動的ライブラリやプロセスの仕組みを実験ベースで押さえる1冊と、サーバー防御の基本を体系で押さえる1冊。「なぜ再起動が要るのか」「何を守っているのか」を腹落ちさせるとパッチ運用の判断が速くなります。
- OpenSSL Vulnerabilities: https://openssl-library.org/news/vulnerabilities.html
- Red Hat Security Updates: https://access.redhat.com/security/security-updates/
- AlmaLinux Errata: https://errata.almalinux.org/
- Rocky Linux Errata: https://errata.rockylinux.org/
- Ubuntu Security Notices: https://ubuntu.com/security/notices
- Debian Security: https://www.debian.org/security/
OpenSSLのパッチ運用、確認から再起動・検証まで自信を持って回せていますか？
rpm -q --changelog、dnf updateinfo、apt changelog、needs-restarting、checkrestart、lsof で deleted を掴むプロセスの掃除。読むだけでなく、実機で繰り返し手を動かすことで初めて身につきます。
ネットの切れ端の情報をコピペするだけでなく、現場で通用する安全なLinuxサーバー構築の「型」を体系的に身につけたい方へ、『Linuxサーバー構築入門マニュアル（図解60P）』を完全無料でプレゼントしています。
「独学の時間がもったいない」「プロから直接、現場の技術を最短で学びたい」という本気の方には、2日で実務レベルのスキルが身につく【初心者向けハンズオンセミナー】も開催しています。
3,100名以上が実践した「型」を無料で公開中
プロのエンジニアはコマンドを暗記していません。
「現場で使える型」を効率よく使いこなしているだけです。
その「型」を図解60Pにまとめた入門マニュアルを、完全無料でプレゼントしています。
登録10秒／合わなければ解除3秒 ／ 詳細はこちら
この記事を書いた人
宮崎 智広（みやざき ともひろ）
株式会社イーネットマーキュリー代表。現役のLinuxサーバー管理者として20年以上の実務経験を持ち、これまでに累計3,100名以上のエンジニアを指導してきたLinux教育のプロフェッショナル。「現場で本当に使える技術」を体系的に伝えることをモットーに、実践型のLinuxセミナーの開催や無料マニュアルの配布を通じてLinux人材の育成に取り組んでいる。
趣味は、キャンプにカメラ、トラウト釣り。好きな食べ物は、ラーメンにお酒。休肝日が作れない、酒量を減らせないのが悩み。最近、ドラマ「フライトエンジェル」を観て涙腺が崩壊しました。
無料メルマガで学習を続ける
Linuxの実践スキルをメールで毎週お届け。
登録は1分、解除もいつでも可。
登録無料・いつでも解除できます