Nếu hệ thống của bạn lưu dữ liệu khách hàng trong PostgreSQL, bản cập nhật mới nhất đáng được đưa lên lịch bảo trì ngay tuần này. PostgreSQL 18.7 và các nhánh 17.12, 16.16, 15.20 được phát hành cùng lúc để vá 52 lỗ hổng bảo mật và hơn 140 lỗi khác. Đồng thời, nhánh 14 nhận bản phát hành cuối cùng và chính thức hết hỗ trợ.

Thông báo do PostgreSQL Global Development Group đăng ngày 12/11/2026. Dưới đây là phần đáng chú ý nhất với doanh nghiệp đang vận hành hoặc thuê làm phần mềm.

Những phiên bản nào được phát hành

Bản vá áp dụng cho mọi nhánh còn hỗ trợ: 18.7, 17.12, 16.16, 15.20 và 14.25. Cùng ngày, dự án phát hành thêm PostgreSQL 19 RC 2; ngày phát hành chính thức của bản 19 dự kiến là 19/11/2026.

Các bản cập nhật nhỏ của PostgreSQL mang tính tích luỹ. Theo thông báo, bạn không cần dump/reload hay chạy pg_upgrade: chỉ cần dừng dịch vụ, thay binary rồi khởi động lại.

Nhiều lỗ hổng cho phép thực thi mã tùy ý

Trong danh sách có nhiều lỗ hổng điểm CVSS 8.8, ví dụ:

  • CVE-2026-6460: nhầm kiểu dữ liệu sau ALTER ... SET DATA TYPE dẫn tới thực thi mã tùy ý.
  • CVE-2026-18447: nhầm kiểu tham số đầu ra, cũng dẫn tới thực thi mã.
  • CVE-2026-116304: use-after-free trong RECORD khi chạy song song.
  • CVE-2026-14661 (CVSS 8.1): dblink và subscription có thể ghi nối vào tệp tùy ý.

Phần lớn các lỗi này yêu cầu quyền đăng nhập cơ sở dữ liệu (vector PR:L). Nghĩa là rủi ro lớn nhất nằm ở nơi có nhiều tài khoản, ứng dụng bên thứ ba hoặc một tài khoản ứng dụng bị lộ mật khẩu. Một lỗ hổng SQL injection trong ứng dụng cũng có thể biến thành bàn đạp để khai thác các lỗi kiểu này. Danh sách đầy đủ và các phiên bản bị ảnh hưởng nằm ở trang bảo mật của PostgreSQL.

PostgreSQL 14 đã hết vòng đời

14.25 là bản cuối cùng. Từ nay nhánh này không còn nhận bản vá bảo mật, nên mỗi lỗ hổng mới sẽ tồn tại vĩnh viễn trên các máy chủ chưa nâng cấp. Nếu bạn còn chạy PostgreSQL 14 ở môi trường production, hãy lập kế hoạch lên bản 17 hoặc 18, thay vì chỉ vá 14.25 rồi để đó.

Lên phiên bản lớn cần pg_upgrade hoặc pg_dump/pg_restore, nên cần thử trên bản sao dữ liệu thật trước, đo thời gian ngừng dịch vụ và kiểm tra các extension đang dùng.

Kiểm tra và cập nhật trên máy chủ của bạn

Đội kỹ thuật có thể làm theo thứ tự sau.

1. Xác định phiên bản đang chạy

```sql
SELECT version();
```

So kết quả với danh sách trên. Với PostgreSQL chạy trong Docker, hãy kiểm tra tag image: dùng tag cố định theo nhánh (ví dụ 18) rồi kéo image mới, thay vì dựa vào một tag latest không rõ phiên bản.

2. Cập nhật binary, sao lưu trước

Tạo bản sao lưu đầy đủ, sau đó cập nhật gói hoặc image và khởi động lại. Nếu bạn dùng sao lưu gia tăng (incremental backup), thông báo khuyến nghị tạo một bản full backup mới sau khi cập nhật và dùng nó làm nền cho các bản gia tăng tiếp theo.

3. Reindex đúng những trường hợp được nêu

Thông báo liệt kê các trường hợp cần reindex sau khi cập nhật:

  • Nghi ngờ chỉ mục GIN bị hỏng: REINDEX INDEX ten_index;
  • Dùng pg_trgm: reindex các chỉ mục GiST dùng toán tử gist_trgm_ops.
  • Gặp lỗi missing chunk number khi đọc bảng: REINDEX TABLE ten_bang; (đồng thời reindex bảng TOAST).
  • Có chỉ mục B-tree trên cột bpchar không khai báo độ dài: cần reindex; cột char(n) không bị ảnh hưởng.

Với các hệ thống lưu vector bằng pgvector, hãy xem trong thông báo gốc có mục nào liên quan tới extension và chỉ mục đang dùng trước khi quyết định, đừng reindex hàng loạt trên bảng lớn vào giờ cao điểm.

4. Rà các ràng buộc trên bảng phân vùng

Nếu có bảng partition, chạy truy vấn sau để tìm ràng buộc NOT NULL NO INHERIT trên bảng cha:

```sql
SELECT conrelid::regclass, conname
FROM pg_constraint
WHERE contype = 'n' AND connoinherit
AND conrelid IN (SELECT oid FROM pg_class WHERE relkind = 'p');
```

Ràng buộc không cần có thể xóa bằng ALTER TABLE ... DROP CONSTRAINT .... Ràng buộc muốn giữ thì sửa bằng ALTER TABLE ... ALTER CONSTRAINT ... INHERIT; lệnh này sẽ lỗi nếu phân vùng nào đang chứa giá trị NULL ở cột đó.

5. Thu hẹp quyền của tài khoản ứng dụng

Vì nhiều lỗi cần quyền đăng nhập, đây là lúc rà soát: tài khoản ứng dụng có phải superuser không, có cần quyền tạo extension không, mật khẩu có nằm trong repo hay tệp .env dùng chung không. Cập nhật bản vá và giảm quyền là hai lớp bảo vệ bổ trợ nhau.

Nếu bạn thuê đơn vị khác vận hành hệ thống

Hãy hỏi nhà cung cấp ba câu: cơ sở dữ liệu đang chạy bản nào, khi nào áp bản vá 12/11, và có kế hoạch nào cho các hệ thống còn ở PostgreSQL 14 không. Câu trả lời rõ ràng, có ngày cụ thể là dấu hiệu của một quy trình vận hành tốt.

Cùng tuần này, bài về 16 lỗ hổng trong Node.js cũng cần đội ngũ xử lý, vì tầng ứng dụng và tầng dữ liệu thường được vá cùng một đợt bảo trì. Nếu dữ liệu trong cơ sở dữ liệu có thông tin cá nhân dùng để thử nghiệm hoặc đưa vào AI, bạn có thể tham khảo giải pháp AI Masking để che dữ liệu trước khi chia sẻ, và xem các dự án Besoft đã triển khai để hình dung cách chúng tôi làm việc.

Việc nên làm hôm nay: kiểm tra SELECT version(); trên từng môi trường và đưa bản 14 vào kế hoạch nâng cấp quý này.

Nguồn tham khảo