Malicious directory junction can cause WiX RemoveFoldersEx to possibly delete elevated files

Exploitation

No confirmed exploitation recorded. Patch Next marks exploitation only from CISA KEV.

CVSS

7.9 · CVSS:3.1/AV:L/AC:L/PR:L/UI:R/S:C/C:N/I:H/A:H

EPSS

• CVE-2024-29188: 0.24% estimated exploitation activity in the next 30 days; percentile 15.41 (FIRST EPSS, 2026-11-03). This is a model estimate, not proof of exploitation or customer exposure.

As published by the source; long descriptions are shortened.

Summary The custom action behind WiX's RemoveFolderEx functionality could allow a standard user to delete protected directories. Details RemoveFolderEx deletes an entire directory tree during installation or uninstallation. It does so by recursing every subdirectory starting at a specified directory and adding each subdirectory to the list of directories Windows Installer should delete. If the setup author instructed RemoveFolderEx to delete a per-user folder from a per-machine installer, an attacker could create a directory junction in that per-user folder pointing to a per-machine, protected directory. Windows Installer, when executing the per-machine installer after approval by an administrator, would delete the target of the directory junction.

Published by the source

25 Mar 2024, 19:42 UTC

Last modified by the source

25 Mar 2024, 19:42 UTC

Source last checked

26 Oct 2026, 17:00 UTC

1. Revision 1 · created · 26 Oct 2026

   Published from ghsa record GHSA-jx4p-m4wm-vvjg

Preview the exact text before you copy it. Commands are read-only suggestions; review them before running anything.

# Patch Next advisory brief: CVE-2024-29188

Advisory: Malicious directory junction can cause WiX RemoveFoldersEx to possibly delete elevated files
IDs: CVE-2024-29188, GHSA-jx4p-m4wm-vvjg
Record: https://patchnext.com/advisories/cve-2024-29188 (revision 1, source checked 26 Oct 2026, 17:00 UTC)
Inventory: none attached. This brief comes from a public page and does not say whether any deployment is affected.
Severity: High (CVSS 7.9)
Exploitation: no confirmed exploitation recorded. Patch Next confirms exploitation only from CISA KEV.
Vendor response: Vendor fix available; fixed versions by package: wixtoolset.util.wixext 4.0.5; wix 4.0.5, 3.14.1. A vendor fix does not mean a deployment is fixed.

## Affected components
- NuGet wixtoolset.util.wixext: affected < 4.0.5; fixed in 4.0.5
- NuGet wix: affected < 3.14.1; >= 4.0.0, < 4.0.5; fixed in 3.14.1, 4.0.5

## Suggested inspection (read-only)
- NuGet wixtoolset.util.wixext: check the installed version with your package manager.
- NuGet wix: check the installed version with your package manager.

## Supported action
Upgrade each affected component to a fixed version on its release line. For a transitive dependency, upgrade the parent package or add an override or constraint, then regenerate the lockfile. Redeploy every environment that ran an affected version.

## Required regression checks
- Run the test suite and a production build.
- Exercise the features that depend on wixtoolset.util.wixext, wix.
- Repeat the inspection and confirm that only fixed versions remain installed.

## Rollback considerations
- Keep the previous lockfile and deployment artifact. Rolling back reinstates the vulnerable version, so apply any documented mitigation while you fix forward.

## Unresolved questions
- Which deployments run an affected version?
- Exploitation status can change. Check again before lowering the priority.
- Mark the work resolved only after the fixed version is verified in production.

## Sources
- Verified: https://github.com/advisories/GHSA-jx4p-m4wm-vvjg (GitHub-reviewed advisory GHSA-jx4p-m4wm-vvjg lists affected ranges: NuGet wix >=0 =4.0.0 =0 <4.0.5)

Commands are suggestions: review each one before running it.