PostgreSQL vá 52 lỗ hổng, gồm lỗi 22 năm tuổi cho phép RCE sau khi đăng nhập

PostgreSQL vừa phát hành bản cập nhật vá 52 lỗ hổng bảo mật, nổi bật là lỗi type confusion có mã CVE-2026-6460 với điểm CVSS 8.8. Lỗi này cho phép một người dùng cơ sở dữ liệu có quyền tạo đối tượng chạy mã trên máy chủ, với quyền của tài khoản hệ điều hành đang chạy PostgreSQL.

Phạm vi ảnh hưởng và mức độ nguy hiểm

Mọi phiên bản trước 18.7, 17.12, 16.16, 15.20 và 14.25 đều bị ảnh hưởng. Nhóm Phát triển Toàn cầu PostgreSQL chưa ghi nhận cuộc tấn công nào khai thác lỗi này, và đánh giá của CISA trong bản ghi CVE cũng xếp mức khai thác là không có.

Lỗi liên quan đến composite type — kiểu dữ liệu ghép từ các trường có tên, mỗi trường có kiểu riêng. Kiểu của một trường có thể bị thay đổi trong khi các giá trị cũ của kiểu đó vẫn còn ở nơi khác trên máy chủ. Khi đó máy chủ có thể đọc giá trị cũ như thể nó mang kiểu mới. Bản vá bổ sung kiểm tra phiên bản để phát hiện giá trị không còn khớp với kiểu của nó.

Chi tiết khai thác

Nhà nghiên cứu bảo mật Mehmet Ince đã mô tả cách khai thác hoạt động trên PostgreSQL 18.6 trong một bài viết kỹ thuật công bố tuần này. Ông chuẩn bị một truy vấn giữ một giá trị, đổi kiểu của một trường trong giá trị đó rồi chạy truy vấn. Bài viết có kèm câu lệnh SQL làm sập máy chủ chưa vá và bước thứ hai rò rỉ địa chỉ bộ nhớ, nhưng không đưa câu lệnh SQL cho bước cuối khiến máy chủ chạy lệnh.

Theo Ince, ông có thể kích hoạt sự cố này với vai trò đăng nhập có đặc quyền thấp nhất. Tuy nhiên, khuyến cáo bảo mật của dự án chỉ mô tả kẻ tấn công là người có thể tạo đối tượng, không nêu rõ cần những đặc quyền nào. Red Hat cho biết kẻ tấn công cần đăng nhập cơ sở dữ liệu với quyền tạo hoặc sửa đối tượng. Không nguồn nào xác nhận liệu tài khoản chỉ có đặc quyền mặc định có thể vượt qua bước làm sập để chạy mã hay không.

Ince truy nguồn gốc lỗi về ngày 5/5/2004, khi PostgreSQL có khả năng đổi kiểu của một cột; kỹ thuật chạy mã của ông dựa vào một thay đổi sau đó ngày 14/5/2015. Ông cũng điều chỉnh khai thác cho các dịch vụ PostgreSQL được quản lý và chia sẻ riêng bản chứng minh với đội bảo mật của họ vào tháng 8, gồm AWS (Aurora và RDS), Microsoft (Azure PostgreSQL), Google (AlloyDB), Supabase, Databricks và Ubicloud. Bài viết không nêu tình trạng vá hiện tại của từng dịch vụ.

Các lỗ hổng khác trong đợt vá

Dự án chấm 32 trong số 52 lỗ hổng ở mức 8.8, cao nhất trong đợt phát hành. Theo chỉ số lỗ hổng, chỉ một lỗi trên máy chủ không cần đăng nhập lẫn thao tác người dùng: CVE-2026-116322 cho phép client chưa xác thực kích hoạt khởi động lại máy chủ PostgreSQL 18.

Một số bản vá khác nằm ở công cụ client. Một tệp lưu trữ được tạo khéo có thể khiến pg_restore chạy mã với quyền người dùng đang chạy nó. Máy chủ nguồn bị xâm nhập có thể khiến psql chạy mã thông qua script khôi phục trong đầu ra tar của pg_dump.

Việc quản trị viên cần làm

• Cập nhật máy chủ lên 18.7, 17.12, 16.16, 15.20 hoặc 14.25 tương ứng với phiên bản chính đang dùng.
• Biên dịch lại hoặc cập nhật mọi extension viết bằng C cùng lúc với máy chủ. Extension biên dịch cho bản cũ vẫn tải được nhưng có thể không được bảo vệ trước các lỗ hổng đã vá; một số còn cần sửa mã nguồn. Ngược lại, extension biên dịch cho bản mới có thể không tải được trên máy chủ cũ.
• Nếu PostgreSQL chạy ngoài service unit của gói, ví dụ dưới Patroni, hãy khởi động lại ngay sau khi cập nhật.
• Cập nhật các công cụ client như pg_dump, pg_restore, reindexdb và vacuumdb trên mọi máy có chạy chúng.
• Không dùng thiết lập composite_type_mismatch mới để tắt các kiểm tra, vì dự án cảnh báo điều này mang rủi ro bảo mật.

Khuyến cáo và ghi chú phát hành không đưa ra cách xử lý tạm thời cho máy chủ chưa thể cập nhật. PostgreSQL 14 nay đã hết vòng đời và 14.25 là bản phát hành cuối; các phiên bản chính cũ hơn cũng bị ảnh hưởng nhưng không có bản vá. Sau khi cập nhật, cần làm theo các bước reindex trong thông báo phát hành; nếu dùng sao lưu tăng dần, hãy tạo bản sao lưu đầy đủ mới và dựa các bản tăng dần sau đó vào nó.

Nguồn: The Hacker News