Skip to content

Backported CVE patches for Firebird 2.5.9

Summary of fixes

Description Severity IBP build no.
CVE-2026-35215 DoS via malicious slice descriptor in slice packet High 27142
CVE-2026-33337 Buffer overflow on parsing corrupted slice packet High 27142
CVE-2026-28212 One packet DoS High 27142
CVE-2026-28214 Server hangs when using specific clumplet on batch creation Medium 27142
CVE-2025-54989 XDR Message Parsing NULL Pointer Dereference High 27140

The CVEs

Disruptive attacks leading to a denial of service with no loss of integrity

Severity - HIGH 7.5/10

Exploitability Impact

Attack vector

Network

Attack complexity

Low

Privileges required

None

User interaction

None

Scope

Unchanged

(loss of) Confidentiality

None

(loss of) Integrity

None

(loss of) Availability

High

These four all have the same characteristics:

  • Accessible via the network

  • Easy to set up and execute

  • Require no special privileges

  • Require no knowledge of any database

  • Server crash is guaranteed

  • No possibility of internal access

In addition it is likely that these bugs have existed in the code since the Borland InterBase days, or perhaps even longer.

Mitigations possible

These attacks are entirely dependent upon network access. If it is not possible to apply a patched release then steps should be taken to ensure that access to the Firebird port (usually 3050) is limited as much as possible.

Severity - MEDIUM 6.5/10

  • CVE-2026-28214 Server hangs when using specific clumplet on batch creation
Exploitability Impact

Attack vector

Network

Attack complexity

Low

Privileges required

Low

User interaction

None

Scope

Unchanged

(loss of) Confidentiality

None

(loss of) Integrity

None

(loss of) Availability

High

Unlike the previous DoS attacks this one requires a valid username and password to connect to a valid database.

Given that there are much easier DoS attacks (see above) it is doubtful that this particular exploit will be ever be used.

That said, it is a reminder that Firebird user logins and passwords should be carefully controlled. Database aliases should also be protected where possible and example databases such as employee should never be deployed to production servers.