Bug 2378689 (CVE-2025-1735)

Summary: CVE-2025-1735 php: pgsql extension does not check for errors during escaping
Product: [Other] Security Response Reporter: OSIDB Bzimport <bzimport>
Component: vulnerabilityAssignee: Product Security DevOps Team <prodsec-dev>
Status: NEW --- QA Contact:
Severity: medium Docs Contact:
Priority: medium    
Version: unspecifiedCC: ronald.l.gould
Target Milestone: ---Keywords: Security
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: ---
Doc Text:
A flaw was found in PHP. Missing error checking could result in SQL injection, and missing error handling could lead to crashes due to null pointer dereferences.
 Story Points: ---
Clone Of: Environment:
Last Closed: Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:

Description OSIDB Bzimport 2025-07-08 17:34:36 UTC 
Missing error checking could result in SQL injection and missing error handling could lead to crashes due to null pointer dereferences.

This is related to https://www.postgresql.org/support/security/CVE-2025-1094/ that was reported to postgres. The reporter used php to showcase the problem.

While working on addressing the report, it was realised that PHP uses the escape functions in a way that does not allow for errors to be reported. Specifically the error parameters is not passed to PQescapeStringConn(), which therefore cannot report an error.

While postgres now tries to make sure that the escaped string will trigger errors on the server-side if the string is invalidly encoded, that still can be insufficient, depending on how the escaped values are used.

It was also noted that several calls to PQescapeIdentifier() do not check for the returned value being NULL, despite that being the documented way that PQescapeIdentifier() (and PQescapeLiteral()) to report errors. Seems like that could cause crashes or at least UB in some of the callsites.
Comment 2 Ron Gould 2025-09-12 18:57:32 UTC 
CVE state is currently "Fix Deferred". Is there a plan to fix this for Red Hat 8.10 for DNF Module php:8.2?