Upgrade Python

What the Python runtime patcher does

This Automox Worklet™ patches Python runtime vulnerabilities on Windows endpoints by upgrading installed Python builds to a version you specify within the same major.minor release series. The Worklet supports point upgrades such as 3.9.1 to 3.9.5 or 3.11.2 to 3.11.9. Python treats each major.minor release (3.9, 3.10, 3.11, 3.12) as a separate product, so cross-series moves are out of scope here and belong to a parallel install policy.

Python on Windows installs per user by default, which means the uninstall keys live under HKEY_USERS rather than HKLM:\SOFTWARE\Python or HKLM:\SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall. The Worklet maps HKEY_USERS as a PowerShell drive named HKU, walks every loaded user hive, and inspects SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall for DisplayName entries that match Python in the target series. Get-Package and the py launcher (py -0p) can confirm the same set of installs from an interactive console, which is useful when validating a pilot run.

Remediation creates a short-lived Windows scheduled task that runs the matching installer (python-3.x.x.exe for 32-bit, python-3.x.x-amd64.exe for 64-bit) with the /quiet argument in the Users principal context. The task unregisters automatically once the installer exits, leaving no residual scheduled task on the endpoint. Both architectures coexist on the same host and are upgraded independently in a single policy run.

Why patch Python runtime CVEs at fleet scale

The Python runtime ships security fixes on a regular cadence. The interpreter, the standard library (urllib, http.client, ssl, tarfile, xml), and the bundled pip, OpenSSL, and SQLite components have all carried CVEs in recent releases. A workstation pinned at 3.9.1 or 3.11.0 keeps every known interpreter and stdlib bug shipped after that build. Build servers, CI runners, and ML workstations make the exposure worse because they execute untrusted requirements.txt content and pull packages from external indexes.

Python advisories regularly carry tarfile path traversal, ssl module, and urllib request CVEs that affect any Windows endpoint running a CPython interpreter from python.org. Developer workstations, build agents, and scripted automation hosts commonly hold multiple side-by-side 3.x installs that Windows Update will not touch. Once you stage the patched python.org installer in the console payload, this Worklet aligns every Windows endpoint to that build, replacing per-host upgrade scripts with a single policy run.

How Python runtime patching works

1. Evaluation phase: The Worklet mounts HKEY_USERS as the HKU PowerShell drive and iterates every user hive. For each user it reads SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall and filters DisplayName entries that contain Python with a DisplayVersion in the target series (derived from $appVersion.Remove(3), so 3.9.5 yields 3.9). Any install whose DisplayVersion is lower than $appVersion increments a remediation counter. The script exits 1 (flag for remediation) when the counter is non-zero, exits 0 with "Compliant" when only current installs are found, and exits 0 with "Not Applicable" when no Python install in the series is present.

2. Remediation phase: The Worklet re-scans HKEY_USERS and splits matches into 32-bit (DisplayName contains "32") and 64-bit (DisplayName contains "64") buckets. For each outdated install, it builds a Schedule.Service task that calls $scriptDir\$32bitFilename or $scriptDir\$64bitFilename with /quiet, registers the task under the Users principal, polls Get-ScheduledTask until State is Ready, then unregisters the task. On installer failure the catch block writes "ERROR: Installation of <filename> failed" and exits 1. On success the Worklet logs "Successfully installed <filename>" and finishes with exit 0.

Python upgrade prerequisites

• Windows 7 or later (Python 3.9 and newer require Windows 10 or Windows Server 2016)

• PowerShell 2.0 or later, with the Schedule.Service COM object available (default on supported Windows builds)

• An existing Python install in the same major.minor series on the endpoint; this Worklet does not cross-upgrade 3.5 to 3.9 or 3.10 to 3.11

• Both the 32-bit and 64-bit python-3.x.x installer .exe files uploaded to the Automox console as policy payload (a host that only runs 64-bit Python still benefits from the parallel script support)

• $appVersion set to the three-segment version (for example, '3.11.9') matching the python.org build

• $32bitFilename and $64bitFilename set to the exact uploaded filenames including the .exe extension (for example, 'python-3.11.9.exe' and 'python-3.11.9-amd64.exe')

Expected endpoint state after Python upgrade

After a successful remediation, every in-series Python install on the endpoint reports the target DisplayVersion under HKEY_USERS\<sid>\SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall, and HKLM:\SOFTWARE\Python\PythonCore\<series>\InstallPath reflects the upgraded interpreter for any system-context entries. py -0p lists the patched build, python --version and python -c "import sys; print(sys.version)" return the new release, and Get-Package -Name "Python*" returns the new Version field. Existing pip-installed packages remain in the per-version site-packages directory and continue to work.

Subsequent Automox policy runs report the endpoint as Compliant without re-running the installer, because the evaluation phase finds DisplayVersion equal to $appVersion. Activity log output is the validation surface to monitor: a successful run writes "Successfully installed python-3.x.x.exe" (and the -amd64 variant when applicable) followed by "Compliant" and exit code 0. A failed run writes "ERROR: Installation of <filename> failed" and exits 1, with the most common causes being a filename mismatch between the $32bitFilename / $64bitFilename variables and the uploaded payload, a missing installer in the console attachment list, or a Schedule.Service registration failure on a hardened endpoint. Virtual environments created against the previous patch level may need recreation when binary wheels were built against the older interpreter; pure-Python packages do not.