CVE-2026-40342

[Tim Crawford]

Customer just sent me this

https://nvd.nist.gov/vuln/detail/CVE-2026-40342

As I read it this is not really an issue, at least on Windows?

Sounds like the perpetrator would need access to the server file system.
If they had that you have other problems already.

Feedback please.

Thanks,
Tim Crawford

[Dimitry Sibiryakov]

Tim Crawford wrote 20.04.2026 18:41:
> As I read it this is not really an issue, at least on Windows?

It is already fixed:
https://github.com/FirebirdSQL/firebird/security/advisories/GHSA-7pxc-h3rv-r257

> Sounds like the perpetrator would need access to the server file system.
> If they had that you have other problems already.

There is no need to have access to all file system. /tmp or FTP upload public
is enough.

--
WBR, SD.

[Tim Crawford]

Thanks very much.
Will have to upgrade a few dbs
But they all behind firewall anyway

Tim

  Original Message  

--
   WBR, SD.

--
Support the ongoing development of Firebird! Consider donating to the Firebird Foundation and help ensure its future. Every contribution makes a difference. Learn more and donate here:
https://www.firebirdsql.org/donate
---
You received this message because you are subscribed to the Google Groups "firebird-support" group.
To unsubscribe from this group and stop receiving emails from it, send an email to firebird-suppo...@googlegroups.com.
To view this discussion, visit https://groups.google.com/d/msgid/firebird-support/0bf7d2a4-a9ac-47b4-a38d-c9c42556ac96%40ibphoenix.com.

[Mark Rotteveel]

It is an issue, because it allows someone with CREATE FUNCTION/CREATE
PROCEDURE privileges to define a UDR and load a .dll/.so from a location
that wasn't intended.

And on its own it might seem not to be so easily exploitable, but if you
consider that if the same person has CREATE TABLE permissions, they can
create external table(s), and then they can create and populate a file
with arbitrary binary data. Or if there is some other issue they can
exploit to put a file somewhere. Or if there already is a suitable file,
and the exploiter knows its location, etc., etc.

That said, I'm a bit confused by the existence of the bug itself, as I
thought that the engine name used in the definition of a UDR where not a
direct library filename, but either referred to a defined name in the
plugins.conf *or* were a name derived from the library names in the
plugins folder, and not the other way around.

Mark
--
Mark Rotteveel

[Nikolaus Kern]

Hello Mark,

can you please explain what the minimum access of an attacker needs to be in this scenario? 

1. Access to the firebird server as RDB$ADMIN?

2. Access to the filesystem of the firebird server?

It would be great to understand the practical impact of this CVE.

Thanks

Niko

[Mark Rotteveel]

On 22-04-2026 20:35, Nikolaus Kern wrote:
> Hello Mark,
>
> can you please explain what the minimum access of an attacker needs to
> be in this scenario?
> 1. Access to the firebird server as RDB$ADMIN?

Access with a user with CREATE FUNCTION, CREATE PROCEDURE, or CREATE
TRIGGER privilege to define a UDR and

1) Sufficient knowledge to be aware of the location of a pre-existing
exploitable library on your system,
or
2) CREATE TABLE privilege to define an external table (assuming
ExternalFileAccess is not None), and that it's possible to construct a
relative path between the plugins directory and the external table file.
or
3) Some other means to inject a file on the system that is knowable or
guessable (e.g. a web app that uploads files to some known, or otherwise
discoverable location)

For 1, 2 and 3, the location needs to be readable by Firebird, 2 also
needs to be writeable by Firebird.

So, yes RDB$ADMIN will have those privileges, but even less privileged
users might have sufficient privileges to pull this off, as long as they
have CREATE FUNCTION/PROCEDURE/TRIGGER and maybe CREATE TABLE.

> 2. Access to the filesystem of the firebird server?

You don't need full access, you just need to know of, or be able to
create a suitable file somewhere that is readable by Firebird.

That is easy enough if you have CREATE TABLE privilege and
ExternalFileAccess is not None. And you need to know where the external
table file can (or will) end up, so you can create a relative path
between the two. And you can probe that by constructing a pathless
external table file with illegal characters in the filename (e.g. just
'.' on Linux, '<' on Windows, I think (right now no Windows available to
check)), and then insert into it, as Firebird will then report the error
with the path where it tried to create the file, which will be the first
location listed in Restrict, or some default location (which might not
work if the config is actually None (default), but will work if it's Full).

And constructing a relative path is trivial: just add (more than) enough
../ sections to reach the root or beyond (which will also end up in the
root) and work back from there. On Windows this might still fail if the
plugins directory is on a different drive from the external table file
though (not sure if there might be some tricks to work around that).

And if you wonder "how can I create an arbitrary file with an external
table"? It's a binary format, and - for example - if you use a column of
BINARY(1) (CHAR(1) CHARACTER SET OCTETS), you can write a file one byte
per insert. Using a BINARY column sized for the whole file, or - if the
file is bigger than 32767 bytes - multiple tables with differing column
lengths pointing to the same file will make it quicker.

Mark
--
Mark Rotteveel

[Nikolaus Kern]

Hello Mark,

 thanks for the detailled response.

 When Firebird runs on a Windows Server as system the read/write access exists.

 Is it recommended to run the Firebird Service on Windows with an own useraccount, that is not system?

Niko

[Mark Rotteveel]

On 30-04-2026 06:54, Nikolaus Kern wrote:
> Hello Mark,
>

> thanks for the detailled response.
>
> When Firebird runs on a Windows Server as system the read/write access
> exists.
>
> Is it recommended to run the Firebird Service on Windows with an own
> useraccount, that is not system?

Using a custom Windows useraccount with more restricted access can make
an installation more secure, yes.

Mark
--
Mark Rotteveel

[Dimitry Sibiryakov]

'Mark Rotteveel' via firebird-support wrote 30.04.2026 9:58:
> Using a custom Windows useraccount with more restricted access can make an
> installation more secure, yes.

Using of virtual accounts is convenient for that:

https://learn.microsoft.com/en-us/windows-server/identity/ad-ds/manage/understand-service-accounts#virtual-accounts

--
WBR, SD.