Ngày 28/10/2026, nhóm phát triển Bitcoin Core công khai chi tiết ba lỗ hổng đã được vá trong các phiên bản 29.5, 30.4, 31.2 và 32.1. Cả ba đều do một đợt quét tự động bằng mô hình ngôn ngữ lớn phát hiện, rồi được con người xác minh trước khi chuyển cho nhóm bảo mật của dự án.

Đợt quét thuộc Project Loupe của Elias Rohrer tại Spiral. Gregory Sanders là người xác minh các phát hiện và chuyển tiếp cho nhóm Bitcoin Core. Sự việc diễn ra chưa đầy một tuần sau khi dự án thay đổi chính sách công bố lỗ hổng theo hướng công khai sớm hơn với những lỗi mà AI có thể tìm ra dễ dàng.

Lỗi nghiêm trọng nhất chỉ ảnh hưởng đến node ngoài Linux

Lỗi đầu tiên nằm ở cách Bitcoin Core theo dõi sự kiện socket trên các nền tảng không phải Linux. Trên Linux, phần mềm dùng cơ chế poll; trên Windows, macOS và BSD, phần mềm dùng cơ chế select. Nhánh select theo dõi cả các điều kiện bất thường trên socket kể cả khi việc đọc đã bị tạm dừng để giới hạn hàng đợi.

Một peer độc hại có thể gửi dữ liệu TCP khẩn cấp để kích hoạt điều kiện đó, buộc node đọc thêm dữ liệu và phá vỡ cơ chế giới hạn. Hệ quả theo mô tả của dự án: kẻ tấn công có thể làm sập bất kỳ node Windows, macOS hoặc BSD nào đang kết nối với mình. Lỗi được xếp mức trung bình và dễ phát hiện. Node chạy Linux không bị ảnh hưởng.

Lỗi thứ hai làm bộ nhớ tăng chậm nhưng không có điểm dừng

Lỗi thứ hai liên quan đến các peer cũ không hỗ trợ thông điệp ping có nonce theo BIP 31. Với nhóm peer này, cơ chế ngắt kết nối khi không phản hồi ping trong 20 phút không được áp dụng, nên một peer có thể giả vờ không hỗ trợ chuẩn mới rồi trì hoãn việc đọc để hàng đợi phình dần.

Mức tăng được ghi nhận tới 2 MB mỗi giờ cho mỗi peer vào và 5 MB mỗi giờ cho mỗi peer ra. Đây là lỗi mức trung bình, được báo cáo từ ngày 15/09 và có thêm một báo cáo độc lập từ L0rinc.

Lỗi thứ ba khó khai thác nhưng chưa vá hết

Lỗi còn lại nằm ở tệp undo, nơi Bitcoin Core lưu dữ liệu cần thiết để hoàn tác một block khi xảy ra tổ chức lại chuỗi. Vị trí trong tệp undo được lưu dưới dạng số nguyên 32 bit, nên nếu tệp vượt 4 GiB thì vị trí sẽ quấn vòng và dữ liệu mới ghi đè dữ liệu cũ.

Về lý thuyết, một thợ đào có thể tạo chuỗi block khiến tệp undo vượt ngưỡng, rồi chờ một đợt tổ chức lại đúng thời điểm để node khác không đọc được undo và phải dừng. Tuy nhiên dự án đánh giá việc khai thác là không thực tế trên hệ thống 64 bit, vì cần khai thác hàng nghìn block với giao dịch phi tiêu chuẩn, tương đương khoảng một tháng sản xuất block của toàn mạng, rồi phải thắng một đợt tổ chức lại hai block.

Bản vá chuyển vị trí sang số nguyên 64 bit và dùng lệnh định vị tệp 64 bit trên Windows. Máy 32 bit và node lưu block trên ổ định dạng FAT32 vẫn bị ảnh hưởng, vì giới hạn kích thước tệp của nền tảng chưa thay đổi.

Chuỗi thời gian cho thấy tốc độ xử lý

Lỗi thứ ba được báo cáo lần đầu ngày 08/07, sau đó có thêm hai báo cáo độc lập vào ngày 21/08 và 23/10. Đến ngày 26/10, các yêu cầu hợp nhất mã nguồn được mở, gộp và chuyển ngược về các nhánh 29, 30, 31, 32. Bản 31.2 và 32.1 phát hành ngày 27/10, bản 29.5 và 30.4 phát hành ngày 28/10, cùng ngày công khai.

Điều đáng chú ý là cả ba lỗi đều đến từ cùng một phương pháp: quét mã nguồn bằng AI rồi để người kiểm chứng. Đây là mặt còn lại của làn sóng AI săn lỗ hổng đang làm thay đổi cách các dự án mã nguồn mở tính thời gian giữ kín thông tin. Với người vận hành node, việc cần làm không phức tạp: kiểm tra phiên bản đang chạy và cập nhật nếu còn ở nhánh cũ.