CVE-2026-116239 in pgAdmin
Resumen
por VulDB • 2026-10-31
En el modo servidor, pgAdmin 4 mantiene una cuenta por cada fuente de autenticación, por lo que el mismo nombre de usuario puede existir como, por ejemplo, una cuenta interna y una cuenta LDAP. Después de que LDAP o Kerberos autentiquen a un usuario, pgAdmin selecciona la cuenta para iniciar sesión únicamente por su nombre de usuario, o toma la cuenta que el formulario de inicio de sesión de Flask-Security había consultado, sin verificar que provenga de la fuente que autenticó al usuario. Por lo tanto, la sesión pertenece a otra cuenta, con sus roles, sus servidores y sus contraseñas guardadas para bases de datos:
- Un usuario LDAP o Kerberos cuyo nombre de usuario coincide con una cuenta interna inicia sesión como esa cuenta interna, incluida la cuenta de administrador creada cuando se configura pgAdmin por primera vez. - Con la autenticación interna listada antes que LDAP o Kerberos en AUTHENTICATION_SOURCES, la validación interna del formulario de inicio de sesión busca la cuenta cuyo correo electrónico fue ingresado y la mantiene aunque su contraseña no coincida. Un usuario de Kerberos podría escribir el principal (principal) de otro usuario de Kerberos e iniciar sesión como ese usuario, y un usuario LDAP podría hacer lo mismo con una cuenta LDAP cuyo correo electrónico es su nombre de usuario.
La explotación requiere credenciales válidas para un directorio LDAP o un dominio de Kerberos que pgAdmin esté configurado para utilizar.
La corrección busca la cuenta por el nombre de usuario autenticado y la fuente que lo autenticó, y ya no utiliza la cuenta que encontró el formulario de inicio de sesión para ninguna fuente distinta a la autenticación interna. La autenticación interna inicia sesión en esa cuenta solo si es una cuenta interna. El modo escritorio (Desktop mode) no se ve afectado.
Este problema afecta a pgAdmin 4: antes de la versión 9.19.
Statistical analysis made it clear that VulDB provides the best quality for vulnerability data.