500 lỗ hổng zero-day của Claude Opus 4.6: Ba bản vá cho thấy điều gì

Ngày 5 tháng 2 năm 2026, Frontier Red Team của Anthropic đã công bố nghiên cứu báo cáo rằng Claude Opus 4.6, được phát hành cùng ngày, đã phát hiện và xác thực hơn 500 lỗ hổng có mức độ nghiêm trọng cao trong phần mềm mã nguồn mở — mà không cần công cụ dành riêng cho tác vụ, scaffolding tùy chỉnh hay prompt chuyên biệt. Ba phát hiện được mô tả chi tiết: một kiểm tra giới hạn ngăn xếp bị thiếu trong Ghostscript, một loạt lời gọi strcat không được kiểm tra trong OpenSC, và một lỗi tràn bộ đệm trong bộ mã hóa GIF CGIF liên quan đến cách nén LZW hoạt động khi từ điển của nó đầy. Anthropic cho biết cả ba hiện đã được những người bảo trì vá, và theo báo cáo của họ, các lỗi đã được phát hiện, xác thực và báo cáo. Bài đăng lưu ý rằng nhiều dự án trong số này được duy trì bởi các nhóm nhỏ hoặc tình nguyện viên không có nhân sự bảo mật chuyên trách, nên gánh nặng báo cáo và vá lỗi đổ dồn lên họ. Mục của chính kho lưu trữ về phát hiện này, được phân loại ở mức thông tin và không ghi nhận thiệt hại thực tế nào, nằm trong Orca AI Incident Archive bên cạnh các hồ sơ chính sách và công bố khác của tháng 2 năm 2026.

Anthropic thực sự đã công bố gì

Bài đăng có tiêu đề "Đánh giá và giảm thiểu rủi ro ngày càng gia tăng của các lỗ hổng 0-day do LLM phát hiện" và được ghi tác giả là Frontier Red Team: Nicholas Carlini, Keane Lucas và Evyatar Ben Asher là những người đóng góp ngang nhau, cùng với Newton Cheng, Hasnain Lakhani, David Forsythe và Kyla Guru. Trang có ngày xuất bản 5 tháng 2 năm 2026 và ghi chú chỉnh sửa ngày 6 tháng 2 năm 2026 ghi nhận rằng danh sách tác giả đã được cập nhật. Bản lưu trữ trích dẫn bài đăng tại red.anthropic.com, hiện chuyển hướng đến anthropic.com/research/zero-days.

Phương pháp quan trọng hơn con số nổi bật. Anthropic cho biết họ đặt mô hình vào trong một máy ảo có quyền truy cập vào các phiên bản mới nhất của những dự án mã nguồn mở, đồng thời cung cấp cho nó các tiện ích tiêu chuẩn và những công cụ mà một nhà nghiên cứu bảo mật con người sẽ dùng — trình gỡ lỗi và fuzzer — nhưng không đưa ra hướng dẫn về cách sử dụng chúng và, theo lời trong bài đăng, “không có harness tùy chỉnh nào có thể cung cấp cho nó kiến thức chuyên biệt về cách tìm lỗ hổng tốt hơn”. Điều đang được kiểm tra là hành vi mặc định của mô hình.

Nhóm đã thu hẹp phạm vi tìm kiếm vào các lỗi làm hỏng bộ nhớ, với lý do rằng một vụ crash dễ xác nhận hơn một lỗi logic. Anthropic khẳng định rõ rằng đây là một bộ lọc, không phải bảo đảm: “không phải mọi đầu vào khiến chương trình crash đều là lỗ hổng có mức độ nghiêm trọng cao.” Vì vậy, các vụ crash được đưa trở lại mô hình để phản biện, loại trùng và sắp xếp lại thứ tự ưu tiên, rồi sau đó chuyển đến con người. “Đối với vòng phát hiện ban đầu của chúng tôi, các nhà nghiên cứu bảo mật của chính chúng tôi đã xác nhận từng lỗ hổng và viết bản vá bằng tay. Khi số lượng phát hiện tăng lên, chúng tôi đã mời các nhà nghiên cứu bảo mật bên ngoài (con người) hỗ trợ xác nhận và phát triển bản vá.” Bài đăng cho biết tự động hóa bản vá vẫn đang được xây dựng.

Ba lỗi và những bản vá theo sau

Ba ví dụ đã được giải có chung một dạng: một công cụ tự động đã thất bại, và mô hình đã tìm ra lỗi bằng cách lập luận về một thứ khác ngoài việc thay đổi đầu vào.

• Ghostscript, trình thông dịch PostScript và PDF. Fuzzing rồi phân tích thủ công đều không phát hiện được gì. Sau đó, mô hình đọc lịch sử Git của dự án, tìm thấy một commit được bài viết mô tả là đã thêm "stack bounds checking for MM blend values" vào charstring Type 1, suy luận rằng mã trước commit đó từng có lỗ hổng, và bắt đầu tìm các điểm gọi khác chưa được xử lý tương tự. Nó tìm thấy một điểm như vậy trong gdevpsfx.c — bài viết dẫn dòng 292 — và tạo một tệp làm chương trình bị sập. Kho mã nguồn xác nhận điều này: commit 87486fb801 của Chris Liddell, ngày 5 tháng 9 năm 2025, có tiêu đề "Type 1 charstrings: add stack bounds checking for MM blend values." Một bản sửa lỗi sau đó của Ken Sharp, commit 4e392a82 ngày 26 tháng 1 năm 2026, thêm kiểm tra giới hạn ngay trước lệnh gọi đó trong bộ chuyển đổi phông chữ, được ghi nhận cho Bug 709080, với báo cáo có tiêu đề “Ghostscript Incomplete fix for Type 1 MM blend stack bounds check”. Một commit vào ngày 13 tháng 2 năm 2026 đã mở rộng kiểm tra giới hạn trong cùng bộ chuyển đổi. Không có thông điệp commit nào cho biết ai đã báo cáo lỗi.

• OpenSC, một tiện ích dòng lệnh dành cho dữ liệu thẻ thông minh. Tại đây, mô hình đã tìm kiếm các lệnh gọi hàm có rủi ro và phát hiện liên tiếp các thao tác strcat ghi vào bộ đệm filename 4096 byte, sau khi một phép tính kích thước đã trừ độ dài của một chuỗi đầu vào nhưng sau đó lại nối thêm các chuỗi khác mà không kiểm tra lại. Bài đăng lưu ý rằng các fuzzer hiện có hiếm khi chạm tới đường dẫn đó do các điều kiện tiên quyết liên quan. Commit 33ab343a5c của OpenSC vào ngày 19 tháng 1 năm 2026 đã thêm một kiểm tra rằng chuỗi được nối đúng 64 byte, và pull request #3554, được hợp nhất ngày 25 tháng 1 năm 2026, đã thay thế các lệnh gọi strcat còn lại trên toàn dự án bằng strlcat; tác giả của nó gọi hàm này là "một thỏi nam châm hút mọi công cụ phân tích tĩnh và CVE."

• CGIF, một bộ mã hóa GIF. Thư viện giả định rằng dữ liệu nén sẽ luôn nhỏ hơn đầu vào chưa nén, điều gần như luôn đúng. Mô hình lập luận rằng LZW xây dựng một từ điển có kích thước cố định, và khi từ điển đầy, các mã xóa được chèn vào luồng có thể khiến đầu ra "đã nén" dài hơn đầu vào — vì vậy một bộ đệm có kích thước cho N+2 mã có thể nhận được nhiều hơn N+1. Bài đăng nói rằng ngay cả độ bao phủ dòng và nhánh 100 phần trăm cũng có thể không phát hiện ra điều này, vì nó cần một chuỗi thao tác cụ thể. Pull request #84 của CGIF, được hợp nhất ngày 19 tháng 1 năm 2026 và phát hành cùng ngày dưới dạng v0.5.1, sửa chính xác điều đó: "Các mã xóa đặt lại đã bị thiếu trong phép tính cho giới hạn trên của phép tính kích thước dữ liệu LZW."

Những bản vá đó đã được đưa vào trước khi nghiên cứu được công bố — CGIF và OpenSC vào ngày 19 tháng 1 năm 2026, OpenSC một lần nữa vào ngày 25 tháng 1, Ghostscript vào ngày 26 tháng 1 — và Anthropic cho biết trong bài đăng rằng họ đã "bắt đầu báo cáo các lỗi này và đang thấy những bản vá đầu tiên của chúng tôi được đưa vào" trước khi công bố ra công chúng. Các kho lưu trữ ghi lại những thay đổi trong mã; chúng không ghi lại ai đã gửi báo cáo, vì vậy mối liên hệ giữa những phát hiện của mô hình và các commit cụ thể này chỉ dựa vào lời kể của Anthropic và mức độ khớp giữa các lỗi được mô tả với các diff.

The researcher who said the OpenSC bug was not real

Public scrutiny of the individual findings did not start and end with Anthropic. On 14 February 2026 K. Reid Wightman, an industrial security researcher posting as @reverseics on infosec.exchange, published a review of the OpenSC example arguing the bug could not be triggered: the input string was already checked to be 64 bytes at line 5138, he wrote, which capped the buffer at 4095 bytes including the terminator. "I spent about an hour looking at the code to debunk their finding," he wrote.

He edited the same post on 17 February 2026 to withdraw the challenge. "Looks like the version of code I was looking at, already had a fix for anthropic-discovered bug(s)," the edit reads, before conceding the arithmetic: "but yes without the strlen() check on 'fp' the overflow could actually be triggered. The humble pie has been eaten." The check he had relied on was the one added to OpenSC on 19 January 2026 — before Anthropic published, and before most readers would have gone looking. The archive does not flag the record as disputed, and here the challenge was retracted by the person who raised it.

OpenSC's own maintainers answered the same question in their tracker. In discussion #3575, opened on 17 February 2026 by a user asking whether Anthropic's claims were legitimate, OpenSC maintainer frankmorgner replied the same day: "We received two bug reports from anthropic, which were both verified by humans." He said the fixes were in pull request #3554 and would be in the next release, and that commit 33ab343 was "a change that was introduced after anthropic reported the problem."

Phần quản trị: thăm dò, chặn và 90 ngày

Điều khiến đây trở thành một văn bản chính sách chứ không phải một ghi chú nghiên cứu thuần túy chính là nửa sau của bài đăng. Cùng với việc phát hành mô hình, Anthropic cho biết họ đã giới thiệu các probe chuyên biệt về mạng, dùng để đo các activation bên trong mô hình trong khi mô hình tạo phản hồi, và rằng họ đã cập nhật quy trình thực thi để sử dụng phát hiện dựa trên probe. Nó còn đi xa hơn cả phát hiện: "chúng tôi có thể tiến hành can thiệp theo thời gian thực, bao gồm chặn lưu lượng mà chúng tôi phát hiện là độc hại." Anthropic thừa nhận cái giá phải trả — "Điều này sẽ tạo ra ma sát cho nghiên cứu hợp pháp và một số công việc phòng thủ" — và nói rằng họ muốn hợp tác với cộng đồng nghiên cứu bảo mật về vấn đề này. Không có tỷ lệ phát hiện, tỷ lệ lỗi hay quy trình kháng nghị nào được công bố.

Bài viết cũng lập luận rằng chính lịch công bố giờ đây là một vấn đề. “Các cửa sổ 90 ngày theo tiêu chuẩn ngành có thể không trụ vững trước tốc độ và khối lượng lỗi do LLM phát hiện,” bài viết nói, và cảnh báo rằng các mô hình “có thể sớm vượt qua tốc độ và quy mô của cả những nhà nghiên cứu con người chuyên nghiệp.” Đó là một nhà cung cấp đang lập luận rằng chuẩn mực mà nó sẽ bị đánh giá dựa theo cần được thay thế, và đó là phần của hồ sơ có tầm ảnh hưởng xa nhất.

Điều gì đã thay đổi sau đó?

Vào ngày 20 tháng 2 năm 2026, Anthropic đã mở Claude Code Security dưới dạng bản xem trước nghiên cứu giới hạn dành cho khách hàng Enterprise và Team, với quyền truy cập nhanh miễn phí cho những người duy trì mã nguồn mở — năng lực này được sản phẩm hóa mười lăm ngày sau nghiên cứu. VentureBeat đưa tin về buổi ra mắt và cho biết đã hỏi Anthropic về tỷ lệ dương tính giả trước và sau khi tự xác minh, về số lỗ hổng đã được công bố có bản vá được triển khai so với số vẫn đang trong quá trình phân loại, và về các biện pháp bảo vệ giúp phân biệt việc sử dụng của kẻ tấn công với việc sử dụng của bên phòng thủ; tờ này đưa tin rằng nhà nghiên cứu chính của dự án không có mặt và công ty đã từ chối chia sẻ các cơ chế phát hiện kẻ tấn công cụ thể.

Các bản vá cũng tiếp tục thay đổi, và không phải lúc nào cũng theo một hướng. Bản sửa lỗi của CGIF cho vấn đề cấp phát mà Anthropic mô tả đã được phát hành trong v0.5.1 vào ngày 19 tháng 1 năm 2026; vào ngày 21 tháng 2 năm 2026, pull request #103 đã sửa lỗi tràn số nguyên 32-bit do chính phép tính cấp phát đó gây ra, được phát hành dưới dạng v0.5.2 vào ngày hôm sau cho GIF ở kích thước tối đa 65,535 x 65,535 pixel. Hóa ra, việc sửa một phép tính giới hạn lại chính là một nguồn nhỏ gây ra các lỗi giới hạn.

Đọc đúng con số

Câu của chính Anthropic là "hơn 500 lỗ hổng có mức độ nghiêm trọng cao". Axios, tờ báo được công ty thông tin trước tiên, đã mô tả chúng vào ngày đăng bài là "hơn 500 lỗ hổng zero-day chưa từng được biết đến trước đó", mỗi lỗ hổng đều được một thành viên trong nhóm của Anthropic hoặc một nhà nghiên cứu bảo mật bên ngoài xác thực. Cả hai mô tả đều chỉ cùng một tập hợp, nhưng chỉ một là cách diễn đạt của nhà cung cấp, và cả hai đều không đi kèm danh sách, ánh xạ CVE hay phân bố mức độ nghiêm trọng. Con số là của Anthropic, các xếp hạng mức độ nghiêm trọng là của Anthropic, và ba dự án được trình bày trong bài đăng là những dự án duy nhất mà công chúng có thể kiểm tra.

Phân tích độc lập sau đó phần lớn đã chấp nhận con số theo đúng bề ngoài của nó và tranh luận về ý nghĩa của nó. Mitch Ashley của Futurum Group đã viết vào ngày 24 tháng 2 năm 2026 rằng kết quả này “quan trọng hơn ở chỗ phương pháp tiết lộ điều gì so với bản thân con số”, và rằng ràng buộc thực sự nằm ở khâu hạ nguồn: “Phát hiện nhiều lỗ hổng hơn với tốc độ nhanh hơn không thu hẹp bề mặt tấn công. Nó tạo ra một hàng đợi lớn hơn trước một quy trình hạ nguồn không thể hấp thụ nổi khối lượng đó.” Đó là một phê bình đối với quy trình công bố thông tin chứ không phải đối với phát hiện, và nó chạm đúng vào điểm mà Anthropic đã nêu về cửa sổ 90 ngày.

Điều mà hồ sơ không xác lập

Hồ sơ lưu trữ xếp bản ghi này ở mức tin cậy A, mức độ nghiêm trọng là thông tin, không ghi nhận tổn hại thực tế nào và không có cờ tranh chấp. Việc xếp mức đó nói về mức độ ghi chép đầy đủ của sự kiện, chứ không nói về mức độ tuyên bố nền tảng đã được kiểm toán kỹ đến đâu, và khác biệt này đáng được giữ chặt. Không ai bên ngoài Anthropic đã xác minh 500. Chưa có tỷ lệ dương tính giả nào được công bố. Các bản vá cho ba dự án được nêu tên là có thật và có thể định ngày, và chúng là bằng chứng củng cố mạnh nhất hiện có — nhưng chúng củng cố ba ví dụ, không phải tổng số.

Vậy thì còn lại là một thông báo được ghi chép đầy đủ, với phần cốt lõi có thể kiểm chứng và phần còn lại không thể kiểm chứng: một nhà cung cấp báo cáo về một năng lực, ba diff upstream khớp với mô tả của họ về các lỗi, và một ý định được nêu rõ là sẽ kiểm soát việc lạm dụng năng lực đó ở tầng mô hình. Kho lưu trữ xếp nó vào mục chính sách, đó là kệ đúng. Tuyên bố về năng lực sẽ được giải quyết bởi bất kỳ ai công bố bản vá thứ tư.