wp2shell: Một lỗ hổng RCE trên WordPress nguyên bản, được phát hiện trong mười giờ với giá 25 USD

Vào ngày 17 tháng 7 năm 2026, Searchlight Cyber đã công bố wp2shell, một chuỗi thực thi mã từ xa trước xác thực trong lõi WordPress không cần plugin, không cần theme và không cần đăng nhập. Chỉ một yêu cầu ẩn danh nhắm vào bản cài đặt mặc định là đủ: "Cuộc tấn công không có điều kiện tiên quyết và có thể bị khai thác bởi người dùng ẩn danh trên bản cài đặt WordPress mặc định không có plugin," khuyến cáo của công ty cho biết. Chuỗi này kết hợp hai lỗi — CVE-2026-63030, một lỗi nhầm lẫn định tuyến trong điểm cuối batch của WordPress REST API mà khuyến cáo của dự án xếp mức nghiêm trọng, và CVE-2026-60137, một lỗi chèn SQL trong tham số author__not_in của WP_Query mà nó xếp mức trung bình. WordPress đã phát hành WordPress 7.0.2 cùng ngày, và các khuyến cáo của dự án liệt kê WordPress 6.9.5, WordPress 6.8.6 và WordPress 7.1 beta2 là có các bản sửa tương tự. Searchlight trích dẫn ước tính hơn 500 triệu trang WordPress. Nhà nghiên cứu đứng sau chuỗi này, Adam Kues, cho biết nó ra đời từ một lần chạy GPT-5.6 Sol Ultra được xây dựng trên một lời nhắc OpenAI đã công bố cho một bài toán toán học: tối đa bốn tác nhân, ít nhất sáu giờ cho việc săn lùng và khoảng bốn giờ nữa cho việc leo thang, khoảng 25 USD chi phí sử dụng mô hình. Bản ghi được lưu là một phát hiện nghiên cứu — mức nghiêm trọng cao theo thang điểm riêng của kho lưu trữ, độ tin cậy hạng A, không ghi nhận tổn hại thực tế nào, ghi nhận vào một ngày duy nhất — và the Orca AI Incident Archive lưu giữ nó cùng các tài liệu gốc được liên kết bên dưới.

Việc công bố đã được phối hợp. Searchlight giữ kín cơ chế vào ngày 17 tháng 7 và cho đội phòng thủ cuối tuần để nâng cấp; Kues công bố bản mô tả kỹ thuật đầy đủ vào ngày 20 tháng 7. Đến lúc đó, chuỗi khai thác đã được tái tạo độc lập: Searchlight cho biết Calif và Hacktron đã dựng lại toàn bộ chuỗi trước khi các bản chứng minh khái niệm khác xuất hiện trên GitHub. Hai khuyến cáo bảo mật của chính WordPress nêu cùng các phiên bản đã sửa, và CISA đã thêm cả hai CVE vào danh mục Known Exploited Vulnerabilities của mình vào ngày 21 tháng 7.

Hai lỗi, và những mảng lệch nhịp

Điểm vào là một tính năng chứ không phải sai sót. WordPress 5.6 đã giới thiệu endpoint hàng loạt vào năm 2020 để client có thể gửi nhiều yêu cầu REST ảo bên trong một yêu cầu HTTP, chẳng hạn để đổi tiêu đề một loạt bài viết cùng lúc. Endpoint này có thể truy cập được dù người gọi đã xác thực hay chưa, và mỗi yêu cầu con mang theo bất kỳ thông tin xác thực nào mà người gọi đã cung cấp. Một yêu cầu trực tiếp đến một route REST của WordPress chạy qua pipeline bốn bước: kiểm tra các tham số bắt buộc và hợp lệ, làm sạch chúng, chạy callback kiểm tra quyền, rồi thực thi callback của endpoint. Các endpoint dựa vào pipeline đó cho những giả định về kiểu của chúng — rằng ID bài viết là số nguyên, rằng tiêu đề là chuỗi.

API batch chia pipeline làm hai, xác thực mọi yêu cầu con trong một vòng lặp và thực thi chúng trong vòng lặp thứ hai, đồng thời giữ hai mảng, $matches và $validation, mà các phần tử của chúng phải khớp theo từng chỉ số. Trong class-wp-rest-server.php, như Kues mô tả, một yêu cầu con mà bản thân nó là lỗi WordPress sẽ được thêm vào $validation rồi gặp một lệnh continue, bỏ qua dòng thêm vào $matches. Từ điểm đó, mọi phần tử match đều bị dịch lùi một vị trí. Vòng lặp thực thi ghép yêu cầu con ở một chỉ số với dữ liệu xác thực được ghi tại chỉ số đó, nhưng handler lại được khớp với một route khác — vì thế một tham số được kiểm tra theo quy tắc của endpoint này rồi lại được thực thi bởi mã của endpoint khác.

Đó là điều biến một tham số danh sách trông bình thường thành lỗi injection. Route collection posts ánh xạ tham số công khai author_exclude của nó sang author__not_in. Khi giá trị là một mảng, WordPress chạy absint trên từng phần tử và sắp xếp chúng; khi giá trị là một giá trị vô hướng, nó được nối nguyên vẹn vào đoạn SQL trở thành NOT IN ($author__not_in). Do đó, một chuỗi như 0) OR 1=1 -- sẽ lọt vào văn bản truy vấn. Khi được gọi bình thường, route sẽ từ chối nó, vì author_exclude phải là một mảng các số nguyên; lời gọi hàng loạt bị mất đồng bộ chính là thứ cho phép một chuỗi đi qua.

Hai trở ngại vẫn còn, và cả hai đều được giải quyết bằng cách lồng ghép thủ thuật. API batch từ chối các yêu cầu GET, còn lỗ hổng injection nằm trên một route GET; và việc xác thực phương thức yêu cầu tự nó được triển khai dưới dạng xác thực tham số, mà cùng một kiểu desync có thể vượt qua. Payload đã công bố của Kues gửi một subrequest bên ngoài bị định dạng sai để làm lệch đồng bộ bước kiểm tra phương thức, rồi một batch bên trong mà subrequest thứ hai của nó mang author_exclude độc hại nhắm vào một handler không xác thực nó, sau đó là GET chạy nó. Một injection dựa trên UNION trả về các giá trị cơ sở dữ liệu tùy ý bên trong các hàng có hình dạng giống như bài viết thông thường.

Lần chạy mô hình: một lời nhắc toán học, hướng vào một cơ sở mã

Kues không tự viết prompt từ đầu. OpenAI đã công bố prompt mà họ sử dụng khi làm việc về giả thuyết Cycle Double Cover, và Kues viết rằng anh đã đọc được thông tin mô hình gần đây đã giải được giả thuyết đó và rằng không ai trong cộng đồng bảo mật có vẻ đang nói về prompt này. Lý do của anh là nếu nó đủ tốt cho toán học khó thì có lẽ nó cũng đủ tốt cho nghiên cứu bảo mật. Anh đã điều chỉnh nó và hướng nó vào WordPress.

Thiết lập được cố ý thu hẹp. Ông đã sao chép bản phát hành WordPress ổn định mới nhất vào một thư mục có tên main/ và xóa thư mục .git của nó, đồng thời bảo mô hình không được dùng nhật ký thay đổi, lịch sử git hay internet mở để so sánh mã với một phiên bản đã vá — lý do ông nêu ra là đối với việc phát hiện lỗ hổng mới, tham khảo lịch sử hoặc web là lãng phí token. Một thư mục third_party/ trống được đưa ra để mô hình có thể sao chép các phụ thuộc như mã nguồn PHP hoặc MySQL nếu nó đánh giá rằng chuỗi cần có lỗi trong các thư viện bên dưới WordPress. Nhiệm vụ được chỉ định là RCE trước xác thực trong một triển khai production điển hình trên MySQL, với tối đa bốn agent và ít nhất sáu giờ. Kues viết rằng ông nêu rõ yêu cầu cấu hình vì nếu không thì các mô hình sẽ “gian lận” — bằng cách chọn các tùy chọn cấu hình cực kỳ khó xảy ra, hoặc bịa ra những điều kiện tiên quyết mà kẻ tấn công không bao giờ có thể đạt được.

Điều trả về, trong đầu ra đang chạy, là một tuyên bố về lỗ hổng SQL injection trước xác thực. Kues hoài nghi điều đó: WordPress nằm trong số những mục tiêu được kiểm toán kỹ lưỡng nhất mọi thời đại, ông viết, và đã không có một lỗ hổng trước xác thực đáng kể nào trong thập kỷ đó. Ông đã cài một bản WordPress nguyên gốc trên một máy chủ từ xa và yêu cầu mô hình đánh cắp email của quản trị viên; trong vài phút, nó in ra địa chỉ mà ông đã dùng để thiết lập bản cài đó. Sau đó ông hỏi liệu lỗ hổng injection chỉ đọc có thể được leo thang hay không, và khoảng bốn giờ sau, mô hình trả lời rằng có thể — lên quyền quản trị viên, mà không cần bẻ khóa bất kỳ mật khẩu nào và không cần tính toán ngoại tuyến.

Chi phí của chính anh ấy: 50% hạn mức sử dụng hàng tuần, mà anh ước tính khoảng 25 đô la theo tỷ lệ tương ứng trên gói đăng ký 200 đô la, cho một exploit được tạo ra chỉ trong hơn mười giờ. Phần con người không hề miễn phí — Kues dành ngày hôm sau để mổ xẻ những gì mô hình đã làm, và viết rằng công việc hậu khai thác khiến anh mất nhiều thời gian hơn để hiểu so với thời gian tạo ra nó. Phán quyết của anh ấy thẳng thừng một cách bất thường và được giới hạn hẹp: "Tôi không đưa ra bất kỳ tuyên bố chung nào, nhưng tôi có thể nói với sự tự tin hoàn toàn rằng không nhà nghiên cứu bảo mật nào có thể tìm ra và hoàn thành chuỗi khai thác này trong 10 giờ mà không có AI."

Từ một SELECT chỉ đọc đến quản trị viên

Phần leo thang là phần quan trọng nhất của bản ghi, vì đó là nơi một thao tác đọc cơ sở dữ liệu đã biến thành khả năng kiểm soát máy chủ. Lời tường trình của Kues mô tả quá trình này như một chuỗi sáu bước, mỗi bước đều lợi dụng một tính năng thông thường của WordPress để chống lại một tính năng khác.

Đầu tiên, hãy đầu độc bộ nhớ đệm bài viết trong RAM.WordPress duy trì bộ nhớ đệm theo từng yêu cầu cho các đối tượng WP_Post để cùng một bài viết được tham chiếu nhiều lần trong một yêu cầu chỉ tốn một lượt truy vấn cơ sở dữ liệu. Lỗ hổng SQL injection có thể tạo ra các bài viết giả mạo, nên kẻ tấn công kiểm soát chính xác những gì được đưa vào bộ nhớ đệm — nhưng những bài viết giả mạo đó không phải là các dòng trong cơ sở dữ liệu, và bộ nhớ đệm sẽ biến mất cùng với yêu cầu.

Thứ hai, biến các bài viết giả tạo thành các hàng thật.Tính năng nhúng của WordPress lưu đệm các lượt nhúng đã được phân giải trong cơ sở dữ liệu dưới dạng bài viết thuộc loại oembed_cache. Việc nhúng một bài viết cục bộ bằng đường dẫn tương đối, như trong [embed]/?p=S[/embed], khiến WordPress bỏ qua yêu cầu HTTP và không bao giờ kiểm tra xem bài viết được tham chiếu có tồn tại hay không, vì vậy một hàng được tạo ra. Ba lần nhúng như vậy với các token chuỗi truy vấn khác nhau tạo ra ba mã băm bộ đệm khác nhau, và đó là cách kẻ tấn công có được nhiều hàng để xử lý.

Thứ ba, hãy lách qua trường duy nhất luôn cố định. Khi phiên bản trong bộ nhớ và phiên bản trong cơ sở dữ liệu của một bài viết không khớp nhau, WordPress sẽ đồng bộ chúng bằng một lệnh gọi đặt rõ ràng post_content từ đầu ra nhúng. Mọi thứ về bài viết đều do kẻ tấn công kiểm soát, trừ nội dung của nó, mà đây chính xác là trường mà một customize_changeset dùng để lưu JSON của các thay đổi giao diện và trang web đang chờ xử lý.

Thứ tư, thủ thuật chu trình. Bài viết có cha, và WordPress từ chối các chu trình: bộ lọc wp_insert_post_parent đi ngược lên cây và, khi phát hiện một vòng lặp, gọi bản cập nhật đặt post_parent về 0. Lệnh gọi đó không ghi đè post_content, nên phiên bản được dựng trong bộ nhớ vẫn tồn tại sau quá trình đối soát — một changeset, với JSON còn nguyên vẹn, được chống đỡ bởi một hàng thật.

Thứ năm, mượn quyền của quản trị viên. Một changeset có trạng thái cho biết nó được lên lịch cho tương lai nhưng ngày của nó lại ở trong quá khứ sẽ được áp dụng ngay lập tức. Mỗi mục trong JSON của nó chỉ định một user_id, và mục trong chuỗi của Kues chỉ định user_id 1, quản trị viên, nên WordPress tạm thời nhận danh tính đó để áp dụng thay đổi. Thay đổi đầu tiên là một bản cập nhật trông có vẻ vô hại đối với nav_menus_created_posts.

Thứ sáu, phát lại yêu cầu với tư cách danh tính đó.Việc xuất bản một bài viết kích hoạt một hành động được đặt tên động, {status}_{post_type}. Bởi vì bài viết được tạo giả, trạng thái và loại đó có thể là bất kỳ thứ gì — bao gồm parse và request, tạo ra parse_request hook và khởi động lại pipeline yêu cầu từ đầu trong khi danh tính quản trị viên được mượn vẫn còn hiệu lực. Yêu cầu hàng loạt ban đầu chứa một yêu cầu con tạo quản trị viên mới; nó thất bại ở lần chạy đầu tiên với tư cách khách và thành công khi phát lại. Từ đó, kẻ tấn công đăng nhập bằng tài khoản mới đó và tải lên một plugin backdoor từ tệp ZIP, dẫn đến thực thi mã.

Kỹ thuật này có kèm một điều kiện. The Hacker News, trích dẫn Cloudflare, đưa tin rằng CVE-2026-63030 chỉ dẫn đến thực thi mã từ xa khi không sử dụng bộ nhớ đệm đối tượng thường trực; bản thân lỗi injection đã xuất hiện từ WordPress 6.8, trong khi chuỗi khai thác đầy đủ cần 6.9 trở lên. Một bản cài đặt mặc định không có bộ nhớ đệm đối tượng thường trực, đó là lý do vì sao cách diễn đạt "không có điều kiện tiên quyết" của Searchlight và từ giới hạn của Cloudflare mô tả cùng một trường hợp mặc định từ các hướng khác nhau.

Các tài liệu gốc xác lập điều gì

Các thông báo bảo mật của chính WordPress là bằng chứng xác thực mạnh nhất, vì chúng là việc nhà cung cấp thừa nhận cơ chế và phát hành bản sửa lỗi. GHSA-ff9f-jf42-662q, được xếp mức nghiêm trọng, mô tả một điểm yếu nhầm lẫn tuyến batch của REST API trong WordPress 6.9 trở lên, kết hợp với lỗi injection để dẫn đến thực thi mã, và ghi nhận Adam Kues tại Assetnote và Searchlight Cyber. GHSA-fpp7-x2x2-2mjf, được xếp mức trung bình, mô tả lỗi injection author__not_in từ WordPress 6.8 trở lên, và nêu rằng cả hai vấn đề đã được sửa trong WordPress 7.0.2, WordPress 6.9.5, WordPress 6.8.6 và WordPress 7.1 beta2. Các bản ghi NVD cho hai CVE, được WPScan CNA chấm điểm thay vì NIST, mang điểm 9.8 cho CVE-2026-63030 với vector AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H, và 5.9 cho CVE-2026-60137 với AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:N/A:N — trong trường hợp đầu, một lỗi có thể truy cập từ mạng và không yêu cầu quyền hạn; trong trường hợp thứ hai, một lỗi yêu cầu độ phức tạp tấn công cao và chỉ gây tác động đến tính bí mật. Trường mức độ nghiêm trọng của chính kho lưu trữ cho mục này ghi là cao, trong khi WordPress gắn nhãn lỗi batch là nghiêm trọng; đây là hai thang đo riêng biệt được áp dụng cho toàn bộ chuỗi và cho một thành phần đơn lẻ, chứ không phải là sự bất đồng về bản thân các lỗi.

Các mục trong danh mục của CISA, như được phản ánh trong các trường làm giàu dữ liệu của NVD, đã được thêm vào ngày 21 tháng 7 năm 2026 với thời hạn khắc phục là ngày 24 tháng 7 đối với CVE-2026-63030 và ngày 4 tháng 8 đối với CVE-2026-60137. CISA đặt tên cho lỗ hổng thứ nhất là “WordPress Core Interpretation Conflict Vulnerability” và lỗ hổng thứ hai là “WordPress Core SQL Injection Vulnerability”. Searchlight cũng đã công bố một công cụ kiểm tra công khai tại wp2shell.com để người vận hành có thể kiểm tra một phiên bản mà không cần chờ chữ ký của máy quét.

Việc tái tạo độc lập do chính Searchlight ghi lại, và do đó đây là một tuyên bố về bên thứ ba chứ không phải là lời kể của bên thứ ba: theo bài viết ngày 20 tháng 7, Calif và Hacktron đã dựng lại toàn bộ chuỗi trước khi các bằng chứng khái niệm khác xuất hiện trên GitHub. Điều có thể kiểm chứng một cách độc lập là tác động — các bằng chứng khái niệm, lưu lượng khai thác và dữ liệu telemetry từ nhà cung cấp trong vòng vài ngày, được đề cập bên dưới.

Điều gì được tuyên bố nhưng chưa được xác lập?

Hai ghi công cho một lỗ hổng injection không dung hòa được trong hồ sơ công khai. Thông báo bảo mật của WordPress về CVE-2026-60137 nêu rằng lỗ hổng này “được phát hiện và công bố một cách có trách nhiệm với tư cách một nhóm bởi TF1T, dtro và haongo”. Bài tường trình của Searchlight trình bày cùng lỗ hổng injection trước xác thực đó như những gì lần chạy mô hình của họ đã phát hiện ra, và không nhắc đến nhóm đó; thông báo bảo mật của WordPress chỉ ghi công cho Kues về nhầm lẫn batch-route, và không nhắc đến mô hình nào. Không tài liệu nào giải thích sự trùng lặp, và không có gì bài viết này tìm được giải quyết được điều đó — khả năng rằng hai phát hiện là những phát hiện độc lập về cùng một lỗi chưa bị loại trừ, và khả năng rằng một báo cáo là một lần phát hiện lại muộn hơn cũng chưa được xác lập. Hồ sơ không phân xử điều đó, và bài viết này cũng không.

Con số nêu trên tiêu đề trong bài đăng ngày 20 tháng 7 của Searchlight không được chính phần thân bài của nó xác nhận. Tiêu đề viết: "Các nhà môi giới lỗ hổng trả 500.000 đô la cho một lỗ hổng RCE WordPress. Tôi đã tìm ra một lỗ hổng với GPT5.6 Sol Ultra và 25 đô la". Phần thân bài ghi lại cụ thể khoản 25 đô la và mười giờ làm việc; bài viết không nêu tên nhà môi giới nào, không có lời chào mua nào, không có thư từ trao đổi nào và không có nguồn nào cho con số 500.000 đô la. Không có báo cáo độc lập nào được tìm thấy cho bài viết này xác nhận một mức giá đã được trả hoặc được chào cho wp2shell. Hãy hiểu con số 500.000 đô la là cách đóng khung của tiêu đề, chứ không phải là một mức giá thị trường đã được xác lập.

Phạm vi của chính mục lưu trữ hẹp hơn câu chuyện xung quanh nó. Mục này ghi lại một phát hiện nghiên cứu vào ngày công bố, không đánh dấu bất kỳ tác hại thực tế nào, và được định ngày vào một ngày duy nhất, 17 tháng 7 năm 2026. Điều đó không phải là tuyên bố rằng không có gì xảy ra sau đó: lưu lượng khai thác đã được báo cáo trong vòng vài giờ sau khuyến cáo, và CISA đã đưa cả hai CVE vào danh mục bốn ngày sau. Cờ này bao quát những gì mục mô tả — việc phát hiện và công bố phối hợp — còn việc khai thác sau đó được các bên khác ghi nhận dựa trên bằng chứng của chính họ, ở phần dưới.

Khai thác sau thông báo bảo mật

Jake Knott, nhà nghiên cứu bảo mật chính tại watchTowr, nói với The Hacker News rằng "đến những giờ đầu của sáng thứ Bảy (giờ UTC), việc khai thác thành công đã diễn ra mạnh mẽ, ban đầu sử dụng mã khai thác công khai để đưa thông tin xác thực đã băm ra ngoài, sau đó là thực thi mã từ xa khi thêm chi tiết được công bố." Cùng báo cáo trích dẫn dữ liệu telemetry của KEVIntel liên kết 13 địa chỉ IP duy nhất, từ Thụy Sĩ, Đức, Vương quốc Anh, Indonesia, Litva, Hà Lan và Singapore, với việc khai thác CVE-2026-63030, và dẫn lời người sáng lập KEVIntel Ryan Dewhurst nói rằng các yêu cầu khớp với bản chứng minh khái niệm có sẵn công khai và rằng các payload mù, dựa trên UNION và dựa trên boolean đều đã được sử dụng.

Các nhà nghiên cứu Shahar Dorfman và Gili Tikochinski của Wiz, công bố ngày 20 tháng 7, đã định lượng quy mô vấn đề: 60% tổ chức sử dụng WordPress có ít nhất một phiên bản dễ bị tổn thương tại thời điểm các CVE được công bố và 25% đang phơi bày một máy chủ dễ bị tổn thương ra internet, giảm xuống 50% và 10% trong vòng 24 giờ khi việc vá lỗi bắt đầu. Họ ghi nhận các vụ tải lên plugin độc hại thông qua trình cài đặt quản trị, liệt kê người dùng nhắm vào endpoint users, các nỗ lực chèn tệp cục bộ nhắm vào wp-config, và truy cập bảng quản trị trả về HTTP 200 — dấu hiệu của một lần đăng nhập thành công chứ không phải thăm dò. Phần mềm độc hại họ tìm thấy trải từ một backdoor PHP tối giản một dòng đến một webshell 150 KB được ngụy trang thành một plugin bảo mật WordPress hợp pháp có tên CMSmap, với các mô-đun quản lý tệp, truy cập cơ sở dữ liệu, quét cổng và leo thang đặc quyền.

Wiz cũng ghi nhận một giới hạn đối với những gì có thể được kết luận. Việc quét khối lượng lớn mà không có hoạt động khai thác sau xâm nhập là phổ biến, phù hợp với quét hàng loạt mang tính cơ hội và với quét bảo mật hợp pháp, và công ty tuyên bố rằng họ chưa xác định được hoạt động di chuyển ngang hoặc rút trích dữ liệu. Đó là một tuyên bố về những gì dữ liệu giám sát từ xa của một nhà cung cấp cho thấy, chứ không phải là kết luận rằng không có gì bị lấy đi.

Những gì đã thay đổi sau đó, và những gì vẫn còn bỏ ngỏ

Đối với các đơn vị vận hành, quy trình ứng phó rất ngắn. Cập nhật lên WordPress 7.0.2, WordPress 6.9.5 hoặc WordPress 6.8.6 là cách khắc phục. Các giải pháp thay thế khẩn cấp của Searchlight, dành cho các trang web không thể cập nhật ngay lập tức, là chặn quyền truy cập ẩn danh vào API batch — hoặc bằng cách cài đặt một plugin chặn hoàn toàn quyền truy cập ẩn danh vào REST API, hoặc bằng cách chặn /wp-json/batch/v1 và ?rest_route=/batch/v1 tại một tường lửa ứng dụng web. Công ty cảnh báo rằng cả hai đều có thể ảnh hưởng đến việc sử dụng hợp pháp trang web và nên được coi là biện pháp tạm thời cho đến khi bản cập nhật được triển khai. Công cụ kiểm tra công khai tại wp2shell.com kiểm tra trực tiếp một phiên bản cài đặt. Các mục trong danh mục của CISA đã bổ sung thời hạn tuân thủ: khắc phục trước ngày 24 tháng 7 đối với CVE-2026-63030 và trước ngày 4 tháng 8 đối với CVE-2026-60137.

Đối với câu hỏi nghiên cứu, phần chưa được giải quyết là mô hình thực sự đã đóng góp gì so với người vận hành nó. Kues nói chính xác về sự phân chia: mô hình tạo ra chuỗi khai thác trong khoảng mười giờ, và việc hiểu nó mất nhiều thời gian hơn so với việc tạo ra nó. Ông từ chối các tuyên bố tổng quát và chỉ nói rằng kết quả trong mười giờ đó không thể đạt được bởi một con người nếu không có trợ giúp. Bản thân prompt không phải bí mật — nó bắt nguồn từ một prompt do OpenAI công bố, và Searchlight đã tái tạo cấu trúc của nó trong bài viết, bao gồm chỉ dẫn bỏ qua lịch sử phiên bản và yêu cầu rằng exploit phải hoạt động trong một cấu hình production điển hình. Liệu công thức đó có chuyển sang các cơ sở mã khác hay không chính là câu hỏi mà Kues nói ông không trả lời, và chưa có lần chạy thứ hai nào được công bố.

Điều mà hồ sơ vẫn chưa xác lập vì thế tuy hẹp nhưng lại quan trọng: bên nào trong hai bên được ghi công đã phát hiện ra lỗ hổng injection trước, liệu có broker nào từng trả con số nêu trên tiêu đề hay không, và những webshell mà Wiz quan sát được thực sự đã lấy được gì, nếu có, từ các trang web mà chúng xâm nhập. Về điểm cuối cùng, tuyên bố công khai duy nhất là của Wiz, rằng họ đã không xác định được hoạt động di chuyển ngang hay rò rỉ dữ liệu nào — một sự thiếu vắng bằng chứng từ một góc nhìn, được đưa ra đúng như bản chất đó.