CVE-2026-87796: Multi Uploader Gravity Forms có lỗi upload file nghiêm trọng

CVE-2026-87796 là lỗ hổng arbitrary file upload nghiêm trọng trong plugin WordPress Multi Uploader for Gravity Forms, slug gf-multi-uploader. Bản ghi CVE do Wordfence phát hành xác định các phiên bản ≤ 1.1.9 bị ảnh hưởng, không yêu cầu đăng nhập và chấm CVSS 9.8 Critical. Nguyên nhân được mô tả là kiểm tra loại file chưa đầy đủ trong quá trình xử lý chunked upload, liên quan tới hàm move_file.

Tại thời điểm bài viết được cập nhật, dữ liệu vulnerability hiện hành chưa chỉ ra một phiên bản đã vá cho CVE-2026-87796. Phiên bản 1.1.9 vẫn là phiên bản mới nhất xuất hiện trên trang plugin WordPress.org được lập chỉ mục, trong khi một nguồn theo dõi repository ghi nhận plugin đã bị đóng tạm thời từ ngày 11/09/2026 để chờ review.

Điểm cần phân biệt ngay từ đầu: CVE-2026-87796 không phải lỗ hổng của Gravity Forms core. Nó nằm trong add-on độc lập Multi Uploader for Gravity Forms. Vì vậy việc website đã cập nhật Gravity Forms chính không đồng nghĩa đã xử lý CVE này.

CVE-2026-87796 là gì?

Theo bản ghi CVE, Multi Uploader for Gravity Forms từ phiên bản đầu tiên tới 1.1.9 có thể cho phép attacker không cần xác thực upload file tùy ý lên máy chủ thông qua luồng xử lý chunked file upload.

Các thông tin chính:

Thuộc tính	Giá trị
CVE	CVE-2026-87796
Plugin	Multi Uploader for Gravity Forms
Plugin slug	`gf-multi-uploader`
Affected version	≤ 1.1.9
Authentication	Không yêu cầu
Weakness	CWE-434 – Unrestricted Upload of File with Dangerous Type
CVSS 3.1	9.8 Critical
Attack vector	Network
User interaction	Không yêu cầu
Hàm được nhắc trong advisory	`move_file`
Patch status tại 18/09/2026	Chưa thấy fixed version trong bản ghi CVE hiện hành

Vector CVSS được công bố là AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H, tức cuộc tấn công có thể bắt đầu qua network, độ phức tạp thấp, không yêu cầu privilege hoặc thao tác của người dùng.

Mức độ nghiêm trọng không chỉ đến từ việc attacker có thể đưa một file lên server. Rủi ro lớn hơn xuất hiện khi file do attacker kiểm soát được lưu vào vị trí mà web server hoặc PHP runtime có thể thực thi.

Vì sao arbitrary file upload có thể dẫn tới RCE?

Arbitrary file upload và RCE không phải cùng một khái niệm.

Arbitrary file upload chứng minh attacker có khả năng đưa nội dung ngoài ý muốn vào filesystem. Để chuyển thành remote code execution, thường cần thêm điều kiện: file phải nằm trong vị trí có thể truy cập và runtime phải cho phép xử lý file đó như code.

Một chuỗi rủi ro có thể được hình dung như sau:

public upload surface → file validation bị bypass → attacker-controlled file được ghi xuống disk → file nằm trong execution path → runtime xử lý file → code execution

Do đó, câu “website có CVE-2026-87796” chưa tự động chứng minh website đã có webshell hoặc đã bị RCE.

Ngược lại, việc server đang chặn PHP execution trong thư mục upload cũng không sửa root cause của plugin. Nó chỉ có thể làm giảm một số hậu quả sau khi file đã được ghi.

SecureWebOps đã phân tích riêng lớp ranh giới này trong bài File Upload Security: Extension, MIME và Magic Bytes chứng minh được gì?.

Lỗ hổng nằm ở chunked upload, không phải Gravity Forms core

Multi Uploader for Gravity Forms được thiết kế để mở rộng khả năng upload của Gravity Forms, trong đó có hỗ trợ upload file lớn theo từng chunk.

Bản ghi CVE mô tả vấn đề tại quá trình xử lý chunked upload: validation loại file không đủ chặt trước khi file được xử lý bởi move_file. Kết quả là một request không cần đăng nhập có thể dẫn tới arbitrary file upload trên phiên bản bị ảnh hưởng.

Điều này quan trọng khi điều tra vì investigator cần xác định đúng component.

Website có Gravity Forms nhưng không cài gf-multi-uploader không tự động thuộc affected scope của CVE-2026-87796.

Ngược lại, website cài add-on này vẫn phải kiểm tra version của chính gf-multi-uploader, không được suy ra trạng thái an toàn từ version của Gravity Forms core.

CVE-2026-87796 khác CVE-2026-19513 của Gravity Forms như thế nào?

Hai CVE cùng liên quan file upload nhưng là hai vulnerability riêng biệt.

CVE-2026-87796 ảnh hưởng add-on Multi Uploader for Gravity Forms ≤1.1.9 và được đánh giá CVSS 9.8. Advisory xác định vấn đề ở file-type validation trong chunked upload handling của add-on.

Trong khi đó, CVE-2026-19513 ảnh hưởng Gravity Forms core ≤3.0.2, liên quan tới cách xử lý state/chunk hash trong GFAsyncUpload::upload(). CVE này được đánh giá CVSS 8.1 và có các prerequisite kỹ thuật khác.

Vì vậy khi inventory WordPress, cần ghi riêng:

Gravity Forms core đang chạy version nào;
gf-multi-uploader có được cài hay không;
version thực tế của add-on;
add-on đang active hay chỉ còn code trên filesystem;
upload endpoint có còn public exposure hay không.

Không nên gom cả hai thành một nhãn chung như “Gravity Forms RCE”.

Phiên bản 1.1.9 có phải bản vá không?

Không nên coi 1.1.9 là bản vá cho CVE-2026-87796.

Bản ghi CVE hiện xác định 1.1.9 và thấp hơn đều bị ảnh hưởng.

Điểm dễ gây nhầm là changelog của 1.1.9 có đề cập việc harden frontend AJAX permission và sửa CVE-2026-5581, một vulnerability khác. WordPress.org cũng cho thấy những version trước từng sửa CVE-2025-14344 và CVE-2025-23921.

Do đó:

“Đã lên 1.1.9” không đồng nghĩa “đã vá CVE-2026-87796”.

Đây cũng là lý do quá trình remediation phải dựa vào affected/fixed range của đúng CVE, không chỉ dựa vào việc plugin đang ở “latest version”.

Nếu website đang dùng Multi Uploader for Gravity Forms thì cần làm gì?

Khi chưa có fixed version được xác nhận, ưu tiên đầu tiên là giảm exposure thay vì chờ một bản cập nhật chưa tồn tại.

1. Xác định website có thật sự chạy plugin hay không

Kiểm tra plugin slug:

gf-multi-uploader

Sau đó xác định:

version đang cài;
trạng thái active/inactive;
website nào đang sử dụng plugin;
form nào phụ thuộc vào chức năng upload này;
plugin có xuất hiện trên staging, production hoặc các site khác cùng server hay không.

Không chỉ kiểm tra tên hiển thị trong WordPress Admin. Inventory cần gắn với code và version thực tế trên production.

2. Nếu đang chạy ≤1.1.9, ưu tiên loại bỏ exposure

Khi chưa có bản vá được xác nhận, phương án an toàn nhất là deactivate hoặc remove component vulnerable nếu nghiệp vụ cho phép.

Nếu chức năng upload là bắt buộc cho hoạt động kinh doanh, cần đánh giá giải pháp thay thế hoặc một biện pháp containment có phạm vi rõ ràng. WAF có thể hỗ trợ giảm exposure trong một số trường hợp nhưng không sửa validation logic bên trong plugin.

Xem thêm: WAF đã chặn exploit WordPress rồi có cần update plugin không?.

3. Đừng xóa evidence trước khi kiểm tra compromise

Nếu website có dấu hiệu bất thường, không nên vội xóa mọi file khả nghi rồi mới điều tra.

Trước khi cleanup, nên bảo toàn tối thiểu:

access/error log liên quan exposure window;
timestamp của file mới hoặc file thay đổi;
plugin version;
file upload hoặc temporary artifact khả nghi;
thông tin ownership và permission;
snapshot phù hợp với quy trình incident hiện tại.

Nếu attacker đã khai thác vulnerability trước khi plugin bị tắt, việc deactivate chỉ đóng entry point. Nó không tự động xóa artifact đã được tạo trước đó.

Nên rà những vị trí nào sau khi phát hiện exposure?

Vì CVE liên quan file upload, quá trình incident validation nên ưu tiên các writable path và execution boundary thay vì chỉ chạy một malware scanner rồi kết luận sạch.

`wp-content/uploads/`

Tìm các file không phù hợp với loại nội dung bình thường của website, đặc biệt là file script hoặc file có extension/content không khớp.

Nhưng file PHP xuất hiện trong uploads chưa tự động chứng minh file đã được thực thi.

Cần kiểm tra tiếp web server routing, PHP handler và log. SecureWebOps có hướng dẫn riêng tại PHP độc hại trong wp-content/uploads trên aaPanel: điều tra execution path và root cause.

Temporary và cache directory

Chunked upload thường có trạng thái trung gian. Vì vậy investigator không nên chỉ nhìn Media Library cuối cùng mà bỏ qua các vùng writable hoặc temporary storage liên quan tới ứng dụng.

Mục tiêu không phải tìm một tên file cố định, mà là dựng được:

request → write event → file provenance → destination → execution behavior

`wp-content/mu-plugins/` và drop-in

Nếu attacker đã đạt code execution, phạm vi investigation phải mở rộng khỏi upload directory.

Các artifact persistence có thể xuất hiện ở những vị trí tự động được WordPress hoặc hosting stack nạp. Tuy nhiên việc thấy MU-plugin lạ không chứng minh CVE-2026-87796 là root cause.

Cần correlation timestamp, request log và provenance trước khi kết luận.

Chỉ tìm file PHP trong uploads có đủ không?

Không.

Một incident investigation tốt cần tách ba câu hỏi:

1. Vulnerability có tồn tại không?
Website có cài đúng plugin và nằm trong affected range không?

2. Vulnerability có thể bị khai thác trong cấu hình hiện tại không?
Public endpoint, file-write path và các control liên quan đang hoạt động như thế nào?

3. Có bằng chứng website thực sự đã bị compromise không?
Có log, file, process, account, scheduled task hoặc persistence nào khớp timeline không?

Một CVE Critical là lý do để hành động nhanh. Nó không phải bằng chứng tự động rằng website đã bị hack.

Ngược lại, không thấy malware trong một lần scan cũng không chứng minh website chưa từng bị khai thác.

Chặn PHP trong uploads có giải quyết CVE-2026-87796 không?

Không giải quyết root cause.

Chặn PHP execution trong một writable upload directory là một defense-in-depth control tốt vì nó tách khả năng “ghi được file” khỏi khả năng “chạy được code”.

Nhưng CVE-2026-87796 nằm ở application logic của plugin. Nếu plugin vẫn cho phép arbitrary file upload, vulnerability vẫn tồn tại dù một exploitation path cụ thể đã bị chặn.

Đây là sự khác biệt giữa:

mitigation — giảm khả năng hoặc hậu quả khai thác;

và

remediation — loại bỏ component hoặc đưa component ra khỏi vulnerable range bằng một bản vá đã được xác nhận.

Có cần rà webshell nếu chưa thấy website bị tấn công?

Nếu production từng chạy phiên bản affected trong khi endpoint có public exposure, nên thực hiện ít nhất một compromise assessment theo risk.

Mức độ sâu phụ thuộc vào exposure window, log retention và các tín hiệu hiện có.

Một số dấu hiệu đáng mở rộng investigation gồm:

file script mới xuất hiện trong writable path;
file có timestamp không khớp deploy;
request upload bất thường;
WordPress administrator lạ;
MU-plugin hoặc drop-in không rõ provenance;
cron/scheduled task mới;
file core/plugin/theme bị thay đổi ngoài quy trình update;
outbound activity bất thường quanh cùng thời điểm.

Nếu đã xuất hiện các dấu hiệu này, nên chuyển từ vulnerability remediation sang Incident Response, vì mục tiêu lúc đó không còn chỉ là tắt plugin mà là xác định entry point, phạm vi compromise, persistence và điều kiện phục hồi an toàn.

CVE-2026-87796 có đang bị khai thác ngoài thực tế không?

Tại snapshot nguồn được kiểm tra cho bài viết này ngày 18/09/2026, bản ghi đang sử dụng không cung cấp bằng chứng xác nhận CVE-2026-87796 đã được đưa vào CISA KEV hoặc đã có exploitation-in-the-wild được xác minh. Một số nguồn theo dõi cũng chưa ghi nhận public exploit tại thời điểm tương ứng.

Điều đó không đồng nghĩa vulnerability có rủi ro thấp.

CVSS 9.8 phản ánh đặc tính kỹ thuật của lỗ hổng: remote, không cần authentication, low complexity và impact tiềm năng cao. Trạng thái exploitation có thể thay đổi sau khi bài viết được xuất bản, vì vậy không nên dùng một snapshot “chưa thấy exploited” làm lý do trì hoãn remediation.

Checklist hành động cho quản trị viên

Nếu website đang sử dụng Multi Uploader for Gravity Forms:

Xác định chính xác plugin slug và version trên production.
Nếu đang chạy ≤1.1.9, coi website nằm trong affected range.
Khi chưa có fixed version được xác nhận, ưu tiên deactivate/remove component nếu nghiệp vụ cho phép.
Bảo toàn log và evidence nếu có dấu hiệu compromise.
Rà writable directory, temporary upload path và wp-content/uploads/.
Kiểm tra PHP execution boundary thay vì suy luận rằng file tồn tại đồng nghĩa file đã chạy.
Rà file integrity, privileged account, MU-plugin, drop-in và scheduled persistence nếu có tín hiệu bất thường.
Theo dõi advisory để xác nhận fixed version trước khi đưa plugin trở lại production.

Khi nào nên mở Incident Response?

Nên mở incident scope nếu quá trình kiểm tra phát hiện bằng chứng cho thấy vấn đề đã vượt khỏi mức “vulnerable plugin”, chẳng hạn:

file do attacker kiểm soát đã được ghi;
file khả nghi đã được request hoặc executed;
administrator/account không rõ nguồn gốc;
persistence artifact xuất hiện;
plugin/theme/core bị thay đổi trái quy trình;
log cho thấy request đáng ngờ trùng exposure window.

Trong trường hợp đó, chỉ xóa file hoặc deactivate plugin là chưa đủ.

SecureWebOps cung cấp Incident Response để xác định entry point, phạm vi ảnh hưởng, bảo toàn evidence, xử lý persistence và xác minh website trước khi đưa trở lại vận hành.

Nếu chưa có bằng chứng compromise nhưng cần biết website có đang phơi nhiễm với CVE, có thể bắt đầu bằng kiểm tra bảo mật website để inventory component, version, exposure và các control liên quan.

Giới hạn và thời điểm của thông tin

Bài viết này phản ánh trạng thái được xác minh ngày 18/09/2026.

CVE-2026-87796 được công bố ngày 17/09/2026, vì vậy fixed version, trạng thái repository, exploitation evidence hoặc mitigation guidance có thể thay đổi nhanh sau thời điểm này. Trước khi thực hiện remediation trên production, cần đối chiếu lại advisory hiện hành.

Điểm không thay đổi là nguyên tắc xử lý:

xác định đúng component → xác nhận affected version → giảm exposure → kiểm tra compromise → triển khai fixed version khi có → read-back trạng thái production.

Kết luận

CVE-2026-87796 là một lỗ hổng đáng ưu tiên vì ảnh hưởng Multi Uploader for Gravity Forms ≤1.1.9, cho phép arbitrary file upload qua network mà không yêu cầu đăng nhập và được đánh giá CVSS 9.8 Critical.

Tuy nhiên cần tránh hai suy luận sai.

Thứ nhất, đây không phải CVE của Gravity Forms core; website phải inventory riêng add-on gf-multi-uploader.

Thứ hai, arbitrary file upload có thể mở đường tới webshell/RCE nhưng không tự động chứng minh code đã được thực thi. Muốn kết luận compromise phải kiểm tra file provenance, execution boundary, log và các artifact hậu khai thác.

Trong lúc chưa có fixed version được xác nhận, cách tiếp cận an toàn là giảm exposure của component, bảo toàn evidence nếu có dấu hiệu bất thường và mở Incident Response khi phát hiện bằng chứng cho thấy attacker đã vượt qua bước file upload.