TeamViewer Fixed a Flaw That Could Override Your Session Permissions
TeamViewer’s 29 September bulletin fixes five High-severity flaws in Full Client and Host, including a remote-session permission bypass. The bulletin’s fixed baseline for its current branch is 15.82; older branches need the platform-specific legacy fixes. The bulletin, issued and last updated on 29 September, says the vendor knew of neither public disclosure nor active exploitation. That is a dated vendor statement, not a finding about every installation.
Remote-support software depends on an unusually important promise: the person granting access should be able to decide what the other party can do. A session that connects successfully is not enough. The selected restrictions also have to hold.
Five paths with different prerequisites
| Vulnerability | Condition and consequence |
|---|---|
| CVE-2026-19743 | An authenticated local low-privilege IPC user: elevated file writes on Windows, macOS and Linux. |
| CVE-2026-92368 | Linux/macOS 15.70 to below 15.82: opening a crafted .tvs recording can execute code with the current user’s privileges. The official CVE vector requires user interaction and no pre-existing privileges; the bulletin instead lists low privileges and no interaction. |
| CVE-2026-92369 | A local low-privilege Windows user can reach SYSTEM through a successfully timed installer-rollback race during installation or updating. |
| CVE-2026-92370 | Windows, Linux and macOS: remote-session restrictions can be bypassed, potentially allowing code execution. The description requires an authenticated remote attacker; the vector lists no pre-existing privileges and requires user interaction. |
| CVE-2026-92371 | Authenticated local Linux user, 15.0 to below 15.82: recording-path race enables privileged file operations. |
Update, 31 October 2026: The current official recording-flaw data supports the file-opening prerequisite despite the bulletin’s differing vector. For the session flaw, a no-privileges metric does not erase the authentication step in the description, and required interaction is not unattended access. These sources do not establish unauthenticated internet takeover. Consult the complete affected-product and fixed-build matrix before selecting a package.
Match maintenance fixes to the operating system
The bulletin lists the following maintenance builds for Full Client and Host. Match the product, operating system and branch to its per-vulnerability affected scope before selecting a build.
| Branch and platform | Listed fixed maintenance build |
|---|---|
| 15.64, Windows 7 and 8 | 15.64.8 |
| 14.7, Windows, Linux and macOS | 14.7.48855 |
| 13.2, Windows | 13.2.36230 |
| 13.2, Linux | 13.2.153995 |
| 13.2, macOS | 13.2.153994 |
Find the installations outside the usual update list
BlackTree’s operational assessment: Treat this as an estate-wide remote-support review. Compare endpoint-management records with software inventories, service lists and supplier-maintained asset lists. A deployment dashboard can only report on the devices it knows. Jump boxes, technicians’ systems and externally maintained machines deserve an explicit owner rather than an assumption that another team handles them.
For each installation, record the product, operating system, current branch and approved destination build. Ask the owner to verify the running version after the change. A successful deployment job can still leave an old process running, an offline device untouched or a second installation outside the package manager’s scope. Keep those exceptions visible until endpoint evidence closes them.
Where an older branch is unavoidable, record its support entitlement and a dated retirement plan. Do not turn availability of a maintenance build into an indefinite exemption from lifecycle work.
Test the permission decision as well as connectivity
In an authorised test environment, pair a normal support session with a deliberately restricted one. Confirm that allowed work succeeds and that a representative denied action remains unavailable. Record both outcomes alongside the installed build. This is an acceptance check for your remote-access configuration, not an instruction to reproduce the vulnerabilities.
For incident review, compare session records with support tickets and approved connection windows. Ask whether the initiating identity, destination and activity fit the work that was authorised. Preserve the relevant records before account or endpoint changes make that comparison harder. An unfamiliar connection is a lead to investigate, not proof of exploitation.
Agree on containment in advance: who can end an unexpected session, who can revoke a supplier’s access and how the business will obtain support while the machine is isolated. Those decisions are easier to make before an analyst has to balance evidence preservation against an active connection.
Close the access exceptions
Patching and access governance answer different questions. Review standing technician permissions, unattended-access settings and former support partners. For occasional external work, use a time-bounded approval with a named owner and an expiry that is actually checked. A corrected client still cannot decide whether an old supplier should remain trusted.
The useful completion record is therefore more than a version number: a known endpoint, an approved build, tested restrictions and accountable access. That gives the next responder something concrete to verify.
Primary source
TeamViewer security bulletin TV-2026-1010, issued and updated 29 September 2026.
