Sự cố PHP2Shell gồm hai lỗ hổng nghiêm trọng, CVE-2026-109618 và CVE-2026-109619. Vụ việc cho thấy quy trình công bố và nguồn lực bảo trì phần mềm nguồn mở chưa theo kịp tốc độ nghiên cứu bảo mật bằng AI.
Một số trang web đã chủ động ngừng hoạt động trong ngày thứ Tư để chờ bản vá. Việc tạm dừng dịch vụ không có nghĩa các trang này đã bị tấn công. Tuy nhiên, mức độ phổ biến của PHP khiến một sai sót nghiêm trọng trong ngôn ngữ này có thể ảnh hưởng đến nhiều hệ thống.
Theo bài điều tra gốc của The New Stack, PHP đang được dùng trên khoảng 70% số trang web. Con số này phản ánh độ phủ của PHP, không phải tỷ lệ trang web tồn tại lỗ hổng hoặc đã bị xâm nhập. Hai lỗ hổng được định danh là CVE-2026-109618 và CVE-2026-109619.
WordPress đã yêu cầu chủ trang web cập nhật PHP. Hai lỗ hổng này không đòi hỏi một bản cập nhật WordPress riêng. Các phiên bản PHP đã được sửa là 8.2.35, 8.3.36, 8.4.27 và 8.5.12. Người còn dùng nhánh PHP cũ cần nâng cấp lên nhánh được hỗ trợ hoặc cài bản sửa do nhà phân phối cung cấp.
Đối với doanh nghiệp và đội vận hành tại Việt Nam, điểm cần kiểm tra trước tiên không phải phiên bản WordPress. Họ cần xác định phiên bản PHP thực sự chạy trên máy chủ, bộ chứa và dịch vụ lưu trữ. Đây là một ví dụ cụ thể cho vấn đề rộng hơn khi AI tăng tốc hoạt động khai thác lỗ hổng nhanh hơn quy trình xử lý thủ công.
Nội dung: AI tìm ra đường thực thi mã từ xa
Sự cố được gọi là PHP2Shell bắt nguồn từ chương trình Patch the Planet của OpenAI. Theo The New Stack, công ty bảo mật Calif đã dùng GPT-5.6 Sol để tìm ra đường dẫn tới khả năng thực thi mã từ xa. Calif báo cáo phát hiện cho nhóm PHP vào ngày 11 tháng 8. OpenAI độc lập báo cáo cùng vấn đề nền tảng trong ngày đó. Wiz gửi phát hiện của mình vào ngày 24 tháng 8.
Dấu hiệu đã xuất hiện từ năm 2024
Theo The New Stack, các nhà duy trì PHP nhận thấy dấu hiệu của vấn đề hết bộ nhớ trong một cuộc kiểm tra năm 2024. Khi đó, họ chưa xác định được đường dẫn thực thi mã từ xa. Mức độ ảnh hưởng đầy đủ chỉ trở nên rõ ràng vào tháng 8.
Moshe Siman Tov Bustan của OX Security mô tả đây là một trong những dạng lỗ hổng nghiêm trọng có phạm vi rộng nhất. Theo ông, đơn vị vận hành PHP công khai mà chưa vá nên giả định hệ thống đã bị phơi nhiễm. Nếu có dấu hiệu khai thác, họ cần tính đến khả năng hệ thống đã bị xâm nhập.
Neatsun Ziv, giám đốc điều hành OX Security, cho rằng đây là hình mẫu của một lỗ hổng ở quy mô Internet. Khi công nghệ bị ảnh hưởng xuất hiện ở quá nhiều nơi, phạm vi tác động không còn giới hạn trong một sản phẩm hoặc một ngành.
Tranh cãi bắt đầu trước giờ công bố bản vá
PHP Foundation cho biết hai mã CVE bắt đầu lưu hành vào ngày 20 tháng 10. Sau đó, một video chứng minh ý tưởng khai thác bị đăng nhầm. Trước thời điểm công bố phối hợp dự kiến vào ngày 21 tháng 10, Chainguard đã phát hành các ảnh bộ chứa có bản vá.
Dan Lorenc, đồng sáng lập kiêm giám đốc điều hành Chainguard, nói ông phá bỏ thời hạn giữ kín vì tin rằng đã có báo cáo về hoạt động khai thác thực tế. Chainguard công khai các ảnh bộ chứa đã sửa cho mọi người sử dụng, thay vì chỉ cung cấp cho khách hàng.
Tốc độ tấn công làm thay đổi đánh giá rủi ro
Nỗi lo về tốc độ tấn công không phải giả thuyết. Theo dữ liệu Patchstack được The New Stack dẫn lại, WordPress phát hành phiên bản 7.1.2 ngày 22 tháng 9 để sửa CVE-2026-87902. Hoạt động dò quét xuất hiện ngay trong ngày. Nỗ lực ghi tệp xuất hiện vào ngày hôm sau. Tuy vậy, trường hợp đó không chứng minh hai lỗ hổng PHP đã bị khai thác thành công khi Chainguard phát hành bản vá sớm.
PHP Foundation phản đối quyết định của Chainguard. Trong tường trình của PHP Foundation, tổ chức này nói Chainguard đã đơn phương phá bỏ thời hạn giữ kín và công bố ảnh dựng chứa bản sửa. Chainguard được nhận bản vá sớm để khách hàng có thể cập nhật đúng thời điểm công bố đã thỏa thuận.
Từ góc nhìn của PHP Foundation, ảnh dựng được phát hành trước có thể giúp một số người phòng vệ sớm, nhưng cũng cho kẻ tấn công cơ hội phân tích điểm đã sửa trong lúc những người dùng PHP khác vẫn chưa có bản vá. Lorenc sau đó xin lỗi vì quyết định của mình làm tăng áp lực cho đội duy trì PHP, đồng thời nói mục tiêu của Chainguard là bảo vệ nhiều người nhất có thể.
Vì sao Chainguard quyết định công bố sớm
Lorenc cho biết Chainguard độc lập tìm thấy cùng vấn đề bằng một bộ công cụ kiểm thử và một mô hình AI tiên tiến được yêu cầu tìm các lỗ hổng nguy hiểm trong PHP. Công ty lần đầu nghe tin về một vấn đề PHP sắp được công bố vào thứ Sáu, ngày 16 tháng 10. Tối hôm đó, đội ngũ của Chainguard tự tìm ra lỗi.
Rò rỉ gia tăng trước ngày phát hành
Theo trình tự Lorenc cung cấp cho The New Stack, Chainguard nhận thông tin đầy đủ vào thứ Bảy, ngày 17 tháng 10. Sau đó, công ty tham gia kiểm thử các bản sửa. Tin tức bắt đầu rò rỉ vào thứ Hai, ngày 19 tháng 10. Đến tối thứ Ba, cuộc thảo luận trở nên căng thẳng. Một số nhà cung cấp báo cáo những dấu hiệu mà họ tin là hoạt động khai thác ngoài thực tế.
Sau cuộc gọi hình ảnh với các nhà nghiên cứu khác, Lorenc quyết định phát hành bản sửa và lập tức thông báo cho nhóm phối hợp công bố. Ông cho rằng hướng dẫn công bố phối hợp cho phép phát hành sớm nếu xuất hiện bằng chứng về hoạt động khai thác thực tế.
Theo Lorenc, ba yếu tố dẫn đến quyết định này. Chainguard có thể tự tìm lỗ hổng và xây dựng mã khai thác trong thời gian ngắn. Thông tin về lỗ hổng và bản sửa đã lưu hành, còn các bên đã chia sẻ bằng chứng về hoạt động khai thác. Tình huống này cho thấy AI đang làm thay đổi quy trình rà soát mã. Tuy nhiên, tốc độ phát hiện không tự giải quyết được câu hỏi ai có quyền quyết định thời điểm công bố.
Thế nào mới được tính là khai thác thực tế
Lorenc nói các nhà cung cấp khác đã nhìn thấy hoạt động khai thác ngoài thực tế. PHP Foundation cho biết tại thời điểm phát hành, đội bảo mật của họ chưa xác định được mã khai thác hoạt động đầy đủ trong số những bản chứng minh ý tưởng đang lưu hành.
Amazon Threat Intelligence sau đó báo cáo một nỗ lực có vẻ là khai thác vào ngày 17 tháng 10. Mục tiêu là hệ thống bẫy của họ. Amazon ghi nhận thêm các nỗ lực vào đầu ngày 21 tháng 10. Theo The New Stack, hãng vẫn chưa thể kết luận chúng có thành công trên hệ thống thực hay không.
Giữ kín thông tin cho đến thời điểm thống nhất giúp các nhà phân phối chuẩn bị cập nhật cùng nhau. Công bố bản sửa sớm có thể bảo vệ những người tiếp cận được nó, nhưng đồng thời tiết lộ manh mối cho kẻ tấn công trong lúc các hệ thống khác chưa có bản vá. Tranh cãi giữa Chainguard và PHP Foundation không phủ nhận hai rủi ro này. Các bên đã đánh giá trọng số của chúng khác nhau.
Thất bại lớn hơn đã hình thành từ năm 2024
PHP Foundation cho biết dấu hiệu của lỗi hết bộ nhớ đã được phát hiện trong một cuộc kiểm tra năm 2024, nhưng công việc sửa lỗi nhiều lần đình trệ vì các đánh đổi giữa khả năng tương thích và bảo mật. Tổ chức này gọi sự chậm trễ là “một thất bại mang tính cấu trúc” bắt nguồn từ quy trình ra quyết định và tình trạng thiếu nguồn lực.
Các nhà phát triển chưa tìm thấy đường dẫn cụ thể từ lỗi hết bộ nhớ tới khả năng thực thi mã từ xa vào năm 2024. Những phương án sửa cạnh tranh với nhau khiến quá trình xử lý không đi đến kết quả dứt điểm trước khi AI giúp các nhà nghiên cứu xác định tác động đầy đủ.
Đây là vấn đề nghiêm trọng hơn bản thân cuộc tranh cãi về thời điểm phát hành. Một dự án nằm dưới phần lớn trang web trên Internet đã nhìn thấy dấu hiệu của lỗi từ năm 2024 nhưng không có đủ quy trình và nguồn lực để xử lý dứt điểm.
PHP Foundation hiện muốn nhận thêm hỗ trợ từ doanh nghiệp, nhà cung cấp dịch vụ lưu trữ và chính phủ phụ thuộc vào PHP. Áp lực này không chỉ tồn tại ở một dự án. Các đội bảo mật cũng đang phải xử lý khối lượng phát hiện tăng nhanh, trong khi việc xác định bối cảnh và ưu tiên lỗi vẫn là phần khó của công việc.
Năng lực khai thác bằng AI sẽ dễ tiếp cận hơn
Nelson, giám đốc công nghệ của CIQ, cho biết ông đã thấy AI được dùng để khai thác lỗ hổng trong không gian nhân Linux trong sáu tháng. CIQ là nhà tài trợ sáng lập của Rocky Linux. Theo Nelson, hoạt động nghiên cứu đang mở rộng sang những phần mềm được dùng rộng rãi khác như PHP.
Ông dự báo các dự án nguồn mở sẽ tiếp tục dùng AI và những công cụ khác để gia cố mã, đồng thời kẻ tấn công cũng có thêm năng lực nghiên cứu. Hiện tại, việc khai thác kiểu này còn cần một mô hình AI tiên tiến. Nelson cho rằng điều đó sẽ không kéo dài.
Lorenc cũng nhìn nhận đây là vấn đề của toàn ngành, không riêng PHP. Khi tốc độ tìm lỗi và phát triển mã khai thác tăng lên, quy trình xử lý lỗ hổng phải đủ nhanh để bảo vệ hạ tầng quan trọng trước khi kẻ tấn công gây thiệt hại thực tế.
Không nên chờ đến kỳ bảo trì thông thường
Đội vận hành cần vá ngoài lịch thông thường
Gunnar Hellekson, phó chủ tịch kiêm tổng giám đốc Lightwell của Red Hat, nói những phần mềm ổn định trong môi trường sản xuất rất dễ bị bỏ quên. Trong khi đó, việc phát hiện bằng AI đang làm tăng cả số lượng lẫn tốc độ xuất hiện của báo cáo lỗ hổng.
Hellekson khuyến nghị khách hàng triển khai bản vá đã được kiểm nghiệm ngay khi chúng có sẵn từ các nhà cung cấp đáng tin cậy, kể cả ngoài khung bảo trì thông thường. Với PHP, đội vận hành cần xác định nhánh đang chạy, lấy bản cập nhật từ nguồn phân phối tin cậy và kiểm tra hệ thống sau khi nâng cấp.
The New Stack cho biết các tổ chức chạy hệ thống PHP bị ảnh hưởng nên rà soát dấu hiệu khai thác từ ngày 17 tháng 10. Việc kiểm tra cần đi cùng triển khai bản dựng đã sửa, bởi cập nhật phần mềm không thể xác nhận liệu hoạt động xâm nhập đã xảy ra trước thời điểm vá hay chưa.
Kara Sprague, giám đốc điều hành HackerOne, cho rằng phần mềm hỗ trợ hàng triệu trang web không thể phụ thuộc vào một nhóm nhỏ nhà duy trì. Họ đang phải đối phó với các mối đe dọa ngày càng tinh vi. Tranh cãi PHP2Shell cho thấy dự án nguồn mở cần thêm nguồn lực. Quy trình công bố cũng phải chịu được rò rỉ, còn công cụ phòng thủ phải theo kịp tốc độ nghiên cứu bằng AI.
Hãy kiểm tra phiên bản PHP và lịch sử hoạt động của hệ thống ngay hôm nay, thay vì chờ đến kỳ bảo trì tiếp theo.
