Hai lỗ hổng PHP chạm tới lõi mọi website: vì sao phải vá ngay hôm nay

Lỗi nằm ở tầng nào, và vì sao điều đó quan trọng

Lỗi không nằm ở WordPress, Drupal hay Joomla. PHP.net nói rõ điều này. Phần lõi thông dịch của PHP chạy trước mọi dòng mã của ứng dụng, nên ngay cả một tệp PHP đơn giản chỉ in ra “Hello World” cũng có thể bị ảnh hưởng.

Lỗi thứ nhất, CVE-2026-109618, xảy ra khi PHP hết bộ nhớ (out-of-memory) giữa lúc đang xử lý một request. Dữ liệu nội bộ của request khi đó có thể mới khởi tạo một phần, nhưng bước dọn dẹp cuối request vẫn coi đó là dữ liệu hợp lệ. Lỗi thứ hai, CVE-2026-109619, là trạng thái toàn cục cũ: dữ liệu của một request vẫn còn sau khi vùng nhớ đã được giải phóng, và worker xử lý request kế tiếp có thể dùng lại nó trước khi được reset.

Calif, đơn vị kiểm tra mã nguồn PHP từ cuối tháng 7, ghi nhận đường khai thác sớm nhất quay về PHP 5.4.0. Đường khai thác phụ thuộc phiên bản và cách PHP được chạy, nhưng luôn khai thác được ở cấu hình mặc định. Nghĩa là lỗi đã nằm trong các bản PHP phát hành suốt hơn một thập kỷ.

Calif xác nhận khai thác được trên những ứng dụng nào

Calif nói đã xác nhận RCE không cần xác thực trên WordPress 7.1.2, Drupal 11.4.3, Joomla 6.1.4, MediaWiki 1.46.2, Roundcube 1.7.4, Magento 2.4.9, phpMyAdmin 5.2.3, Nextcloud 35.0.1, Laravel 13.11, Symfony 8.1 và WHMCS. Ở một số trường hợp, họ còn chạy được script PHP tùy ý.

Danh sách này không có nghĩa mọi bản cài đặt đều bị khai thác. Nhưng nó cho thấy việc chờ ứng dụng tự vá là chưa đủ, vì lỗi nằm dưới tầng ứng dụng.

Vì sao cùng một lỗi được tìm ra nhiều lần

PHP Foundation kể lại mốc thời gian. Calif bắt đầu kiểm tra PHP từ 30/7/2026 trong chương trình Patch the Planet. Ngày 11/8, một nhà nghiên cứu của Calif báo cáo lỗi RCE không điều kiện, có cùng nguyên nhân gốc với lỗi OOM mà Foundation từng tìm ra năm 2024. OpenAI báo cáo độc lập cùng nguyên nhân trong đúng ngày đó. Wiz báo đường khai thác vào 24/8, OpenAI thêm một đường khác vào 18/9.

Chuỗi mốc này đáng chú ý hơn con số CVSS. Hai nhóm tìm ra cùng một nguyên nhân gốc trong cùng một ngày, và các đường khai thác tiếp theo xuất hiện trong khoảng hai tháng. Tiêu đề một trong các báo cáo khai thác đã đặt AI ở vị trí trung tâm. Có thể đọc đây là dấu hiệu công cụ tự động đang rút ngắn khoảng cách từ lỗi trên lý thuyết tới khai thác chạy được. Tuy vậy, PHP Foundation không mô tả quy trình tìm lỗi bằng AI, nên đây mới là suy đoán có căn cứ, chưa phải kết luận đã kiểm chứng.

Việc cần làm: nâng cấp trước, giảm nhẹ sau

Các bản vá là PHP 8.5.12, 8.4.27, 8.3.36 và 8.2.35. PHP 8.2 hết hỗ trợ vào 31/12/2026, nên nếu đang dùng 8.2 thì đây là lúc lên lịch chuyển sang nhánh còn được hỗ trợ. PHP 8.1 trở xuống không còn được dự án PHP vá. Nếu dùng bản PHP do nhà cung cấp hệ điều hành đóng gói, hãy hỏi họ đã backport bản vá chưa, vì bản đó có thể đến muộn hơn.

Gói rpm từ kho remirepo chưa có cập nhật trong ngày 21/10. PHP.net khuyên chuyển sang gói của distro hoặc tự build từ mã nguồn để áp bản vá ngay.

Nếu chưa thể nâng cấp trong ngày, PHP.net liệt kê vài biện pháp giảm nhẹ: đặt memory_limit=-1 ở tầng mà ứng dụng không ghi đè được, giới hạn post_max_size (8M nếu không cần upload, 32M nếu cần), đặt session.upload_progress.enabled=0 rồi khởi động lại mọi worker. Trên PHP 8.5, thêm fatal_error_backtraces=0. Có hai điều cần nhớ. Đừng dùng RLIMIT_AS hay RLIMIT_DATA, vì chúng có thể kích hoạt đúng đường lỗi cấp phát. Và đừng coi đó là an toàn, vì PHP.net nói rõ các biện pháp này chỉ chặn một số đường tấn công.

Con số 10.0 lan trước giờ phát hành

Khoảng 15:00 UTC ngày 20/10, hai mã CVE bắt đầu lan trên diễn đàn và mạng xã hội, kèm ngày phát hành sai và điểm CVSS 10.0. PHP Foundation xác nhận điểm đúng là 9.2, và đã đẩy lịch phát hành từ 22/10 lên 21/10 lúc 14:00 UTC. Nếu thấy con số 10.0 ở đâu đó, đó là thông tin cũ.

Với website và máy chủ ở Việt Nam

PHP không phải sản phẩm có giá bán, nên ở đây không có mốc giá hay kênh bán lẻ nào để so sánh. Câu hỏi thực tế là ai đang giữ bản PHP trên máy chủ của bạn. Với hosting chia sẻ, phiên bản PHP thường do nhà cung cấp quản lý, nên hãy hỏi họ xác nhận đã vá chưa. Với VPS hoặc máy chủ tự dựng, việc này thuộc về bạn, và nên làm trong ngày chứ không để sang tuần.

Cách kiểm tra đơn giản nhất là chạy php -v trên máy chủ. Nếu số phiên bản không khớp danh sách đã vá, việc cần làm trước là nâng cấp. Các biện pháp giảm nhẹ để sau.

Một ngôn ngữ mà Wiz ước tính chạy khoảng 70% website trên thế giới thì không thể để lỗ hổng ở lõi của nó sang tuần sau.

Nguồn tham khảo: PHP.net, The PHP Foundation, Wiz Research, Calif