Hai lỗ hổng nghiêm trọng trong PHP đã gây gián đoạn trên diện rộng. Doanh nghiệp, bệnh viện, trường học và cơ quan chính phủ phải tạm ngừng một số trang web và dịch vụ trực tuyến để tự bảo vệ. Theo bài viết gốc của The New Stack, PHP2Shell không chỉ là một cuộc khủng hoảng của PHP. Sự cố phơi bày khoảng cách ngày càng lớn giữa tốc độ phát hiện tự động và nguồn lực cần thiết để xử lý từng lỗ hổng.
Phạm vi ảnh hưởng và các biện pháp ứng phó
PHP2Shell có thể cho phép kẻ tấn công chưa xác thực thực thi mã độc trên máy chủ bị ảnh hưởng. Cloudflare triển khai biện pháp bảo vệ trên tường lửa ứng dụng web. Automattic cho biết các trang thuộc WordPress.com, WordPress VIP và Tumblr đã được bảo vệ. Wikimedia Foundation tạm đưa một số dịch vụ hỗ trợ ra ngoại tuyến trong lúc chờ bản vá.
Dự án PHP phát hành các bản sửa lỗi khẩn cấp cho PHP 8.2 đến 8.5. Những phiên bản cũ hơn không còn được hỗ trợ chính thức, dù một số nhà phân phối và nhà cung cấp vẫn phát hành bản sửa lỗi cũ. PHP cũng cung cấp các bản vá giới hạn cho phiên bản 7.4 đến 8.1.
Một câu lệnh đơn giản cũng có thể tìm ra lỗ hổng
Chainguard cho biết họ đã tái phát hiện lỗ hổng bằng một mô hình AI tiên tiến và câu lệnh đơn giản yêu cầu tìm các lỗ hổng nghiêm trọng trong PHP. Sự việc cho thấy một lỗi đã được phát hiện có thể nhanh chóng bị nhiều bên tìm lại, làm tăng áp lực lên quy trình công bố và phát hành bản vá.
Quy trình công bố và nội dung phối hợp
Thông tin về các bản vá sắp phát hành xuất hiện vào thứ Ba. Chi tiết đã bị rò rỉ trước thời điểm công bố dự kiến. Sang ngày hôm sau, OpenAI cho biết công ty bảo mật Calif đã tìm thấy một trong hai lỗ hổng bằng mô hình GPT-5.6 Sol. Wiz, công ty thuộc Google, phát hiện độc lập cả hai lỗ hổng.
OpenAI cho biết họ dành hai tháng để phối hợp phản ứng với nhóm duy trì PHP, các nhà nghiên cứu bảo mật, Cloudflare và những cơ quan an ninh mạng của chính phủ trong khuôn khổ chương trình Patch the Planet.
Kế hoạch công bố phối hợp bị xáo trộn khi Chainguard phát hành ảnh bộ chứa PHP đã vá. Việc phát hành diễn ra sớm hơn thời điểm thống nhất hơn sáu giờ. Tổng giám đốc Dan Lorenc thừa nhận ông là người đưa ra quyết định. Chainguard đã tự phát hiện lại lỗ hổng bằng một mô hình trí tuệ nhân tạo tiên tiến. Họ dùng câu lệnh đơn giản có nghĩa là “hãy tìm các lỗ hổng nghiêm trọng trong PHP”.
Lorenc giải thích quyết định này dựa trên các báo cáo về hoạt động tấn công và mức độ dễ tái tạo của lỗ hổng. PHP Foundation phản bác rằng việc phát hành sớm có thể giúp kẻ tấn công trong lúc các nhà cung cấp khác vẫn đang chuẩn bị bản vá.
Nils Adermann là thành viên hội đồng PHP Foundation, người sáng lập và đồng duy trì Composer. Ông nói chưa có vụ khai thác nào được xác nhận. Theo Adermann, những hoạt động được phát hiện mới chỉ là các nỗ lực khai thác. Ông chỉ trích việc Chainguard hành động đơn phương và không trao đổi với nhóm PHP. Thời hạn giữ kín đã được thảo luận nhiều lần dựa trên rủi ro khai thác và khả năng bảo vệ người dùng.
Trí tuệ nhân tạo tạo ra một trạng thái bình thường mới
Phát hiện ở quy mô hàng triệu dòng mã
Một ngày trước thông báo của OpenAI, nghiên cứu của Anthropic công bố kết quả rà soát của Claude. Mô hình đã xác định 493 vấn đề bảo mật trong 25 dự án mã nguồn mở, với tổng cộng hơn năm triệu dòng mã. Một lỗi cấu hình đã tồn tại suốt 21 năm. Lỗi này có khả năng vô hiệu hóa yêu cầu xác thực. Khi đó, máy khách không được cấp quyền có thể tiếp cận một máy chủ vốn được cho là bị hạn chế.
Anthropic lưu ý rằng không phải phát hiện nào cũng là lỗ hổng có thể khai thác. Dù vậy, kết quả cho thấy khoảng cách giữa năng lực phát hiện tự động và nguồn lực cần thiết để xác minh từng báo cáo. Vấn đề tương tự xuất hiện trong các hệ thống nơi trí tuệ nhân tạo dồn thêm lỗi cho đội bảo mật nhưng không tự giải quyết được bài toán ưu tiên.
Christopher Robinson là giám đốc công nghệ của Akrites. Ông cũng là giám đốc công nghệ kiêm kiến trúc sư trưởng về bảo mật tại Open Source Security Foundation. Robinson cho rằng chuẩn bị trước là cách giảm tác động của sự cố như PHP2Shell. Dự án mã nguồn mở và doanh nghiệp cần có quy trình quản lý lỗ hổng. Họ cũng cần biết có thể nhờ ai hỗ trợ khi vấn đề vượt quá năng lực nội bộ.
Khi tìm lỗi dễ hơn sửa lỗi
PHP có đủ tầm ảnh hưởng để huy động một nhóm phản ứng gồm nhiều nhà cung cấp, cơ quan chính phủ và các đơn vị vận hành tường lửa ứng dụng web. Michelle Tilley, kỹ sư phần mềm kiêm giám đốc công nghệ của Atuin, cho rằng một dự án nhỏ khó có được nguồn lực tương tự.
Dự án nhỏ chịu áp lực lớn hơn
Atuin là công cụ mã nguồn mở dành cho nhà phát triển. Atuin có hơn 32.000 lượt đánh dấu yêu thích trên GitHub. Công ty của bà đã nhận nhiều báo cáo lỗi và đề nghị sửa mã do trí tuệ nhân tạo tạo ra hơn trước. Atuin còn đủ kỹ sư để xử lý. Tuy nhiên, nhiều dự án nhỏ dựa vào những người duy trì không được trả lương và chỉ làm việc trong thời gian rảnh.
Khi lượng báo cáo vượt quá khả năng xử lý, những người duy trì có thể kiệt sức. Một số tìm người tiếp quản, còn nhiều người dừng làm việc mà các tổ chức đang sử dụng phần mềm phía dưới không hề biết. Dự án sau đó có thể giữ lại những lỗ hổng không bao giờ được vá.
Tilley cho rằng người tìm ra lỗi và các công ty phụ thuộc vào mã nguồn phải gánh thêm chi phí khắc phục. Nhiều doanh nghiệp hưởng lợi từ một thư viện, nhưng toàn bộ việc xác minh và sửa lỗi vẫn do vài tình nguyện viên đảm nhận. Số phát hiện mới do trí tuệ nhân tạo tạo ra sẽ khiến mô hình này mất cân bằng nhanh hơn.
Bản vá đúng vẫn cần người duy trì giàu kinh nghiệm
Madelyn Olson, kỹ sư chính tại AWS và người duy trì cơ sở dữ liệu Valkey, cho biết dự án của bà đang tìm và sửa nhiều lỗi bảo mật hơn hẳn trong năm 2026 so với trước. Theo Olson, phần khó nhất đã chuyển từ tìm lỗi sang sửa lỗi.
Khả năng tương thích làm chậm bản vá
Một nhà phát triển PHP lần đầu nhận ra vấn đề nền tảng phía sau một trong các lỗ hổng. Phát hiện xuất hiện khi người này sửa một lỗi từ cuộc kiểm toán bảo mật năm 2024 do Open Source Technology Improvement Fund tổ chức. Tuy nhiên, quá trình xử lý bị đình trệ. Các phương án sửa có nguy cơ phá vỡ khả năng tương thích, ảnh hưởng hiệu năng hoặc làm gián đoạn tiện ích mở rộng của bên thứ ba.
PHP Foundation cho biết chỉ có ít kỹ sư đủ chuyên môn để cân bằng những đánh đổi đó. Trí tuệ nhân tạo có thể chỉ ra đoạn mã đáng ngờ. Tuy nhiên, nó không tự chịu trách nhiệm cho một bản vá làm gián đoạn hệ thống của người dùng.
Vấn đề này liên quan trực tiếp đến yêu cầu xác minh mã khi trí tuệ nhân tạo tăng tốc lập trình. Tốc độ tạo ra phát hiện không thể thay thế kiểm thử hồi quy, đánh giá tương thích và quyết định phát hành của người duy trì.
Để ứng phó, Valkey đang thu hẹp định nghĩa về lỗ hổng bảo mật, dùng trí tuệ nhân tạo kiểm tra mã của chính dự án và đơn giản hóa việc chuyển bản sửa lỗi về các phiên bản cũ cũng như phát hành phiên bản mới.
Thời hạn giữ kín lỗ hổng có thể phải ngắn hơn
Nhiều nhà nghiên cứu có thể độc lập tìm lại cùng một lỗi bằng mô hình ngôn ngữ lớn. Vì vậy, thời hạn giữ kín dài hơn có thể kéo dài khoảng thời gian hệ thống chưa được bảo vệ. Tuy nhiên, công bố trước ngày thống nhất cũng có thể cung cấp thông tin cho kẻ tấn công. Rủi ro tăng lên khi các nhà cung cấp chưa triển khai xong bản vá.
Nhiều bên có thể độc lập tìm lại cùng một lỗi
Tranh cãi quanh Chainguard đặt ra câu hỏi về thời gian công bố lỗ hổng. Olson kể rằng trong cùng một tuần, ba nhà nghiên cứu đã độc lập báo cáo một lỗi của Valkey và cả ba đều dùng mô hình ngôn ngữ lớn.
Nếu một người có thể tìm thấy lỗi bằng mô hình ngôn ngữ lớn, người khác cũng có thể làm điều tương tự. Valkey vì thế đang hướng đến thời hạn giữ kín ngắn hơn và phát hành nhanh hơn. Olson cho biết đây là xu hướng xuất hiện ở phần lớn dự án lớn.
Rút ngắn thời hạn theo thỏa thuận không giống với tự ý phá vỡ ngày phát hành đã thống nhất. Công bố sớm có thể trao thêm thông tin cho kẻ tấn công. Khi đó, những đơn vị vận hành có thể chưa kịp triển khai bản vá. Ngược lại, nhiều mô hình có thể độc lập tìm lại cùng một lỗi. Giữ kín quá lâu vì thế cũng kéo dài khoảng thời gian hệ thống chưa được bảo vệ.
Hàng đợi bảo mật tiếp tục phình to
Người duy trì phải xử lý đồng thời các lỗ hổng hợp lệ và báo cáo chất lượng thấp. AI có thể tăng số lượng phát hiện, nhưng không loại bỏ thời gian cần để phân loại, tái tạo lỗi và phát triển bản vá. Với một nhóm nhỏ, riêng công việc xác minh đã có thể chiếm hết nguồn lực kỹ thuật.
Phân loại báo cáo tiêu tốn nguồn lực kỹ thuật
Derek Zimmer, giám đốc điều hành Open Source Technology Improvement Fund, cho biết người duy trì đang phải xử lý đồng thời các phát hiện hợp lệ và báo cáo chất lượng thấp. Trong năm 2026, việc tìm lỗi nghiêm trọng đã dễ hơn, nhưng phân biệt đâu là lỗ hổng thật vẫn tiêu tốn nhiều thời gian kỹ thuật.
Tổ chức này đang thử nghiệm Project V-LAT, chương trình đưa kỹ sư vào làm việc trực tiếp với dự án để xem xét phát hiện, phát triển bản sửa lỗi và cải thiện quy trình tiếp nhận báo cáo.
Robinson cũng kêu gọi chia sẻ chuyên môn bảo mật và bố trí kỹ sư chuyên trách hỗ trợ các dự án đầu nguồn. Việc phát hiện thêm lỗ hổng không nhất thiết khiến mã nguồn mở kém an toàn hơn, nếu những công ty phụ thuộc vào mã thực sự tham gia sửa lỗi. Trở ngại là nhiều dự án không có ngân sách, hạ tầng hoặc công cụ để tự phản ứng.
Trong các dự án nguồn mở thiếu ngân sách, hạ tầng và chuyên môn, lỗi chưa vá có thể tồn tại lâu hơn. Với dự án chỉ có ba người duy trì, một làn sóng báo cáo tự động có thể chiếm hết thời gian trước khi nhóm kịp xác nhận báo cáo nào đáng xử lý.
PHP2Shell cảnh báo về khoảng cách giữa phát hiện và vá lỗi
Cách thu hẹp khoảng cách vá lỗi
Các dự án cần chuẩn bị quy trình tiếp nhận, phân loại và ứng phó trước khi báo cáo đến dồn dập. Doanh nghiệp sử dụng mã nguồn mở cũng phải góp kỹ sư và kinh phí, thay vì để toàn bộ chi phí khắc phục cho những người duy trì tình nguyện.
Hãy tiếp tục theo dõi Sine để nắm những thay đổi về trí tuệ nhân tạo, bảo mật phần mềm và cách chúng tác động đến đội ngũ kỹ thuật.
