Lỗ hổng Node.js: bản vá Node2Shell và cách kiểm tra phiên bản Node.js (WordPress)

Thông báo tiếp thị liên kết Ver 3.1
Thông báo tiếp thị liên kết Ver 3.2 (chỉ trên di động)
Môi trường thử nghiệm Họ RHELAlmaLinux 9.8Nginx + Apache · WordPress 7.1.3Kiểm tra ngày 2026-10-23

Node2Shell là biệt danh của CVE-2026-111497, lỗ hổng Node.js có bản vá được công bố ngày 21 tháng 10 năm 2026; tiêu đề chính thức mô tả lỗi ghi ngoài giới hạn trong bộ giải mã Brotli của Google. Vì việc giải nén dữ liệu Brotli bị chế tác có thể dẫn đến thực thi mã từ xa, việc đầu tiên là kiểm tra phiên bản Node.js, Bun và libbrotli trên server của bạn rồi nâng lên phiên bản đã vá.

Đây là quá trình kiểm tra các gói dùng bộ giải mã Brotli và đường đi mà yêu cầu từ xa của WordPress đi qua libbrotli, trên một server cấu hình Nginx + Apache chạy WordPress 7.1.3.

1️⃣ Lỗ hổng Node.js Node2Shell: cơ chế lỗi và phạm vi ảnh hưởng

Cái tên Node2Shell là biệt danh do nhóm nghiên cứu của công ty bảo mật Imperva đặt trong bài nghiên cứu ngày 22 tháng 10. Tiêu đề thông báo của nodejs.org là [Brotli decoder out-of-bounds write permits remote code execution]. Lỗi nằm trong mã nguồn bộ giải mã Google Brotli được tích hợp sẵn trong Node.js (c/dec/decode.c), nên sửa mã ứng dụng cũng không chặn được.

Theo bản ghi của NVD, bộ giải mã Google Brotli 1.0.3 đến 1.2.0 ghi vượt quá cuối bộ đệm khi giải nén một luồng nén bị chế tác, làm hỏng vùng nhớ trạng thái liền kề của bộ giải mã. Kẻ tấn công từ xa không cần đăng nhập có thể lợi dụng lỗi này để đọc nội dung bộ nhớ server, làm gián đoạn dịch vụ và thực thi mã tùy ý.

Có hai mức đánh giá độ nghiêm trọng. Thông báo của nodejs.org xếp mức High, còn Google, bên phát hành CVE, chấm 9,2 điểm (Critical) theo CVSS 4.0. Tính đến ngày 23 tháng 10, NVD chưa hoàn tất phân tích riêng nên chưa có điểm NVD. Loại điểm yếu là không kiểm tra giá trị trả về (CWE-252) và ghi ngoài giới hạn (CWE-787).

Theo thông báo bảo mật của nodejs.org, tất cả các dòng Node.js còn được hỗ trợ (22.x, 24.x và 26.x) đều bị ảnh hưởng, và phiên bản đã vá là 22.23.4, 24.22.1 và 26.12.1. Cùng thông báo đó cho biết các dòng đã hết hỗ trợ luôn được coi là bị ảnh hưởng mỗi khi có thông báo bảo mật.

Mọi chương trình dùng cùng bộ giải mã đều bị ảnh hưởng, kể cả ngoài Node.js. Ngày 21 tháng 10, Google phát hành ba phiên bản thư viện Brotli sửa cùng CVE này: 1.0.10, 1.1.1 và 1.2.1. Bun đưa Brotli vào danh sách bản sửa bảo mật trong thông báo phiên bản 1.4.4 ngày 22 tháng 10, và một issue trong kho mã cho biết phiên bản đó có bản sửa cập nhật brotli.

đíchPhiên bản bị ảnh hưởngPhiên bản đã váNguồn
Node.jsTất cả dòng còn hỗ trợ 22.x · 24.x · 26.x · các dòng đã hết hỗ trợ22.23.4 · 24.22.1 · 26.12.1Thông báo bảo mật của nodejs.org (2026-10-21)
Thư viện Brotli của Google1.0.3 ~ 1.2.01.0.10 · 1.1.1 · 1.2.1Bản ghi NVD · bản phát hành google/brotli (2026-10-21)
BunBrotli trong danh sách bản sửa bảo mật của thông báo 1.4.41.4.4Thông báo của Bun (2026-10-22)
Gói libbrotli của bản phân phốiCác gói xây dựng từ Brotli 1.0.3 đến 1.2.0Phiên bản do thông báo bảo mật của bản phân phối đưa ra (tính đến 2026-10-23 chưa có)Trang theo dõi bảo mật của từng bản phân phối

Bản thân Node.js không tự giải nén dữ liệu Brotli nhận được. Theo thông báo bảo mật của công ty hosting Vercel, điểm bị lộ là nơi ứng dụng hoặc thư viện giải nén dữ liệu nén đến từ bên ngoài. Ví dụ là khi fetch() tích hợp nhận phản hồi br và khi Express 5 hoặc body-parser 2 giải nén phần thân yêu cầu br; server HTTP mặc định chỉ nhận dữ liệu thì không giải nén.

Tính đến ngày 23 tháng 10, chưa có xác nhận nào về việc bị khai thác thực tế. CVE này không có trong danh mục lỗ hổng đã biết bị khai thác của CISA (KEV, phiên bản ngày 21 tháng 10). Mức khai thác mà CISA gán trong bản ghi CVE đã đổi thành [công bố bằng chứng khái niệm (PoC)] vào ngày 23 tháng 10.

Bộ giải mã nằm ở đâu sẽ quyết định việc cần làm. Bản nhị phân chính thức của Node.js tích hợp bộ giải mã ngay trong tệp thực thi, và cũng có bản build dùng libbrotli của hệ thống, như gói nodejs của Debian. Các bản phân phối Linux cài cùng mã nguồn này dưới dạng gói libbrotli để các chương trình như curl dùng chung.

2️⃣ Website WordPress và PHP cũng bị ảnh hưởng: đường đi mà yêu cầu từ xa giải nén phản hồi bằng libbrotli

Ngay cả server WordPress không cài Node.js cũng có cùng bộ giải mã dưới dạng gói libbrotli. Tính đến ngày 23 tháng 10, phía WordPress, curl và PHP chưa có phát biểu chính thức nào về CVE này, và CVE này cũng không có trong danh sách lỗ hổng chính thức của curl. Vì vậy chương này chỉ xác nhận cấu trúc qua mã lõi, tài liệu curl và đo đạc trên server thử nghiệm.

Trên server cấu hình Nginx + Apache đã đo, có năm gói cần thư viện giải mã (libbrotlidec), và gói nối với WordPress là libcurl.

rpm -q --whatrequires 'libbrotlidec.so.1()(64bit)' | sed 's/-[0-9].*//'
freetype
brotli-devel
libjxl
libcurl
libsoup

libcurl cần libbrotli để giải nén phản hồi HTTP đã nén. Theo tài liệu chính thức của curl, libcurl được build kèm thư viện brotli sẽ tự động giải nén phản hồi có Content-Encoding là br. Phần mở rộng curl của PHP gọi thẳng libcurl đó.

ldd /usr/lib64/libcurl.so.4 | grep brotli
    libbrotlidec.so.1 => /lib64/libbrotlidec.so.1 (0x00007f32803ed000)
    libbrotlicommon.so.1 => /lib64/libbrotlicommon.so.1 (0x00007f327f858000)
php -i | grep BROTLI
BROTLI => Yes

Phiên bản libcurl mà WordPress dùng hiện ở dòng [Phiên bản cURL] khi bạn mở mục [Máy chủ] trong tab [Thông tin] của [Công cụ › Tình trạng website] trên trang quản trị. Dòng đó không cho biết có hỗ trợ brotli hay không, nên hãy kiểm tra bằng lệnh trên server như ở trên.

Màn hình tab Thông tin của Tình trạng website: menu bên trái Công cụ › Tình trạng website và các dòng Kiến trúc máy chủ, Máy chủ web, Phiên bản PHP, PHP SAPI, Phiên bản cURL trong mục Máy chủ — kiểm tra phiên bản libcurl, đường đi phía WordPress của lỗ hổng Node.js Node2Shell, ở dòng Phiên bản cURL (WordPress 7.1.3)

Dòng [Phiên bản cURL] trong hình hiển thị phiên bản libcurl cùng thư viện SSL được build kèm. Theo tài liệu curl, br được hỗ trợ từ 7.57.0, nên nếu giá trị này thấp hơn thì không giải nén được phản hồi br. Nếu bằng hoặc cao hơn, hãy kiểm tra bằng lệnh trên server xem bản build có brotli hay không.

Thư viện Requests trong lõi WordPress đặt giá trị [CURLOPT_ENCODING] của handle curl thành chuỗi rỗng khi gửi yêu cầu tới địa chỉ bên ngoài. Theo tài liệu curl, chuỗi rỗng nghĩa là chấp nhận mọi phương thức nén mà libcurl đó hỗ trợ. Vì vậy, nếu server bên kia gửi phản hồi nén bằng br, libbrotli của server WordPress sẽ giải nén nó.

grep -n CURLOPT_ENCODING wp-includes/Requests/src/Transport/Curl.php
110:            curl_setopt($this->handle, CURLOPT_ENCODING, '');
212:            curl_setopt($this->handle, CURLOPT_ENCODING, 'none');

Dòng 110 là giá trị mặc định cho mọi yêu cầu, còn dòng 212 chỉ chạy khi một yêu cầu giải nén thất bại được gửi lại không nén. Không có cách tấn công trực tiếp từ bên ngoài; server mà WordPress nhận phản hồi, như khi kiểm tra cập nhật lõi và plugin, oEmbed hay nguồn cấp RSS, phải bị chiếm quyền trước.

🧩 Luồng tấn công Node2Shell
Sơ đồ giải thích
①Dữ liệu nén đến từ bên ngoàiPhần thân yêu cầu nén bằng br hoặc phản hồi từ server khác
②Ứng dụng giải nén bằng bộ giải mã BrotliNode.js fetch() · Express 5 · Bun fetch() · WordPress qua libcurl → libbrotli
③Lỗi bộ giải mã BrotliLuồng bị chế tác ghi vượt quá cuối bộ đệmCVE-2026-111497
④Thực thi mã trên máy chủRò rỉ bộ nhớ · gián đoạn dịch vụ · chiếm quyền server
✅ Các phiên bản đã vá chặn luồng nàyNode.js 22.23.4 · 24.22.1 · 26.12.1Bun 1.4.4Brotli 1.0.10 · 1.1.1 · 1.2.1

Luồng bắt đầu từ dữ liệu nén br đến từ bên ngoài. Lỗi bị kích hoạt ở bước fetch() của Node.js, Express 5, fetch() của Bun hoặc libbrotli do libcurl của WordPress gọi giải nén dữ liệu đó. Kết quả dẫn đến thực thi mã trên server. Phiên bản đã vá chặn luồng này, nên việc cần làm là thay bộ giải mã bằng phiên bản đã vá.

mod_brotli của Apache chỉ liên kết thư viện bộ mã hóa (libbrotlienc) dùng để nén phản hồi, nên cấu hình bật nén bằng module này không nằm trên đường đi của lỗi bộ giải mã.

ldd /usr/lib64/httpd/modules/mod_brotli.so | grep brotli
    libbrotlienc.so.1 => /lib64/libbrotlienc.so.1 (0x00007f34b4b79000)
    libbrotlicommon.so.1 => /lib64/libbrotlicommon.so.1 (0x00007f34b4a79000)

3️⃣ Kiểm tra phiên bản Node.js: server có Node.js, Bun và libbrotli hay không và phiên bản nào

Việc cần làm trước tiên là liệt kê những gì đã cài trên server. Với Node.js, xem phiên bản bằng [node -v]; nếu giá trị thấp hơn 22.23.4, 24.22.1 hoặc 26.12.1 theo dòng của nó thì bị ảnh hưởng.

Môi trường của bạnLệnh kiểm traChỗ được sửa
Bộ cài nodejs.org · nvm · image Docker chính thức[node -v]Chính Node.js (22.23.4 · 24.22.1 · 26.12.1)
nodejs của bản phân phối · có dòng libbrotli trong ldd[ldd $(command -v node)]Gói libbrotli
nodejs của bản phân phối · kết quả ldd là 0[ldd $(command -v node)]Gói nodejs (sau thông báo bảo mật của bản phân phối)
Node.js Selector trên shared hosting (CloudLinux alt-nodejs)Thông báo của nhà cung cấp · số release của góiGói do nhà cung cấp phát hành + khởi động lại ứng dụng
Bun[bun --version]Bun 1.4.4 trở lên
Không có Node.js (chỉ WordPress)Kiểm tra libcurl bằng [ldd]Gói libbrotli + khởi động lại php-fpm · trước đó dùng biện pháp tạm thời
Managed hostingThông báo của nhà cung cấp · hỏi hỗ trợGói do nhà cung cấp nâng cấp

Trên PC (Windows hoặc macOS), cài lại bằng bộ cài phiên bản đã vá từ nodejs.org; với nvm, xem phiên bản bằng [nvm ls] rồi cài lại theo số dòng, như [nvm install 24]. Các tag 22, 24 và 26 của image node chính thức trên Docker đã được build lại bằng phiên bản đã vá vào ngày 22 tháng 10, nên hãy tải lại image, build và triển khai. Thông báo của Vercel cũng khuyên nâng các image container tự build, môi trường CI và môi trường phát triển cục bộ lên phiên bản đã vá.

Server đã cài Node.js qua stream dnf module sẽ hiện phiên bản thuộc dòng của stream đó ở [node -v]; dù cùng dòng, nếu các chữ số cuối chưa tới phiên bản đã vá thì vẫn phải nâng lên.

node -v
v24.xx.x

Node.js dùng libbrotli của hệ thống hay bộ giải mã tích hợp thì kiểm tra bằng [ldd]. Nếu kết quả có dòng libbrotlidec, đó là bản build dùng thư viện dùng chung; nếu là 0 như bên dưới thì bộ giải mã được tích hợp sẵn, phải nâng chính Node.js mới sửa được.

ldd $(command -v node) | grep -c brotli
0

Với Bun, kiểm tra phiên bản bằng [bun --version] và nâng lên nếu thấp hơn 1.4.4.

Trên họ RPM, xem phiên bản gói libbrotli bằng [rpm -q libbrotli]. Số phiên bản gói do bản phân phối đặt nên không so trực tiếp với số phát hành của Google, mà so với phiên bản mà thông báo bảo mật của bản phân phối đưa ra cho số CVE này.

rpm -q libbrotli
libbrotli-1.0.x-x.el9_x.x86_64

Kiểm tra bản phân phối đã ra thông báo hay chưa bằng [dnf updateinfo info --cve CVE-2026-111497]. Nếu kết quả trống, kho đó chưa có thông báo cho CVE này.

dnf updateinfo info --cve CVE-2026-111497

Gói chỉ đưa bản sửa vào mà giữ nguyên số phiên bản sẽ để lại số CVE trong nhật ký thay đổi. Vì vậy hãy kiểm tra bằng [rpm -q --changelog libbrotli | grep CVE-2026-111497]; nếu có dòng hiện ra thì đó là gói đã vá.

rpm -q --changelog libbrotli | grep CVE-2026-111497

Tính đến ngày 23 tháng 10, gói libbrotli của Debian, Ubuntu, Red Hat và AlmaLinux vẫn chưa có phiên bản vá CVE này. Alpine mới chỉ có phiên bản đã vá cho gói nodejs; nguồn là trang theo dõi bảo mật của từng bản phân phối. Vì vậy lúc này thứ tự là theo dõi thông báo bảo mật của bản phân phối rồi nâng cấp khi thông báo ra.

Họ Debian và Ubuntu dùng tên gói libbrotli1, và các mục tương tự đã được kiểm tra trên một server thử nghiệm Debian 12 của một dịch vụ hosting được quản lý. Trên server này, libcurl cũng liên kết libbrotlidec và phần mở rộng curl của PHP hỗ trợ brotli. Nhật ký thay đổi xem bằng [zcat /usr/share/doc/libbrotli1/changelog.Debian.gz | grep CVE-2026-111497].

dpkg -l libbrotli1 | tail -1
ii  libbrotli1:amd64 1.1.0-2+0~20240305.8+debian12~1.gbp62df71 amd64        library implementing brotli encoder and decoder (shared libraries)
ldd /usr/lib/x86_64-linux-gnu/libcurl.so.4 | grep brotli
    libbrotlidec.so.1 => /lib/x86_64-linux-gnu/libbrotlidec.so.1 (0x00007fa2baac6000)
    libbrotlicommon.so.1 => /lib/x86_64-linux-gnu/libbrotlicommon.so.1 (0x00007fa2b9cb9000)

4️⃣ Cập nhật Node.js: nâng lên phiên bản đã vá rồi kiểm tra lại

Với hosting được quản lý và shared hosting, nhà cung cấp là bên nâng gói trên server, nên hãy xác nhận tình trạng vá của Node.js và libbrotli qua thông báo của nhà cung cấp hoặc hỏi hỗ trợ. Nếu tự vận hành server, hãy nâng Node.js lên phiên bản đã vá trong thông báo của nodejs.org, và Bun lên 1.4.4 trở lên bằng [bun upgrade].

Node.js cài qua stream module của bản phân phối được nâng bằng lệnh kiểu [dnf upgrade nodejs] sau khi phiên bản đã vá có trong kho đó. Server tải Node.js trực tiếp từ nodejs.org để cài thì thay bằng phiên bản đã vá từ cùng nơi đó. Các dòng đã hết hỗ trợ không có phiên bản vá, nên hãy chuyển sang dòng 22, 24 hoặc 26 đang được hỗ trợ.

Node.js Selector trên shared hosting (CloudLinux alt-nodejs) mang bản sao brotli riêng, nên nâng libbrotli của hệ thống cũng không sửa được. Theo thông báo của CloudLinux, phải chuyển sang gói do nhà cung cấp phát hành rồi khởi động lại ứng dụng thì bản nhị phân mới mới chạy. Cùng thông báo đó cho biết với phiên bản đã hết hỗ trợ, giá trị [node --version] vẫn giữ nguyên nên phải kiểm tra bằng số release của gói.

Với gói libbrotli, khi thông báo bảo mật của bản phân phối ra thì nâng gói đó lên, và phải khởi động lại các tiến trình đang nạp thư viện trong bộ nhớ thì mới chuyển sang thư viện mới. Thư viện dùng chung được đọc khi tiến trình khởi động, nên trên server WordPress, việc khởi động lại php-fpm là một phần của cùng bước này.

Sau khi nâng cấp, hãy xem [node -v] đã là phiên bản đã vá trở lên chưa và [rpm -q libbrotli] có đúng phiên bản trong thông báo của bản phân phối không. Kiểm tra số CVE đã có trong nhật ký thay đổi chưa bằng [rpm -q --changelog libbrotli | grep CVE-2026-111497]. Nếu đã khởi động lại php-fpm, hãy kiểm tra cả trạng thái dịch vụ và phản hồi của website.

systemctl is-active php-fpm
active
curl -s -o /dev/null -w '%{http_code}\n' 'https://example.com/?r=1'
200

5️⃣ Biện pháp tạm thời trước khi vá: tắt giải nén br trong yêu cầu từ xa của WordPress

Hướng dẫn CVE của Red Hat khuyên cấu hình ứng dụng để không nhận, hoặc không tự động giải nén, nén br đến từ nguồn không đáng tin cậy.

Ngay cả trước khi có gói đã vá, bạn vẫn có thể chặn đường đi phía WordPress ngay bây giờ. WordPress cung cấp hook [http_api_curl] truyền handle curl ở mỗi yêu cầu từ xa. Đặt [CURLOPT_ENCODING] thành null ở đó thì tính năng tự động giải nén của libcurl sẽ tắt.

Đặt tệp bên dưới vào thư mục [wp-content/mu-plugins/] thì áp dụng cho mọi yêu cầu từ xa; tên tệp chỉ là ví dụ. Muốn hoàn tác thì xóa tệp này.

<?php
// no-brotli-decode.php — WordPress từ xa trong yêu cầu libcurl Tự động giải nén Tắt(libbrotli bản vá phiên bản ra mắt cho đến khi)
if ( ! defined( 'ABSPATH' ) ) {
    exit;
}
add_action( 'http_api_curl', function ( $handle ) {
    curl_setopt( $handle, CURLOPT_ENCODING, null );
}, 99 );

Nhiều người nghĩ rằng thu hẹp [CURLOPT_ENCODING] thành [gzip, deflate] sẽ loại br ra. Giá trị đó chỉ bỏ br khỏi header Accept-Encoding của yêu cầu, nên nếu server bên kia trả lời bằng br, libcurl vẫn giải nén những gì nhận được. Khi tải httpbin.org/brotli với cùng giá trị đó trên website thử nghiệm, phản hồi có Content-Encoding là br vẫn được giải nén và đọc được bình thường.

Theo tài liệu curl, giá trị duy nhất tắt tự động giải nén là null; với null, header Accept-Encoding không được gửi và phần thân nhận được cũng không được giải nén. Phản hồi gzip và deflate do chính thư viện Requests của WordPress giải nén nên vẫn đọc được; chỉ phản hồi br là còn nguyên chưa giải nén.

Hook này là thứ WordPress gắn vào vị trí [curl.before_send], nơi Requests gọi ngay trước khi chạy curl. Hook được gọi ở dòng 174 của Curl.php và curl chạy ở dòng 205, nên giá trị chuỗi rỗng mà lõi đặt ở dòng 110 bị ghi đè ở khoảng giữa.

Kiểm tra việc áp dụng bằng tệp kiểm tra bên dưới. httpbin.org là địa chỉ thử nghiệm trả lại header của yêu cầu đã nhận và cũng trả về phản hồi nén bằng br và gzip, nên có thể thấy cùng lúc WordPress gửi gì và giải nén gì.

<?php
// br-check.php — WordPress từ xa yêu cầu loại nào nén gửi có giải nén không Xác nhận(httpbin.org thử nghiệm Địa chỉ)
$h = json_decode( wp_remote_retrieve_body( wp_remote_get( 'https://httpbin.org/headers' ) ), true );
echo 'Accept-Encoding: ', isset( $h['headers']['Accept-Encoding'] ) ? $h['headers']['Accept-Encoding'] : '(none)', PHP_EOL;
foreach ( array( 'brotli', 'gzip' ) as $p ) {
    $r = wp_remote_get( 'https://httpbin.org/' . $p );
    $readable = strpos( wp_remote_retrieve_body( $r ), ': true' ) !== false;
    echo $p, ': Content-Encoding=', wp_remote_retrieve_header( $r, 'content-encoding' ), ' / ', strlen( wp_remote_retrieve_body( $r ) ), ' bytes / ', ( $readable ? 'readable' : 'not decoded' ), PHP_EOL;
}

Trước khi thêm tệp, Accept-Encoding có br và phản hồi br được giải nén, đọc được.

wp eval-file br-check.php
Accept-Encoding: deflate, gzip, br
brotli: Content-Encoding=br / 316 bytes / readable
gzip: Content-Encoding=gzip / 317 bytes / readable

Sau khi thêm tệp, header Accept-Encoding biến mất, phản hồi br vẫn chưa được giải nén và phản hồi gzip vẫn đọc được.

wp eval-file br-check.php
Accept-Encoding: (none)
brotli: Content-Encoding=br / 199 bytes / not decoded
gzip: Content-Encoding=gzip / 272 bytes / readable

Sau khi đã nâng lên gói libbrotli đã vá của bản phân phối và khởi động lại php-fpm, hãy xóa tệp này để trở về như cũ.

🔢 FAQ & nội dung đề xuất

Cập nhật tự động của WordPress chỉ áp dụng cho lõi, plugin, theme và bản dịch; libbrotli và Node.js là các gói cài trên server nên do quản trị viên server hoặc nhà cung cấp hosting nâng cấp. Phải nâng cấp xong và khởi động lại php-fpm thì yêu cầu từ xa của WordPress mới được xử lý bằng thư viện mới.

Dù plugin đi qua WordPress HTTP API hay gọi trực tiếp hàm curl thì đều đi qua cùng một libcurl. Thứ cần sửa là gói libbrotli trên server, và trước khi có phiên bản đã vá, bạn có thể tắt tự động giải nén của yêu cầu từ xa WordPress bằng thiết lập ở mục 5️⃣. Theo tài liệu curl, mã gọi trực tiếp hàm curl mà không đặt [CURLOPT_ENCODING] sẽ không tự động giải nén phản hồi nén. Mã gọi trực tiếp và đặt giá trị đó thành chuỗi rỗng thì nằm ngoài hook [http_api_curl], nên hãy kiểm tra riêng các yêu cầu của plugin đó.

Bản ghi CVE-2026-111497 trên NVD và cve.org (CNA Google) có vị trí lỗi (c/dec/decode.c), các phiên bản bị ảnh hưởng và loại điểm yếu. Ghi chú phát hành google/brotli v1.2.1, v1.1.1 và v1.0.10 có ghi việc sửa lỗi. Chi tiết tái hiện cuộc tấn công không được đưa vào bài viết này.

ℹ️ Thông báo tiếp thị liên kết
Nội dung trên trang này có chứa liên kết affiliate (tiếp thị liên kết). Khi khách truy cập mua sản phẩm hoặc dịch vụ qua các liên kết này, trang sẽ nhận hoa hồng từ bên bán. Trong quá trình đó, số tiền người mua phải trả (sẽ giảm khi có chương trình khuyến mãi ↓) không hề tăng lên. Giá, khuyến mãi và tình trạng hàng được đăng theo thời điểm viết bài và có thể khác với thực tế, vì vậy hãy kiểm tra lại lần cuối với bên bán trước khi mua. Việc chọn và đánh giá sản phẩm dựa trên tiêu chí riêng của trang; việc có nhận hoa hồng hay không không ảnh hưởng đến thứ tự giới thiệu hay nội dung đánh giá.

Để lại một bình luận

Email của bạn sẽ không được hiển thị công khai. Các trường bắt buộc được đánh dấu *

Prove your humanity: 10   +   10   =