社内の印刷管理システムをクラウド上や自社データセンターで運用している方に向けた内容です。PaperCut MF/NGという印刷管理ソフトウェアに、認証を経由せずにサーバー乗っ取りまで到達できる脆弱性連鎖が見つかりました。オンプレ設置でも仮想マシン上でも影響は同じなので、環境を問わず確認しておく価値があります。
何が起きるか
今回の問題は2つの脆弱性が組み合わさって発生します。CVE-2026-81578は認証バイパス（本来必要なログイン処理を飛ばして管理機能にアクセスできてしまう不具合）です。CVE-2026-82078は動的クラスロード（サーバーが実行時に外部から指定されたJavaのプログラム部品を読み込んでしまう仕組み）の不備です。
この2つが連鎖すると、ログインすら不要な攻撃者が、PaperCutのSYSTEM権限（Windowsで最も強い実行権限）でコードを実行できてしまいます。実際の攻撃では、管理インターフェースに未認証のまま接続し、バックエンドの管理操作を呼び出してデータベース関連の設定を書き換える手口が確認されています。
攻撃者は許可されていないドライバークラス名を指定し、あらかじめ配置しておいたJavaクラスを読み込ませます。するとpc-app.exeというPaperCutの実行プロセスが、SYSTEM権限でコマンドを実行してしまいます。攻撃の痕跡を消すために、出力ファイルやserver.logを削除する動きも報告されています。
影響範囲は印刷管理サーバー単体にとどまりません。SYSTEM権限を奪われると、設定情報や接続情報の窃取、追加のマルウェア配置、認証情報の窃取、そして社内ネットワーク内の他サーバーへの横展開（ラテラルムーブメント）の足がかりになります。印刷サーバーは監視の目が届きにくい割に、Active Directoryとの連携設定を持っていることが多く、侵入経路として狙われやすい位置にあります。
なぜ起きるか
原因を分解すると、大きく3層に分かれます。
1層目は認証設計の不備です。管理インターフェースへのアクセス制御が、本来必要なチェックをすり抜けられる形で実装されていました。Webアプリケーションでよくある「特定のAPIエンドポイントだけ認証チェックが漏れる」パターンに近い構造です。
2層目はJavaの動的クラスロードという仕組み自体のリスクです。動的クラスロードは、アプリケーションの拡張性を高めるために便利な機能ですが、読み込むクラス名を外部入力からそのまま受け取ると、任意のコードを実行される穴になります。JDBCドライバーのクラス名指定機能が悪用され、jdbc:derby:memory:pwnのような細工されたURLが使われた例が確認されています。
3層目は初回パッチの不完全さです。PaperCut側は最初の緊急パッチで対応したものの、バイパス経路が一部残っていました。そのため2度目の緊急パッチ（Release 2）を追加で出す事態になっています。セキュリティパッチは1回当てれば終わりという思い込みは危険で、ベンダーの追加告知を追う運用が必要です。
自分の環境が該当するか確認する
まず確認すべきはPaperCutのバージョンです。管理コンソールにログインし、「About」または「ヘルプ」メニューからバージョン番号を確認します。v23より前のバージョンは特に注意が必要で、最新のリリースラインへの更新が推奨されています。
次に、管理インターフェースの公開範囲を確認します。以下のような観点でチェックしてください。
- 管理コンソール（通常はTCP 9191/9192番ポート）がインターネットから直接到達可能になっていないか
- クラウド環境の場合、セキュリティグループやNSG（ネットワークセキュリティグループ）で管理ポートが全世界公開になっていないか
- VPN経由や社内ネットワークからのみアクセスできる構成になっているか
侵害の痕跡がすでにないかも確認しておきたいところです。以下のログ・ファイルをチェックします。
# server/lib 配下に見慣れない .class や .cmd ファイルがないか確認
find /path/to/papercut/server/lib -newer /path/to/papercut/server.log -type f
# server.log が消えていないか、更新日時が不自然でないか確認
ls -la /path/to/papercut/server.log
# derby.log 内に不審な接続文字列がないか確認
grep -i "jdbc:derby:memory:pwn\|No suitable driver found" /path/to/papercut/server/logs/derby.logWindows環境であれば、プロセス監視ツールやEDR（エンドポイント検知応答製品）のログで、pc-app.exeがwhoami、ver、tasklist、cmd.exeを子プロセスとして起動していないかも確認してください。通常運用では起きない親子関係なので、見つかった時点で侵害を疑うべきサインです。
対策の手順
確認の結果、対象になりそうであれば以下の順で対処します。
1. パッチ適用: PaperCutの公式セキュリティアドバイザリからRelease 2を取得し、直ちに適用します。v23より前のバージョンは、パッチ単体ではなく最新リリースラインへのアップグレードが必要です。
2. アクセス制御の見直し: 管理インターフェースをインターネットから遮断し、信頼できるIPレンジまたはVPN経由のみアクセス可能にします。クラウド上で運用している場合は、セキュリティグループの受信ルールを見直し、0.0.0.0/0からのアクセスを許可していないか確認します。
3. 侵害調査: 上記のログ確認コマンドで異常が見つかった場合、HTTPログ・アプリケーションログ・監査ログを保全します。初回の異常検知タイムスタンプと送信元IPを特定し、影響範囲を洗い出します。
4. 監視の強化: pc-app.exeからの不審な子プロセス起動や、server/lib配下のファイル変更を監視対象に追加します。すでにSIEM（セキュリティ情報イベント管理システム）を運用している場合は、これらを検知ルールとして組み込みます。
5. 復旧判断: SYSTEM権限での実行が確認された場合、パッチ適用だけでなくサーバーの再構築を検討します。認証情報の窃取や横展開の痕跡があれば、影響範囲全体の認証情報ローテーションも必要です。
監視コスト面では、印刷サーバーは重要度が低いと見なされがちで、専用の監視体制を組んでいない現場も見られます。今回のようにAD連携や高権限実行を持つコンポーネントが放置されると、侵入後の被害が拡大しやすくなります。EDRやログ収集の対象に印刷サーバー群を含めているか、この機会に棚卸ししておくと安心です。
まとめ
PaperCut MF/NGの認証バイパスと動的クラスロードの連鎖は、未認証でSYSTEM権限のコード実行に至る深刻な組み合わせです。
- まずは管理コンソールでバージョンを確認し、v23以降かつRelease 2適用済みかを確かめる
- 管理インターフェースの公開範囲をセキュリティグループやファイアウォール設定で再点検する
server/lib配下の不審ファイルとderby.logのエラー文字列を確認し、侵害の有無を洗い出す- 印刷サーバーのようなAD連携コンポーネントも監視対象に含め、次回同種の脆弱性発表に備える
パッチ適用の有無だけでなく、ネットワーク到達性とログの両面から確認すると、見落としを減らせます。