Someone adds you to a group chat. A link appears. You click it, and a file from your disk is on its way to a stranger’s channel. On 3 October a researcher published the chain behind that sentence in Telegram Desktop, and the write-up reached the Hacker News front page this week.
Telegram had already fixed it. The fix landed in the public repository on 16 September and shipped in version 7.2.9 the following morning. That is a good response, and it is not the interesting part. The interesting part is who received it. On 10 October 2026, twenty-three days after the fixed release, we checked every packaging channel that distributes Telegram Desktop. Sixty-four of eighty-six still hand you a build the advisory calls vulnerable.
TL;DR
- CVE-2026-107181 is an IPC record-separator injection in Telegram Desktop before
7.2.9: a craftedtg://link with an unescaped semicolon splits into several instructions and exfiltrates local files, including the session keys that are your login. CVSS 8.1 High. - Upstream fixed it on 16 September and released
7.2.9the next day. That release’s notes say, in full: “Fix some tlottie incorrect renderings.” The CVE was not published until 7 October. - Of the 86 repositories that package Telegram Desktop, 22 ship 7.2.9 or newer and 64 do not. The median packaged build was released 128 days ago; 20 channels are over three years behind.
- Not a silent-backport artefact: Debian’s tracker marks bookworm and sid vulnerable and the fix unfixed; Ubuntu’s marks bionic, focal and jammy needs-triage, in
universeon all three. - The channels that delivered were the vendor’s own: Snap stable had
7.3.0on release day, Flathub is patched, Telegram’s tarball serves7.2.9. Across 36 security-relevant desktop applications and 226 repositories, 996 of 3,211 application/repository pairs ship the current version and 793 are a full major version behind.
The defect, in one paragraph
Telegram Desktop registers the tg URI scheme. Click a tg:// link while the application is running and the operating system starts a second process anyway; that process finds the first over a local socket, flattens the URL into text and hands it over. The wire format is a keyword, an argument and a semicolon closing the record, and the argument is never escaped, so a semicolon inside the URL becomes a record boundary and one instruction becomes several. The injected OPEN: record accepts any scheme, including an internal one called interpret: that reads a named file and sends it to a chat without asking who requested it. Point it at tdata and the session keys leave the machine. VulnCheck assigned CVE-2026-107181; Ubuntu’s record scores it 8.1 High on CVSS 3.1.
Finding 1: the release note said nothing
The fix is commit db3405699f8f, authored 16 September 2026, touching eleven files across core/sandbox.cpp, core/application.cpp and the main window. Its message is “Remove legacy interpret path helper.” Nothing in it says security.
Version 7.2.9 was published to GitHub at 09:31 UTC on 17 September. We pulled the release body. It reads, in its entirety: “Fix some tlottie incorrect renderings.” The CVE record followed on 7 October, twenty days later.
That gap is the window in which downstream packagers decide whether a release is routine. A maintainer triaging a queue on 18 September had a changelog entry about animation rendering and no advisory. There was nothing to escalate. We measured the general case last week: 1,826 of 6,119 advisories we timed landed more than a month after the fix was already public. This post is the other half of that clock. Once the advisory finally exists, how long until the fix reaches a user?
Finding 2: 64 of 86 channels still ship the bug
We pulled all 331 package records for telegram-desktop from the Repology API, reduced them to the newest version in each of the 86 distinct repositories, and compared each against 7.2.9. Mapping every shipped version string back to its upstream release date, using all 874 tags in the Telegram Desktop repository, turns “behind” into days.
| Channel | Ships | Released | Age on 10 Oct |
|---|---|---|---|
| Ubuntu 18.04 | 1.2.17 | 2018-04-08 | 3,107 days |
| Debian 11, Ubuntu 20.04, Devuan 4, Trisquel 10 | 3.1.1 | 2021-09-25 | 1,841 days |
| Ubuntu 22.04 LTS | 3.6.1 | 2022-03-16 | 1,669 days |
| Debian 12 (bookworm) | 4.6.5 | 2023-02-25 | 1,323 days |
| Debian 13 backports, Debian sid, Kali rolling | 5.7.2 | 2024-11-05 | 704 days |
| Alpine 3.24 | 6.8.5 | 2026-06-04 | 128 days |
| Gentoo, NixOS 26.05 | 7.1.5 | 2026-09-02 | 38 days |
| openSUSE Tumbleweed, Fedora RPM Fusion | 7.2.5 | 2026-09-04 | 36 days |
| Arch, FreeBSD, Termux, Chocolatey | 7.2.9 | 2026-09-17 | 23 days, patched |
| Scoop, Homebrew casks, SlackBuilds | 7.3.0 | 2026-10-09 | 1 day, patched |
Across all 86 channels the median packaged build was released 128 days ago and the mean 581. Thirty-six are more than a year behind, twenty-four more than two years, twenty more than three. Every patched channel is a rolling release, a community overlay or a user-space package manager: Arch and its derivatives, FreeBSD ports, Termux, Chocolatey, Scoop, Homebrew casks, SlackBuilds. Not one conventional stable distribution is on the list.
Rolling is not sufficient either. openSUSE Tumbleweed ships 7.2.5 and Alpine edge 7.2.6. Rolling buys you weeks, not days, when nobody has been told there is a reason to hurry.
Finding 3: the two biggest say it out loud
A version number is not a patch state: Debian and Ubuntu backport fixes without changing the upstream version, so a stale version string is suggestive rather than conclusive. That is why we went to their own trackers.
Debian’s security tracker entry for CVE-2026-107181 lists telegram-desktop as vulnerable in bookworm at 4.6.5+ds-2 and vulnerable in forky and sid at 5.7.2+ds-5. The fixed-version table reads (unfixed), against Debian bug 1150328. The madison query confirms there is no telegram-desktop in Debian 13 stable at all; the only route onto a current Debian is trixie-backports, which serves 5.7.2+ds-2~bpo13+1, a build upstream released in November 2024.
Ubuntu’s record, published 8 October, marks bionic, focal and jammy as needs-triage and noble and resolute as DNE. Launchpad shows why the triage queue is slow: telegram-desktop is in universe on every series that carries it. Universe is community-maintained and carries no Canonical security commitment outside an Ubuntu Pro subscription. The free user on 22.04 LTS is running a four-and-a-half-year-old build of a messenger with a published account-takeover CVE, and nobody owes them a fix.
Note the inversion. Ubuntu 24.04 and 25.10 do not package Telegram Desktop at all, which leaves their users better off than the three LTS releases that do: they were forced onto a channel that updates.
Finding 4: the channels that did deliver
- Snap was the fastest thing we measured anywhere. The stable channel carried
7.2.9on 18 September, one day after the GitHub release, and7.3.0on 9 October, the same day upstream tagged it. - Flathub publishes
7.2.9in its current appstream data, and its manifest on master is already pinned to tagv7.3.0at commit42f8a36d43b8, committed at 23:45 UTC the night before we looked. Patched on either reading. - Telegram’s own download at
telegram.org/dl/desktop/linuxredirects totd-setup-linux-x64-7.2.9.tar.xz. Patched, and one release behind the Snap.
On Linux the vendor’s channels were current and the operating system’s channels were not. That is the opposite of the security advice most teams give, and it is the correct answer for this class of software.
Finding 5: this is not a Telegram problem
To check whether this was one badly maintained package or a structural property, we repeated the measurement across 36 further applications that handle messages, credentials or network traffic: 3,211 application/repository pairs across 226 repositories.
996 of 3,211 pairs, 31.0 per cent, ship the current upstream version. 793, 24.7 per cent, are a full major version behind. Evolution is current in 5 of 110 repositories, Chromium in 5 of 101, HexChat in 6 of 109, Telegram Desktop in 7 of 86. The best result in the cohort is password-store at 104 of 118, which is a shell script with no build step, and that is the whole explanation.
Three channels were current for every cohort application they carry: Homebrew at 11 of 11, Vylen and CRUX at 9 of 9. A long tail is current for nothing it ships: Debian 11 and Ubuntu 20.04 at 0 of 25, Ubuntu 18.04 at 0 of 24, and Rocky, AlmaLinux and CentOS Stream 8, 9 and 10 at 0 of 7 each.
What this measurement does not say
It does not say 64 channels are exploitable. It says they ship a version string below the fixed release, which we converted into a vulnerability claim only for Debian and Ubuntu, where their own trackers state it. For the rest, the version string is the only evidence on offer, and that absence is itself a finding: there is no machine-readable way to ask most packagers whether a specific CVE is closed in their build. The 36-application cohort likewise measures delivery latency, not exposure, and the major-version figure is the subset where the gap is hard to explain away as release-cadence noise.
If you ship software, your release is a proposal
Publishing a fixed version is not shipping a fix. Eighty-six independent parties decide whether your release becomes a delivery, on their own cadence, and you cannot see which one your users installed from unless you build that visibility yourself. Four things follow, and the first two cost nothing.
- Say “security” in the release notes. Packagers and their automation read release bodies and CVE feeds. A security fix described as a rendering fix is invisible to both. Telegram’s response time was excellent and its signalling was not, and the signalling is what the downstream clock runs on.
- Request the CVE at release, not three weeks later. The advisory is the trigger for every downstream security process in existence. Twenty days of silence after a public fix is twenty days in which the diff is available to anyone reading the commit log and the defenders are not looking.
- Record the install channel in your telemetry. Version alone tells you a user is behind. Version plus channel tells you whether you can do anything about it, and which channel to go and poke.
- If delivery has to be guaranteed, own the updater. That is a real cost with real signing and rollback obligations, and it is the only mechanism on this page that put a fix on a machine within a day.
If you run a fleet rather than ship one, inventory by install channel rather than by operating system, and for the handful of applications where a one-click file read ends your week, prefer the vendor channel over the distribution package. The same gap runs the other way in the libraries you bundle: the Chromium inside your Electron app does not auto-update either.
Method
All figures first-hand on 10 October 2026. Package data from the Repology API (331 records for Telegram Desktop, 3,211 pairs after the cohort sweep); upstream release dates from 874 tags in the Telegram Desktop repository; vulnerability status from OSV, NVD, the Debian security tracker, madison, the Ubuntu security API and Launchpad; channel checks against the Snapcraft info API, the Flathub appstream API and manifest, and the Telegram download redirect. The scripts are a hundred lines of Python and the sweep runs in under four minutes, which is the argument for running it against your own estate rather than reading ours.
REPTILEHAUS builds and maintains software for teams who have to answer questions like this one, across development, DevOps, AI and Web3. If you ship an application and cannot say what version your users are running, or you run a fleet and the honest inventory is a spreadsheet, that is a solvable problem and we have solved it before. Get in touch.
📷 Photo by Arum Visuals on Unsplash
