CVE-2026-86938: DLL Hijacking in the FileMaker Pro Installer

On March 29, I reported a DLL hijacking issue in the Windows installer for Claris FileMaker Pro. My original report covered the 22.0.5 installer. A local user who could place a malicious DLL in the installer's directory could get that code loaded when the installer ran with administrator privileges.

The issue was assigned CVE-2026-86938. Claris credited me for the report and fixed the issue in FileMaker Pro 26.0.3. Claris's advisory confirms the impact and the fixed version.

The installer directory was the trust boundary

The installer brought together two kinds of access: permission to change files in its directory and permission to run code as an administrator. The vulnerability let a file supplied through the first become executable code inside the second.

That distinction matters because a DLL runs inside the process that loads it. The loading process supplies its security context. In this case, the installer ran with administrator privileges, so code loaded from the installer directory gained those privileges too. Microsoft's DLL security guidance describes this relationship between an untrusted library location and local privilege elevation.

The directory therefore became part of the installer's code trust boundary. Protecting the installer executable alone would leave that dependency unresolved: the program also needed to control where its libraries came from.

I classify this as CWE-427: Uncontrolled Search Path Element. The relevant weakness is that a location used to resolve code can be modified by someone whose code should not run with the caller's authority.

Why library location matters

Windows can resolve a library by searching directories when a program requests it without a fully qualified path. The executable's directory is one of the locations in the standard search order for an unpackaged application. That makes library resolution sensitive to the files surrounding an executable. Microsoft's search-order documentation describes the rules and the factors that can change them.

The executable's directory and the current working directory are separate concepts. Safe DLL search mode moves the current working directory later in the search order. The executable's directory remains a search location. This is why a general setting described as a safer search order still needs to be considered alongside the application's own loading policy.

Those Windows rules explain the failure class. The CVE record identifies the installer directory as the location involved, but it does not identify the loader call, the DLL name, or whether the request originated in the installer or one of its components.

Directory permissions and elevation

Local access alone does not tell us who can modify a particular directory. Windows checks file and directory access against their security descriptors and the caller's access token. A directory writable by one user is not automatically writable by every other local account. Microsoft's file security documentation explains those checks.

For this issue, the relevant condition was the ability to place a library in the directory used by the affected installer. The risk depends on both the permissions at that location and the context in which the installer later executes.

Elevation is a separate part of that context. Under the usual User Account Control flow, a standard user supplies administrator credentials, or an administrator approves a consent prompt, before a process receives an administrative token. Microsoft's UAC documentation describes that distinction.

The documented issue depends on the installer running with elevated rights. Loading the DLL into that process gives its code the process's authority. The public record does not establish a way to bypass the elevation prompt.

Scope of the finding

The CVE record describes arbitrary code execution with elevated administrator privileges and lists FileMaker Pro versions before 26.0.3 as affected.

The affected range is the vendor's published scope. My original report's version is narrower. The public record does not establish a remote attack path or an issue in FileMaker Server, WebDirect, or the macOS installer.

The fix

Claris says the issue is addressed in FileMaker Pro 26.0.3 and recommends updating. The FileMaker Pro release notes list version 26.0.3 in September 2026.

For deployment teams, I would include saved installer packages in that update. Updating an installed application does not replace an older installer kept for future deployments. Use the fixed installer, replace affected copies in deployment repositories, and restrict who can modify the directory used for an elevated installation. These are operational recommendations based on the installer-specific scope.

For developers, Microsoft's DLL security guidance recommends explicit library paths and controlled search locations. LoadLibraryEx search flags and SetDefaultDllDirectories provide ways to constrain that policy. The selected directories also need suitable permissions, since an explicit path can still point at a file someone else can replace.

Dependencies need the same review. Windows can resolve a loaded library's dependencies separately, even when the first library was selected by a full path. A loading policy needs to cover those dependencies as well. Microsoft's search-order documentation calls out that behavior.

These are general defenses for the weakness. The public CVE record identifies the fixed release without describing Claris's implementation change.

Illustrative loading examples

These standalone Windows C++ examples show how a developer can constrain library loading. The application name and private library path are fictional.

Load a Windows library from System32

For a Windows-provided library, LOAD_LIBRARY_SEARCH_SYSTEM32 restricts the directory search to the system location. This example uses version.dll and stops if loading fails. The flag's behavior is documented in Microsoft's LoadLibraryExW reference.

#include <windows.h>

int wmain()
{
    HMODULE library = LoadLibraryExW(
        L"version.dll",
        nullptr,
        LOAD_LIBRARY_SEARCH_SYSTEM32
    );

    if (library == nullptr) {
        return static_cast<int>(GetLastError());
    }

    // Use the library while this handle remains valid.
    FreeLibrary(library);
    return 0;
}

Load an application library from a protected path

A private component needs an explicit path to a directory controlled by the application's trusted deployment process. Here, LOAD_LIBRARY_SEARCH_DLL_LOAD_DIR includes that library's directory when resolving dependencies, while LOAD_LIBRARY_SEARCH_SYSTEM32 also permits system dependencies. Microsoft requires a fully qualified path for this combination. Flag reference.

#include <windows.h>

int wmain()
{
    // Placeholder: use the verified path from trusted installation metadata.
    const wchar_t* libraryPath =
        L"C:\\Program Files\\ExampleApp\\ExampleComponent.dll";

    HMODULE library = LoadLibraryExW(
        libraryPath,
        nullptr,
        LOAD_LIBRARY_SEARCH_DLL_LOAD_DIR | LOAD_LIBRARY_SEARCH_SYSTEM32
    );

    if (library == nullptr) {
        return static_cast<int>(GetLastError());
    }

    // Use the component before releasing its module handle.
    FreeLibrary(library);
    return 0;
}

The second example assumes the library and its directory are protected from modification by lower-privileged users. The full path selects a file, but the directory's permissions determine who can replace it. Both properties matter for the installer trust boundary described above.

Timeline