22/10 – “Bug Day”: PHP vừa vá hai lỗi Critical, Node.js công bố 10 CVE

Đợt cập nhật của PHP xử lý CVE-2026-109618 và CVE-2026-109619, đều được dự án xếp mức Critical. Theo cảnh báo chính thức, hai lỗ hổng có thể tạo điều kiện cho kẻ tấn công thực thi mã trên máy chủ từ xa mà không cần đăng nhập, khi điều kiện khai thác phù hợp. PHP đã phát hành các phiên bản sửa lỗi 8.2.35, 8.3.36, 8.4.27 và 8.5.12; các hệ thống đang vận hành PHP cần ưu tiên cập nhật theo nhánh hỗ trợ hoặc hướng dẫn của nhà cung cấp bản phân phối. [5]

Node.js cũng phát hành ba phiên bản bảo mật trong ngày 21/10: 22.23.4 cho nhánh 22 LTS, 24.22.1 cho nhánh 24 LTS và 26.12.1 cho nhánh 26 Current. Thông báo của dự án liệt kê tổng cộng 10 CVE, gồm bốn High, ba Medium và ba Low. Không có cơ sở để kết luận hai sự cố của PHP và Node.js có liên hệ kỹ thuật với nhau; điểm chung là chúng đều nằm ở lớp nền tảng mà nhiều ứng dụng web dựa vào để vận hành. [1][2][3][4]

Trong bốn lỗ hổng High, CVE-2026-111497 gây chú ý vì liên quan đến bộ giải mã Brotli. Lỗi ghi vượt ranh giới bộ nhớ (out-of-bounds write) có thể dẫn đến thực thi mã từ xa (RCE). Brotli là thuật toán nén dữ liệu thường gặp trong các hệ thống web; mức độ rủi ro đối với từng ứng dụng phụ thuộc vào việc đường xử lý của ứng dụng có tiếp nhận dữ liệu nén không đáng tin cậy và kích hoạt thành phần bị ảnh hưởng hay không. Khả năng RCE mà dự án xác nhận không đồng nghĩa đã có bằng chứng khai thác thành công trên diện rộng. [1]

Ba lỗi High còn lại nằm ở DNS và TLS: CVE-2026-105482 liên quan đến cách dns.resolve xử lý tên miền chứa ký tự NUL; CVE-2026-105483 và CVE-2026-106069 liên quan đến việc xác minh tên máy chủ trên chứng chỉ TLS khi địa chỉ IP được biểu diễn không chuẩn. Các lỗi này không có cùng cơ chế với Brotli, nhưng đều đáng quan tâm đối với dịch vụ kết nối tới hệ thống bên ngoài và dựa vào TLS để xác thực đầu mối kết nối. [1]

Nhóm Medium gồm CVE-2026-105481 (xử lý phản hồi HTTP trên kết nối keep-alive), CVE-2026-106072 (xác thực chứng chỉ cho dạng địa chỉ IPv4 không chuẩn) và CVE-2026-106074 (bộ nhớ đệm entropy của crypto.randomUUID() và randomInt() trong một số trường hợp sử dụng startup snapshot hoặc Single Executable Application). Ba lỗi Low gồm CVE-2026-106070 về xác thực header ZIP, CVE-2026-106071 về cấp quyền quá rộng trong Permission Model và CVE-2026-106073 về kiểm tra quyền khi dùng fs.realpathSync. Mức độ ảnh hưởng phụ thuộc phiên bản và tính năng thực tế được dùng. [1]

Theo danh sách ảnh hưởng của Node.js, nhánh 22.x có 7 CVE trong đợt này, 24.x có 8 CVE và 26.x có đủ 10 CVE. Phiên bản cần hướng tới lần lượt là 22.23.4, 24.22.1 và 26.12.1 hoặc bản sửa lỗi mới hơn thuộc nhánh được hỗ trợ. Trong đó, Node.js 26 có thêm hai lỗi Low chỉ được liệt kê cho nhánh 26.x. [1][2][3][4]

Những hệ thống còn chạy Node.js 20 hoặc 25 phải được xem xét theo hướng nâng cấp nhánh, không chỉ chờ một bản vá nhỏ: hai nhánh này đã hết vòng đời hỗ trợ chính thức với bản cập nhật cuối cùng lần lượt vào ngày 24/3 và 31/3/2026. Việc phần mềm vẫn hoạt động ổn định không có nghĩa là runtime vẫn nhận được bản sửa lỗi bảo mật. [6]

Một công ty có thể sử dụng Node.js để chạy API, dịch vụ đăng nhập, quy trình xử lý đơn hàng hoặc tác vụ nền, trong khi PHP vẫn vận hành website giới thiệu, WordPress hay một hệ thống quản trị cũ. Người dùng có thể không hề nhìn thấy những lớp công nghệ này. Nhưng nếu một lỗ hổng bị khai thác, hệ quả kinh doanh có thể là gián đoạn dịch vụ, rò rỉ dữ liệu hoặc chi phí khôi phục cao hơn nhiều so với việc cập nhật có kế hoạch.

Rủi ro cũng không được quyết định đơn giản bằng việc repository có chứa JavaScript hoặc PHP. Một website tĩnh được build bằng Node.js có bề mặt tấn công khác với API Node.js tiếp nhận dữ liệu trực tiếp từ Internet. Ngược lại, container production, máy chủ server-side rendering, tác vụ định kỳ và phần mềm bên thứ ba có thể đang dùng runtime cũ dù mã nguồn ứng dụng và các gói npm đã được cập nhật.

Việc đầu tiên là xác định phiên bản runtime đang thực sự chạy trên production, không chỉ phiên bản trên máy lập trình viên. Với Node.js, cần kiểm tra tiến trình và image container, đối chiếu nhánh đang dùng với 22.23.4, 24.22.1 hoặc 26.12.1 và nâng cấp bản tương ứng sau khi kiểm tra tương thích. Với PHP, cần đối chiếu 8.2.35, 8.3.36, 8.4.27 hoặc 8.5.12, đồng thời làm việc với nhà cung cấp hosting nếu việc cập nhật không thuộc quyền quản trị trực tiếp của doanh nghiệp. [1][5]

Sau khi vá, cần triển khai lại workload, xác minh phiên bản mới thực sự được nạp, chạy kiểm thử các luồng quan trọng như đăng nhập và giao dịch, theo dõi lỗi bất thường và chuẩn bị phương án khôi phục khi phát sinh vấn đề tương thích. Đặc biệt, cập nhật các gói npm bằng npm update không tự động cập nhật binary Node.js đang chạy. Trách nhiệm cuối cùng thuộc về quy trình vận hành, không thuộc về một lệnh cài đặt duy nhất.

Đối với các hệ thống có thể tiếp nhận dữ liệu nén từ bên ngoài, nên ưu tiên rà soát luồng giải nén liên quan Brotli. Đối với dịch vụ PHP công khai trên Internet, cảnh báo từ PHP nhấn mạnh rằng các biện pháp giảm thiểu tạm thời không thay thế được bản vá đầy đủ. Khi chưa thể cập nhật, doanh nghiệp phải đánh giá phương án giảm mức phơi nhiễm và thời hạn khắc phục theo mức độ quan trọng của dịch vụ. [1][5]

“Bug Day” không phải ngày lễ chính thức và cũng chẳng có quy luật nào khiến lỗi bảo mật cứ đến 22/10 là xuất hiện. Đây chỉ là cách Automize gọi vui sự trùng hợp của đợt công bố năm 2026. Việc dự án nguồn mở tìm ra, công bố và sửa lỗ hổng là một hoạt động có trách nhiệm; đếm số CVE rồi kết luận chất lượng phần mềm đang đi xuống sẽ là cách đọc quá đơn giản.

Nếu muốn giữ ngày 22/10 hằng năm làm “Bug Day”, có lẽ cách kỷ niệm thiết thực nhất là mở lại danh sách hệ thống đang vận hành: phiên bản nào đã hết hỗ trợ, ai chịu trách nhiệm cập nhật, và bản vá cuối cùng đã thực sự tới production hay chưa. Không cần bánh kem cho ngày này. Một bản kiểm kê runtime chính xác và quy trình vá lỗi có kiểm chứng sẽ hữu ích hơn nhiều.