PHP parchea una inyección SQL en PostgreSQL: CVE-2026-17543 y las cuatro ramas actualizadas de golpe

Cuatro ramas parcheadas el mismo día: eso ya dice algo

El 30 de julio PHP publicó 8.5.9, 8.4.24, 8.3.33 y 8.2.33, las cuatro a la vez y las cuatro etiquetadas como security release. Cuando el equipo de PHP saca la misma tanda simultáneamente en todas las ramas soportadas no es por gusto: es que el fallo está en código compartido y llega hasta la versión más vieja que siguen manteniendo.

Hace tres semanas ya escribimos sobre 8.5.8 y 8.4.23, y aquello era una tanda tranquila. Esta tiene más chicha: hay un CVE de inyección SQL. Ahora bien, antes de que cunda el pánico, la respuesta honesta a "¿me toca?" depende mucho de qué base de datos uses.

En una frase

Se cierran cinco CVE: una inyección SQL en la extensión pgsql (CVE-2026-17543), una escritura fuera de límites en bccomp() de BCMath (CVE-2026-17544), la corrupción de memoria en openssl_encrypt que ya conocíamos y que por fin llega a la rama 8.5 (CVE-2026-14355), un crash de Phar con enlaces simbólicos recursivos (CVE-2026-7260) y una actualización de libgd (CVE-2026-9672). De propina, cuatro fallos de memoria en PDO_ODBC sin CVE asignado.

Si trabajas con PostgreSQL, deja de leer, actualiza y vuelve. Si vas con MySQL o MariaDB —la mayoría—, el titular no te afecta, pero probablemente sí BCMath.

Los fallos, ordenados por lo que deberías mirar primero

1. Inyección SQL en pgsql (CVE-2026-17543)

Es el titular de la tanda. El aviso de seguridad lo describe como una inyección SQL por fuga de la barra invertida en cadenas E'...'.

La traducción práctica: PostgreSQL tiene un tipo de literal de cadena especial, el que se escribe E'texto', en el que la barra invertida se interpreta como carácter de escape en lugar de tratarse como un carácter normal. El escapado de PHP no lo estaba teniendo en cuenta correctamente, de modo que una entrada preparada podía salirse de las comillas y colar SQL propio en la consulta.

Te toca si tu aplicación habla con PostgreSQL a través de la extensión pgsql y construye consultas escapando valores en lugar de usar consultas preparadas con parámetros. Si usas consultas preparadas de verdad —parámetros $1, $2, no concatenación disfrazada— el vector se te complica muchísimo, pero actualiza igual: no vale la pena auditar cada rincón del código para ahorrarte un apt install.

2. Escritura fuera de límites en bccomp() (CVE-2026-17544)

BCMath es la extensión de aritmética de precisión arbitraria, la que se usa para no perder céntimos con los decimales de coma flotante. Es decir: cualquier cosa que maneje dinero en serio tiene números pasando por ahí. bccomp() es la función que compara dos de esos números, y el parche cierra una escritura fuera de límites en ella.

Este es el que afecta a más gente de las tiendas y facturación que gestionamos, y es el motivo por el que esta tanda no es "opcional" aunque no toques PostgreSQL.

3. openssl_encrypt con AES-WRAP-PAD: el que arrastrábamos (CVE-2026-14355)

Este ya lo contamos el 6 de julio, cuando se corrigió en 8.4.23. Lo que no dijimos entonces —porque entonces no se sabía— es que la rama 8.5 se quedó fuera de aquel parche. Se corrige ahora, en 8.5.9, y ya con número de CVE asignado.

Merece la pena quedarse con la lección más que con el fallo: que una rama esté más actualizada no significa que tenga más parches. Si en julio te fuiste a 8.5.8 pensando que ibas por delante de quien estaba en 8.4.23, en este fallo concreto ibas por detrás. Sigue siendo un modo de cifrado poco habitual (envoltura de claves, no cifrado del día a día), así que la mayoría no lo dispara jamás.

4. Phar con enlaces simbólicos recursivos (CVE-2026-7260) y libgd (CVE-2026-9672)

Los dos de cierre. El de Phar provoca un crash mediante enlaces simbólicos recursivos: caída del proceso, no ejecución de código. Te importa si manipulas archivos .phar o cargas código empaquetado en ese formato. El de libgd llega por actualización de la librería que hay debajo de la extensión GD, la que usan medio internet y todos los CMS para redimensionar imágenes subidas por usuarios. Si tu web deja subir fotos, ese código lo estás ejecutando.

5. PDO_ODBC: cuatro fallos de memoria sin CVE

Sin número de CVE pero con mala pinta: lectura fuera del búfer cuando un valor de columna supera el tamaño que declara el driver, desbordamiento de heap cuando un parámetro de salida es más largo de lo declarado, escritura fuera de límites cuando el driver reporta un mensaje de diagnóstico más largo que el búfer de error, y un crash con el pooling de conexiones cuando el DSN no lleva credenciales.

En un servidor web típico esto no lo tocas ni de lejos. Si tienes PHP hablando por ODBC contra un SQL Server o un AS/400 heredado, tú sabrás que lo tienes, y estos cuatro son tuyos.

A quién afecta

• Prioridad alta: quien use PostgreSQL con la extensión pgsql (CVE-2026-17543) y quien mueva dinero por BCMath (CVE-2026-17544).
• Prioridad media: quien esté en la rama 8.5 y use openssl_encrypt para envolver claves —el parche que la 8.4 tuvo hace tres semanas y la 8.5 no—, y cualquier web que acepte subida de imágenes (libgd).
• Casos concretos: aplicaciones que manipulan Phar y las que conectan por ODBC.
• Todos los demás: no hay un exploit corriendo por internet apuntando a tu servidor esta semana, pero son cuatro ramas parcheadas el mismo día y la actualización es de diez minutos. No hay excusa razonable para dejarlo para septiembre.

Qué tienes que hacer hoy

1. Mira qué versión tienes

php -v

Los objetivos, según tu rama:

2. Comprueba si te toca lo gordo

# ¿Tengo la extensión de PostgreSQL cargada?
php -m | grep -i pgsql

# ¿Y BCMath?
php -m | grep -i bcmath

Si la primera devuelve algo, la inyección SQL es asunto tuyo y esto pasa a ser urgente.

3. Actualiza y recarga PHP-FPM (sin downtime)

# Debian / Ubuntu (repositorio de Ondřej Surý)
sudo apt update && sudo apt install --only-upgrade php8.5 php8.5-fpm
sudo systemctl reload php8.5-fpm

# RHEL / AlmaLinux / Rocky (repositorio Remi)
sudo dnf update php php-fpm
sudo systemctl reload php-fpm

El reload de PHP-FPM aplica el binario nuevo sin cortar las peticiones en curso. Ajusta el número de versión (php8.5, php8.4…) al que tengas instalado.

4. Confirma que quedó aplicado

php -v
php-fpm8.5 -v   # o php-fpm -v según tu distro

Como siempre con las distribuciones: a veces backportean el fix manteniendo un número de versión distinto. No te fíes solo del número, mira la fecha del paquete o el changelog de seguridad de tu distro. "Está actualizado" se comprueba, no se recuerda.

Lo que hacemos nosotros

Cuando sale una tanda así, lo primero no es actualizar a lo bruto: es cruzar el fallo con lo que hay montado. Sacamos qué servidores tienen pgsql cargada, cuáles exponen la aplicación de cara a internet y cuáles tienen facturación pasando por BCMath, y esos van primero, hoy. El resto entra en la ronda normal de actualizaciones de la semana.

Esa lista —qué extensión tiene cada servidor, qué versión corre, cuándo se parcheó por última vez— es la que convierte una tanda de cinco CVE en un trámite de diez minutos en lugar de una tarde de sustos. Tenerla al día vale más que correr detrás de cada punto de versión.

La rutina de siempre

• php -v para saber dónde estás.
• php -m para saber qué extensiones cargas de verdad.
• apt/dnf update de PHP y PHP-FPM.
• systemctl reload php*-fpm.
• php -v otra vez para confirmar.

Si tu PHP lleva meses sin ver un parche, o no tienes claro qué extensiones carga cada servidor que gestionas, es buen momento para revisarlo. Y si prefieres que lo llevemos nosotros, hablamos.

Referencias

• PHP.net — ChangeLog de la rama 8
• PHP.net — Descargas
• GHSA-7qpv-r5mr-78m4 — Inyección SQL en pgsql
• GHSA-x692-q9x7-8c3f — Escritura fuera de límites en bccomp()
• GHSA-vc5h-9ppw-p5f3 — Crash de Phar con enlaces simbólicos recursivos