PHP phát hành các bản vá bảo mật khẩn cấp cho lỗ hổng thực thi mã từ xa nghiêm trọng

Dự án PHP đã phát hành ngay lập tức các bản cập nhật bảo mật cho phiên bản 8.5.12, 8.4.27, 8.3.36 và 8.2.35 để xử lý hai lỗ hổng nghiêm trọng. Các lỗi này cho phép kẻ tấn công chưa được xác thực thực thi mã tùy ý trên máy chủ chạy PHP trong những điều kiện cụ thể. Bản phát hành này là kết quả của nỗ lực tiết lộ có phối hợp, vốn bị gián đoạn một phần do việc rò rỉ sớm các định danh lỗ hổng.

Chuyện gì đã xảy ra

Các bản phát hành cập nhật vá lỗi CVE-2026-109618 và CVE-2026-109619, cả hai đều có mức độ nghiêm trọng cao. Lỗ hổng đầu tiên liên quan đến việc thực thi mã từ xa thông qua hỏng bộ nhớ khi hết bộ nhớ (OOM). Nếu một yêu cầu chạm tới giới hạn bộ nhớ của PHP vào đúng thời điểm, engine có thể để lại dữ liệu nội bộ khởi tạo chưa hoàn chỉnh trong bộ nhớ. Các thao tác sau đó có thể coi dữ liệu này là hợp lệ, dẫn đến hỏng bộ nhớ. Trên Apache với mod_php, một yêu cầu chưa được xác thực có thể kích hoạt vấn đề này trước khi bất kỳ mã ứng dụng nào chạy, cho phép thực thi mã từ xa toàn diện ngay cả với cấu hình mặc định. Các nhà nghiên cứu cũng đã xác nhận các đường khai thác thông qua PHP-FPM bằng mã ở cấp độ ứng dụng.

Lỗ hổng thứ hai bắt nguồn từ cách xử lý trạng thái toàn cục cũ. Một lỗi nghiêm trọng (fatal error) xảy ra tại một điểm cụ thể có thể để lại các con trỏ nội bộ tham chiếu đến bộ nhớ đã được giải phóng từ yêu cầu trước đó. Các yêu cầu tiếp theo được xử lý bởi cùng một tiến trình worker có thể truy cập vào vùng bộ nhớ đã giải phóng này, dẫn đến lỗi use-after-free, làm sập worker và tiềm ẩn nguy cơ thực thi mã từ xa. Vấn đề này đã được chứng minh trên các ứng dụng thực tế chạy trên Apache với mod_php. Cả hai sự cố đều nằm trong các thành phần cốt lõi được hầu hết mọi yêu cầu sử dụng, khiến chúng đặc biệt nguy hiểm và khó sửa chữa mà không ảnh hưởng đến hiệu suất hoặc phá vỡ tính tương thích với các extension bên thứ ba.

Cơ chế hoạt động

Những lỗ hổng này khai thác các khía cạnh cơ bản trong hệ thống quản lý bộ nhớ và xử lý lỗi của PHP. Trong kịch bản OOM, engine thất bại trong việc đặt lại sạch sẽ trạng thái nội bộ khi đạt tới giới hạn bộ nhớ. Thay vì dừng lại an toàn, nó để lại các cấu trúc bị hỏng mà các thao tác sau đó hiểu nhầm là dữ liệu hợp lệ. Điều này cho phép kẻ tấn công thao túng bố cục bộ nhớ bằng cách kích hoạt tình trạng cạn kiệt bộ nhớ tại các điểm chiến lược, cuối cùng giành quyền kiểm soát luồng thực thi.

Vấn đề trạng thái toàn cục cũ nảy sinh từ cách PHP quản lý tài nguyên giữa nhiều yêu cầu trong cùng một tiến trình worker. Khi một lỗi nghiêm trọng xảy ra, các quy trình dọn dẹp có thể không vô hiệu hóa hoàn toàn các con trỏ trỏ tới bộ nhớ đã được cấp phát trước đó. Nếu một yêu cầu mới tái sử dụng các con trỏ treo (dangling pointers) này, nó sẽ truy cập vào các vùng bộ nhớ không hợp lệ. Kẻ tấn công có thể thiết kế các chuỗi yêu cầu để kích hoạt những lỗi này và sau đó khai thác sự nhầm lẫn bộ nhớ resulting để chèn và thực thi mã độc. Vì các cơ chế này là trung tâm trong hoạt động của PHP, việc sửa chữa chúng đòi hỏi sự cân nhắc kỹ lưỡng giữa an toàn, hiệu suất và tính tương thích ngược.

Chi tiết chính

• Phiên bản bị ảnh hưởng: PHP 8.5.12, 8.4.27, 8.3.36 và 8.2.35 chứa các bản sửa lỗi; các phiên bản cũ hơn không còn được hỗ trợ vẫn dễ bị tổn thương.
• CVE-2026-109618: Thực thi mã từ xa thông qua hỏng bộ nhớ khi hết bộ nhớ, có thể khai thác trên Apache/mod_php mà không cần xác thực.
• CVE-2026-109619: Thực thi mã từ xa thông qua trạng thái toàn cục cũ và use-after-free, đã được xác nhận trên Apache/mod_php.
• Gián đoạn tiết lộ: ID CVE bị rò rỉ vào ngày 20 tháng 10, thúc đẩy lịch trình phát hành tăng tốc từ ngày 22 tháng 10 lên ngày 21 tháng 10.
• Người đóng góp nghiên cứu: Calif, OpenAI, Wiz và Trail of Bits đã xác định và báo cáo các lỗ hổng thông qua các kênh tiết lộ có trách nhiệm.
• Lịch sử nguyên nhân gốc rễ: Vấn đề OOM ban đầu được đưa ra giả thuyết vào năm 2024 nhưng thiếu vector khai thác cụ thể cho đến khi nghiên cứu hỗ trợ bởi AI gần đây làm rõ đường tấn công.

Tại sao điều này quan trọng

Đối với các đội ngũ duy trì ứng dụng PHP, những lỗ hổng này đại diện cho rủi ro đáng kể vì chúng có thể được kích hoạt mà không cần xác thực và ảnh hưởng đến hành vi của engine cốt lõi. Việc khai thác khả thi trên các cấu hình mặc định có nghĩa là nhiều môi trường sản xuất đang bị phơi nhiễm cho đến khi được vá. Sự phức tạp của các bản sửa lỗi nhấn mạnh nợ kỹ thuật tích lũy trong các dự án lâu đời như PHP, nơi thay đổi logic quản lý bộ nhớ có nguy cơ phá vỡ vô số extension bên thứ ba và ứng dụng hiện có.

Sự cố này cũng nêu bật bối cảnh đang thay đổi của nghiên cứu bảo mật phần mềm. Các công cụ hỗ trợ bởi AI đã đóng vai trò lớn trong việc xác định và xác thực các lỗ hổng này, đẩy nhanh quá trình khám phá so với kiểm toán thủ công truyền thống. Tuy nhiên, chính công nghệ này làm tăng khối lượng báo cáo mà các đội bảo mật phải phân loại, bao gồm nhiều submission không hợp lệ hoặc trùng lặp. Các khoản đầu tư gần đây của PHP Foundation vào nhân sự bảo mật chuyên nghiệp và công cụ tự động là rất quan trọng trong việc quản lý dòng chảy này và cung cấp các bản vá kịp thời, chứng minh nhu cầu về tài trợ bền vững cho bảo mật hạ tầng mã nguồn mở.

Bạn có thể làm gì

• Cập nhật các cài đặt PHP của bạn lên phiên bản 8.5.12, 8.4.27, 8.3.36 hoặc 8.2.35 ngay lập tức tùy thuộc vào nhánh hiện tại của bạn.
• Xác minh rằng pipeline triển khai của bạn có thể tự động tải các phiên bản cập nhật này từ trình quản lý gói hoặc kho lưu trữ phân phối của bạn.
• Xem xét nhật ký máy chủ để tìm các sự kiện cạn kiệt bộ nhớ bất thường hoặc lỗi nghiêm trọng có thể chỉ ra nỗ lực khai thác trước khi vá.
• Cân nhắc tài trợ cho PHP Foundation nếu tổ chức của bạn phụ thuộc vào PHP, vì công việc của họ trực tiếp hỗ trợ bảo mật và ổn định của hệ sinh thái.
• Theo dõi các kênh chính thức của PHP để biết thêm các khuyến nghị, vì vụ rò rỉ gần đây có thể đã đẩy nhanh sự phát triển của các proof-of-concept exploits công khai.
• Đánh giá việc sử dụng mod_php so với PHP-FPM, vì các vector tấn công khác nhau đôi chút giữa các cấu hình này, mặc dù cả hai đều bị ảnh hưởng.