Zombie Apps and Other Halloween Horrors on Your Endpoints

October 27, 2026 8 min. read

Direct Answer 

Zombie software is an application that is still installed and running on devices after its vendor stopped supporting it, or after newer versions fixed known vulnerabilities. It is one of five recurring endpoint problems this article covers: zombie apps, ghost installs that IT never deployed, shapeshifting version sprawl, poisoned installers from unofficial sources, and vulnerabilities that Defender reports but nobody fixes. Each one has the same root cause, a missing or manual third-party patching process, and the same cure: inventory, prioritization, automated publishing through Intune, Configuration Manager or WSUS, and reports that show what was actually installed. This Halloween, the Cybersecurity Awareness Month message still applies: don't make it easy for them.

Key Takeaways

  • Zombie apps are not rare. Discovery data from Intune or Defender Vulnerability Management usually shows end-of-life browsers, runtimes and readers that nobody meant to keep.
  • Ghost installs are the applications users installed themselves. They are patched only if your process finds them first.
  • Shapeshifters are the six versions of the same application living side by side; supersedence and Required assignments bring them back to one.
  • Poisoned candy is an installer downloaded from a mirror or a forum. Download from the vendor's original source and verify the hash.
  • The monster under the bed is a known CVE that stays open because finding (Defender) and fixing (Intune) are two different teams and two different tools.

1. Zombie apps: end-of-life software that refuses to die

What it looks like. A Java 8 runtime a line-of-business tool needed in 2019. A PDF reader whose vendor ended support two years ago. A browser pinned to an old version because "the portal only works there." The application still runs, so nobody notices, but it no longer receives security fixes.

Why it matters. Vulnerabilities in end-of-life versions are public and permanent. Scanners flag them every month, and attackers use them because they know the fix will never arrive.

How to banish it.

  1. Export installed software from Intune Discovered apps, Configuration Manager inventory or the software inventory in Microsoft Defender Vulnerability Management.
  2. Mark every application whose vendor has ended support or whose installed version is more than one major version behind.
  3. Uninstall what no longer has an owner. For what must stay, define an exit date and an interim control, such as restricting it to a small device group.
  4. Put everything else on an automated update path so it does not become a zombie next year.

2. Ghost installs: applications IT never deployed

What it looks like. Discovery data shows screen-recording tools, personal cloud sync clients, alternative browsers and compression utilities that do not appear in any deployment. Users installed them, often with good reasons, and nobody is patching them.

Why it matters. You cannot patch what you do not know you run. Ghost installs are usually the oldest versions on the device because they were installed once and never touched again.

How to banish it.

  1. Compare discovered applications with your list of deployed applications. The difference is your ghost list.
  2. Decide per application: adopt it (deploy and update it centrally), replace it with an approved alternative, or remove it.
  3. Add adopted applications to your catalog so the next release reaches them automatically.
  4. Run the comparison monthly. Ghosts come back.

3. Shapeshifters: one application, six versions

What it looks like. The same application appears in inventory as 118.0, 120.1, 124.0, 126.2 and two unknown builds. Some devices got the update, some were offline during the maintenance window, some were re-imaged from an old reference image.

Why it matters. Version sprawl hides risk behind an average. A compliance report that says "92 percent current" still leaves the 8 percent that run the version with the known exploit.

How to banish it.

  1. Report by installed version, not by "update published."
  2. In Intune, use Win32 app supersedence so a new version updates devices that still run an older one. In Configuration Manager, use automatic deployment rules and collections based on installed version.
  3. Use Required assignments for security updates. Available assignments wait for users to open Company Portal, which some never do.
  4. Fix the reference image so new devices do not arrive already behind.

4. Poisoned candy: installers from the wrong source

What it looks like. An administrator in a hurry downloads an installer from a mirror site, a forum link or a search result that looks official. The package installs, works, and may carry more than the application.

Why it matters. Trojanized installers are a common delivery method, and a package published through your own deployment tool inherits all of its trust.

How to banish it.

  1. Download installers only from the vendor's original source.
  2. Verify the file hash against the vendor's published value before packaging.
  3. Keep the hash with the package record so an auditor can trace what was deployed.
  4. If you use a publishing tool, confirm it downloads from vendor sources and performs integrity checks on every package.

5. The monster under the bed: the CVE everyone can see and nobody fixes

What it looks like. Microsoft Defender Vulnerability Management lists the same vulnerable application for weeks. The security team sees it in Defender. The endpoint team manages deployments in Intune. The ticket between them is where the fix stalls.

Why it matters. The window between a public vulnerability and its fix is exactly what attackers exploit. Every manual hand-off adds days to that window.

How to banish it.

  1. Agree on remediation targets per severity with the security team, and prioritize with CVSS, the CISA Known Exploited Vulnerabilities catalog and EPSS."
  2. Connect findings to deployments: when Defender reports an application as vulnerable above an agreed CVSS threshold, the updated package should be published to Intune and assigned to the affected groups without a ticket.
  3. Review Not Applicable and failed installations weekly, and record every exception with an owner and an expiry date.

The five horrors at a glance

Horror Where it hides Symptom Cure
Zombie apps Unsupported runtimes, readers, pinned browsers Still runs, never updates Inventory, exit dates, automated updates
Ghost installs User-installed tools Not in any deployment Discovery comparison, adopt/replace/remove
Shapeshifters Same app, many versions "Mostly current" reports Version-level reporting, supersedence, Required assignments
Poisoned candy Installers from mirrors and forums Package works, origin unknown Vendor sources only, hash verification
Monster under the bed Open CVEs in Defender Finding and fixing in different tools Threshold-based automation from Defender to Intune

How Easy2Patch helps

Easy2Patch publishes third-party application updates into Microsoft Intune, Configuration Manager and WSUS from one catalog, without installing an additional agent on endpoints. Its catalog shows the CVEs each update fixes, installers are downloaded from vendors' original sources and verified with hash checks, and version supersedence keeps devices on the current release. With the Defender integration in E2P Patch Manager, applications that Microsoft Defender Vulnerability Management reports as vulnerable can be published to Intune automatically once their highest CVSS score meets the minimum you configure, then assigned to the Microsoft Entra ID groups you choose.

Frequently Asked Questions

Zombie software is an application that remains installed and running on devices after its vendor has stopped supporting it, or after newer versions have fixed known vulnerabilities. Because it still works, users and administrators rarely notice it. Its vulnerabilities are public and will never be fixed by the vendor, so the only remediation is to upgrade, replace or remove it. Software inventory from Intune, Configuration Manager or Microsoft Defender Vulnerability Management is the usual way to find it.

Compare discovered software with deployed software. Intune's Discovered apps report, Configuration Manager hardware inventory and the software inventory in Defender Vulnerability Management list what is actually installed on devices. Anything on that list that does not match a deployment is user-installed. For each one, decide whether to adopt it into central deployment and updates, replace it with an approved alternative, or remove it, and repeat the comparison monthly.

Version sprawl means that a share of devices still runs a version with known vulnerabilities even when most devices are current. Compliance should therefore be reported per installed version rather than per published update. In Intune, Win32 app supersedence lets a new version update devices that run an older one, and Required assignments install it without waiting for users. In Configuration Manager, automatic deployment rules and version-based collections serve the same purpose.

Download installers only from the vendor's original source, verify the file hash against the value the vendor publishes, and keep that hash with the package record. Avoid mirror sites, forum links and search results that imitate vendor pages. If you use a publishing tool, confirm that it downloads from vendor sources and performs integrity checks before publishing to Intune, Configuration Manager or WSUS.

Microsoft Defender Vulnerability Management identifies vulnerable applications but does not package or deploy third-party updates. The fix has to be delivered by a deployment system such as Intune or Configuration Manager, and the hand-off between the security team that sees the finding and the endpoint team that deploys the update is where delays occur. Agreed remediation targets, prioritization with CVSS, CISA KEV and EPSS, and automation that publishes updates when a finding exceeds a threshold shorten that window.

Conclusion

The scariest things on an endpoint are rarely new. They are the applications that were installed years ago and never updated, the versions nobody counted, and the findings nobody owned. Use the last days of Cybersecurity Awareness Month to run the inventory, name an owner for every application, and put updates on an automated path. Then the only ghosts left on October 31 will be the ones at the door.

Get started with our patch management software for free Advanced Patch Management Get 30 Days Premium Trial