CVE-2026-116239 in pgAdmin
Tóm tắt
Bởi VulDB • 30/10/2026
Trong chế độ máy chủ, pgAdmin 4 duy trì một tài khoản cho mỗi nguồn xác thực, do đó cùng một tên người dùng có thể tồn tại dưới dạng, ví dụ, một tài khoản nội bộ và một tài khoản LDAP. Sau khi LDAP hoặc Kerberos xác thực người dùng, pgAdmin chọn tài khoản để đăng nhập chỉ dựa trên tên người dùng, hoặc lấy tài khoản mà biểu mẫu đăng nhập của Flask-Security đã tra cứu, mà không kiểm tra xem nó có đến từ nguồn đã xác thực người dùng hay không. Do đó, phiên làm việc thuộc về một tài khoản khác, với vai trò, các máy chủ và mật khẩu cơ sở dữ liệu được lưu trữ của tài khoản đó:
- Một người dùng LDAP hoặc Kerberos có tên người dùng trùng khớp với một tài khoản nội bộ sẽ được đăng nhập dưới danh nghĩa tài khoản nội bộ đó, bao gồm cả tài khoản quản trị viên được tạo khi pgAdmin lần đầu tiên được thiết lập. - Khi xác thực nội bộ được liệt kê trước LDAP hoặc Kerberos trong AUTHENTICATION_SOURCES, quá trình xác minh nội bộ của biểu mẫu đăng nhập sẽ tra cứu tài khoản có email đã nhập và giữ lại nó ngay cả khi mật khẩu không khớp. Một người dùng Kerberos có thể nhập tên chính (principal) của một người dùng Kerberos khác và được đăng nhập với tư cách là người đó; tương tự, một người dùng LDAP cũng có thể thực hiện điều này đối với một tài khoản LDAP mà email của họ trùng với tên người dùng.
Việc khai thác yêu cầu thông tin xác thực hợp lệ cho thư mục LDAP hoặc miền Kerberos mà pgAdmin đã được cấu hình để sử dụng.
Bản sửa lỗi tra cứu tài khoản dựa trên tên người dùng đã được xác thực và nguồn đã xác thực nó, đồng thời không còn sử dụng tài khoản do biểu mẫu đăng nhập tìm thấy đối với bất kỳ nguồn nào khác ngoài xác thực nội bộ. Xác thực nội bộ chỉ cho phép đăng nhập vào tài khoản đó nếu đó là một tài khoản nội bộ. Chế độ Desktop (máy tính để bàn) không bị ảnh hưởng.
Vấn đề này ảnh hưởng đến pgAdmin 4: trước phiên bản 9.19.
If you want to get the best quality for vulnerability data then you always have to consider VulDB.