Postgres security issue in QGIS
Patrick Maslen
Emma Hain
 |
North Road Cartography • Development • Spatial Analysis north-road.com    QGIS User Conference 2025 2-3 June, Norrköping, Sweden FOSS4G 2025 17-23 November, Auckland, New Zealand |
--
You received this message because you are subscribed to the Google Groups "QGIS Australia User Group" group.
To unsubscribe from this group and stop receiving emails from it, send an email to australian-qgis-use...@googlegroups.com.
To view this discussion, visit https://groups.google.com/d/msgid/australian-qgis-user-group/f0b3e582-731f-44b8-a0b9-db729100b25en%40googlegroups.com.
Daniel Paez
The best way to check is to verify the PostgreSQL version bundled with the upcoming QGIS release—if it matches a patched version from the CVE advisory, it's covered. You can also check QGIS’s release notes or GitHub for updates on dependencies. If the fix isn’t included, users can mitigate the risk by manually using a separate PostgreSQL installation instead of the bundle in QGIS (this is what I did).
Cheers,
Brad Hards
On Thursday, 20 February 2025 2:13:26 PM AEDT Patrick Maslen wrote:
> Hi team, we have several hundred QGIS users here at the Department of
> Biodiversity, Conservaiton and Attractions in WA. Our cybersecurity team
> have been alerted to a vulnerability in Postgres
> (https://www.postgresql.org/support/security/CVE-2025-1094/) and they
> believe that this is an issue in QGIS because of Postgres binaries embedded
> within QGIS (I believe this includes bin/psql.exe on Windows installs,
> there may be other files).
Its worth understanding the nature of vulnerabilities. In this case, the project page (which you linked to) describes it:
Improper neutralization of quoting syntax in PostgreSQL libpq functions PQescapeLiteral(), PQescapeIdentifier(), PQescapeString(), and PQescapeStringConn() allows a database input provider to achieve SQL injection in certain usage patterns. Specifically, SQL injection requires the application to use the function result to construct input to psql, the PostgreSQL interactive terminal. Similarly, improper neutralization of quoting syntax in PostgreSQL command line utility programs allows a source of command line arguments to achieve SQL injection when client_encoding is BIG5 and server_encoding is one of EUC_TW or MULE_INTERNAL. Versions before PostgreSQL 17.3, 16.7, 15.11, 14.16, and 13.19 are affected.
The way I read that, you'd need to be using those functions either directly or indirectly via psql.
I just checked the QGIS source code - there is nothing that matches PQescape. In addition, your client_encoding is probably not BIG5. Nor are your system admins likely using server_encoding of EUC_TW or MULE_INTERNAL. So I'd say that the chances of this specific vulnerability affecting QGIS directly are pretty low.
> Postgres has a known fix detailed in the link above, but I'm wondering if
> anyone here knows if the Postgres binaries in the coming release will have
> been updated to incorporate that fix? Apologies if my terminology is
> wrong, it's not really my area.
There are two different parts to this - is the part of QGIS that interfaces with Postgres vulnerable, and is other stuff that comes along vulnerable.
The answer to the first part is "its highly unlikely that QGIS is directly vulnerable" - see above.
If your installer is OSGeo4W, then the answers are "maybe the old libpq is a problem depending on what else you installed", and "yes, it'll get updated". See
https://github.com/jef-n/OSGeo4W/commit/d3dbd84660b652cf0a059b640b0161f63208fe16
HTH