Inventory

How to Find Vulnerabilities in Hidden Software Packages and Installers

Picture this: Your IT department updated the organization's computer systems last week, patching a vulnerability in one of the applications that is used daily. Your vulnerability scanner, however, is still showing alerts for that same CVE. How is this possible? The answer often lies in the hidden, forgotten, and redundant software packages scattered across your assets - a problem that creates significant, and usually invisible, security risks.

Unfortunately this isn't a hypothetical scenario. It's a daily struggle for security and IT teams. The complexity of modern software deployment means that a single asset can have multiple, conflicting versions of the same application installed through different mechanisms, leaving the organization vulnerable, even after patching the system.

What’s more, because this software is often out of sight, it can go unpatched and unmonitored for extended periods, providing a persistent and unnoticed entry point for attackers. 

The challenge of diverse package management

The problem arises from the diverse ways software is installed and managed on modern operating systems. These are the most commonly used tools to install software:

  • System Package Managers (such as Advanced Package Tool (APT) and Yellowdog Updater Modified (YUM): The official, stable way to manage core OS components.
  • Modern Package Managers (such as Snap): Newer, containerized formats that can store multiple versions of an application for rollback purposes.
  • Application Installers: Standard .msi, .dmg, or .pkg files that may or may not clean up old versions during an update.
  • Pre-Staged Packages: In environments like Windows, some packages are "staged" by the OS for all users, meaning they exist on the disk even if not fully installed for a specific user.

This variety of installation methods creates a fragmented environment, making it hard to understand exactly what is installed on your systems.

Examples of how hidden packages can have vulnerabilities

The following scenarios illustrate how diverse package management systems on various operating systems can lead to significant vulnerability blind spots if you don’t have access to deeper scanning.

Example 1: Multiple package managers on Linux

Your vulnerability scanner detects a vulnerability on an Ubuntu system that’s resolved in Firefox 142. The Administrator updates the system to the latest version. Upon rescanning the asset however, the vulnerability alert for Firefox persists, even after you verify that Firefox on this asset has indeed been updated to the latest version. What now?

Mondoo detects a Firefox vulnerability on an Ubuntu asset

A deep scan of the asset reveals the problem. It turns out that the system has three different Firefox packages:

  1. An old `apt` package, a remnant of a transition to a newer format.
  2. The current, secure version of Firefox is installed via `snap`.
  3. An older, vulnerable version of Firefox, also from `snap`, kept on the disk for potential rollbacks.

The administrator updated the current version, but didn’t remove the old `apt` package and the older vulnerable version of Firefox that’s also on the disk.

Why is this a problem? This is because an attacker could execute the older, vulnerable binary. The vulnerability isn't truly remediated until the old `apt` package is purged and the old `snap` revision is explicitly removed.

How Mondoo helps

Performing investigations into why a system is still vulnerable can involve a lot of work. However, as opposed to other vulnerability management platforms that may detect that the system is still vulnerable but can’t pinpoint where the CVE still exists, Mondoo actually tells you exactly where to find all the vulnerable installations, even for hidden packages. This enables Administrators to confidently fix all vulnerabilities on an asset without leaving any behind.

By running a query on the asset from the Mondoo platform, we can immediately see where the vulnerable packages are.

Running a data query in Mondoo shows the remaining vulnerable packages

Example 2: Complex application states on Windows

A critical vulnerability is flagged for an old version of Microsoft Edge, but IT has already deployed the latest, patched version. How is this possible? 

Microsoft Edge CVEs are still being detected even though it has already been patched

After investigation, we find that the reason for this is because there are multiple versions of Edge on the system with different package names (`Microsoft.MicrosoftEdge`, `Microsoft.MicrosoftEdge.Stable`) and in various states (`Installed`, `Staged`, `Installed(pending removal)`). Although the primary application is up to date, a `staged` package of a vulnerable version remains on the disk. 

Most vulnerability scanners will correctly identify this as a risk, as the package could be activated or exploited. However, they will not be able to pinpoint where the vulnerability is, leaving engineering teams to spend time investigating the matter to find out where the vulnerable package is.

How Mondoo helps

Due to the complexity of the Windows app model, vulnerability scanners that don’t collect enough information on the asset won’t be able to detect the hidden vulnerabilities. However, Mondoo collects detailed information on all software on every asset, including installed software and hidden packages. For each package, Mondoo shows the exact version, package type, and install location when applicable.

By running a simple one-line query in Mondoo, you instantly see what is causing the issue, so that you can remediate all instances of the vulnerability:

<code>
cnquery run -c "packages.where(name == /Edge/){ name version files }"
→ Connecting to your local system. To learn how to scan other platforms, use the --help flag.
→ no Mondoo configuration file provided, using defaults
packages.where.list: [
  0: {
    files: [
      0: pkgFileInfo path="C:\Program Files\WindowsApps\Microsoft.MicrosoftEdge.Stable_135.0.1000.55_neutral__8wekyb3d8bbwe"
    ]
    name: "Microsoft.MicrosoftEdge.Stable"
    version: "135.0.1000.55"
  }
  1: {
    files: [
      0: pkgFileInfo path="C:\Program Files\Microsoft Edge\Edge.exe"
    ]
    name: "Microsoft Edge"
    version: "139.0.3405.111"
  }
]
</code>

Example 3: Installer artifacts on macOS

A similar situation appears on a macOS device. Although Microsoft Edge has been updated to the latest version, the alert for a Microsoft Edge CVE will not disappear, even after verifying that the Microsoft Edge application has been patched. This is because the issue isn't caused by the formal package manager but the application's installer. The updater has left an old, vulnerable version of the `Microsoft Edge.app` bundle on the file system in a different directory.

The presence of the old application file means that the vulnerability remains exploitable. The only way to fix it is to manually hunt down and delete the old file, a task that is impossible to do at scale without the right tools.

How Mondoo helps

Mondoo saves IT Administrators a lot of time by instantly showing all the vulnerable packages installed on the system, just by running a simple one-line query. This then allows them to remediate the vulnerability much faster.

Find and fix the security risks that pose the biggest threat to your business.

Remediate 3x faster with Mondoo Unified Exposure Management

The power of a detailed asset inventory

The common thread in all these cases is a lack of visibility. You cannot secure what you cannot see. To effectively manage vulnerabilities, you need a single source of truth that shows you exactly what software is on your assets, how it got there, and its current state. Many vulnerability scanners don’t go deep enough to capture complete asset contents, with the result that they aren’t able to discover hidden software packages.

Mondoo however, collects deep information on all your assets, including configurations, relationships, installed software, exposures, contextual risks, and business-criticality. By continuously scanning your systems, Mondoo discovers every package and configuration file, regardless of its installation method. It normalizes this data, so a `snap` package and a Windows `AppX` package are both presented in a unified, easy-to-understand format.

Mondoo shows the details of the vulnerable AppX package

When Mondoo reports a vulnerability, you no longer have to search for it. You can see precisely which assets are affected and why. Mondoo shows:

  • Names of vulnerable packages
  • File versions
  • Exact location of the vulnerable files
  • Application type (active, old version left behind by an installer, or a staged package) 

This level of detail can transform a multi-day investigation into a matter of minutes, allowing security teams to manage risk proactively.

Here’s an example of the information that Mondoo shows for a Microsoft Edge application on an asset:

Mondoo shows package name, format, location, version, and more

Conclusion

The hidden complexity of modern software management is a significant source of security risk. Without a complete and detailed inventory of your software assets and what exactly is running on them, you’re operating in the dark. Especially when a zero-day hits, you need to be able to rely on a detailed asset inventory to quickly understand your exposure and make sure you remediate or mitigate the vulnerability as fast as possible. 

By leveraging a platform like Mondoo, with deep visibility into your entire environment, you can eliminate any hidden risks - significantly reducing your attack surface and enabling you to maintain a truly resilient security posture.

Want to uplevel your vulnerability management with Mondoo? Schedule a demo with one of our experts to learn more.

Christian Zunker

Christian Zunker is Senior Software Engineer at Mondoo. Prior to joining Mondoo in 2022, Christian worked in various infrastructure and development roles for 22+ years.

You might also like

Policy as Code
Why You Need Unified Policy as Code for Terraform Workflows
Policy as Code
Styra OPA Alternative for Infrastructure Security and Compliance Policies
Microsoft
Microsoft Patch Tuesday August 2025: How to Prioritize Vulnerabilities for Patching