Summary
Sometimes when deploying an Update Package aiming to patch your active Insecure/EOL programs, your WSUS/SCCM takes it further and applies your update as a brand new installation on machines that were not intended to install it. This article explains why this happens and how to avoid it.
Symptoms
You scanned few/all machines with SVM2018 and the scan engine detected Insecure/End-Of-Life programs on your systems. 
You go ahead and 'Create Update Package', then you publish it with the default configuration. You approve the package for your machines trusting that the update will only patch your 'regular' installations only.
Your update package installs well on the machines you intended to update. However, it also goes further and it installs on machines that have not had this program before (e.g Adobe Reader).
All of a sudden, you end up with an unwanted new Adobe Reader program installed on a File Server at the path 'C:\ Program Files' even though this server never had it installed before.
You wonder how did that happen?
Cause
When SVM2018 update packages are deployed, they have certain 'Applicability' configuration appended to them that is been actively used for evaluation of the package applicability by WSUS/SCCM servers.
One of those Applicability rules is the 'Path' rule which makes Windows Update (or SCCM) to look at the machine and compare its path/file availability against the 'Path' rules enabled in a given package.
If the client(s) being evaluated have the same path location on their systems, and version of the program lower than the version of your update package, the package is then offered for installation as 'Applicable'. That's just basic deployment controls used by Microsoft deployment servers. 
Why does your Update Package installed on a system where it wasn't installed before?
Based on its detection, the SVM will configure new packages with the Path applicability it had appended based on its scan findings:
- Somewhere in the system there is a standalone program file, plugin ActiveX control file, or self-contained self-executable file which contains metadata of an active installation
- This could be a file that was not removed correctly from the previous uninstall.
- Such files are known to be 'zombie files'.
- This could be a temporary file that was dropped upon download and never taken care of.
- They may exist at locations like %AppData\...%, %Temp%, at forgotten directories at C:\Program Files\, or at alternative locations where the user had placed these.
- Maybe somewhere on the system, you've got backup directory where you store legacy executable files for backward compatibility support or for other purposes?
Steps To Reproduce
Steps to reproduce the issue.
- Drop any insecure executable file on any drive (internal) on your system and then run a scan.
- Find your scan result in the interface and review it.
- Note the vulnerable version you dropped, and see the detected path.
- Go to SPS (after you have compiled your Smart Groups) and find the product package entry there.
- Double-click on the entry to create a patch and move with Next to step 3 where you will see rules.
- Notice that your custom path is listed there. Leave it enabled (tick the checkbox).
- Publish the package and approve it for your test system
- The package will appear in Windows Update / or will be installed by the SCCM if that's your server.
- These behaviors are expected when the package is offered to the system after evaluation of its path applicability matches this system conditions:
- If this package aimed to update existing installation on the system, the update package should update the existing components of the active installation without changing their location.
- If the package was deployed by mistake (because it had path applicability of backup directory), it will run as 'Full New Install' and then it will install at its default installation directory.
- These behaviors are expected when the package is offered to the system after evaluation of its path applicability matches this system conditions:
Resolution
To perform successful deployments you should leave enabled paths that match your company's deployment policies and match your expectations for a legitimate approved program instance installation path.
It is important to pay careful attention to the enlisted paths in your SVM2018 Update Packages and recognize those paths that are not intended candidates for the type of update you create.
You may want to avoid locations such as:
- ....\Backup
- C:\Users
- E:\External\Personal\Files
- %AppData%
- %Temp%
- Other paths that may look odd and not intended
- You can look at the files and ask yourself:
"Are those files portable standalone executable files?" Are these actual applications, aren't the paths odd compared to standard locations?
- Determine what's OK and what's not OK to enable as Applicability for your package.
- Deselect all checkboxes next to those paths and only leave enabled the ones which you approve
- Add additional applicability rules if you wish to strengthen the control even more before.
- Publish the package and deploy it based on the correct applicability criteria preventing unwanted deployments.
Workaround
See more about "Blacklisting" and understand how you can prevent such files to be scanned and reported therefore keeping your application database clean and focused on actively used applications.
You must always have a process to clean old executable leftovers, or zombie-files, that can be used as they are vulnerable nevertheless. This is a best-security practice and recommended by Flexera.
