Dos nuevas vulnerabilidades críticas en PHP ponen en jaque a servicios con PostgreSQL y SOAP

Los fallos CVE-2025-1735 y CVE-2025-6491 afectan a versiones anteriores de PHP 8.4.10 y podrían permitir inyecciones SQL y caídas del proceso

PHP vuelve a estar en el punto de mira. Esta vez por dos vulnerabilidades de alto impacto que afectan directamente a extensiones muy comunes entre desarrolladores y administradores de sistemas: PostgreSQL (pgsql) y SOAP. Identificadas como CVE-2025-1735 y CVE-2025-6491, estas fallas fueron corregidas en la última tanda de actualizaciones del intérprete, y suponen un riesgo real para entornos que aún no se han actualizado a PHP 8.1.33, 8.2.29, 8.3.23 o 8.4.10.

Aunque su ejecución requiere ciertos contextos específicos, ambas vulnerabilidades pueden ser explotadas en entornos productivos mal configurados o que acepten entrada de datos sin validación estricta.

CVE-2025-1735: cuando la extensión pgsql ignora los errores

Este fallo afecta a cómo PHP gestiona internamente el escape de cadenas e identificadores con PostgreSQL. El problema se origina cuando funciones como PQescapeStringConn() no reciben el parámetro de error adecuado, lo que impide detectar entradas malformadas o codificaciones inválidas.

“Al no pasar correctamente el parámetro de error, PHP no puede reaccionar si PostgreSQL rechaza una cadena mal codificada. En consecuencia, es posible que se produzca una inyección SQL o un segfault si se devuelve un puntero NULL sin validación previa”, explica el aviso de seguridad.

Para quienes utilizan PQescapeIdentifier() sin comprobar si el resultado es NULL, el riesgo es mayor: se puede provocar un crash por desreferencia de puntero, lo que impactaría en la estabilidad de aplicaciones críticas.

Este fallo demuestra lo importante que es no confiar ciegamente en funciones de escape y validar siempre los retornos, especialmente cuando se trata de extensiones de bajo nivel.

CVE-2025-6491: SOAP y la trampa del nombre XML de 2 GB

La segunda vulnerabilidad, descubierta por Ahmed Lekssays (Qatar Computing Research Institute), afecta a la extensión SOAP de PHP. En este caso, el problema aparece al pasar un nombre XML con un prefijo superior a 2 GB, lo que provoca una desreferencia de puntero nulo durante la serialización.

Un ejemplo práctico que puede inducir la falla:

$hugePrefix = str_repeat("A", 0x7fffffff);
$localName = "Element";
$soapVar = new SoapVar("value", XSD_STRING, null, null, "{$hugePrefix}:{$localName}");
$client = new SoapClient(null, ['location'=>'http://127.0.0.1/', 'uri'=>'urn:dummy']);
$client->__soapCall("DummyFunction", [$soapVar]);
Lenguaje del código: PHP (php)

“Basta un prefijo de más de 2 GB para que xmlBuildQName() falle silenciosamente y genere un segfault en la siguiente operación”, indican desde el equipo de PHP.

Esto convierte a la vulnerabilidad en un vector efectivo de denegación de servicio (DoS) si la API SOAP acepta contenido XML externo sin restricciones.

¿Qué deberían hacer los administradores y desarrolladores?

1. Actualizar PHP a la última versión estable según la rama usada:
   • 8.1.33
   • 8.2.29
   • 8.3.23
   • 8.4.10
2. Auditar extensiones activas, especialmente pgsql y soap, y revisar el código que haga uso de escape manual o SoapVar.
3. Monitorizar logs de errores del servidor web o del sistema para detectar comportamientos anómalos, especialmente segfaults relacionados con llamadas SOAP o consultas PostgreSQL.
4. Implementar validaciones defensivas para todas las entradas de usuario antes de llegar a estas extensiones.
5. Limitar el uso de SoapClient en contextos donde se reciban peticiones externas sin autenticación.

Un recordatorio para la comunidad técnica

Estas vulnerabilidades nos recuerdan una vez más que PHP, por muy estable que parezca, sigue dependiendo en gran medida de extensiones escritas en C que pueden introducir errores de bajo nivel con consecuencias graves.

Según el último informe KPMG Tendencias 2025, uno de los grandes retos actuales para las empresas es mantener al día sus stacks tecnológicos frente al avance de nuevas amenazas y a la velocidad del desarrollo. Este caso lo ilustra a la perfección: una omisión menor en la gestión de errores puede abrir la puerta a ataques con impacto en disponibilidad o integridad de datos.

Conclusión:
El equipo de PHP ya ha hecho su parte. Ahora, la responsabilidad está en los equipos técnicos de desarrollo y sistemas para aplicar los parches, revisar los entornos y evitar que estas vulnerabilidades pasen de ser un aviso a convertirse en un incidente real.

Porque cuando hablamos de seguridad en producción, el tiempo juega siempre en contra.

Fuente: opensecurity