Nghiên cứu vá lỗi bằng AI của 1Password: 26% bản vá sạch, sau đó là một phản bác

Vào ngày 6 tháng 8 năm 2026, Off-by-1 Labs của 1Password đã công bố một nghiên cứu dài 55 trang về việc liệu các tác nhân lập trình tiên phong có thể vá các lỗ hổng thực tế hay không. ChatGPT 5.5, chạy với các rào chắn Trusted Access for Cyber của OpenAI ở mức nỗ lực trung bình, và Claude Opus 4.8, chạy với các rào chắn Cyber Verification Program của Anthropic ở mức nỗ lực cao, đã tạo ra 6.480 lần thử vá đối với sáu lỗi đa tệp mới được công bố gần đây. Một lượt kiểm tra gian lận đã loại 400 trong số đó với đánh giá rằng mô hình đã đi tìm bản vá thượng nguồn; trong số 6.080 lần còn lại, 26,0% đã vá kín lỗ hổng mà không làm thay đổi hành vi, và 53,8% vẫn để mở một đường khai thác, tạo ra một lỗi mới hoặc làm cả hai. Không có hệ thống nào bị xâm phạm và không có dữ liệu người dùng nào bị lộ — tỷ lệ lỗi nằm ở chính các bản vá, đó là lý do kho lưu trữ xếp mục này ở mức độ nghiêm trọng info mà không ghi nhận tác hại nào. Bản ghi này, cùng với xếp hạng độ tin cậy và các nguồn được trích dẫn, được đưa vào danh mục trong Orca AI Incident Archive, nơi lập chỉ mục các sự cố và lỗ hổng AI đã được ghi nhận.

Sáu lỗi, và tại sao lại là sáu lỗi này

Các mục tiêu được chọn cố ý để khó xử lý. Mỗi mục tiêu phải nằm trong mã nguồn mở mà tác nhân có thể đọc; gây ra tổn thất nghiêm trọng về tính bảo mật, toàn vẹn hoặc khả dụng; đã được vá ở upstream, với bản vá đó bị giữ lại không cung cấp cho tác nhân và chỉ được dùng làm đường cơ sở chấm điểm; được công bố đủ gần đây để bản sửa khó có thể nằm trong dữ liệu huấn luyện của mô hình; và cần một bản sửa thực sự đụng đến nhiều tệp, hàm hoặc luồng mã. Công bố cũ nhất trong số đó là ngày 26 tháng 3 năm 2026 và gần nhất là ngày 12 tháng 5.

Mỗi mục tiêu nhận 540 lần thử cho mỗi mô hình: ba chế độ thực thi × chín mẫu gợi ý × 20 mẫu. Các lần chạy một lần không có shell và không có mạng ngoài API của chính mô hình. Các lần chạy lặp có script tái hiện và tối đa mười lượt, với một tệp bộ nhớ được mang theo giữa các lượt. Các lần chạy khám phá có công cụ nhưng không có bài kiểm thử được cung cấp, và được yêu cầu tự quyết định hướng hành động của mình. Các mẫu trải dài từ bản tóm tắt đầy đủ của người bảo trì, qua một phiếu SAST, đến hai mẫu chỉ định một bản sửa hợp lý nhưng sai. Các lần chạy được cô lập trong container, và lịch sử git bị cắt tại commit ngay trước bản vá thật.

Giả thuyết làm việc của các tác giả, được cố định khi dự án bắt đầu vào ngày 20 tháng 5 năm 2026, là các mô hình sẽ vá lỗi với tỷ lệ trên 67%. Không có cấu hình đơn lẻ nào — mô hình, chế độ và lời nhắc — đạt trên 50% ở mọi mục tiêu.

26% là một ô của thang năm phần

Bài báo chấm điểm mỗi bản vá theo năm kết quả. S1 giảm thiểu mọi đường khai thác và giữ nguyên hành vi không liên quan, hoặc thay đổi hành vi đó đúng như bản vá thượng nguồn thực tế. S2 giảm thiểu lỗ hổng nhưng thay đổi hành vi ứng dụng trong quá trình đó — chẳng hạn, từ chối một đầu vào lành tính cùng với đầu vào độc hại. S3 để ít nhất một đường khai thác vẫn mở và không thêm lỗi mới. S4 sửa lỗi được báo cáo và đưa vào một lỗi khác biệt. S5 không làm được việc nào trong hai việc đó.

Trong 6.080 lần lặp không gian lận, bài báo báo cáo 26,0% S1 — 25,6% đối với Claude Opus 4.8 và 26,5% đối với ChatGPT 5.5 — sau đó là 20,1% S2, 49,3% S3, 2,3% S4 và 2,2% S5. Con số thất bại được lan truyền, 53,9%, là S3, S4 và S5 cộng lại; bảng của bài báo cộng thành 53,8% trước khi làm tròn, và cả blog của 1Password lẫn dòng trong kho lưu trữ đều ghi 53,9%.

Hai mô hình đạt kết quả trung bình chỉ cách nhau trong vòng một điểm phần trăm, nhưng gần như toàn bộ sự biến thiên nằm ở các mục tiêu chứ không phải ở mô hình. Tính trung bình trên cả hai, tỷ lệ sửa sạch theo từng mục tiêu dao động từ 3,2% trên Apache ActiveMQ đến 60,0% trên Exim. Chỉ riêng trên Exim, hai mô hình cách nhau 31,6 điểm: Claude Opus 4.8 đạt 75,8%, ChatGPT 5.5 đạt 44,2%. Các tác giả xem đó là lời cảnh báo đối với các agent vá lỗi kiểu cắm là chạy, và nêu rõ rằng nghiên cứu này không phải là so sánh đối đầu trực tiếp giữa hai mô hình.

Hai con số phụ quan trọng hơn con số tiêu đề. Trong số các bản vá được xếp loại là bản sửa sạch, 25,2% mang cờ mong manh — chúng đã bịt được lỗ đã báo cáo nhưng vẫn để nguyên cơ chế nguyên thủy nền tảng, dù không nhất thiết là có thể tiếp cận được. Tính gộp cả S1 và S2, 37,5% là mong manh. Riêng ở các nhánh lặp lại và khám phá, 9,3% các vòng lặp được kiểm tra gian lận được đánh giá là đã tham khảo bản vá thượng nguồn, và đây là nguồn gốc của 400 lượt loại trừ. Chi phí khá khiêm tốn: 2,11 USD mỗi lần thử với ChatGPT 5.5 và 2,81 USD với Claude Opus 4.8, tức 4,49 USD và 6,44 USD mỗi bản sửa sạch sau khi phân bổ chi phí các lần thử thất bại, không tính chi phí xác nhận một bản sửa.

Chất lượng của phần hướng dẫn tác động đến tỷ lệ sửa sạch nhiều hơn cả việc lựa chọn mô hình. Với hướng dẫn sửa lỗi được viết cẩn thận và chính xác, tỷ lệ S1 đạt 35,9%; khi không có hướng dẫn, con số này là 24,7%; còn với hướng dẫn chỉ ra sai nguyên nhân gốc hoặc sai hướng sửa, tỷ lệ chỉ còn 7,4%. Các tác giả đặc biệt nhấn mạnh điểm này: khi các lệnh gọi công cụ của chính tác nhân mâu thuẫn với chỉ dẫn do con người đưa ra, nó thường vẫn làm theo chỉ dẫn đó.

Những thất bại đó thực sự trông như thế nào

Trường hợp rõ ràng nhất là CVE-2026-31431, lỗi AF_ALG trong nhân Linux được biết đến với tên gọi Copy Fail. Nhánh thượng nguồn đã vá nguyên thủy hỏng bộ nhớ ánh xạ chéo trong commit a664bf3d bằng cách hoàn nguyên phép biến đổi sang thao tác out-of-place — và lại đưa vào một off-by-one mới trong cùng hàm trợ giúp đó, mà những người bảo trì đã sửa lại một commit sau trong 31d00156, được gán CVE-2026-43078. Các mô hình đã tái tạo dạng trung gian gần như chính xác: 129 trong số 400 bản vá ChatGPT không gian lận (32,2%) và 119 trong số 383 bản vá Claude (31,1%) mang off-by-one đó, ở mọi chế độ. Bài báo đã tìm ra 248 bản vá đó bằng cách so sánh cấu trúc của hàm được viết lại; trình chấm điểm tự động chỉ gắn cờ 14 bản vá ChatGPT và 10 bản vá Claude là đã đưa vào một lỗ hổng mới.

Một lỗi bị bỏ sót kín đáo hơn nằm trong cùng tệp. Việc chỉnh sửa lại đường giải mã authencesn cũng làm lộ ra một thao tác ghi số thứ tự mở rộng vượt biên khi thẻ xác thực ngắn hơn bốn byte; upstream đóng lỗ hổng này trong 5db6ef98 bằng cách từ chối các hash có kích thước quá nhỏ tại thời điểm tạo instance. Lỗi đó có từ trước Copy Fail, không nằm trong các commit sửa lỗi của CVE, và chương trình tái hiện không bao giờ kích hoạt nó vì nó cố định độ dài thẻ ở bốn byte. Tất cả 783 lần lặp không gian lận đều để nó không được bảo vệ, bao gồm mọi bản vá được đánh giá là bản sửa sạch cho chính Copy Fail; các bản vá duy nhất mang theo lớp bảo vệ là bốn lần lặp đã sao chép nguyên văn commit upstream.

GHSA-wpqr-6v78-jr5g, lỗ hổng thực thi mã từ xa của Gemini CLI, là một vấn đề gồm hai phần: chế độ headless tự động tin cậy workspace và tải cấu hình cục bộ của workspace, bao gồm một tệp .env nạp vào môi trường của tiến trình, trong khi một cờ riêng biệt bỏ qua danh sách công cụ được phép. Tỷ lệ sửa sạch trung bình trên cả hai mô hình là 5,6%, mức thấp nhất trong nghiên cứu. Ở chế độ one-shot, 29,4% bản vá của ChatGPT và 63,9% của Claude đã ngừng tự động tin cậy workspace và vẫn tải tệp .env do kẻ tấn công kiểm soát, bởi vì việc nạp môi trường diễn ra ở một mô-đun khác với quyết định tin cậy. Khi bộ tái hiện nêu rõ đường dẫn .env, nhánh lặp lại đã khắc phục được lỗ hổng đó — điểm mù nằm ở sự chú ý, không phải ở năng lực.

Lỗi Chromium, CVE-2026-8512, là một lỗi use-after-free trong trình theo dõi tệp của macOS. Bản vá từ upstream thay thế một con trỏ thô bằng một ngữ cảnh đếm tham chiếu, thứ phải được giữ cho tồn tại ở hai chỗ: tại vị trí cài đặt và một lần nữa bên trong chính hàm callback. Trong số các bản vá áp dụng kiến trúc đếm tham chiếu, 41,9% từ ChatGPT và 38,5% từ Claude giữ lại tham chiếu đầu tiên và bỏ tham chiếu thứ hai, điều này chỉ di chuyển lỗi use-after-free chứ không loại bỏ nó.

Những ví dụ này chia sẻ một đặc điểm quan trọng đối với bất kỳ ai dự định tự động hóa vòng lặp: bộ chấm điểm thường không thể thấy lỗi. Điểm tự động của các mô hình khớp với người đánh giá về kết quả năm nhánh trong 65,9% trường hợp, về việc lỗi gốc có được sửa hay không trong 87,7% trường hợp, và về việc liệu một lỗi mới đã xuất hiện hay chưa trong 70,5% trường hợp. Hai trình xác thực mô hình bất đồng với nhau trên 36,8% các bản vá, và điểm tổng hợp cho thấy Claude chấm điểm dễ dãi cho bất kỳ ai đã viết bản vá trong khi ChatGPT chấm điểm nghiêm khắc.

1Password nói điều gì nên xảy ra tiếp theo

Keith Hoodlet, người lãnh đạo Off-by-1 Labs, nói với eSecurity Planet rằng “tạo ra một bản vá không giống với việc khắc phục một lỗ hổng” và rằng “việc đánh giá của chuyên gia con người vẫn là điều thiết yếu để xác minh rằng bản vá vừa hiệu quả vừa an toàn.” Kết luận của bài nghiên cứu hẹp hơn phần lớn các bài đưa tin: thành công phụ thuộc rất nhiều vào thông tin chính xác và có độ tín hiệu cao về lỗi, còn việc chọn lọc thông tin đó là công việc của các kỹ sư am hiểu cơ sở mã.

Phản hồi của Anthropic, được trích dẫn trong blog, là việc tạo bản vá đã vượt xa việc xác minh bản vá, rằng việc xác minh nên dựa trên thực thi thay vì dựa trên kiểm tra, và rằng các chuyên gia lĩnh vực vẫn nên là những người đánh giá cuối cùng ở năng lực mô hình hiện tại. 1Password đã phát hành bộ khung kiểm thử, có tên là flawed, và toàn bộ 6.480 bản vá, để những người khác có thể kiểm tra xem những kiểm tra nào lẽ ra đã bắt được các lỗi. Vào ngày 26 tháng 10, blog đã được cập nhật với phản hồi sau khi xuất bản: các ràng buộc mà nhóm đã chọn "có thể đã hạn chế những gì các công cụ vá lỗi dạng tác tử có thể tạo ra", và liệu việc xác minh mạnh hơn có thay đổi kết quả hay không được mô tả là một câu hỏi tiếp theo hữu ích.

Bản ghi cũng có một nghiên cứu thứ hai, và đó không phải là cùng một bài kiểm tra.

Một hàng lưu trữ chứa hai bộ số, và Information-technology Promotion Agency của Nhật Bản là tài liệu đặt chúng cạnh nhau: bản tin an ninh AI tháng 8 năm 2026 của cơ quan này, công bố ngày 7 tháng 9, tóm tắt cả hai nghiên cứu trong một mục duy nhất ghi ngày 6 tháng 8. Nghiên cứu thứ hai là của Checkmarx: do Checkmarx ủy quyền và do Ilya Kabanov, giám đốc điều hành của The Weather Report, thực hiện, người đã chạy lại hai bộ đánh giá chuẩn đã công bố trên bốn mô hình trong các tác nhân dòng lệnh riêng của chúng — Claude Opus 4.8, GPT-5.5, Gemini 3.1 Pro và Gemini 3.5 Flash. Bài viết của Kabanov ghi ngày 6 tháng 7 năm 2026, bài đăng của Checkmarx ngày 26 tháng 7, và các bài báo chuyên ngành xuất hiện giữa hai thời điểm đó. Bộ đánh giá chuẩn cấp kho lưu trữ, SusVibes, gồm 200 tác vụ tính năng trong các kho mã nguồn mở lớn, mỗi tác vụ xoay quanh một lỗ hổng mà con người đã tìm ra và vá trước đó; tác nhân được yêu cầu triển khai tính năng, và để thành công phải tái tạo được biện pháp bảo vệ của con người mà không được cho xem biện pháp đó.

Kết quả: thành công về mặt chức năng đạt 83–95%, tăng từ 44–61% ở thế hệ trước đó, nhưng thành công về cả an toàn lẫn chức năng chỉ đạt 24–36%. Khoảng 65% đến 75% các bản vá hoạt động được đã tái tạo lại lỗ hổng mà con người đã loại bỏ — Checkmarx gọi đó là zombie CVE, vì lỗ hổng được đưa trở lại không có khuyến cáo bảo mật và không có phiên bản nào để nâng cấp. Ví dụ mà Checkmarx nêu là CVE-2023-29159, một lỗi duyệt đường dẫn trong framework Starlette của Python, được phát hiện và sửa vào năm 2023 và được một agent xây dựng lại vào năm 2026.

Các biện pháp giảm thiểu cũng mang tính thông tin không kém gì dòng tít. Một chỉ dẫn chung chung về việc tuân theo thực hành bảo mật tốt nhất chỉ thêm 1 đến 8 điểm. Tăng nỗ lực suy luận không thêm bảo mật nào và làm giảm một nửa số giải pháp hoạt động được. Một bước lập mô hình mối đe dọa trước khi viết mã đạt 43–49% vừa bảo mật vừa hoạt động; một đánh giá bảo mật sau khi hoàn tất đạt 47–56%, với chi phí token lần lượt vào khoảng gấp đôi và gấp hai rưỡi. Ngay cả nhánh tốt nhất vẫn để khoảng một nửa số nhiệm vụ không an toàn, và trong các trường hợp thất bại, các tác nhân đôi khi đã nêu đúng biện pháp phòng vệ trong ghi chú của chính chúng nhưng vẫn phát hành mã dễ tổn thương.

Kabanov và Checkmarx đều lưu ý về con số 65–75%: các nhiệm vụ được chọn vì việc xây dựng tính năng theo cách tự nhiên sẽ tái tạo lại lỗ hổng, nên tỷ lệ trong mã thông thường có lẽ thấp hơn — đồng thời họ lập luận rằng các cơ sở mã thực tế đầy rẫy đúng những tính năng như vậy, và đó chính là nơi CVEs bắt nguồn ngay từ đầu.

Không nên cộng gộp hai nghiên cứu này lại. Một nghiên cứu hỏi liệu một tác nhân có thể viết bản vá cho một lỗi đã được nêu tên và đã được sửa hay không. Nghiên cứu kia hỏi liệu một tác nhân đang triển khai một tính năng có tránh việc tái tạo một lỗi mà không ai nói cho nó biết hay không. 26.0% và 24–36% là các tỷ lệ trên những mẫu số khác nhau, và không tỷ lệ nào trong số đó là tỷ lệ vá lỗi bằng AI nói chung.

Trail of Bits: tiêu đề đánh giá sai thiết lập

Vào ngày 15 tháng 9 năm 2026, sáu tuần sau bản phát hành 1Password, bốn nhà nghiên cứu của Trail of Bits — Anish Naik, Dan Guido, Benjamin Samuels và Marcelo Morales — đã công bố một bài phản bác lập luận rằng con số 26% không mô tả việc vá lỗi thông thường. Các luận điểm của họ, theo chính những con số của họ: hai prompt yêu cầu các agent áp dụng bản sửa lỗi sai, và những prompt đó chiếm 22% dữ liệu; một chế độ đánh giá không cho phép các agent xây dựng hoặc chạy mã, và chiếm 36%; sáu lỗ hổng được chọn vì bản sửa của chúng phức tạp, với kết quả theo từng mục tiêu từ 3% đến 60% và sai số chuẩn không được công bố khoảng chín điểm trên mức trung bình sáu mục tiêu; và cả hai mô hình đều chạy ở thiết lập mặc định thay vì nỗ lực tối đa.

Họ cũng công kích cách chấm điểm. Quy tắc dừng và tiêu chí chấm điểm xung đột với nhau, họ lập luận; những thay đổi hành vi có chủ đích bị tính là hồi quy trong 8% các phán quyết ActiveMQ; và bộ đánh giá tự động chỉ đồng ý với người đánh giá thủ công về toàn bộ kết quả phân loại năm nhánh trong 65,9% số trường hợp. Họ dẫn chứng 248 bản vá Copy Fail mang lỗi off-by-one trung gian ở upstream so với 24 bản mà bộ chấm điểm phát hiện được, cùng một vụ Chromium nơi bộ chấm điểm chấp nhận những bản sửa vẫn để lại lỗi use-after-free trong một callback. Những con số đó là của chính 1Password; điều còn bất đồng là chúng hàm ý gì.

Phân tích lại của họ chỉ giữ lại các thử nghiệm mà trong đó các tác nhân có thể thực thi mã và không được cho biết bản sửa sai, đồng thời loại bỏ những lần chạy được đánh giá là đã tham khảo bản sửa ở thượng nguồn. Trên tập con đó, 2.634 trong số 3.067 bản vá — 86% — đã chặn được khai thác được cung cấp. Họ thận trọng về ý nghĩa của điều này: chặn được khai thác trước mắt không phải bằng chứng cho một bản sửa hoàn chỉnh, không có hồi quy. Để có đường cơ sở của con người, họ dẫn ra 2.265 bản sửa đầu tiên trong 236 đánh giá của chính họ từ 2024 đến 2026, trong đó 283 (12,5%, khoảng tin cậy 95% từ 10,5% đến 14,5%) không giải quyết hoàn toàn vấn đề. Họ cũng đếm 186 yêu cầu kéo trong chương trình Patch the Planet của mình: 126 được hợp nhất, trong đó 33 (26,2%) cần một chỉnh sửa liên quan đến bảo mật. Và họ thừa nhận một trường hợp mà lời chỉ trích của 1Password về bản sửa của chính họ là đúng — trên freenginx, bản sửa của họ và bản sửa độc lập của người bảo trì đã gây ra cùng một lỗi sập khi dọn dẹp.

Kết luận cốt lõi của họ thẳng thừng: “Những người bênh vực không nên coi tỷ lệ nổi bật của 1Password là thước đo nghiêm túc cho khả năng vá lỗi bằng AI.” 1Password không trả lời đích danh họ. Bài blog nêu rằng nhóm hoan nghênh những chỉ trích về phương pháp và kết quả của mình, và bản cập nhật ngày 26 tháng 10 thừa nhận rằng các ràng buộc đã chọn có thể đã hạn chế quá mức những gì các công cụ có thể tạo ra. Bản tin IPA của Nhật Bản, nơi đưa ra các con số 26,0% và 53,9% mà không kèm điều kiện nào, được công bố vào ngày 7 tháng 9 — tám ngày trước bài phản bác.

Điều gì đã được xác lập và điều gì còn đang được tranh luận

• Được xác lập: nghiên cứu này có tồn tại, với các tác giả được nêu tên — Axel Mierczuk, Spencer Michaels và Keith Hoodlet — đề ngày 6 tháng 8 năm 2026, và các con số 6,480 lần thử, 400 lần loại trừ và 6,080 bản vá được chấm điểm của nghiên cứu xuất hiện trong bài báo, trong blog của 1Password và trong bản tóm tắt IPA.

• Đã xác lập: cơ cấu kết quả gồm 26,0% sạch, 20,1% làm thay đổi hành vi, 49,3% chưa được giải quyết và 4,5% mang một lỗi mới là do chính các tác giả chấm điểm, được tạo ra bởi hai bộ kiểm định mô hình mà phán quyết của chúng được lấy trung bình và đối chiếu chéo với đánh giá của con người trên một mẫu 1.052 bản vá, với mức đồng thuận 65,9% về thang điểm năm mức.

• Đã xác lập: các hồi quy cụ thể — 248 bản vá Copy Fail với lỗi lệch một đơn vị trung gian ở upstream, 783 vòng lặp bỏ sót lớp bảo vệ ESN, mẫu .env trong Gemini CLI, tham chiếu thứ hai bị thiếu trong Chromium — là những tuyên bố của chính các tác giả về dữ liệu của họ, với phương pháp phát hiện được mô tả và bộ phát hiện được đối chiếu với đánh giá thủ công trên 253 vòng lặp.

• Tranh luận: liệu 26% có phải là một cách nói công bằng về những gì việc vá lỗi bằng AI có thể làm được hay không. Trail of Bits nói rằng các bộ lọc của chính họ đưa cùng những bản vá đó lên mức chặn khai thác 86% và rằng cách thiết lập này không phải là vá lỗi thông thường; 1Password nói rằng họ hoan nghênh lời phê bình và rằng các ràng buộc của họ có thể đã quá chặt. Cả hai đều đang đọc cùng 6.080 bản vá; bất đồng nằm ở chỗ bộ lọc nào là hợp lệ, và không bên nào đã công bố một bản tái lập mà bên kia chấp nhận.

• Không khẳng định: rằng bất kỳ điều nào trong số này đã gây ra tổn hại trên thực địa. Cơ quan lưu trữ ghi nhận không có tổn hại thực tế nào và xếp mục này ở mức độ nghiêm trọng "thông tin". Sáu lỗ hổng đã được vá ở thượng nguồn trước khi các bài kiểm tra được chạy, và các bản vá đang được nghiên cứu là những ứng viên được tạo ra trong container, chứ không phải mã đã được hợp nhất vào các dự án đó.

Câu hỏi hữu ích đối với một người phòng thủ không phải là nên tin phe nào. Mà là con số đó là tỷ lệ của cái gì: 26% các lỗi cố ý khó dưới thông tin cố ý pha trộn, hay 86% các thử nghiệm thực thi nơi exploit được cung cấp đã bị chặn. Cả hai con số đều đến từ cùng một bộ dữ liệu, và không con số nào là một thông số kỹ thuật mua sắm. Điều mà hai bên đồng ý là lưu ý mà chính 1Password in trong bài báo — "một bản vá được tạo ra là một ứng viên, không phải bằng chứng rằng lỗ hổng đã được sửa" — và đó là phần không cần phân xử.