PHP Group PHP: use-after-free trong trạng thái toàn cục cho phép thực thi mã từ xa

Lưu ý: Dữ liệu này chỉ có tính chất tham khảo, phục vụ nghiên cứu an ninh mạng.CyStack khuyến nghị người dùng không sử dụng các thông tin này nhằm các mục đích bất hợp pháp

Lỗ hổng CVE-2026-109619 là gì?

Lỗ hổng CVE-2026-109619 là lỗ hổng thuộc các loại Use After Free, Improper Handling of Exceptional Conditions, Access of Uninitialized Pointer và 2 loại khác, ảnh hưởng tới PHP (phiên bản bị ảnh hưởng: 8.2.* – < 8.2.35, 8.3.* – < 8.3.36 và các phiên bản bị ảnh hưởng khác). Lỗ hổng này được xếp hạng ở mức Nghiêm trọng, với điểm CVSS 9.2. Các nguồn hiện có chưa ghi nhận lỗ hổng này bị khai thác.

Giới thiệu chung

Dữ liệu gốc

PHP có nhiều trạng thái toàn cục tạm thời trỏ vào bộ nhớ của request. Trong một số tình huống, trạng thái toàn cục có thể không được đặt lại đúng cách hoặc có thể được nạp lại sau khi đã được đặt lại. Khi đó, trạng thái toàn cục có thể vẫn tham chiếu đến bộ nhớ của request ngay cả sau khi bộ nhớ đó đã được giải phóng. Các request tiếp theo có thể đọc hoặc rẽ nhánh dựa trên trạng thái cũ này trước khi trạng thái được khởi tạo đầy đủ. Nhiều chiến lược có thể kích hoạt điều kiện này và dẫn đến thực thi mã từ xa (RCE).

Sản phẩm và phạm vi ảnh hưởng

PHP Group PHP package php-src có defaultStatus là unaffected ngoài các phạm vi được liệt kê. Các nhánh bị ảnh hưởng và mốc đã sửa là:

  • Nhánh 8.2.*: bị ảnh hưởng khi nhỏ hơn 8.2.35; bản sửa được liệt kê là 8.2.35.
  • Nhánh 8.3.*: bị ảnh hưởng khi nhỏ hơn 8.3.36; bản sửa được liệt kê là 8.3.36.
  • Nhánh 8.4.*: bị ảnh hưởng khi nhỏ hơn 8.4.27; bản sửa được liệt kê là 8.4.27.
  • Nhánh 8.5.*: bị ảnh hưởng khi nhỏ hơn 8.5.12; bản sửa được liệt kê là 8.5.12.

Các nhánh song song hoặc phát hành ngoài những phạm vi này không được suy diễn thêm từ việc một nhánh đã có bản sửa.

Chi tiết kỹ thuật

PHP duy trì một số trạng thái toàn cục, gồm trạng thái lỗi, session, object và extension, trong worker nhưng các trạng thái này có thể trỏ đến bộ nhớ thuộc về một request. Một thao tác producer có thể công bố trạng thái do request sở hữu, sau đó không đặt lại trạng thái hoặc vô tình nạp lại trạng thái sau khi đã reset. Khi request kết thúc, heap của request được giải phóng nhưng worker vẫn giữ tham chiếu cũ; một request tiếp theo được xử lý bởi cùng worker có thể trở thành consumer và đọc, giải phóng, rẽ nhánh hoặc thực hiện thao tác khác trên trạng thái lỗi thời trước khi quá trình khởi tạo request thông thường thay thế nó.

Các điều kiện producer đã được mô tả gồm fatal error, lỗi do cạn kiệt bộ nhớ, lỗi parse hoặc compile, lỗi uncaught, lỗi require, timeout thực thi và một số chẩn đoán phát sinh trong giai đoạn cleanup. Consumer đã được xác nhận gồm chẩn đoán INI trước khi khởi tạo request và session upload progress trước khi session được khởi tạo thông thường. Với Apache mod_php, cấu hình .htaccess và các giá trị php_value, php_flag hoặc php_admin_* có thể được áp dụng sớm; với FPM, đường khai thác phụ thuộc vào các tham số PHP_VALUE hoặc PHP_ADMIN_VALUE do frontend gửi và vào hoạt động của ứng dụng. Khả năng bị ảnh hưởng của các nhóm trạng thái khác phụ thuộc vào ứng dụng, extension và thời điểm trạng thái được công bố.

Khả năng khai thác

Lỗ hổng có thể bị khai thác qua mạng, không yêu cầu quyền trước hoặc tương tác của người dùng, nhưng cần các điều kiện triển khai và lifecycle cụ thể. Request producer và request consumer phải được xử lý bởi cùng một worker; nhiều worker hoặc worker recycling làm giảm xác suất thành công trên từng request nhưng không loại bỏ điều kiện này.

Advisory xác nhận RCE qua đường fatal_error_backtraces trên mod_php, đồng thời xác nhận đường session upload progress trên mod_php và FPM. Đường FPM đã xác nhận yêu cầu trạng thái được công bố trong quá trình thực thi ứng dụng sau khi startup thành công, sau đó một fatal error và một request tiếp theo sử dụng session upload progress. Bản ghi được cung cấp không xác định public exploit; phần enrichment hiện tại cũng ghi nhận trạng thái exploitation là none, nhưng điều đó không chứng minh rằng việc khai thác là không thể.

Tác động kỹ thuật

Kết quả kỹ thuật đã được xác nhận gồm heap use-after-free không cần xác thực, memory disclosure và RCE với quyền của web worker. Đường fatal_error_backtraces đã cho thấy RCE trên mod_php; đường session lifecycle đã được kiểm chứng trên cả mod_php và FPM. Các nhóm trạng thái lỗi, exception, object hoặc extension khác chỉ được xác định là có security impact khi chứng minh được producer và consumer cụ thể.

Attacker vẫn cần tạo được producer, giải phóng request memory, khiến cùng worker xử lý request tiếp theo và chạm tới consumer trước khi khởi tạo request hoàn tất. Vì vậy, không phải mọi triển khai hoặc mọi route đều có cùng khả năng khai thác, nhưng việc không quan sát thấy lỗi trong log không loại trừ rủi ro. Nếu RCE thành công, attacker có thể đạt quyền của worker và tác động đến dữ liệu, mã ứng dụng hoặc tài nguyên mà tài khoản đó được phép truy cập.

Tác động đến tổ chức

Khai thác thành công có thể cho phép attacker chưa xác thực thực thi mã với quyền của web worker, đọc dữ liệu từ heap hoặc làm sai lệch hoạt động của tiến trình PHP. RCE có thể dẫn đến truy cập hoặc thay đổi dữ liệu mà worker được phép truy cập, nhưng phạm vi thực tế vẫn bị giới hạn bởi quyền của worker và cấu hình hệ thống. Lỗi cũng có thể làm suy giảm tính sẵn sàng nếu trạng thái heap hoặc tiến trình bị tác động. Nhiều worker và việc recycle worker chỉ làm giảm xác suất thành công trên mỗi request, không loại bỏ rủi ro.

Cách khắc phục

  1. Nâng cấp từng nhánh bị ảnh hưởng lên đúng bản sửa tương ứng: 8.2.35, 8.3.36, 8.4.27 hoặc 8.5.12. Đây là biện pháp đáng tin cậy duy nhất theo advisory vì bản sửa đặt lại đầy đủ trạng thái toàn cục.
  2. Nếu chưa thể cập nhật trên PHP 8.5, đặt fatal_error_backtraces=0 trong cấu hình quản trị và restart mọi worker. Biện pháp này loại bỏ producer được dùng trong đường RCE đã xác nhận, nhưng không xử lý các trạng thái request-owned khác.
  3. Nếu chưa thể cập nhật và không cần session upload progress, đặt session.upload_progress.enabled=0 và restart mọi worker. Biện pháp này ngăn đường producer và consumer của session đã được chứng minh, nhưng không giảm thiểu các lifecycle path khác.
  4. Loại bỏ fatal error, warning và diagnostic trên các đường request attacker có thể tiếp cận, gồm upload, import, error page, shutdown, destructor, serialization, output handler, plugin và extension path. Ưu tiên cấu hình php.ini, FPM pool hoặc server tại startup thay cho override theo request và loại bỏ directive lỗi thời.
  5. Nếu phù hợp với yêu cầu hiệu năng, cân nhắc giới hạn số request mỗi worker bằng pm.max_requests=1. Không xem việc thay đổi execution time limit là bản vá đầy đủ; nó chỉ loại bỏ một dạng interruption có thể xảy ra.
  6. Sau khi thay đổi cấu hình, restart toàn bộ worker liên quan và xác minh lại inventory, cấu hình, log cùng application flow.

Cách phát hiện

  1. Kiểm kê mọi triển khai PHP và xác định worker model, đặc biệt là Apache mod_php, FPM và LSAPI; đối chiếu package php-src với các nhánh và mốc sửa lỗi trong phần affected_summary.
  2. Rà soát các thiết lập có thể tạo chẩn đoán trước khi khởi tạo request, gồm cấu hình .htaccess, PHP_VALUE, PHP_ADMIN_VALUE, các thiết lập INI áp dụng theo request và những giá trị INI không hợp lệ, lỗi thời hoặc xung đột.
  3. Kiểm tra fatal_error_backtraces và session.upload_progress.enabled, đồng thời xác định các route có thể kích hoạt upload, lỗi fatal, timeout, callback, plugin hoặc extension behavior.
  4. Trong một đợt audit cô lập, bật log_errors=On, dùng error_reporting=E_ALL và bảo đảm error_log hoạt động. Rà soát log Apache, PHP-FPM, reverse proxy và service để tìm warning, deprecation, core error, fatal hoặc uncaught error, lỗi parse, Maximum execution time exceeded và lỗi chỉ xảy ra trên các route hoặc loại nội dung do attacker kiểm soát.
  5. Dùng log để bổ sung cho inventory, static configuration audit và application-flow audit. Không xem việc không có log lỗi là bằng chứng hệ thống an toàn, vì lỗi có thể xảy ra trước khi được ghi hoặc các mức log liên quan có thể đã bị loại bỏ.
Nguồn (5)
Tìm hiểu thêm

Kiểm tra chuyên sâu cùng giải pháp quản lý rủi ro Web toàn diện

Giải pháp CyStack VulnScan liên tục phát hiện tài sản, xác minh lỗ hổng và giúp đội ngũ bảo mật ưu tiên khắc phục cho toàn bộ doanh nghiệp.

Khám phá các giải pháp khác liên quan