https://db.gcve.eu Contains only the most 10 recent entries. http://www.rssboard.org/rss-specification python-feedgen en Sun, 01 Nov 2026 01:58:02 +0000 https://db.gcve.eu/vuln/fkie_cve-2026-116244 <p>When a pgAdmin 4 connection was not meant to use a Kerberos user&#39;s delegated credentials, pgAdmin removed KRB5CCNAME from its environment, so the Kerberos library fell back to the default credential cache, or a client keytab, of the operating-system account running pgAdmin. libpq then answered any server that asked for GSSAPI authentication with that account&#39;s ticket, whatever user name the pgAdmin user gave, so in server mode any user could connect as the service account&#39;s Kerberos principal; gssencmode=disable did not prevent it. On Windows, SSPI used the service account&#39;s logon in the same way. psql was also started with pgAdmin&#39;s environment, which could hold another user&#39;s credential cache while that user was connecting.</p> <p>The fix points KRB5CCNAME and KRB5_CLIENT_KTNAME at a file that cannot exist except while a Kerberos-authenticated user connects with Kerberos, and gives every other connection, psql and the utilities require_auth=!gss,!sspi and gssencmode=disable, checked on the final connection string. require_auth needs libpq 16 or later.</p> <p>This issue affects pgAdmin 4: before 9.19.</p> <p>When a pgAdmin 4 connection was not meant to use a Kerberos user&#39;s delegated credentials, pgAdmin removed KRB5CCNAME from its environment, so the Kerberos library fell back to the default credential cache, or a client keytab, of the operating-system account running pgAdmin. libpq then answered any server that asked for GSSAPI authentication with that account&#39;s ticket, whatever user name the pgAdmin user gave, so in server mode any user could connect as the service account&#39;s Kerberos principal; gssencmode=disable did not prevent it. On Windows, SSPI used the service account&#39;s logon in the same way. psql was also started with pgAdmin&#39;s environment, which could hold another user&#39;s credential cache while that user was connecting.</p> <p>The fix points KRB5CCNAME and KRB5_CLIENT_KTNAME at a file that cannot exist except while a Kerberos-authenticated user connects with Kerberos, and gives every other connection, psql and the utilities require_auth=!gss,!sspi and gssencmode=disable, checked on the final connection string. require_auth needs libpq 16 or later.</p> <p>This issue affects pgAdmin 4: before 9.19.</p> https://db.gcve.eu/vuln/fkie_cve-2026-116244 https://db.gcve.eu/vuln/ghsa-5539-rjhp-jvgv <p>When a pgAdmin 4 connection was not meant to use a Kerberos user&#39;s delegated credentials, pgAdmin removed KRB5CCNAME from its environment, so the Kerberos library fell back to the default credential cache, or a client keytab, of the operating-system account running pgAdmin. libpq then answered any server that asked for GSSAPI authentication with that account&#39;s ticket, whatever user name the pgAdmin user gave, so in server mode any user could connect as the service account&#39;s Kerberos principal; gssencmode=disable did not prevent it. On Windows, SSPI used the service account&#39;s logon in the same way. psql was also started with pgAdmin&#39;s environment, which could hold another user&#39;s credential cache while that user was connecting.</p> <p>The fix points KRB5CCNAME and KRB5_CLIENT_KTNAME at a file that cannot exist except while a Kerberos-authenticated user connects with Kerberos, and gives every other connection, psql and the utilities require_auth=!gss,!sspi and gssencmode=disable, checked on the final connection string. require_auth needs libpq 16 or later.</p> <p>This issue affects pgAdmin 4: before 9.19.</p> <p>When a pgAdmin 4 connection was not meant to use a Kerberos user&#39;s delegated credentials, pgAdmin removed KRB5CCNAME from its environment, so the Kerberos library fell back to the default credential cache, or a client keytab, of the operating-system account running pgAdmin. libpq then answered any server that asked for GSSAPI authentication with that account&#39;s ticket, whatever user name the pgAdmin user gave, so in server mode any user could connect as the service account&#39;s Kerberos principal; gssencmode=disable did not prevent it. On Windows, SSPI used the service account&#39;s logon in the same way. psql was also started with pgAdmin&#39;s environment, which could hold another user&#39;s credential cache while that user was connecting.</p> <p>The fix points KRB5CCNAME and KRB5_CLIENT_KTNAME at a file that cannot exist except while a Kerberos-authenticated user connects with Kerberos, and gives every other connection, psql and the utilities require_auth=!gss,!sspi and gssencmode=disable, checked on the final connection string. require_auth needs libpq 16 or later.</p> <p>This issue affects pgAdmin 4: before 9.19.</p> https://db.gcve.eu/vuln/ghsa-5539-rjhp-jvgv