Gotenberg là một API tự lưu trữ dùng để chuyển HTML và tệp văn phòng sang PDF, thường được dùng để tạo hóa đơn hoặc báo cáo. Một website WordPress hay PHP thông thường không có sẵn thành phần này, vì vậy bước đầu tiên là hỏi đơn vị phát triển hoặc nhà cung cấp hosting xem hệ thống của bạn có dùng Gotenberg hay không. Nếu không, cảnh báo này không áp dụng cho bạn. Toàn bộ thông tin dưới đây được kiểm tra tính đến ngày 30 tháng 10 năm 2026.

Lỗ hổng được công bố như thế nào

Ngày 30 tháng 4 năm 2026, người bảo trì Gotenberg công bố khuyến cáo GHSA-rqgh-gxv4-6657, mã CVE-2026-42589. Lỗi nằm ở đường dẫn API ghi metadata PDF: ai tiếp cận được đường dẫn này có thể thực thi lệnh mà không cần đăng nhập, trong phạm vi quyền của dịch vụ Gotenberg, chứ không mặc nhiên là quyền root trên máy chủ hay thoát khỏi container. Khuyến cáo xác nhận 8.29.1 bị ảnh hưởng và 8.31.0 đã vá, không phải danh sách đầy đủ các phiên bản bị ảnh hưởng.

Nên chạy phiên bản nào ngay bây giờ

Bản phát hành v8.31.0, công bố ngày 17 tháng 4 năm 2026, mô tả việc loại bỏ ký tự điều khiển và ký tự xuống dòng khỏi metadata PDF cùng một số gia cố khác. Ghi chú phát hành không nêu tên CVE, nhưng nội dung khớp với khuyến cáo, và việc bản sửa ra trước ngày công bố công khai là điều bình thường. Có một điểm lệch: bản ghi riêng trong cơ sở dữ liệu khuyến cáo của GitHub, cập nhật lần cuối ngày 14 tháng 5 năm 2026, vẫn chưa liệt kê phiên bản đã vá. Chúng tôi không biết vì sao hai bản ghi khác nhau, nên chúng tôi theo khuyến cáo của người bảo trì, vốn được ghi chú phát hành củng cố.

Bản đó là bản sửa được ghi nhận cho đúng CVE này, nhưng không phải phiên bản nên cài hôm nay. Bản v8.39.0, công bố ngày 27 tháng 10 năm 2026 và là bản ổn định mới nhất, mang theo các bản sửa bảo mật sau đó cho phần xử lý metadata và chính sách mạng, nối tiếp những bản như v8.37.0. Hãy yêu cầu nâng lên 8.39.0, hoặc bản mới hơn được người bảo trì hỗ trợ tại thời điểm bạn đọc bài này, và đề nghị nhà cung cấp rà soát các thay đổi phá vỡ tương thích (breaking changes) giữa phiên bản hiện tại và phiên bản đích.

Đã có khai thác thực tế được ghi nhận

Công ty bảo mật VulnCheck cho biết ngày 26 tháng 10 năm 2026 rằng mạng cảm biến mồi (canary) của họ đã ghi nhận hành vi khai thác CVE-2026-42589, bao gồm các nỗ lực cài reverse shell, và họ cũng chỉ ra 8.31.0 là bản sửa lỗi. Đó là dữ liệu từ cảm biến của chính VulnCheck. Nó không cho biết website của bạn có bị động đến hay không, cũng không có nghĩa mọi hệ thống Gotenberg đều đã bị xâm nhập. Nếu nhà cung cấp xác nhận bạn đang chạy một phiên bản bị ảnh hưởng và đã lỗi thời, hãy ưu tiên nâng cấp và kiểm chứng theo các bước dưới đây.

Những gì cần hỏi nhà cung cấp

  • Phiên bản Gotenberg và image digest (mã định danh của đúng image đang triển khai) nào đang thực sự chạy lúc này, trên từng bản sao (replica), và ai chịu trách nhiệm cập nhật bản vá. Một tag thay đổi được như “8” không chứng minh container cũ đã được tạo lại, và tải image mới về không đồng nghĩa với việc đang chạy bản đã vá.
  • Dịch vụ chỉ tiếp cận được từ ứng dụng của bạn, hay từ mạng rộng hơn. Cấu hình mặc định lắng nghe trên mọi giao diện mạng ở cổng 3000 và tắt xác thực, nhưng mức phơi lộ thực tế phụ thuộc vào tường lửa, reverse proxy và kiến trúc mạng, không chỉ riêng cổng.
  • Xác thực có thực sự được bắt buộc hay chỉ là tùy chọn có sẵn. Basic auth hoặc OIDC tích hợp sẵn của Gotenberg, một reverse proxy có xác thực đặt phía trước dịch vụ, hoặc một cơ chế kiểm soát tương đương của nền tảng đều có thể đảm nhận việc này nếu được cấu hình đúng. Đây là các lớp bổ sung, không thay thế được phần mềm đã sửa lỗi.
  • Nếu Gotenberg của bạn là gói tùy biến hoặc tự dựng, bản sửa nào đã được áp dụng và tương ứng với upstream ra sao. Hãy yêu cầu bằng chứng gắn với bản dựng hoặc image đang chạy, chứ không chỉ dựa vào nhãn phiên bản.

Thử nghiệm nâng cấp mà không ảnh hưởng hóa đơn thật

Hãy yêu cầu nâng cấp có tài liệu trên môi trường staging trước, dùng hóa đơn và báo cáo giả lập không chứa dữ liệu khách hàng. Kiểm tra các luồng mà hệ thống của bạn thực sự dùng: ghi metadata, chuyển URL sang PDF và các lời gọi có xác thực từ ứng dụng tới dịch vụ. Xác nhận các bước sao lưu, hoàn tác và khôi phục trước khi đưa lên production, theo hướng dẫn của chúng tôi về chiến lược backup, RPO, RTO và kiểm thử khôi phục. Nếu có gì hỏng, hãy sửa phần tích hợp thay vì tắt xác thực hay mở rộng quyền truy cập mạng. Sau đó, xác nhận bản dựng đã sửa đúng là bản mà production đang chạy.

Nếu có dấu hiệu bất thường

Lỗi tạo PDF không rõ nguyên nhân, tiến trình lạ hoặc các dấu hiệu xâm nhập khác đòi hỏi bạn giữ lại nhật ký và hồ sơ triển khai, đồng thời yêu cầu đánh giá chuyên môn về khoanh vùng và khôi phục. Một tệp PDF tạo thành công hay mã HTTP 200 chỉ cho thấy dịch vụ đang hoạt động hôm nay, không chứng minh trước đó không có chuyện gì xảy ra. Trạng thái bản vá, kiểm soát khả năng tiếp cận, kiểm chứng việc chuyển đổi và đánh giá sự cố là các điểm cần xác minh riêng, như bài viết của chúng tôi về giám sát không chỉ dừng ở uptime đã phân tích.

Nguồn tham khảo

Bài viết tóm lược khuyến cáo của người bảo trì, ghi chú phát hành chính thức và nghiên cứu của VulnCheck tính đến ngày 30 tháng 10 năm 2026.