cPanelやWHMを使ってサーバーを運用している人にとって、かなり嫌なニュースです。
Copahostの記事が伝えているのは、cPanelがまた緊急のセキュリティ修正を出したという話です。しかも今回は、ただの小さな修正ではありません。
2026年5月8日、cPanelは3つの新しい脆弱性を修正しました。
このうち2件はCVSS 8.8で、危険度はHigh。
CVSSは脆弱性の深刻さを数値化したものですが、ざっくり言うと8点台後半はかなり危ない部類です。Criticalの一歩手前ですから、悠長に構えている場合ではありません。
しかも、今回の修正は10日間で2回目の緊急セキュリティリリース（TSR）だそうです。
これはかなり異例です。普通、ここまで短期間に緊急パッチが連発するのは、かなりまずい兆候です。個人的には、この時点で「cPanel内部で相当あわてて調査しているな」と感じます。いや、むしろそうせざるを得ない状況なのでしょう。
記事には Technical Security Release（TSR） という言葉が出てきます。
これはcPanelが使っている、緊急のセキュリティ修正を配る仕組みです。
難しく聞こえますが、要するにこういうことです。
という流れです。
セキュリティの世界では、修正が出る前に攻撃者へ情報が漏れるのが一番まずいので、詳細はギリギリまで伏せられます。今回も、5月7日に事前通知が行われ、5月8日12:00 ESTにパッチが出たとされています。
これは任意のファイルを読めてしまう脆弱性です。
記事によると、feature::LOADFEATUREFILE という管理者向けの呼び出しで、feature file name の入力チェックが不十分だったのが原因です。
攻撃者は、本来読めないはずのファイルを読める可能性があります。
たとえば、
などが漏れると、次の攻撃につながります。
この手の脆弱性は、単体では「そこまで派手じゃない」と見られがちです。
でも実際には、侵入口というより“情報収集の穴”として非常に危険です。攻撃者は、こういう地味な穴からじわじわ本丸に迫ってきます。地味だけど怖い、典型例だと思います。
これは今回の3件の中で、かなり危険です。
create_user API の plugin パラメータのチェックが不十分で、任意のPerlコードを実行できる可能性があるとされています。
Perl code execution というのは、ざっくり言うとサーバー上で勝手にプログラムを動かされる状態です。
しかも「認証済みアカウントの system user として」実行されるので、共有サーバーでは特に厄介です。
共有ホスティングでは、1台のサーバーを複数の利用者で共有しています。
つまり、1人の利用者の権限が突破口になって、同居している他人の領域や、場合によってはサーバー全体に影響する可能性があります。
記事ではこの脆弱性を最も危険としていますが、私もその見方にはかなり同意です。
「認証が必要」と聞くと少し安心してしまいがちですが、共有環境では**“認証済みのどこかのアカウント”がある時点で十分に危ない**のです。
こちらはunsafe symlink handling、つまりシンボリックリンクの扱いが危険な脆弱性です。
シンボリックリンクは、ファイルやディレクトリへの“ショートカット”のようなものです。便利ですが、扱いを間違えると事故のもとになります。
攻撃者がシンボリックリンクを使って、本来触れないはずのファイルに対して chmod を起こさせることで、権限を変えられる可能性があります。
その結果として起こりうるのは、
といった問題です。
記事では、CVE-2026-29202 と組み合わせると、
コード実行 → シンボリックリンク作成 → chmod悪用
という連鎖で、より深い侵害につながる可能性があるとしています。
この「単体ではそこまででも、組み合わせるとヤバい」というのが、セキュリティの面白くて怖いところです。攻撃者はいつも、1発逆転ではなく小さな穴のつなぎ合わせを狙ってきます。
ここが今回の記事で一番重要です。
今回の3件は単独で見ても危険ですが、背景にある出来事を知ると、もっと重く見えてきます。
その前の2026年4月28日、cPanelはCVE-2026-41940の緊急修正を出していました。
これは認証回避（authentication bypass）の脆弱性で、未認証の攻撃者が管理者権限を取れてしまうというかなり深刻なものです。CVSSは9.8で、ほぼ最上位クラスです。
しかもこの脆弱性は、ゼロデイとして実際に悪用されていたとされています。
ゼロデイとは、修正が出る前に攻撃される脆弱性のことです。
記事によれば、攻撃の痕跡は2026年2月下旬までさかのぼるとのこと。
つまり、攻撃者は修正が出るよりかなり前から動いていたわけです。これは本当に厄介です。
さらに、少なくとも44,000台のIPアドレスが侵害されたとされ、攻撃者はGo製のLinux encryptorを使って、「Sorry」というランサムウェアを展開したと説明されています。
この数字はかなり重いです。
4万4千台というのは、もはや「数台の事故」ではありません。Webホスティング基盤の信頼性そのものを揺さぶる規模です。
記事の主張はかなり明快です。
最初の大きな事故が起きると、その周辺コードを徹底的に見直すことになります。すると、まだ見つかっていなかった別の問題が出てくる。
これはセキュリティの世界では珍しくない流れです。
むしろ、重要な侵害のあとには高確率で起きます。
なので今回の3件は「たまたま見つかった小物」ではなく、
大事故をきっかけに、隣接する危険箇所が掘り起こされた結果と見るべきでしょう。
正直、こういう流れはかなり怖いです。
というのも、これで終わりとは限らないからです。記事も「さらなる告知があるかもしれない」と示唆しています。私も、その可能性は十分あると思います。
記事では、修正手順もかなり具体的に書かれています。
/scripts/upcp
これはrootで実行します。
May 8のTSRを取得するための標準コマンドです。
/scripts/upcp --force
sed -i "s/CPANEL=.*/CPANEL=cl6110/g" /etc/cpupdate.conf
/scripts/upcp
/scripts/restartsrv_cpsrvd
/usr/local/cpanel/cpanel -V
重要なのは、アップデートしたつもりで終わらないことです。
ちゃんと再起動して、バージョンを確認して、パッチ済みの版が動いていることを確かめる必要があります。ここを飛ばすと、せっかくの作業が空振りになります。
ここも大事です。
もしあなたのサーバーが、2月下旬から4月28日までの間に未修正版のcPanelを使っていたなら、単にアップデートするだけでは足りない可能性があります。
その場合は、「もう侵害されているかもしれない」前提で調査するべきです。
/usr/local/cpanel/logs/access_log/usr/local/cpanel/logs/login_log特に、普段と違うIPアドレスからの不審な認証や操作を確認します。
ホームディレクトリを再帰的に確認して、**.sorry 拡張子のファイル**がないか探すよう勧めています。
これが見つかれば、ランサムウェアが実際に展開された証拠になります。
ここまで来ると、もはや「パッチを当てて終わり」ではありません。
インシデント対応が必要です。個人的には、こういうケースで「更新したから大丈夫」で済ませるのはかなり危険だと思います。
Copahostの記事は、cPanelだけの話に閉じていません。
Webホスティング業界全体で、脆弱性発見と悪用のスピードが上がっているという話につなげています。
たとえば、
という状況です。
記事は、AI支援のセキュリティ研究によって脆弱性の発見が速くなり、
「見つかってから悪用されるまでの時間」がどんどん短くなっていると指摘しています。
これはかなり納得感があります。
攻撃者だけでなく防御側もツールを強化しているので、全体の競争が激しくなっているわけです。
ただし、現場の運用担当者からすると「だから余計にしんどい」としか言いようがないのも本音でしょう。
今回の件で一番覚えておきたいのは、
cPanelは今、かなり厳しいセキュリティ局面にあるということです。
単発の修正ではなく、
という流れなので、これはもう「早めに直しておこう」では足りません。
cPanel/WHMを運用しているなら、今すぐやるべきなのは次の3つです。
率直に言って、今回の記事はかなり不穏です。
でも、不穏だからこそ役に立ちます。こういうときに怖がるだけで終わらず、実際の点検と対応に落とし込めるかが勝負だと思います。