Microsoft Teams for Desktop RCE (Nessus 250276): Update New Teams and Remove the Teams Machine-Wide Installer

Microsoft Teams for Desktop < 25122.1415.3698.6812 Remote Code Execution (August 2025) is a Nessus finding (plugin 250276) for a new Teams build that lacks the fix for CVE-2025-53783. To fix it, update new Teams (re-provision with teamsbootstrapper.exe -p where needed), then remove the Teams Machine-Wide Installer and leftover classic Teams folders so the finding stays closed.

What the scanner is actually detecting

A host with a long Teams history usually shows several related Tenable plugins together. Two of them cover new Teams (the MSIX app) and one covers classic Teams 1.x:

All three are local checks in Nessus’s Windows family that compare versions and exploit nothing. Plugin 250276 depends on the KB items SMB/Registry/Enumerated and WMI/Windows App Store/Enumerated: during a credentialed scan Nessus reads the registry and the list of Store (MSIX) apps through WMI, then flags any Teams package below the fixed build. Plugin 179635 works from the installed software inventory for classic Teams and relies on the version the files report, so a classic Teams copy left in any user profile is enough to trigger it.

Real-world risk

CVE-2025-53783 is a heap-based buffer overflow (CWE-122) that Microsoft says lets an unauthorized attacker execute code over a network. Microsoft scores it CVSS 3.1 7.5 with the vector AV:N/AC:H/PR:N/UI:R: no privileges needed, but user interaction is required and attack complexity is high, meaning the attacker must gather information specific to the target environment. Microsoft rated it Important, listed it as neither publicly disclosed nor exploited when it was released on August 12, 2025, and assessed exploitation as “less likely”. Tenable’s VPR was 4.9 when we checked.

Classic Teams is a different story. Microsoft ended support on July 1, 2024 and ended availability on July 1, 2025, after which the classic client no longer works. It will never receive another fix, so plugin 179635 cannot be closed by updating. The practical risk from leftover classic folders is modest (nobody can work in them), but they are unpatchable code on disk and they keep your report noisy.

Keep the age in mind too. Microsoft ships Teams updates twice a month, so a host still below the August 2025 build has not updated for a long time. Treat the finding as a sign of a broken updater, not a one-off missing patch.

How to confirm it on the host

Run these in an elevated PowerShell session. First, list new Teams versions registered for each user and the version provisioned for new profiles:

# New Teams (MSIX) registered per user
Get-AppxPackage -AllUsers -Name MSTeams |
  Format-List Name, Version, PackageUserInformation

# Version provisioned for profiles created later
Get-AppxProvisionedPackage -Online |
  Where-Object DisplayName -eq 'MSTeams' | Select-Object DisplayName, Version

# Any registration still below the highest fixed build in the table
$fixed = [version]'25163.3611.3774.6315'
Get-AppxPackage -AllUsers -Name MSTeams | Where-Object { [version]$_.Version -lt $fixed }

Then look for classic Teams, both the MSI and the per-user copies:

# Teams Machine-Wide Installer (PSChildName is the MSI product code)
Get-ItemProperty 'HKLM:SOFTWAREMicrosoftWindowsCurrentVersionUninstall*',
                 'HKLM:SOFTWAREWOW6432NodeMicrosoftWindowsCurrentVersionUninstall*' -ErrorAction SilentlyContinue |
  Where-Object DisplayName -like 'Teams Machine-Wide Installer*' |
  Select-Object DisplayName, DisplayVersion, PSChildName

# Classic Teams binaries left in any profile
Get-ChildItem 'C:Users*AppDataLocalMicrosoftTeams' -Filter Teams.exe -Recurse -Depth 2 -Force -ErrorAction SilentlyContinue |
  Select-Object FullName, @{n='Version';e={$_.VersionInfo.FileVersion}}

New Teams lives in %ProgramFiles%WindowsApps and stores its data under %LocalAppData%Packages, so anything under %LocalAppData%MicrosoftTeams belongs to classic Teams.

How to fix it

Step 1: bring new Teams up to date

New Teams checks for updates when it starts and every few hours in the background, but only while a user is signed in to the machine, and an update applies only after Teams restarts. On a single machine, sign in, open Teams and use the Restart button that appears next to the ellipsis (…) when an update is waiting.

To force the current build onto a machine for every user, download the latest bootstrapper from Microsoft (https://go.microsoft.com/fwlink/?linkid=2243204) and run it from an elevated prompt:

teamsbootstrapper.exe -p

This downloads the latest Teams MSIX, provisions it for all current and future users and replaces any other Teams version already present. For bandwidth-constrained sites, download the MSIX once and point the bootstrapper at it, either a local path or a UNC share:

teamsbootstrapper.exe -p -o "\fileserverpackagesMSTeams-x64.msix"

Microsoft stresses using the newest bootstrapper, so compare Properties > Details > Product version of your stored copy with a fresh download. The tool prints success or an HRESULT on failure. Deploy it with Intune, Configuration Manager or Group Policy software installation, the same way you would push a change to hundreds of PCs.

Step 2: remove the Teams Machine-Wide Installer

Do this only after new Teams is provisioned, or users can end up with no Teams client. The Machine-Wide Installer is what placed classic Teams into each profile, and Microsoft notes that uninstalling it triggers removal of classic Teams for each user as they sign in. Use the product code from the confirm step:

:: 64-bit Teams Machine-Wide Installer
msiexec.exe /x {731F6BAA-A986-45A4-8936-7C3AAAAA760B} /qn ALLUSERS=1

:: 32-bit Teams Machine-Wide Installer
msiexec.exe /x {39AF0813-FA7B-4860-ADBE-93B9B214B914} /qn ALLUSERS=1

On machines with Microsoft 365 Apps, Microsoft says Office attempts this removal on its own, but hosts that still show the installer in a scan need it done explicitly.

Step 3: clean up per-user classic Teams

Profiles that nobody signs in to never trigger the automatic cleanup. For those, Microsoft publishes a signed classic Teams uninstallation script (UninstallClassicTeams.ps1, from https://aka.ms/uninstallclassicteamsscript). Run it elevated:

Get-AuthenticodeSignature .UninstallClassicTeams.ps1 | Select-Object Status, SignerCertificate
powershell.exe -NoProfile -ExecutionPolicy Bypass -File .UninstallClassicTeams.ps1

For every profile under C:Users, the script ends running classic teams.exe processes, runs each user’s classic uninstaller, and deletes AppDataLocalMicrosoftTeams, AppDataRoamingMicrosoftTeams, AppDataLocalMicrosoftSquirrelTemp and the per-user TeamsMeetingAddin folder. It also uninstalls the Machine-Wide Installer, removes its TeamsMachineInstaller Run values and stale registry keys, and prints a JSON summary. Unless you pass -SkipAllArtifactsRemoval, it also deletes %ProgramFiles(x86)%MicrosoftTeamsMeetingAddin and TeamsPresenceAddin.

Step 4: fix whatever stopped updates

If new Teams was behind, find the cause or the finding will return. Microsoft lists these common blockers:

• The Delivery Optimization service is disabled, or download mode is set to 100 (Bypass), which Teams does not support. Check Get-Service DoSvc and the DODownloadMode value under HKLM:SOFTWAREPoliciesMicrosoftWindowsDeliveryOptimization (GPO: Computer Configuration > Administrative Templates > Windows Components > Delivery Optimization > Download Mode).
• Firewalls or proxies that block Microsoft 365 and Teams CDN endpoints, or SSL inspection on those endpoints.
• Modified ACLs under %ProgramFiles%WindowsApps, which leave the package corrupted and unable to update.
• Machines where nobody signs in, such as kiosks and rarely used lab PCs. Re-provision these on a schedule.

How to verify the fix and rescan

1. Re-run the confirm commands. The version filter should return nothing, the provisioned version should be current, and both classic Teams queries should come back empty.
2. Read the JSON output of the uninstall script from your deployment tool to catch hosts where removal failed.
3. Rescan with the same credentialed policy. Plugin 250276 needs WMI enumeration of Store apps, so make sure WMI is reachable from the scanner; a scan without it can look clean simply because the check never ran.

What can break and how to roll back

• Outlook meeting add-in: Microsoft warns that after classic Teams is removed, new Teams and the Teams meeting add-in may not work together. For new Teams builds below 24215.1007.3082.1590, Microsoft provides a separate DetectAndUninstallTMA.ps1 script. Updating new Teams first (Step 1) keeps you clear of that range.
• Users without Teams: removing classic Teams before new Teams is provisioned leaves users with nothing. The recovery is simply teamsbootstrapper.exe -p.
• Running sessions: the script kills classic Teams processes, so schedule it outside working hours.
• Replaced installs: provisioning replaces any Teams version a user installed themselves.

There is no meaningful rollback to classic Teams, since it stopped working in July 2025. If you must remove new Teams while troubleshooting, Microsoft documents Get-AppxPackage *MSTeams* -AllUsers | Remove-AppxPackage -AllUsers and teamsbootstrapper.exe -x -m. Do not pin an older build: it reopens the vulnerabilities.

Common false positive reasons

• Departed users’ profiles: classic Teams folders in dormant profiles are real files that get reported even though nobody runs them. Remove them rather than excluding the plugin.
• Stale per-user registrations: updates need a signed-in user, so an account that has not signed in since the update can still have an older MSTeams version registered. Re-provision, or delete the unused profile.
• Update waiting for a restart: Teams downloaded the fix but has not restarted. That is not a true false positive, since the old build is still running.
• Non-persistent VDI and golden images: fixes made on a session host are lost when it resets. Fix the master image instead.

FAQ

Does updating new Teams also clear plugin 264898?

Yes. Its fixed build (25163.3611.3774.6315) is higher than the one for 250276, so any current build clears both.

Do I need the Microsoft Store to update new Teams?

No. Tenable’s solution mentions the Store, but the bootstrapper downloads the MSIX straight from Microsoft, and Teams updates itself using Delivery Optimization.

Can I just delete %LocalAppData%MicrosoftTeams?

Microsoft says manual deletion is possible but not recommended because it may leave residual files. Use the uninstallation script, which also cleans registry entries.

Is Teams on macOS affected?

Yes. Microsoft lists new Teams for Mac as fixed in 25122.1207.3700.1444, delivered through Microsoft AutoUpdate. Plugin 250276 itself checks Windows hosts only.

Tracking this finding across many hosts

Teams findings usually come back on the same hosts because of a broken updater or golden image, so it helps to track them as one campaign instead of separate tickets. SITEY imports Nessus results uploaded as .nessus exports, merges duplicate findings within each scanner and can retest individual Nessus findings after a fix. Its AI can draft host-specific remediation scripts, such as the provisioning and cleanup steps above, which run only after human approval through SITEY agents on Windows endpoints, followed by a retest to confirm closure.

Sources

• Tenable: Microsoft Teams for Desktop < 25122.1415.3698.6812 Remote Code Execution (August 2025), plugin 250276
• Tenable: Microsoft Teams < 1.6.0.18681 RCE, plugin 179635
• Microsoft Security Response Center: CVE-2025-53783
• Microsoft Learn: Bulk deploy the Microsoft Teams desktop client
• Microsoft Learn: How to uninstall the classic Teams client