Threat actors are actively exploiting a critical remote code execution flaw in the Collabora Online — Built-in CODE Server app (richdocumentscode) for Nextcloud, according to BleepingComputer — and the fallout goes beyond a single intrusion. Backdoor persistence has been found on servers reached through the bug.

The flaw, tracked in BleepingComputer's reporting as CVE-2026-110447, sits in a component many self-hosted Nextcloud administrators install to get document editing without standing up a separate Collabora or OnlyOffice stack. That convenience is what makes the exposure widespread, and why the response has to extend past applying an update.

One caveat before anything else: the CVE identifier and the affected-version ranges in this story come from BleepingComputer's reporting. Vendor advisories from Nextcloud and Collabora were not confirmed in the source material at the time of writing, and the identifier itself has not been independently verified here. Administrators should treat CVE-2026-110447 as a search term, not an authority, and confirm every affected and fixed version number against the Nextcloud app store listing and Collabora's own security advisories before acting.

Why "patch" is not the whole job

What matters operationally here is not that a remote code execution flaw exists in a Nextcloud app — bugs in that ecosystem get fixed routinely. It is that backdoors were found on servers reached through this one. That single observed fact changes the remediation sequence materially.

A patch closes the initial access path. It does nothing about code, accounts, cron jobs, or web shells an attacker planted while they held command execution. An administrator who patches and moves on can believe a server is clean while it continues to serve an intruder. Post-patch auditing is therefore a mandatory second phase, not an optional hardening step for unusually cautious teams.

The same logic applies to any self-hosted Nextcloud instance running richdocumentscode: compromise of a document-editing component is compromise of the host, and the host is where persistence lives.

Recommended response sequence

  1. Patch the Collabora CODE Server component immediately. Update richdocumentscode via the Nextcloud app store, using the version ranges published by Nextcloud or Collabora as your reference. Where a vendor advisory is not yet available, apply the newest available release rather than waiting for a targeted fix.
  2. Audit for persistence before declaring the incident closed. Once the vulnerable component is updated, sweep the server for unrecognised web shells, unfamiliar scheduled tasks, unexpected cron entries, new or modified administrator accounts, and unexplained outbound connections. Backdoor removal — not patching — is what ends the incident.
  3. Review logs and indicators of compromise. BleepingComputer's report lists artefacts associated with the campaign; treat those as observer-reported and potentially incomplete. Where Nextcloud or Collabora publishes indicators directly, those vendor-sourced artefacts carry more authority and should be preferred as the detection baseline.
  4. Limit exposure while the fix is applied. If immediate patching is not possible, restrict network access to the Nextcloud instance and the document-editing service to trusted ranges, and disable or remove the richdocumentscode app until it can be brought to a fixed version.

The wider lesson

Incidents of this shape keep landing on the same fault line in self-hosted deployments: convenience components — the optional apps that turn a file-sync platform into a collaboration suite — are frequently the softest part of the stack, and they run with enough privilege to hand an attacker the whole machine.

For teams running their own Nextcloud, the durable practice is the one this incident makes unavoidable. Patch the vulnerable component, then treat the server as compromised until an audit says otherwise. Skipping the second half is how patched systems stay owned.

據 BleepingComputer 報道，威脅行為者正積極利用 Nextcloud 的 Collabora Online — Built-in CODE Server 應用程式（richdocumentscode）中一個嚴重的 remote code execution（RCE）漏洞，而且影響範圍不止於單一次入侵。經由此漏洞被入侵的伺服器上已發現後門持久化機制。

該漏洞在 BleepingComputer 的報道中編號為 CVE-2026-110447，存在於一個許多自架（self-hosted）Nextcloud 管理員都會安裝的元件之中，其用途是在毋須另外部署 Collabora 或 OnlyOffice 架構的情況下取得文件編輯功能。正是這種便利性令暴露範圍如此廣泛，亦說明應對措施不能止於套用更新。

在展開討論前先作一點說明：本文提及的 CVE 編號及受影響版本範圍均來自 BleepingComputer 的報道。截至撰稿時，來源資料中並未確認 Nextcloud 及 Collabora 的官方安全公告，該編號本身亦未經此處獨立核實。管理員應將 CVE-2026-110447 視為一個搜尋關鍵詞而非權威依據，在採取行動前，務必逐一對照 Nextcloud app store 的版本資料及 Collabora 自身的安全公告，核實每一個受影響及已修復的版本號。

為何「打補丁」並非全部工作

就運作層面而言，關鍵並不在於 Nextcloud 應用程式中存在一個 RCE 漏洞——該生態系統的漏洞一直獲例行修補。真正的關鍵是經由此漏洞被入侵的伺服器上發現了後門。單是這一點已足以大幅改變補救工作的先後次序。

補丁關閉的是最初的入侵途徑，但對攻擊者在掌管執行權限期間植入的程式碼、帳戶、cron jobs 及 web shell 全無作用。管理員若打完補丁便置之不理，很可能誤以為伺服器已乾淨，而它其實仍在為入侵者服務。因此，補丁後的審計是不可或缺的第二階段，並非過分謹慎的團隊才需要做的額外強化措施。

同一邏輯適用於所有執行 richdocumentscode 的自架 Nextcloud 實例：文件編輯元件被入侵，等同主機被入侵，而持久化機制正是藏在主機之上。

建議的應對步驟

  1. 立即修補 Collabora CODE Server 元件。 透過 Nextcloud app store 更新 richdocumentscode，以 Nextcloud 或 Collabora 公布的版本範圍為準。若官方安全公告尚未發出，則應套用現時最新的可用版本，而非等待針對性的修復。
  2. 在宣告事件結束前，先審計持久化機制。 受影響元件更新後，全面檢查伺服器是否存在不明的 web shell、陌生的排程任務、異常的 cron entries、新建或被修改的管理員帳戶，以及無法解釋的對外連線。終結事件的是清除後門，而非打補丁。
  3. 檢視日誌及入侵指標（indicators of compromise）。 BleepingComputer 的報告列出與該攻擊活動相關的 artefacts，應視之為觀察者回報的資料，可能並不完整。若 Nextcloud 或 Collabora 直接公布入侵指標，這些來自廠商的 artefacts 具有更高權威性，應優先作為偵測基準。
  4. 在套用修復期間限制暴露面。 如無法即時修補，應將 Nextcloud 實例及文件編輯服務的網絡存取限制於可信的網段，並停用或移除 richdocumentscode 應用程式，直至能將其升級至已修復的版本。

更廣泛的啟示

此類事故一再落在自架部署同一條斷層線上：那些便利元件——即令檔案同步平台搖身一變成為協作套件的選用應用程式——往往正是整個 stack 最薄弱的部分，而且其運行權限足以讓攻擊者掌控整部主機。

對於自行運行 Nextcloud 的團隊，今次事故所凸顯的做法是無可回避的持久守則：先修補受漏洞影響的元件，然後在審計結果證明伺服器乾淨之前，一律將其視為已遭入侵。略過後半部步驟，正是已打補丁的系統仍然受人控制的原因。

新聞來源 / Original News Source