Firefox 156 is out, and The Register's read on it is that we now live in a forest of forks: Waterfox for the privacy crowd, LibreWolf for the Mozilla hardliners, Pale Moon for the engine purists. Great news for enthusiasts. Terrible news for whoever is accountable for 800 endpoints.
Because every one of those forks is another browser binary sitting on a machine you own the SLA for. Another version number drifting out of date. Another thing users installed without a ticket. And in most IT shops, another thing your tooling literally cannot see — because monitoring lives in one console, the RMM in another, remote access in a third, and the helpdesk in a fourth.
If you have ever been asked "which machines are running an outdated Firefox-family browser right now?" and answered with a spreadsheet and a prayer, this post is for you.
What the Fork Explosion Actually Means for Your Fleet
Three things make browser forks operationally different from Firefox itself, and none of them work in your favor:
Forks patch on their own schedule. LibreWolf and Waterfox rebuild from Mozilla source, but a fix reaches a user's machine only after the fork maintainer ships it. Pale Moon is a different story entirely: it runs Goanna, its own engine, so a Mozilla security fix may never apply to it at all — the Pale Moon team has to port it themselves.
Third-party patch catalogs rarely cover forks. Your patch module almost certainly knows about Firefox, Chrome, and Edge. LibreWolf, Waterfox, and Pale Moon are usually absent from the catalog entirely — which means they sit on machines for months without an update, and no compliance scan ever flags them, because the scan only checks the applications it knows exist.
Users install them in ways that dodge classic inventory. User-level installs that never touch HKLM. Portable builds dropped into a profile folder. No MSI, no uninstall entry in the standard registry keys. A WMI query for Win32_Product or a scan of the usual uninstall locations comes back clean, and everyone believes the fleet is standardized.
The Problem: You Cannot Patch What Your Tooling Cannot See
Here is how the average Tuesday goes in a shop with disconnected tooling:
A rendering-engine vulnerability in Gecko hits the news with reports of exploitation in the wild. Security asks IT for an inventory of affected machines by end of day. Your monitoring tool — PRTG, Zabbix, whatever you run — watches CPU, disk, and services. It has no idea what browsers are installed. Your RMM has software inventory, but it is a point-in-time snapshot refreshed weekly, and its data does not talk to anything else. Your helpdesk holds tickets, not inventories. So the process becomes: export from the RMM, notice the scan missed user-level installs, push an audit script manually to a handful of machines because that is all the standalone remote tool will queue at once, merge spreadsheets, and still end the day with a list you cannot fully defend.
Meanwhile the ticket queue is burning: users whose fork of choice just auto-updated and now crashes, users asking whether they are affected, a manager who read the news. Every one of those tickets means a tech opens the remote access tool separately, types in a machine name, and pokes around with zero monitoring history on screen. Twelve tabs, five tools, one client.
The real cost is not the CVE. The real cost is that a 10-minute inventory question became a half-day project, remediation drags across a week instead of an afternoon, and nobody — including you — can produce a clean audit trail proving which machines were fixed and when. That is an SLA miss, a compliance gap, and a steady drip of technician burnout, all at once.
How AlertMonitor Turns This Into a 10-Minute Job
This is the exact workflow AlertMonitor was built to collapse. The difference is not a shinier dashboard — it is that monitoring, RMM, helpdesk, and patching share one agent, one data model, and one timeline.
- Continuous software inventory from the same agent. Installed applications, including user-level installs, are reported continuously — not as a weekly snapshot. Browser versions are queryable per device, per group, per client, fleet-wide.
- Run an audit script across a device group in one action. Select your Windows workstations group, pick the browser audit script, execute. Results stream back into the platform as monitoring data, visible on the same timeline as alerts and tickets. No exports, no spreadsheet merging.
- Alert on the finding. Set a condition on script output: any result matching Waterfox, LibreWolf, or Pale Moon raises an alert, routes to the endpoint team, and links to a ticket automatically. Discovery is not a report someone has to read — it is a tracked work item with an owner and a clock.
- One click from alert to remote session. When a tech picks up the ticket, the remote session opens from the same screen, with the device's monitoring history right there. No second tool, no retyping machine names, no hoping the endpoint is reachable.
- Push the approved baseline, script out the rest. Deploy the approved Firefox MSI across the group from the same console. For unapproved forks, review the list first, then run a removal script against the affected devices — and the removal, the alert, and the ticket resolution all land on the same timeline.
- An audit trail that answers the compliance question. When the CISO asks for proof that every endpoint was remediated by Friday, the answer is one filter on the timeline — not four exports stitched together.
In practice, the inventory question that used to take 45-plus minutes of exports and guesswork becomes a saved script and one execution — roughly 10 minutes to a verified, per-device answer. Remediation that dragged across a week compresses into the same afternoon, because the alert, the remote session, the software push, and the ticket all live in one place.
Practical Steps: Audit Your Fleet Today
Step 1 — Find out what is actually installed. This script checks the standard uninstall keys (64-bit, 32-bit, and per-user HKCU) plus common portable-install locations for Firefox-family browsers and forks. Save it in AlertMonitor and run it against your workstation device groups:
# Browser fork audit — run from the AlertMonitor script engine against a device group
$pattern = 'Firefox|Waterfox|LibreWolf|Pale Moon'
$uninstallPaths = @(
'HKLM:\SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall\*',
'HKLM:\SOFTWARE\WOW6432Node\Microsoft\Windows\CurrentVersion\Uninstall\*',
'HKCU:\SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall\*'
)
$installed = Get-ItemProperty $uninstallPaths -ErrorAction SilentlyContinue |
Where-Object { $_.DisplayName -match $pattern } |
Select-Object DisplayName, DisplayVersion, Publisher, InstallLocation
# Portable builds often never write an uninstall key — check known paths
$portablePaths = @(
(Join-Path $env:LOCALAPPDATA 'Waterfox'),
(Join-Path $env:LOCALAPPDATA 'LibreWolf')
)
$portable = $portablePaths | Where-Object { Test-Path $_ }
[pscustomobject]@{
ComputerName = $env:COMPUTERNAME
BrowsersFound = ($installed.DisplayName -join '; ')
Versions = ($installed.DisplayVersion -join '; ')
PortableFound = ($portable -join '; ')
}
Step 2 — Make it continuous, not one-off. In AlertMonitor, schedule that script daily against the workstation group and set an alert condition on its output: a result containing Waterfox, LibreWolf, or Pale Moon raises a low-priority alert and auto-creates a ticket. From that moment, shadow browsers are a tracked work item, not a surprise.
Step 3 — Enforce the baseline. Use the patch module or a software push to keep the approved Firefox MSI current. For forks you have decided to remove, test the uninstall command on one machine first — fork uninstall strings vary — then run it against the flagged devices:
# Example: silent removal after review. Verify the exact key per fork on one machine first.
$app = Get-ItemProperty 'HKLM:\SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall\*' -ErrorAction SilentlyContinue |
Where-Object { $_.DisplayName -match 'LibreWolf' }
if ($app -and $app.QuietUninstallString) {
Start-Process cmd.exe -ArgumentList ('/c ' + $app.QuietUninstallString) -Wait
}
Step 4 — Do not forget the Linux fleet. The same audit belongs on your Linux endpoints:
#!/bin/bash
for b in firefox waterfox librewolf palemoon; do
if command -v "$b" >/dev/null 2>&1; then
echo "$b: $("$b" --version 2>/dev/null)"
fi
done
The Bottom Line
The forest of Firefox forks is not going away, and neither is endpoint diversity in general. The teams that handle this well are not the ones with the most tools — they are the ones where inventory, alerting, scripted remediation, remote sessions, patching, and the ticket thread all live in one system. When the next in-the-wild browser CVE lands, your answer to security should be a saved script and a verified list, not a spreadsheet and a prayer.
Related Resources
AlertMonitor RMM & Remote Management AlertMonitor Platform Overview Book a Demo RMM & Remote Management Resources
Is your security operations ready?
Get a free SOC assessment or see how AlertMonitor cuts through alert noise with automated triage.