Remove Outdated PuTTY Versions from Windows Endpoints

What the outdated PuTTY remover does

This Automox Worklet™ enumerates every PuTTY installation on a Windows endpoint and removes all of them except the newest. The Worklet scans the Uninstall registry keys under HKLM:\SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall and HKLM:\SOFTWARE\WOW6432Node\Microsoft\Windows\CurrentVersion\Uninstall, along with the per-user equivalents under HKCU. PuTTY entries are identified by Publisher (Simon Tatham, the upstream maintainer) and by DisplayName matching PuTTY*. The script parses the DisplayVersion field, sorts numerically, keeps the highest, and uninstalls every other version.

PuTTY installs accumulate on long-lived endpoints because the official installer does not always uninstall older versions cleanly. A user who upgrades from 0.74 to 0.78 to 0.81 often ends up with three Program Files entries, three sets of Start menu shortcuts, three registered URL handlers, and three Uninstall entries side by side. The Worklet runs each older version's QuietUninstallString and then deletes any orphaned Program Files (x86)\PuTTY directories and orphaned uninstall registry keys that the upstream MSI does not clean on its own.

The evaluation phase counts the Simon Tatham-published PuTTY Uninstall entries before invoking any QuietUninstallString, so endpoints with a single install pass at exit code 0 and remediation is skipped. Endpoints with two or more installs are flagged, and because the version-sort logic always preserves the highest DisplayVersion, a recurring policy never accidentally removes the version the user just installed even if the upgrade landed minutes before the evaluation.

Why consolidate down to a single PuTTY version

Older PuTTY versions have a steady stream of accumulated bugs and vulnerabilities. PuTTY before 0.81 was vulnerable to the NIST P-521 key recovery issue (CVE-2024-31497); older releases have other documented weaknesses around RSA key generation, the SSH-2 transport, and the X11 forwarding path. An endpoint with PuTTY 0.70 and PuTTY 0.81 installed side by side is only as secure as the version the user happens to double-click; the older binary remains on disk, registered with Windows, and reachable by any script that finds it in PATH.

Scheduling this Worklet across the Windows developer estate converges every endpoint on a single-version PuTTY footprint, so a CVE that affects PuTTY at version N or earlier becomes a non-issue the moment the fleet is brought up to version N plus one. Recurring evaluation re-applies the rule any time a user reinstalls an older release from an archived MSI, and the version-sort logic guarantees the newest install is always preserved. Pair this Worklet with a PuTTY-install Worklet that delivers the approved current release to endpoints that need it, and the combined policy keeps the fleet at the same supported version without per-laptop intervention.

How the outdated PuTTY removal works

1. Evaluation phase: The Worklet runs Get-ItemProperty against the Uninstall registry hives (64-bit and Wow6432Node 32-bit) and filters by Publisher -like 'Simon Tatham' or DisplayName -like 'PuTTY*'. It parses DisplayVersion into a System.Version object for comparison, sorts the results, and identifies any version older than the maximum. If at least one outdated install is found, the endpoint is flagged for remediation. Endpoints with a single PuTTY install are reported compliant and skipped.

2. Remediation phase: The remediation script iterates the outdated list and runs each entry's QuietUninstallString (falling back to UninstallString with /S or /quiet when no quiet variant exists). After each uninstall, the script removes any orphaned C:\Program Files\PuTTY and C:\Program Files (x86)\PuTTY directories, then strips lingering uninstall registry keys via Remove-Item. Exit 0 if the endpoint ends with exactly one PuTTY install matching the highest version; non-zero with the offending entry name in stderr if a removal failed.

PuTTY cleanup requirements

• Windows 10, Windows 11, or Windows Server 2016 and later with PowerShell 5.1 or PowerShell 7 available

• Local administrator or SYSTEM privileges for the Automox agent (the default agent context satisfies this) to remove HKLM uninstall keys and per-user PuTTY installs

• Awareness that the Worklet does not migrate stored PuTTY sessions between versions; sessions live in HKCU:\Software\SimonTatham\PuTTY\Sessions and are shared across all PuTTY installs, so removing older versions does not delete saved sessions

• Coordination with developer teams that may rely on a specific older PuTTY release for compatibility with a legacy server; exclude those endpoints from the policy scope rather than disabling the Worklet wholesale

• A paired Worklet that deploys the approved current PuTTY release to endpoints that need it, so the fleet converges on the same version rather than each endpoint keeping whatever happened to be newest

Expected PuTTY state after cleanup

After successful remediation, Apps and Features on the Windows endpoint lists exactly one PuTTY entry, and that entry is the highest-version PuTTY install that was found at evaluation time. The Program Files PuTTY directories contain only the binaries for the kept version. Start menu shortcuts and URL handler registrations point at the kept version. Subsequent policy runs report the endpoint as compliant unless a user reinstalls an older version, at which point the next evaluation catches it and removes it again.

Validate by running Get-Package -Provider Programs on a remediated endpoint and confirming only one PuTTY entry appears. For audit evidence, capture the activity log entry showing the removed versions and the kept version, then store it with the policy run identifier. If a user reports that a saved PuTTY session disappeared after the cleanup, the cause is almost always that the session was stored under HKCU for a service account or shared profile rather than the user's own profile; the Worklet itself does not touch the Sessions hive.