Lo habitual cuando hablamos de denegación de servicio es pensar en el servidor cayendo bajo una avalancha de peticiones. Aquí pasa lo contrario: es el cliente el que se queda colgado, y quien le hace daño es el propio servidor PostgreSQL al que intenta conectarse. Red Hat lo ha corregido en RHEL 10 con la actualización RHSA-2026:24348, clasificada como Important.
Qué falla exactamente
El problema está en pgjdbc, el driver JDBC oficial de PostgreSQL, y tiene asignado CVE-2026-42198. El fallo aparece durante la autenticación SCRAM-SHA-256, el método por defecto en las versiones modernas de PostgreSQL.
SCRAM usa PBKDF2 para derivar la contraseña, y el número de iteraciones de esa función lo dicta el servidor dentro del intercambio de autenticación. El driver lo aceptaba sin ningún límite superior. Un servidor controlado por un atacante puede anunciar un número de iteraciones gigantesco, y el cliente se pone a calcular PBKDF2 hasta que ese número se agota, antes incluso de poder rechazar la conexión.
Una sola conexión así monopoliza un núcleo de CPU al 100 %. Si lanzas varias en paralelo, agotas los núcleos disponibles y dejas el pool de conexiones inutilizable. El parámetro loginTimeout no salva la situación: el hilo de trabajo sigue ejecutando el cálculo de PBKDF2 aunque el timeout haya vencido, así que la CPU sigue ocupada.
El identificador de debilidad es CWE-770 (asignación de recursos sin límite ni control). La puntuación es CVSS 7.5 (vector AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H): el impacto es solo de disponibilidad, sin compromiso de confidencialidad ni integridad.
A quién afecta
A cualquier aplicación Java que se conecte a PostgreSQL con pgjdbc y use SCRAM-SHA-256. Las versiones vulnerables van de la 42.2.0 a la 42.7.10, corregidas en la 42.7.11 upstream.
El matiz importante es el modelo de amenaza. Para que esto te afecte, el cliente tiene que conectarse a un servidor que un atacante controle o haya comprometido, o estar expuesto a un servidor suplantado por un intermediario. No es un fallo que cualquiera explote contra ti desde fuera sin más; requiere que dirijas tu driver hacia un endpoint hostil. Aun así, en entornos donde las cadenas de conexión llegan desde configuración externa, multitenencia o servicios de terceros, el riesgo es real.
Cómo protegerte
En RHEL 10 basta con aplicar la actualización: Red Hat empaqueta la corrección en postgresql-jdbc 42.7.2-1.el10_2.2.
sudo dnf update postgresql-jdbcSi gestionas la dependencia directamente en tu proyecto Java (Maven, Gradle), sube el driver a 42.7.11 o posterior. Reinicia las aplicaciones para que el cambio surta efecto, ya que el driver se carga en el arranque de la JVM.
Como medida de fondo, revisa hacia dónde apuntan tus cadenas de conexión y desconfía de servidores PostgreSQL que no controles. Mientras no puedas parchear, limitar la conectividad de salida a hosts de base de datos conocidos reduce la exposición.
Si administras RHEL, este aviso encaja con el resto del lote de seguridad de Red Hat de principios de junio; tienes el contexto de la versión en nuestra ficha de Red Hat Enterprise Linux 10.2.
Fuente
- Red Hat – RHSA-2026:24348
- NVD – CVE-2026-42198