>_toolkitbox

~/ / Bài viết về AI / AI đã giúp tìm ra PHP2Shell: các lỗ hổng PHP nghiêm trọng của tháng 10 năm 2026

AI đã giúp tìm ra PHP2Shell: các lỗ hổng PHP nghiêm trọng của tháng 10 năm 2026

Theo các báo cáo của báo chí, các mô hình AI đã giúp các nhà nghiên cứu tìm ra hai lỗ hổng nghiêm trọng trong chính PHP, CVE-2026-109618 và CVE-2026-109619, có thể cho phép thực thi mã từ xa mà không cần xác thực. PHP đã phát hành các phiên bản đã vá vào ngày 21 tháng 10 năm 2026. Bài viết này tóm tắt những gì các thông báo chính thức và các báo cáo nói về các lỗi này cũng như về vai trò của AI, và cho phép bạn kiểm tra xem PHP mà bạn đang chạy đã có bản vá hay chưa.

Đối chiếu với các thông báo chính thức vào ngày 2026-10-24. Trang này không phải là thông báo bảo mật chính thức và các chi tiết có thể thay đổi, vì vậy hãy theo dõi các nguồn ở cuối trang.

Việc cần làm trước tiên

  1. Cập nhật PHP lên một bản phát hành đã vá (8.5.12, 8.4.27, 8.3.36 hoặc 8.2.35), hoặc lên gói đã vá từ bản phân phối Linux của bạn. PHP cho biết không có biện pháp giảm thiểu nào đầy đủ và cập nhật là lựa chọn an toàn duy nhất.
  2. Sau khi cập nhật, hãy khởi động lại PHP-FPM, Apache và mọi worker PHP chạy lâu dài để chúng nạp mã đã vá. Một dịch vụ đã khởi động trước khi cập nhật vẫn đang chạy mã cũ.
  3. Nếu PHP đến từ một gói của bản phân phối, hãy kiểm tra phiên bản gói đầy đủ, bao gồm phần sau dấu gạch ngang đầu tiên. Các bản phân phối có thể đã có bản vá mà không thay đổi phần đầu của số phiên bản.
  4. Nếu bạn không thể cập nhật ngay, hãy xem các biện pháp giảm thiểu bên dưới. PHP cho biết chúng làm giảm mức độ phơi nhiễm trước một số đường tấn công cụ thể nhưng không làm cho bản cài đặt trở nên an toàn.

Chuyện gì đã xảy ra

Vào ngày 21 tháng 10 năm 2026, PHP phát hành 8.5.12, 8.4.27, 8.3.36 và 8.2.35. Các bản này vá hai lỗ hổng nghiêm trọng, cả hai đều được xếp hạng CVSS v4.0 9.2.

CVE-2026-109618, được gọi là RCE via OOM corruption: việc xử lý hết bộ nhớ có thể làm PHP bị ngắt khi dữ liệu yêu cầu nội bộ mới chỉ được khởi tạo một phần, và bước dọn dẹp yêu cầu sau đó có thể coi dữ liệu không hợp lệ đó là hợp lệ.

CVE-2026-109619, được gọi là RCE via stale global state: trạng thái nội bộ thuộc về một yêu cầu có thể vẫn tồn tại sau khi vùng nhớ chứa nó đã được giải phóng, và một yêu cầu sau đó do cùng worker xử lý có thể dùng trạng thái cũ này.

  • CVE-2026-109618 · CVSS 4.0 9.2
  • CVE-2026-109619 · CVSS 4.0 9.2

AI đã tham gia như thế nào

Theo The Next Web, công ty bảo mật Calif đã tìm ra lỗi đầu tiên vào tháng 8 với sự hỗ trợ của một mô hình OpenAI, trong quá trình kiểm toán mã nguồn PHP do OpenAI tài trợ. Wiz cho biết họ đã phát hiện các lỗi này một cách độc lập, vài tuần sau đó, bằng các công cụ AI gồm cả các mô hình Gemini của Google.

Trang php2shell.com ghi nhận nghiên cứu của Wiz Research, OpenAI Codex Security và Calif. Calif cho biết họ đã dùng các mô hình phổ biến công khai, và việc hiểu lịch sử của PHP quan trọng hơn bản thân mô hình.

Cùng bài viết đó cho biết Cloudflare đã bật các quy tắc WAF cho khách hàng của mình khoảng chín giờ trước khi công bố, và sau đó một mã khai thác chứng minh khái niệm đã lưu hành trên mạng. Trang php2shell.com cho biết không nên coi một quy tắc WAF hay CDN là sự thay thế cho việc cập nhật PHP.

Dòng thời gian

  1. PHP thông báo sắp có một bản phát hành bảo mật nghiêm trọng, dự kiến vào ngày 21 tháng 10 lúc 14:00 UTC.
  2. PHP 8.5.12, 8.4.27, 8.3.36 và 8.2.35 được phát hành kèm một thông báo bảo mật, và Ubuntu công bố USN-8948-1.
  3. PHP công bố một thông báo mang tính tham khảo về session.upload_progress.enabled, liên quan đến một hướng tấn công khác ít có khả năng xảy ra, được theo dõi dưới mã CVE-2026-115560.

Ai bị ảnh hưởng

PHP cho biết mọi bản cài đặt PHP phục vụ các yêu cầu web đều có nguy cơ, bao gồm PHP-FPM, Apache với mod_php, php-cgi, FrankenPHP và LiteSpeed. PHP đánh giá rủi ro cao nhất với mod_php, nơi một yêu cầu không cần xác thực có thể kích hoạt cuộc tấn công trước khi bất kỳ mã ứng dụng nào chạy.

Các thông báo trên GitHub liệt kê các phiên bản dưới 8.2.35, 8.3.36, 8.4.27 và 8.5.12 là bị ảnh hưởng. Trang php2shell.com, được cho là do Wiz vận hành, cho biết các bản phát hành bị ảnh hưởng kéo dài từ PHP 5.4.

PHP 8.1 trở về trước không còn nhận được cập nhật từ dự án PHP. Một số bản phân phối và nhà cung cấp LTS cung cấp các bản vá được backport, và PHP đã cung cấp các bản backport mã nguồn tối thiểu cho PHP 7.4, 8.0 và 8.1 dành cho những người tự biên dịch từ mã nguồn.

Các phiên bản đã vá

Phiên bản bằng hoặc cao hơn bản phát hành đã vá của nhánh tương ứng thì đã có bản vá. Gói của bản phân phối được xác định là đã vá theo phiên bản gói, vì vậy hãy dùng bảng thứ hai cho Ubuntu và Debian.

Các bản phát hành của chính PHP

NhánhBản phát hành đầu tiên đã vá
PHP 8.58.5.12
PHP 8.48.4.27
PHP 8.38.3.36
PHP 8.28.2.35

Gói Ubuntu và Debian

Bản phân phốiGóiPhiên bản gói đã váThông báo
Ubuntu 26.10php8.58.5.9-0ubuntu2.1USN-8948-1
Ubuntu 26.04 LTSphp8.58.5.4-0ubuntu1.5USN-8948-1
Ubuntu 24.04 LTSphp8.38.3.6-0ubuntu0.24.04.13USN-8948-1
Ubuntu 22.04 LTSphp8.18.1.2-1ubuntu2.28USN-8948-1
Debian 12 (bookworm)php8.28.2.35-1~deb12u1DLA-4848-1
Debian 13 (trixie)php8.48.4.27-1~deb13u1DSA-6574-1

Các bảng chỉ hiển thị những gì các thông báo chính thức liệt kê. Với các bản phân phối khác, hãy xem thông báo bảo mật của nhà cung cấp của bạn.

Kiểm tra PHP của bạn

Chọn nguồn gốc PHP của bạn, dán văn bản phiên bản, và công cụ sẽ so sánh nó với các phiên bản đã vá ở trên. Công cụ chỉ đánh giá văn bản bạn dán vào. Nó không thể biết phiên bản nào đang chạy, vì vậy hãy xác nhận thêm rằng dịch vụ đã được khởi động lại sau khi cập nhật.

Các lệnh hiển thị phiên bản

  • php -v
  • dpkg -l 'php*' | grep ^ii
  • apt-cache policy php8.3-fpm | grep Installed

Mọi thứ chạy ngay trong trình duyệt của bạn. Văn bản bạn dán vào không được tải lên.

Nếu bạn không thể cập nhật ngay

PHP liệt kê các biện pháp này. PHP cho biết chúng làm giảm mức độ phơi nhiễm trước một số đường tấn công cụ thể nhưng không làm cho bản cài đặt trở nên an toàn, và chỉ có cập nhật mới là giải pháp đầy đủ.

CVE-2026-109618

  • Đặt memory_limit=-1, tốt nhất theo cách mà ứng dụng không thể ghi đè, chẳng hạn php_admin_value trong pool FPM hoặc cấu hình Apache. Một lỗi cấp phát bộ nhớ ở tầng bên dưới vẫn có thể dẫn đến đường dễ bị tấn công.
  • Đặt post_max_size ở mức thấp: 8M cho các ứng dụng không cần tải tệp lên, và 32M nếu cần tải tệp lên. Giữ upload_max_filesize nhỏ hơn post_max_size.
  • Áp đặt giới hạn tại máy chủ web hoặc proxy đối với kích thước yêu cầu sau khi giải mã, số trường đầu vào, số phần multipart, số header và độ sâu lồng nhau.
  • Dùng giới hạn của container hoặc cgroup làm ranh giới về tính khả dụng. Không dùng RLIMIT_AS hoặc RLIMIT_DATA, vì chúng có thể gây ra lỗi cấp phát bộ nhớ dẫn đến đường dễ bị tấn công.

CVE-2026-109619

  • Đặt session.upload_progress.enabled=0 trong php.ini, một pool FPM hoặc cấu hình máy chủ, rồi khởi động lại mọi worker. Không dựa vào ini_set() hoặc tệp .user.ini của FPM.
  • Trên PHP 8.5, đặt fatal_error_backtraces=0 và khởi động lại mọi worker.
  • Loại bỏ các thiết lập không hợp lệ hoặc đã lỗi thời được áp dụng theo từng yêu cầu và phát ra thông báo chẩn đoán trước khi khởi tạo. Việc ẩn thông báo chẩn đoán không có tác dụng.
  • Sửa các lỗi nghiêm trọng (fatal error) và hết thời gian thực thi mà kẻ tấn công có thể kích hoạt.

Thông báo mang tính tham khảo ngày 23 tháng 10

PHP đề nghị đặt session.upload_progress.enabled=0 cho đến bản sửa lỗi định kỳ tiếp theo, để bảo vệ đầy đủ trước một hướng thực thi mã từ xa khác ít có khả năng xảy ra. Nếu bạn đã áp dụng thiết lập này theo thông báo ngày 21 tháng 10, hãy giữ nguyên.

PHP cho biết vấn đề chỉ có thể xảy ra trong một tổ hợp bất thường: một ứng dụng đặt session.serialize_handler thành php_binary hoặc php_serialize trong cấu hình, chuyển nó sang php khi chạy bằng ini_set() trước session_start(), và tính năng theo dõi tiến trình tải lên của phiên vẫn đang bật. PHP sẽ công bố thông báo đầy đủ cho CVE-2026-115560 cùng với bản phát hành tiếp theo.

Trang này không làm những gì

  • Đây không phải là thông báo bảo mật chính thức và không đưa ra chi tiết khai thác. Các thông báo và cảnh báo chính thức bên dưới mới là thẩm quyền.
  • Trang không thể cho biết một hệ thống có từng bị tấn công hay không. Trang php2shell.com lưu ý rằng việc không có hoạt động đáng ngờ không chứng minh được rằng hệ thống không bị ảnh hưởng.
  • Mức độ phơi nhiễm phụ thuộc vào phiên bản, cấu hình và từng lỗ hổng cụ thể. Các biện pháp giảm thiểu có thể ảnh hưởng đến cách ứng dụng hoạt động.

Nguồn