Bảo mật XRPL được củng cố sau khi lỗ hổng sửa đổi hàng loạt của xrpl bị chặn trước khi ra mắt mainnet

Quỹ XRPL đã ngăn chặn một vấn đề nghiêm trọng liên quan đến bản cập nhật batch của xrpl trước khi nó ảnh hưởng đến mainnet, nhấn mạnh vị thế an ninh đang phát triển của sổ cái.

Lỗi nghiêm trọng được phát hiện trong giai đoạn bỏ phiếu

Quỹ XRPL tiết lộ rằng một lỗ hổng nghiêm trọng trong đề xuất cập nhật Batch đã được xác định và vô hiệu hóa trước khi kích hoạt trên mainnet. Lỗ hổng xuất hiện khi thay đổi vẫn đang trong giai đoạn bỏ phiếu của validator, cho phép các nhà phát triển phản ứng trước khi có ảnh hưởng đến sản xuất.

Vấn đề được phát hiện vào ngày 19 tháng 2 năm 2026 bởi kỹ sư an ninh Pranamya Keshkamat cùng với công cụ tự động Apex của Cantina AI. Theo quỹ, không có quỹ người dùng nào gặp rủi ro vì bản cập nhật chưa được kích hoạt trên XRPL mainnet.

Bản cập nhật, chính thức gọi là XLS-56, nhằm giới thiệu các giao dịch theo lô trên XRP Ledger. Nó sẽ cho phép nhóm nhiều giao dịch nội bộ thành một lô duy nhất, nâng cao hiệu quả và phối hợp. Tuy nhiên, các giao dịch nội bộ này được để trống chữ ký một cách có chủ ý, với quyền ủy quyền được giao cho một giao dịch lô bên ngoài liệt kê các người ký.

Cách lỗi trong xác thực chữ ký hoạt động

Theo báo cáo hậu sự kiện của quỹ, lỗ hổng bắt nguồn từ logic xác thực chữ ký của tính năng Batch. Hơn nữa, vấn đề tập trung vào lỗi vòng lặp trong hàm xác thực người ký dùng để xác minh quyền của lô.

Khi hệ thống gặp một mục người ký liên kết với một tài khoản chưa tồn tại trên sổ cái, nó có thể thoát vòng lặp sớm. Nếu khóa ký phù hợp với tài khoản mới, quá trình xác thực sẽ bị đánh dấu sai là thành công. Điều này khiến phần mềm bỏ qua kiểm tra tất cả các mục người ký còn lại trong lô.

Hành vi này mở ra khả năng thực hiện các giao dịch trái phép. Một kẻ tấn công có thể thực hiện các thao tác từ các tài khoản nạn nhân mà không cần có khóa riêng của họ, vì các kiểm tra khóa có thể bị bỏ qua. Tại thời điểm phát hiện, bản cập nhật chỉ trong giai đoạn bỏ phiếu của validator và vẫn chưa được kích hoạt trên mainnet.

Quỹ XRPL nhấn mạnh rằng đề xuất chưa được kích hoạt và nhấn mạnh: “Bản cập nhật đang trong giai đoạn bỏ phiếu và chưa được kích hoạt trên mainnet; không có quỹ nào gặp rủi ro.” Cam đoan này rất quan trọng để hạn chế lo ngại của thị trường và làm nổi bật lợi ích của việc kiểm tra kỹ lưỡng trước khi kích hoạt.

Ảnh hưởng tiềm năng của lỗi trong bản cập nhật batch

Kịch bản khai thác được báo cáo yêu cầu một giao dịch batch được thiết kế cẩn thận. Một kẻ tấn công sẽ tạo ra một batch chứa ba thao tác nội bộ, được tổ chức để khai thác logic sai trong xác thực người ký.

Đầu tiên, một giao dịch nội bộ sẽ tạo ra một tài khoản mới do kẻ tấn công kiểm soát hoàn toàn. Thứ hai, một giao dịch nội bộ khác sẽ gửi một chuyển khoản đơn giản hoặc hành động từ tài khoản mới tạo đó. Thứ ba, một khoản thanh toán từ tài khoản nạn nhân được chọn sang tài khoản của kẻ tấn công sẽ được bao gồm, nhằm chuyển tiền mà không có sự ủy quyền hợp lệ.

Để hoàn tất thiết lập, kẻ tấn công cung cấp hai mục người ký trong batch. Một mục người ký hợp lệ cho tài khoản mới do kẻ tấn công kiểm soát. Mục người ký thứ hai giả mạo để ủy quyền các giao dịch cho tài khoản nạn nhân. Tuy nhiên, do lỗi thoát vòng lặp sớm, hệ thống có thể chấp nhận người ký đầu tiên và không xác thực đúng người ký thứ hai.

Kết quả là, khoản thanh toán của nạn nhân có thể được thực hiện mà không cần chữ ký hợp lệ, làm thay đổi sổ cái theo cách mà nạn nhân không chấp thuận. Quỹ XRPL cảnh báo rằng việc sử dụng thành công kỹ thuật này có thể đã cho phép chuyển tiền tùy ý và gây rối loạn sổ cái nếu triển khai trên quy mô lớn.

Hơn nữa, tổ chức nhấn mạnh rủi ro đối với niềm tin của toàn bộ hệ sinh thái nếu một khai thác như vậy đã đến được mainnet. Giám đốc điều hành Cantina và Spearbit Hari Mulackal bình luận, “Chúng tôi có hệ thống săn lỗi tự động, Apex, đã phát hiện ra lỗi nghiêm trọng này.” Các nhóm kỹ thuật của Ripple sau đó đã tái tạo hành vi này bằng một bằng chứng về khái niệm và hoàn thành kiểm thử đơn vị đầy đủ trước khi xử lý lỗi.

Phản ứng khẩn cấp và cập nhật rippled

Sau khi tiết lộ, các validator UNL của XRPL đã được khuyến cáo bỏ phiếu “Không” cho đề xuất Batch. Sự phối hợp này đảm bảo rằng bản cập nhật không thể vô tình vượt qua ngưỡng kích hoạt trong khi đang sửa lỗi.

Phiên bản phần mềm khẩn cấp, rippled 3.1.1, đã được phát hành vào ngày 23 tháng 2 năm 2026. Phiên bản này rõ ràng đánh dấu cả bản cập nhật Batch gốc và thay đổi fixBatchInnerSigs là không được hỗ trợ. Do đó, chúng bị chặn khỏi việc nhận phiếu bầu của validator và không thể kích hoạt trên bất kỳ mạng sản xuất nào.

Phiên bản khẩn cấp này không bao gồm logic đã chỉnh sửa cuối cùng. Thay vào đó, nó hoạt động như một hàng rào bảo vệ, đảm bảo rằng cả Batch lẫn fixBatchInnerSigs không thể đạt đến trạng thái kích hoạt trong dạng lỗi của chúng. Tuy nhiên, biện pháp bảo vệ này đã mua cho các nhà phát triển thời gian quan trọng để thiết kế và xem xét một giải pháp an toàn hơn.

Một bản cập nhật sửa lỗi tên BatchV1_1 đã được thực hiện như là người kế nhiệm của thiết kế ban đầu. Bản cập nhật này loại bỏ lỗi thoát sớm trong xác thực người ký và tăng cường kiểm tra trên tất cả các đường dẫn ủy quyền. Quỹ xác nhận rằng bản sửa này vẫn đang trong quá trình xem xét và chưa có ngày triển khai chính thức.

Nâng cao thực hành an ninh của XRPL

Sau sự cố, Quỹ XRPL đã đề ra các biện pháp an ninh bổ sung để củng cố quy trình phát triển. Hơn nữa, họ dự định mở rộng vai trò của AI trong việc xem xét các thay đổi giao thức để phát hiện sớm các lỗi logic tinh vi.

Tổ chức dự định tăng cường sử dụng kiểm tra mã tự động hỗ trợ AI, dựa trên thành công của các công cụ của Cantina AI và hệ thống Apex trong trường hợp này. Họ cũng sẽ mở rộng phân tích tĩnh để đặc biệt phát hiện các mẫu như trả về thành công sớm trong vòng lặp, góp phần vào lỗi trong logic xác thực batch.

Tuy nhiên, quỹ nhấn mạnh rằng sự cố bản cập nhật batch của xrpl cho thấy tầm quan trọng của các lớp phòng thủ, bao gồm xem xét của con người, phân tích tự động và kích hoạt theo g từng giai đoạn. Bằng cách kết hợp các phương pháp này, các nhà duy trì hy vọng giảm thiểu rủi ro của các lỗ hổng chưa phát hiện trong các nâng cấp giao thức tương lai.

Cuối cùng, Quỹ XRPL nhấn mạnh rằng lỗi nghiêm trọng đã được vá trước khi kích hoạt trên mainnet và trước khi quỹ nào bị xâm phạm. Việc phát hiện sớm, phản ứng phối hợp của validator và phát hành khẩn cấp rippled đã giúp ngăn chặn các giao dịch trái phép và duy trì tính toàn vẹn của mạng XRPL.