PostgreSQL vá 52 lỗ hổng bảo mật cùng lúc, nhiều lỗi cho tài khoản thường chạy mã trên máy chủ; PostgreSQL 14 hết hỗ trợ

Ngày 12/11/2026, nhóm phát triển PostgreSQL phát hành các bản 18.7, 17.12, 16.16, 15.20 và 14.25, vá 52 lỗ hổng bảo mật và hơn 140 lỗi khác. Đây là đợt vá bảo mật lớn bất thường của PostgreSQL, hệ quản trị cơ sở dữ liệu đứng sau rất nhiều ứng dụng web viết bằng Django, Rails, Laravel, Node.js và các nền tảng như Supabase, Neon.

Cùng đợt này, PostgreSQL 14 chính thức hết hỗ trợ: 14.25 là bản phát hành cuối cùng, sau đó sẽ không còn bản vá bảo mật nào nữa.

Mức độ nghiêm trọng

Tin tốt: chưa có báo cáo khai thác thực tế hay mã khai thác công khai, và gần như toàn bộ lỗi cần có tài khoản đăng nhập database mới khai thác được. Chỉ có một lỗi không cần đăng nhập (CVE-2026-116322, CVSS 5.3, chỉ ở bản 18), và lỗi này chỉ gây treo một phần máy chủ chứ không chạy được mã.

Tin xấu: khoảng 40 lỗi có điểm CVSS 8.8, cho phép một tài khoản database quyền thấp chạy mã tùy ý trên máy chủ với quyền của tiến trình PostgreSQL. Các lỗi tập trung ở:

• Lõi xử lý câu lệnh: nhầm lẫn kiểu dữ liệu (type confusion), dùng vùng nhớ đã giải phóng (use-after-free), tràn bộ đệm trong các hàm tìm kiếm toàn văn như ts_rank_cd() và tsvector_delete().
• Ngôn ngữ thủ tục: nhiều lỗi trong PL/Perl (plperl), cùng lỗi ở PL/Tcl và PL/pgSQL.
• Extension dblink: một lỗi cho phép ghi nối vào file tùy ý trên máy chủ (CVSS 8.1), một lỗi use-after-free (8.8).
• Phân quyền và bảo mật mức dòng (RLS): một số câu lệnh như INSERT ... ON CONFLICT, DROP OWNED, REASSIGN OWNED có thể đọc hoặc gỡ các chính sách RLS không thuộc quyền của người chạy.

Lỗi ở công cụ sao lưu và khôi phục

Một nhóm lỗi khác nằm ở công cụ dòng lệnh đi kèm PostgreSQL, bị khai thác khi bạn xử lý file sao lưu hoặc kết nối tới máy chủ do kẻ tấn công kiểm soát:

• pg_restore (CVE-2026-116314, 8.8) và file restore.sql trong bản dump định dạng tar (CVE-2026-116330, 8.8): khôi phục một file dump độc hại có thể chạy mã trên máy của người khôi phục.
• pg_dump (bản 18), reindexdb, vacuumdb (bản 18): lỗi chèn SQL hoặc cho phép chủ database chạy mã với quyền người chạy công cụ.
• Logical replication (CVE-2026-120145, 8.8): máy chủ nguồn độc hại có thể ghi vào bảng hệ thống của máy chủ đăng ký nhận dữ liệu.

Ai cần lo nhất?

Vì cần đăng nhập, rủi ro phụ thuộc vào việc ai có tài khoản database của bạn:

• Ứng dụng có lỗ hổng SQL injection: kẻ tấn công lợi dụng SQL injection để chạy câu lệnh với tài khoản của ứng dụng, rồi dùng các lỗi trên để từ đọc dữ liệu leo lên chạy mã trên máy chủ.
• Máy chủ dùng chung nhiều người, nhiều khách hàng trên cùng một cụm PostgreSQL: một khách hàng có thể chiếm cả máy chủ và đọc dữ liệu của người khác.
• Công cụ cho người dùng tự chạy SQL: trang quản trị, công cụ báo cáo, notebook phân tích dữ liệu, ứng dụng AI cho phép hỏi dữ liệu bằng câu lệnh SQL.
• Ai hay khôi phục file dump nhận từ bên ngoài (khách hàng, đối tác, tải từ Internet).
• Máy chủ có bật plperl, pltcl hoặc dblink. Nếu không dùng, nên gỡ các extension này.

Cần làm gì?

1. Cập nhật lên bản vá

Đây là bản cập nhật nhỏ (minor) trong cùng nhánh: chỉ cần dừng PostgreSQL, cài gói mới và khởi động lại. Không cần dump/restore hay pg_upgrade. Kiểm tra phiên bản đang chạy bằng câu lệnh SELECT version();.

Nhớ cập nhật cả máy có cài công cụ pg_dump/pg_restore (máy sao lưu, máy lập trình viên), không chỉ máy chủ database.

2. Dùng database được quản lý (managed)?

Nếu dùng Amazon RDS, Google Cloud SQL, Azure, Supabase, Neon, DigitalOcean..., nhà cung cấp sẽ tự triển khai bản vá. Hãy kiểm tra lịch bảo trì trong bảng điều khiển; một số dịch vụ cho phép bấm cập nhật sớm.

3. Còn dùng PostgreSQL 14 trở về trước?

Cài 14.25 ngay, rồi lên kế hoạch nâng cấp lên nhánh mới (17 hoặc 18) bằng pg_upgrade hoặc dump/restore. Từ nay mọi lỗ hổng mới trên PostgreSQL 14 sẽ không được vá. PostgreSQL 19 dự kiến ra bản chính thức ngày 19/11/2026.

4. Việc cần làm sau khi nâng cấp

Ngoài bản vá bảo mật, đợt này sửa một số lỗi có thể làm hỏng chỉ mục (index). Nhóm PostgreSQL khuyên:

• Index GIN (hay dùng cho cột jsonb, mảng, tìm kiếm toàn văn): nếu nghi ngờ truy vấn trả thiếu hoặc sai kết quả, chạy REINDEX INDEX ten_index;.
• Index GiST dùng gist_trgm_ops (extension pg_trgm, hay dùng cho tìm kiếm LIKE '%...%'): nên tạo lại.
• Index B-tree trên cột kiểu bpchar không khai báo độ dài: tạo lại (cột char(n) không bị ảnh hưởng).
• Gặp lỗi missing chunk number: chạy REINDEX TABLE ten_bang;.
• Dùng sao lưu tăng dần (incremental backup) của PostgreSQL 17/18: tạo một bản sao lưu đầy đủ mới trước khi tiếp tục sao lưu tăng dần.
• Nếu bỏ qua nhiều đợt cập nhật trước, đọc thêm ghi chú phát hành của các bản đã bỏ qua.

5. Giảm rủi ro lâu dài

• Ứng dụng web không kết nối bằng tài khoản superuser, chỉ cấp quyền cần thiết trên các bảng cần dùng.
• Không mở cổng 5432 ra Internet; chỉ cho phép IP của máy chủ ứng dụng kết nối.
• Không khôi phục file dump không rõ nguồn gốc trên máy chủ thật; nếu cần, khôi phục thử trên máy riêng đã cập nhật.

Nguồn tham khảo: PostgreSQL - thông báo phát hành, PostgreSQL - bảng lỗ hổng bảo mật, The Hacker News.