Security researchers have published a full working exploit for a pre-authentication remote code execution flaw in AnyDesk on Linux that hands attackers root privileges before any user approves the connection — and with a working proof-of-concept now in the open, defenders running unpatched Linux installations are being urged to audit their remote-access deployments immediately.
AnyDesk shipped a fix in version 8.0.3, released in June. But according to The Hacker News, reporting on the researchers' October disclosure, the vendor's changelog described it only as "fixed a bug that could lead to a crash." No CVE identifier was assigned and no security advisory was issued — leaving anyone tracking the vendor's release notes with no signal that the underlying bug was a pre-authentication path to root, rather than a routine stability fix.
That detail matters more than it might first appear. The most dangerous element of this bug is that it bypasses AnyDesk's connection-approval prompt — the mechanism users and helpdesk staff rely on to decide which remote sessions to allow. With the check defeated and execution landing as root, an attacker can establish control of a host without any human in the loop. The researchers' published exploit lowers the bar for abuse from skilled operators to anyone able to run existing code.
The CVE gap is the quiet problem
The disclosure pattern here also illustrates a structural weakness in how organisations audit patch posture. Without a CVE identifier, a vulnerability cannot flow into the tooling most teams depend on: automated vulnerability scanners, asset inventories, and compliance pipelines all key off those identifiers to flag affected systems. A fix shipped as an unlabelled "crash" fix is effectively invisible to that machinery — which mechanically explains how unpatched Linux hosts can persist for months after a patch exists.
The highest-risk population is internet-exposed Linux hosts running AnyDesk with unattended access or persistent sessions enabled — a common configuration in managed service provider and helpdesk environments, where technicians reach client machines outside business hours. Those deployments should be treated as the top priority, and because no indicators of compromise are available as a search aid, teams should rely on behavioural review of logs and processes rather than signature matching.
What to do now
- Update AnyDesk on Linux to 8.0.3 or later wherever it is deployed, treating it as an urgent patch rather than a routine maintenance item.
- Inventory every Linux host running AnyDesk, including client-managed machines in MSP estates that may not appear in central patch reports.
- Restrict reachability to trusted management networks wherever sessions are not genuinely required from the open internet, and disable unattended access where it is not operationally necessary.
- Review logs and processes for anomalies on exposed instances, checking for unexpected sessions, unfamiliar processes, and persistence mechanisms rather than waiting for published indicators.
As of publication, AnyDesk has not issued a CVE or security advisory for the flaw, and that status should be re-checked before this article is treated as current: a retroactive identifier would begin flowing into scanning and compliance tooling and would change the tracking picture described above.
For managed service providers and IT teams across Hong Kong running client estates on Linux — where a single unattended-access host can expose many downstream customers — the immediate question is not whether the changelog entry looked alarming, but how many machines were patched on the strength of it. A "crash fix" that was really a pre-authentication root RCE is precisely the class of bug that CVE-dependent patch auditing is designed to catch, and precisely the class that slips through when no CVE is ever assigned.
安全研究人員已公開一套完整可用的 exploit，針對 AnyDesk 在 Linux 版本上的一項預驗證遠端代碼執行（pre-authentication RCE）漏洞——攻擊者在任何用戶批准連線之前即可取得 root 權限。隨著可用的概念驗證（proof-of-concept）已公開流通，執行未修補 Linux 系統的防守方被促請立即檢視其遠端存取部署。
AnyDesk 已於六月發布的 8.0.3 版本中修復相關問題。但據 The Hacker News 報道研究人員十月的披露內容，該廠商的版本更新紀錄僅將其描述為「修正一個可能導致系統崩潰的錯誤」（fixed a bug that could lead to a crash）。事後並未分配 CVE 編號，亦未發出任何安全公告——令追蹤廠商版本更新說明的業界人士無從得知，底層的錯誤其實是一條通往 root 的預驗證路徑，而非例行的穩定性修復。
這項細節的重要性遠超表面所見。該漏洞最危險之處，在於它繞過 AnyDesk 的連線批准提示（connection-approval prompt）——即用戶和技術支援人員用來決定允許哪些遠端工作階段的機制。一旦該檢查機制被繞過，且執行以 root 身分落地，攻擊者便可在完全不涉及任何人為參與的情況下全面控制主機。研究人員公開的 exploit，將濫用此漏洞的技術門檻由熟練的操作者降至任何能執行現有代碼的人。
CVE 編號缺失才是隱藏的問題
此次的披露模式，亦揭示了企業在審視其補丁狀態（patch posture）時的一項結構性弱點。若沒有 CVE 編號，漏洞便無法流入大多數團隊所依賴的工具鏈：自動化漏洞掃描器、資產清單系統以及合規 pipeline，全部都以這些編號為依據來標記受影響的系統。一項以未經標示的「系統崩潰修復」形式發布的補丁，實際上對上述機制而言是隱形的——這正從機制上解釋了為何在補丁早已存在的情況下，未修補的 Linux 主機仍可持續暴露數月之久。
風險最高的群體，是那些對外暴露於互聯網、並啟用了無人值守存取（unattended access）或持久工作階段功能的 Linux 主機——這在託管服務供應商（MSP）及技術支援環境中是常見配置，因為技術人員需要在辦公時間以外遠端連接客戶機器。這類部署應列為最高優先處理對象；由於目前沒有可供搜尋的入侵指標（indicators of compromise），團隊應依賴對日誌及程序的行為分析（behavioural review），而非倚靠特徵碼比對。
現在應該採取的行動
- 將任何 Linux 部署的 AnyDesk 更新至 8.0.3 或以上版本，並將其視為緊急補丁處理，而非例行維護項目。
- 盤點所有執行 AnyDesk 的 Linux 主機，包括 MSP 管理範圍內由客戶自行管理的機器，這些機器可能不會出現在中央補丁報告中。
- 將存取範圍限制於可信的管理網絡，凡工作階段並非必須從公開互聯網進行的場景一律套用，並在營運上並非必要時停用無人值守存取。
- 審查日誌及程序中的異常，於暴露的實例上檢查是否有意料之外的工作階段、不熟悉的程序及持久化機制（persistence mechanisms），而非等待已公開的入侵指標。
截至本文刊登時，AnyDesk 尚未就該漏洞發出 CVE 編號或安全公告，而在將本文視為最新資訊之前應重新確認相關狀態：若事後補發編號，相關資料將開始流入掃描及合規工具，從而改變上述的追蹤形勢。
對於全港託管服務供應商及在 Linux 上管理客戶系統的 IT 團隊而言——在這些環境中，一台啟用無人值守存取的主機便可能連帶暴露大量下游客戶——當前的關鍵問題並不在於該版本更新紀錄看起來是否令人憂慮，而是究竟有多少部機器僅憑該段說明便進行了修補。一項實為預驗證 root RCE 的「系統崩潰修復」，正是依賴 CVE 進行補丁審計的機制理應捕捉的漏洞類別，也正是在從未分配 CVE 的情況下必然會被漏掉的那一類。