AnyDesk Linux: the researchers' root exploit came 107 days after a release logged only as a crash fix

A release logged as a crash fix, and exploit code 107 days later

AnyDesk's Linux changelog lists version 8.0.3, dated 23 June 2026, with one line: "Fixed a bug that could lead to a crash". On 8 October 2026 the researchers at V12 published exploit code for a pre-authentication flaw in AnyDesk for Linux. The commit to their public repository is dated 22:19 BST that evening. The gap between the dated release and the code is 107 days (derived: 23 June to 8 October 2026), or 108 days from V12's first public post about the flaw on 22 June. The Hacker News reports that 8.0.3 carries the fix. AnyDesk's own pages never tie that release to the flaw.

What that gap does not establish matters as much as the number. It is not 107 days of exposure: the flaw is older than 8.0.3, and when it was introduced is not stated. It is not 107 days of exploitation: AnyDesk said on 23 June that it had "no evidence of exploitation against our infrastructure or customer environments", and no source read for this briefing reports any since, but that was an early assessment made 107 days before the code was public. It does not show that Windows and macOS are unaffected, only that AnyDesk says so and that no independent test was found. It does not say how many Linux installations accept direct connections, because nobody states that number. And the code, as The Hacker News reports it, is probabilistic and written for one build, 8.0.2: when it does not land, the service crashes.

What the gap does show is smaller and sharper. For 107 days the only line about that release on the page where AnyDesk lists what each release fixes was a crash fix. There was no CVE, which means no National Vulnerability Database record, no CISA Known Exploited Vulnerabilities entry and nothing for a scanner keyed on CVE numbers to match, and no advisory on any AnyDesk page this briefing could find. The researchers say the code runs a command as root, the account that owns the whole Linux machine. A silent fix is not a notified fix, and the people most exposed are the ones whose update process waits to be told.

What is stated, by whom, and what is not

Four kinds of source carry this story: AnyDesk's own pages and posts, two posts on X by V12, the news reports from The Hacker News and Cyber Security News, and the public registers. The researchers' detailed write-up is kept with their exploit code in a public repository. This briefing did not read it, because it is the exploit's own documentation. The repository's visibility and the commit time were checked through public metadata only, and the repository is not linked. Whatever the write-up says reaches this briefing only through The Hacker News, and the table marks it so.

Claims about the AnyDesk Linux flaw, with the source that makes each, read on 9 October 2026. Day counts are derived from the dates shown.

Question	Stated, and by whom	Not stated
Dates	V12 on X: first post 22 June 2026 (22:01 UTC, derived from the post identifier). AnyDesk on X: reply 23 June (15:23 UTC, derived). AnyDesk Linux changelog: 8.0.3 dated 23 June. Researchers' repository: AnyDesk entry committed 8 October at 21:19 UTC.	When AnyDesk was first told. When the flaw was introduced. The time of day 8.0.3 was released.
What the flaw is	V12: a pre-authentication RCE, a "heap buffer overflow". The Hacker News: in the session protocol; the code runs a command as root; it is probabilistic; its offsets suit 8.0.2.	Any technical statement from AnyDesk. A severity score from anyone.
Which versions	The Hacker News: fixed in 8.0.3; the published code targets 8.0.2; the researchers imply earlier builds such as 8.0.1 may share the code path, unconfirmed.	Any AnyDesk list of affected builds. Whether builds before 8.0.2 are exploitable. Any independent test of 8.0.3 or 8.1.0.
Platforms	AnyDesk on X, 23 June: "Windows and macOS are not affected."	Any independent test of that. Whether the Windows and macOS crash fixes of 25 June and 2 July are related.
Reach	AnyDesk: "limited to direct connections on Linux (connections that do not go through our relays)". The Hacker News, for the researchers: the same code path is reachable through relays, shown with an instrumentation trigger, with the full chain not shown over relays.	Which statement is right. What an attacker would need to try a relay route.
Notice	AnyDesk changelog: "Fixed a bug that could lead to a crash". AnyDesk on X, same day: "We are aware of this vulnerability."	Any advisory, severity, CVE or list of affected builds. Any date for a CVE.
Exploitation	AnyDesk on X, 23 June: no evidence of exploitation against its infrastructure or customer environments, an initial assessment. Neither news report describes any. CISA's catalogue has no AnyDesk entry.	Any AnyDesk statement since 23 June. Any scanning or telemetry data. With no CVE, the catalogue could not list it anyway.
How many installations	AnyDesk, download page: "Trusted by over 200,000 customers". Trust Center: more than 200 million sessions a month. Neither is split by platform.	How many Linux installs exist, how many accept direct connections, how many run 8.0.2 or earlier.

"Crash fix": accurate about one outcome, silent about the other

A crash is what a failed attack looks like. The Hacker News reports that when the code's memory layout does not line up, the service crashes instead of running the command. So "could lead to a crash" is accurate about one outcome and silent about the other. That reading is an inference from a news report, not an AnyDesk statement. What can be checked is the vendor's own vocabulary. AnyDesk's changelogs have words for security fixes and have used them, as the table shows.

How AnyDesk's own changelogs word fixes, read on 9 October 2026 from the Linux, Windows and macOS changelog pages. The dates and lines are AnyDesk's.

Release and date	Changelog line	What it tells a reader
Linux 5.5.3, 21 Feb 2020	"Fixed a security vulnerability."	That a vulnerability was fixed. NVD's CVE-2020-13160, Linux and FreeBSD code execution, says "before 5.5.3".
Linux 7.0.0, 16 Apr 2025	"Fixed security vulnerabilities (CVE-2025-27917, CVE-2025-27918)"	Two numbers to look up.
Linux 7.1.2, 22 Dec 2025	"Fixed security vulnerabilities"	That vulnerabilities were fixed. No numbers.
Windows 9.7.10, 13 Jul 2026	"Fixed security vulnerabilities"	The same, on Windows.
Linux 8.0.3, 23 Jun 2026	"Fixed a bug that could lead to a crash"	A crash risk. No vulnerability, no code execution, no root.
Windows 9.7.8, 25 Jun 2026	"Fixed a bug that could lead to a crash"	The same sentence on the Windows page two days later. Whether it is related is not stated.
macOS 9.7.2, 2 Jul 2026	"Fixed a bug that could cause a crash"	A near-identical line. Same caveat.

On 23 June AnyDesk wrote "vulnerability" on X about the researchers' flaw, and dated 8.0.3, the release The Hacker News says carries the fix, with the word "bug" in its changelog. An administrator who checks changelogs saw the second one. The same sentence on the Windows page two days later, and a near-identical one on macOS, raise a question that no source answers: whether three crash fixes share a cause. AnyDesk says Windows and macOS are not affected, and nobody independent has tested that.

Even when AnyDesk does name a CVE, the register can lag. CVE-2025-27918, a heap-based buffer overflow that NVD and CISA-ADP both score 9.8, is named in the Linux 7.0.0 changelog of 16 April 2025. NVD's record was published on 6 November 2025, 204 days later (derived), and the CVE list records MITRE as the numbering authority, not AnyDesk. The Hacker News says that earlier flaw has a different mechanism from the one now in the news, so a search for CVE-2025-27918 will not find this one.

The 107 days to scale: eight days of activity, then 85 with no new release

Read to scale, the record has two clusters. In the first eight days, from 22 to 30 June, there is the researchers' post, AnyDesk's reply, 8.0.3 and a follow-up release, 8.0.4, whose only line is a compatibility fix for older distributions. Then 85 days pass without a new Linux release (derived: 30 June to 23 September). The next, 8.1.0, adds a redesigned main window, mentions and status indicators, and two bug fixes, with no security line. Fifteen days after 8.1.0 the code was published (derived). Between 8.0.3 and the latest release there is one release, 8.0.4, and neither it nor 8.1.0 mentions security. The Hacker News says to update to at least 8.0.3, which implies later builds carry the fix. AnyDesk's changelog does not say so.

The download page adds a detail. AnyDesk's Linux list on 9 October shows 8.0.0, 8.0.1 and every build back to 6.3.2, then 8.0.3, 8.0.4 and 8.1.0. It does not show 8.0.2, the build the code targets, though the changelog still lists 8.0.2 (1 April 2026). Internet Archive captures show 8.0.2 as the current download on 23 May and absent by 14 July. The researchers told The Hacker News the vendor "appears to have deleted (?) the 8.0.2 build" after their video. The archive fits that order and cannot show who removed it, why, or whether it was before or after 22 June. What it does show is that withdrawing the one build the code was written for leaves the builds before it listed. The researchers imply those may share the code path. That is unconfirmed, and it is the reason to treat them as unpatched.

Direct connections only, or relays too: two statements, neither tested here

AnyDesk's statement of 23 June reads: "this is limited to direct connections on Linux (connections that do not go through our relays)". The researchers, as The Hacker News reports them, say the same code path is reachable through AnyDesk's relay servers, which they checked with an instrumentation trigger, and that they did not show the full chain over relays. Those are different kinds of claim. AnyDesk's is a scope statement, its "current impact assessment" posted the day after V12's first post. The researchers' is a partial demonstration. AnyDesk runs the relays and can say what they pass through. The researchers can say what their instrumented test showed. Neither has published data that a reader can check, and this briefing tested nothing.

What AnyDesk documents about the direct path matters to a defender. Its settings page says the "Allow direct connections" option gives faster direct connections and that, if it is off, sessions are routed through AnyDesk servers. It says AnyDesk uses TCP port 7070 by default for direct connections and that a custom port can be set. Its firewall page lists the ports it needs as TCP 80, 443 and 6568, says at least one must be open, and does not mention 7070. So a rule written for 7070 protects hosts on the default and no others, and the relay path rides on ports that the vendor tells administrators to keep open.

Two vendors, two interests

AnyDesk Software GmbH sells remote access software, and it has an interest in a narrow scope. The scope it stated, direct connections on Linux, is also the narrowest reading of the exposure. V12 sells a security engine that reviews code. Its follow-up post on X says the flaw was "found using V12", calls V12 its "autonomous AI hacker" and invites readers to find bugs like this in their own code, so a published working exploit is also publicity for that product. Neither interest makes a statement false. Each decides what is stressed: AnyDesk stresses what is not affected, V12 what is reachable. AnyDesk's published disclosure policy asks researchers to allow it "sufficient time" before going public. When V12 told AnyDesk is not stated in anything read, so whether the 22 June post came before or after a report cannot be judged.

The public record: no CVE, no catalogue entry, and what a scanner sees

A keyword search for AnyDesk in NVD returns 21 records, and CVE.org's own search returns the same 21 (both read on 9 October, NVD re-read at 18:59 BST and CVE.org at 19:02 BST). None describes the Linux session protocol. The newest two, CVE-2026-15681 and CVE-2026-15682, were published on 13 July 2026 by the Zero Day Initiative and describe local denial of service through link following. By identifier year there are five 2025 numbers (CVE-2025-27916 to 27919, and 34499) and two 2026 numbers. AnyDesk's changelogs name 27916, 27917 and 27918 in the release lines of 2025 on every platform they affect. They do not name the others in any line found. The Windows changelog entry dated 13 July 2026 reads "Fixed security vulnerabilities", the date NVD published the two 2026 records. The changelog does not say the two are linked.

CISA's Known Exploited Vulnerabilities catalogue, version 2026.10.08, released at 20:09 UTC on 8 October with 1,739 entries, has no AnyDesk entry. Every entry in it is keyed on a CVE number, so a flaw with no CVE cannot be listed, and absence says nothing about exploitation either way. The catalogue release read was about 70 minutes older than the exploit commit (derived), so a later release may differ.

The consequence is practical. A scanner that matches on CVE numbers has nothing to match, and there is no score to put a patching deadline against. Whether any scanner vendor has written a version-based check for this flaw is not known here. Ask yours. Until one exists, the only reliable signal that a Linux host is behind is its version string.

UK reading: a remote tool is an administration interface, and update by default is the control

UK organisations meet this tool in three places: the managed service provider that supports them, the Linux servers, thin clients and kiosks where someone installed it to get in remotely, and the small estate with a handful of Linux machines that nobody inventories. No source read counts how many of each there are. The guidance that applies does not name AnyDesk. AnyDesk is a remote desktop client and service in the same family as the RDP and VNC that the NCSC does list, so treating it as an administration interface is this briefing's reading, not the NCSC's wording.

UK sources, read on 9 October 2026. The NCSC pages were read in a browser. Cyber Essentials was read from a text extraction of the NCSC's requirements PDF saved earlier that day.

Source and date	What it says	What it leaves open here
NCSC, Protect your administration interfaces, part of Secure system administration	Lists remote management protocols such as RDP and VNC, and installed client software that drives an administration protocol, among administration interfaces. Calls them an attack surface and says to constrain who can connect and from where, by a dedicated network, a VPN or an IP allow list, noting allow lists can be overcome and are hard to maintain. Says to install updates as soon as possible, because attackers study what they fix.	Does not name AnyDesk or any remote support product, and says nothing of tools that route through a vendor's relays.
NCSC, Put in place a policy to update by default, version 2.1, reviewed 1 May 2026	Says vendors may "silently" update some flaws without public acknowledgement, so missing an update could miss them, and recommends installing all updates as soon as possible. Best-practice timescales: 5 days for internet-facing software, 7 for operating systems and applications, 14 for internal.	Does not say which row a remote tool with a listening port belongs in.
Cyber Essentials, requirements for IT infrastructure v3.3, April 2026	Updates within 14 days where the vendor calls them critical or high risk, the CVSS v3 score is 7 or more, or the vendor gives no level for the vulnerabilities fixed. Automatic updates where possible. Block unauthenticated inbound connections by default, with inbound rules approved and documented with a business need. Remote administration provided as an external service must meet the controls, and accounts used by an MSP are in scope.	The 14-day clock starts from the vendor's description or a score. A crash line gives neither. Whether an assessor would count the third condition is not stated.

Measured against those timescales, the update was due long before the exploit existed. Five days after 23 June is 28 June and 14 days is 7 July (derived). An organisation that updates by default would have been past 8.0.3 in early July, whatever the changelog said. The organisations exposed are the ones that update by exception: pinned versions, copies that nobody owns, builds taken from an old download page. That is the case for the NCSC's policy over an advisory-driven one, because a changelog cannot be relied on to flag the update that matters, so the policy cannot wait for it. Whether any UK organisation was affected is not stated. If a supplier's staff reach your Linux servers through AnyDesk, ask which build, which port, and whether it is installed on yours at all.

The pattern is not new on this site. Brief 279 covers a cloud role narrowed 260 days after a report with no vendor notice. Brief 155 covers a fix filed as a behaviour change, with no CVE, 21 days before its advisory. Brief 114 covers eight fixes in one release with none named. Different vendors, the same shape: the fix exists, the notice does not, and the date arithmetic is the finding. AnyDesk is also a tool that attackers install themselves, as brief 239 describes. That is a separate matter from this flaw, and a reason to decide who may install it.

What to do, in the order worth doing

Ordered by how quickly each step answers the question that matters: which of your Linux machines are behind, and who can reach them.

What could not be verified

The question that exposes the gap

If the maker of the tool that lets your supplier into your Linux servers fixed a flaw in June and called it a crash fix, what in your process would have made you install that update before the exploit arrived in October, and how would you know today whether you had?

Key facts