2026年8月27日、PaperCut社のセキュリティ対応チームが、同社製品 PaperCut NG および PaperCut MF に対する実際の攻撃を調査していると公表した。同社の声明は「確認された顧客インシデントを把握しており、最優先事項として扱っている」というものである。

注目すべきは、この脆弱性が発見された経緯だ。報道によれば、ある大学の顧客のセキュリティチームとフォレンジック対応チームが提供した情報によって、PaperCut社は脆弱性を再現できたという。つまり、ベンダーが自力で見つけたのではなく、すでに被害に遭った組織の調査から逆算して判明したということになる。攻撃が先行していた。

緊急ビルドがリリースされたのはオーストラリア東部時間8月28日 午前2時10分——日本時間では28日の未明にあたる。定例のリリースサイクルを外した、明らかな緊急対応である。ベンダーがこの時間帯にビルドを出すという事実そのものが、深刻度を物語っている。

具体的に、以下はこの記事の執筆時点で公表されていない。

報道の一部には「リモートコード実行を許す」と書いているものもあるが、PaperCut社自身がそう明言した形跡は確認できなかった。緊急対応の様子から「インターネット越しに悪用できる深刻な経路がある」と推測されている段階であり、断定はできない。ここは正直に留保しておく。

PaperCut NG/MF は、組織内の印刷を集中管理するソフトウェアである。誰がどのプリンタで何枚刷ったかを記録し、部署ごとに課金し、認証カードで出力を制御する。大学、自治体、病院、製造業など、共用プリンタを大量に抱える組織で広く使われている。今回の発見のきっかけが大学だったのも偶然ではない。

ここで少し立ち止まって考えたい。印刷管理サーバーは、組織の中で何を「知って」いるのだろうか。

まず、全社員の名簿を持っている。誰が印刷できるかを判定する必要があるからだ。多くの環境では Active Directory と連携しており、社員IDと氏名とメールアドレスが同期されている。次に、組織図を持っている。部署ごとに課金するには、誰がどの部署かを知っていなければならない。そして行動の記録を持っている。いつ誰がどの端末からどのプリンタに何を送ったか、というログである。

攻撃者の視点でこれを眺めると、印刷サーバーは「地味な設備」ではなく組織の名簿と構造が1か所に集まった場所に見える。標的型攻撃の下調べに、これ以上都合のよい情報源はそう多くない。2023年の CVE-2023-27351 で実際に抜かれたのが、ユーザー名・氏名・メールアドレスだったことを思い出してほしい。

この種のサーバーには、攻撃者にとって都合のよい性質が3つ重なっている。

とくに③は見落とされやすい。印刷管理は情報システム部門ではなく総務や各キャンパスの事務が導入していることがあり、資産台帳を見ても出てこない。「うちは使っていない」と即答できる組織は、実は多くない。今回まず確認すべきなのは、台帳ではなく実際に動いているサーバーである。

2023年3月、PaperCut は CVE-2023-27350（CVSS 9.8）と CVE-2023-27351（同 8.2）を修正した。前者は認証を回避して、SYSTEM権限で任意のコードを実行できるというものだった。印刷サーバーの管理権限ではなく、OSの最高権限である。

パッチ公開後の展開は速かった。2023年4月13日ごろから悪用が始まり、Microsoftは攻撃を Lace Tempest（FIN11 / TA505 と重なるとされる攻撃者）に帰属させた。この攻撃者は Clop ランサムウェアの配布で知られる。

この「ログが消される」という性質は、確認作業の順序にも影響する。サーバー上の server.log だけを見て終わりにすると、消された分は永久に分からない。もし転送先にログを集約しているなら、そちらを先に見るほうが確実だ。攻撃者はサーバー上のファイルは消せても、すでに外へ送られたログまでは追いかけられないことが多い。ログ集約の仕組みがまだ無い場合、今回の件は導入を検討する具体的な理由になる。

多くの組織は、脆弱性対応のトリガーを外部に置いている。JVNに載ったら、CISAのKEVカタログに入ったら、JPCERT/CCが注意喚起を出したら動く——運用としては合理的だ。判断のコストを外部の専門機関に預けられる。

ところが今回のように、ベンダーが認めているのにCVE番号がまだ無いケースでは、この仕組みが空回りする。CVEが無ければJVNにも載らない。載らなければ社内の脆弱性管理プロセスにも乗らない。「悪用が確認されている」という最も重要な情報が、番号が無いという事務的な理由で流通経路から落ちる。

重要なのは、対処に必要な情報はすでに全部そろっているという点である。影響製品も、緩和策も、侵害の痕跡も、緊急ビルドも公開済みだ。足りないのは番号だけで、番号は防御には使わない。番号は管理のための道具であって、判断の条件ではない。

実務的な落としどころとしては、脆弱性管理のプロセスに「CVE未採番でも、ベンダーが悪用を認めた案件は即時扱いにする」という例外ルートを1本用意しておくことだろう。年に数回しか通らない経路だが、通るときは決まって今回のような場面である。

Q. 社内ネットワークにしか置いていないので関係ないのでは？

インターネットから直接叩かれるリスクは確かに下がる。ただし2023年の事例が示したのは、印刷サーバーは最終目的地ではなく通過点だったということだ。何らかの経路で社内に入られた後、次の足場としてこの種のサーバーが使われる。外部露出の遮断は「最優先の応急処置」であって、「これで終わり」ではない。緊急ビルドの適用と痕跡確認は、内部設置でも実施する価値がある。

Q. まだCVE番号が無いのに、社内の脆弱性管理プロセスに乗せられない。

これは制度の問題であって、リスクの問題ではない。多くの脆弱性管理プロセスはCVE番号を主キーにして作られているため、番号が無いものは物理的に登録できないことがある。現実的な回避策は、「ベンダー公表の緊急案件」という別枠を用意して、番号が付いた時点で通常のプロセスに合流させるやり方だ。今回のようなケースは年に数回起きるので、一度枠を作っておけば次から使い回せる。

Q. ログに何も出ていないので、侵害されていないと判断してよいか？

できない。公表されているIoCの1つが「server.log ファイルの消失・削除・不自然な切り詰め」である点に注意してほしい。攻撃者はログを消している。つまり「ログがきれいであること」自体が疑わしい兆候になりうるという、少し落ち着かない状況にある。PaperCut社も「痕跡が無いことは侵害されていないことを意味しない」と明記している。判断材料をサーバー上のログだけに頼らず、ネットワーク側の通信記録やEDRの記録も併せて見るのが望ましい。

Q. v24系を使っている。緊急ビルドが無いなら何もできないのか？

できることはある。むしろ、パッチが無いからこそアクセス制限の重要度が上がる。管理画面を信頼できるIPに限定し、そのうえで痕跡確認を行い、公式の続報を追う。本記事の執筆時点でv24系のビルドは「作成中」と報じられていたので、状況は変わっている可能性が高い。まず公式の最新情報を見てほしい。

Q. 結局、どのくらい急ぐべきなのか？

判断の基準は「インターネットから管理画面に到達できるかどうか」に尽きる。到達できるなら今日中——ベンダーが名指しで警告しているのはこの状態である。到達できないなら、今週中に緊急ビルドを適用し、あわせて痕跡を確認する、という速度で構わない。全社に緊急招集をかける話ではないが、来月のメンテナンス枠まで待つ話でもない。