Nextcloudの内蔵CODEに悪用された脆弱性｜無効化だけで終えない更新と調査

Nextcloudに組み込む「Collabora Online - Built-in CODE Server」アプリに、認証なしのOSコマンド実行につながるCVE-2026-110447が公表されています。特に注意したいのは、内蔵CODEサーバーが停止している時間帯に攻撃が成立し得る点と、アプリを無効化しただけでは対策にならない点です。

Collaboraの公式アドバイザリが示す修正済みバージョンは26.4.303。評価はCVSS v4.0で9.2です。PHP本体の重大脆弱性とは別の欠陥であり、PHPを更新していても、このアプリの修正状況を確認する必要があります。

本稿は2026年10月22日に一次資料を確認した注意喚起です。アドバイザリの公開日は10月14日、修正済みアプリの公開は9月11日で、今日初めて修正版が出たというニュースではありません。未掲載だった重要案件として、共有ファイル基盤の運営者が確認すべき構成と対処を整理します。

対象はNextcloudに内蔵するアプリ

対象アプリのIDはrichdocumentscodeです。利用者向けの表示名はCollabora Online - Built-in CODE Serverで、ブラウザーから文書を編集するためのサーバーをNextcloudの中で動かす構成に使われます。Nextcloud本体のバージョンだけを確認しても、このアプリが修正済みかは分かりません。

公式は26.4.303未満を影響対象としています。一方、独立したサーバーとして運用するStandalone Collabora Onlineは今回の対象ではないと明記しています。NextcloudからOffice文書を編集できるという見た目だけで判断せず、内蔵アプリを使うのか、外部のCollaboraサーバーへ接続するのかを確認してください。

また、外部サーバーへの切り替えを過去に行っていても、以前導入したrichdocumentscodeが残っている可能性は点検対象です。無効化されたアプリも含め、インストール済み一覧と実ファイルを照合することを勧めます。これは自社構成を調べるための提案で、すべての環境に不要なアプリが残るという意味ではありません。

確認した構成	今回の判断
richdocumentscodeが26.4.303未満	更新または削除を優先
古いrichdocumentscodeを無効化済み	無効化のみで完了にしない
独立したCollabora Onlineのみを利用	公式は今回の欠陥の対象外と説明
Nextcloud 29以前と対象アプリを利用	本体更新またはアプリ削除を検討

停止中の起動経路でコマンドが実行される

公式が問題を指摘するのは、対象アプリのproxy.phpを通る経路です。外部からの要求によって、Webサーバーの実行ユーザーの権限でOSコマンドが動く可能性があります。一般の利用者に管理者権限を渡していなくても、Webから届く入力が実行処理へ影響する点が問題になります。

成立条件として、内蔵CODEサーバーが動いていない状態が挙げられています。コンテナの再起動、更新作業、クラッシュ後などが例示されています。平常時に文書を問題なく開けていたことだけでは、その前後の停止時間帯まで安全だったとは評価できません。

この条件は「CODEを止めれば安全」という直感と逆です。今回の公式勧告はアプリを26.4.303以上へ更新するか削除することであり、無効化だけでは不十分です。停止状態を作って試すような攻撃再現は本番で行わず、更新済みファイルの確認と通常機能の検証を進めてください。

以前の同種CVEへの対処と混同しない

Collaboraは、今回の経路はCVE-2025-66208と異なり、以前の問題の修正では防げないと説明しています。過去に「Collaboraのコマンド実行を修正済み」と記録していても、その記録だけでCVE-2026-110447の対応完了にはできません。

保守台帳では、Nextcloud本体、文書編集用の連携アプリ、内蔵CODEサーバー、独立したOfficeサーバーを分けて記録します。名前が似ているコンポーネントを一つの更新対象として扱うと、連携画面は新しくても、起動処理を持つアプリの旧版が残るといった確認漏れが起きます。

Web制作会社や運用委託先へ依頼する場合は、アプリID、適用版、配置場所、更新日時を具体的に伝える方法を勧めます。PHPやOSのセキュリティ更新を依頼したチケットに埋もれさせず、対象アプリの更新結果を別の完了条件として確認してください。

修正版公開と詳細公表の日付を分ける

Nextcloud App Storeのリリース履歴では、26.4.303は9月11日、26.4.402は9月24日に公開されたことが確認できます。26.4.303は今回の修正を含む最小バージョンであり、確認時点で常に最新の選択肢という意味ではありません。利用するNextcloudの系列に対応する修正済み版を選んでください。

10月14日のアドバイザリは、修正対象と条件を公に整理した資料です。9月にアプリを更新していれば修正を取り込んでいる場合がありますが、更新した記憶ではなく保存された版と配備ファイルを確認します。別ノード、古いコンテナ、復元用イメージに対象版が残っていないかも調べます。

開発元リポジトリーの9月11日付Issueには、利用者自身が9月10日以降の攻撃とWebシェルの設置を報告しています。これは被害利用者による一次報告で、開発元のアドバイザリは10月14日です。NVDのCVE説明にも9月と10月の実環境での悪用が記載されています。詳細勧告の公表後だけに調査期間を限るべきではありません。これらは全Nextcloudサーバーの被害を意味しません。

一覧の確認とファイルの確認を組み合わせる

Nextcloudのアプリ管理コマンド資料では、occ app:listで有効・無効のアプリを一覧にできます。app:getpathはアプリの配置場所、config:app:getのinstalled_versionは記録上の版を確認する手段です。以下はNextcloudの導入ディレクトリで実行する確認例で、実行ユーザーとPHPのパスは環境に合わせます。

sudo -u www-data php occ app:list
sudo -u www-data php occ app:getpath richdocumentscode
sudo -u www-data php occ config:app:get richdocumentscode installed_version

コマンドの出力と、実際にWeb側が参照するアプリの配置先を照合してください。コンテナのCLIとWebが異なるボリュームやイメージを見ている構成では、CLIだけを確認しても配備状態を保証できません。複数ノードでは、すべての配置先を対象にします。

設定値の数字を手動で書き換えて更新済みに見せる操作は修正になりません。公式ドキュメントも、アプリの版やインストール状態を設定へ直接書き込むより、アプリ管理コマンドを利用するよう説明しています。ファイルと管理情報の両方が一致する状態を確認します。

更新できないときの削除と公開制限

更新には管理画面または公式のapp:updateを使い、互換性のある修正済み版へ進めます。通常機能の動作試験を用意しつつ、修正前の状態を公開したまま長期間検証しないように作業範囲を決めます。検証中の到達範囲を絞る方法は、自社のリバースプロキシやネットワーク構成に合わせてください。

利用しない場合はアプリの削除が公式に挙げられた対策です。削除すると文書編集機能やアプリのデータに影響する場合があるため、機能の利用者、必要な保管データ、復旧手順を事前に確認します。侵害が疑われる場合は、削除で関連ファイルや痕跡を失う前に、対象アプリとログの証拠保全を進めます。

Nextcloud 29以前について、アドバイザリは本体を更新するか対象アプリを削除するよう求めています。App Storeで更新候補が表示されない場合も、それだけで安全とは判断できません。対応するNextcloud系列の制約を調べ、更新可能な構成へ移す計画を立ててください。

更新は過去の侵害を取り消さない

修正版へ切り替えることは、今回の欠陥を通る新たな攻撃経路を閉じる対応です。もし既に別のPHPファイルや永続化設定を置かれていれば、アプリ更新だけでそれらが消えるとは限りません。本サイトは、修正作業と過去の侵害調査を並行して進めることを提案します。

調査では、proxy.phpへのアクセス、内蔵CODEの起動・停止時刻、Webユーザーによる不審な子プロセス、予期しないPHPファイル、定期実行の変更、外部通信を関連付けます。これらは本サイトが勧める確認対象で、特定のファイル名だけを検索すれば検出できるという公式ルールではありません。記録されていない期間と項目も残してください。

Webサーバーのユーザー権限で実行できる範囲を確認すると、影響調査の優先順位を付けやすくなります。読み取り可能な設定、共有データ、外部ストレージの接続情報、バックアップの置き場所を整理します。root権限を取得されたと決めつけず、実際の権限と観測した操作から範囲を評価することが重要です。

復旧確認は文書を一度開くだけで終えない

更新後は検証用の文書で開く、編集する、保存するという通常の流れを確認し、複数ノードへの反映を記録します。計画した再起動や再デプロイの後にも修正済みアプリが残ることを確認してください。古いイメージを再起動のたびに使う構成では、一度の更新が失われる場合があります。

バックアップから戻す場合も、復元先を直ちに公開せず、対象アプリを修正してから接続を戻す手順を用意します。復元データに不審ファイルが含まれる可能性があるときは、復旧の速さだけでなく、どの時点のデータを信頼するかを調査担当と決める必要があります。

今回の教訓は、使わないアプリを画面で無効にするだけでは、実ファイルに直接届く経路を閉じられない場合があることです。対象アプリの更新または削除、配備状態の照合、停止時間帯を含む記録の確認までを、一つの保守作業として進めてください。

関連記事

• コマンドインジェクションを防ぐ実装｜シェルを外した後も確認する引数と権限