Phát hiện RCE WordPress bằng GPT5.6 và 25 đô la

 (slcyber.io)
2 điểm bởi GN⁺ 14 giờ trước | 1 bình luận | Chia sẻ qua WhatsApp
  • GPT5.6 Sol Ultra đã phân tích phiên bản ổn định mới nhất của WordPress và hoàn thiện một chuỗi tấn công từ SQL injection trước xác thực đến tạo tài khoản quản trị viên và thực thi mã từ xa (RCE) chỉ trong khoảng hơn 10 giờ
  • Điểm xuất phát là sự không khớp chỉ mục mảng trong Batch API có từ WordPress 5.6; bằng cách kết hợp các yêu cầu Batch đệ quy, nó vượt qua giới hạn GET và kiểm tra tham số
  • Sau khi gây UNION injection bằng chuỗi author_exclude chưa được kiểm tra, chuỗi này đưa bài viết đã thao túng vào bộ nhớ đệm trong RAM rồi lần lượt lạm dụng oEmbed cache, changeset, tham chiếu vòng và hook
  • Với user_id: 1 trong customize_changeset, nó tạm thời giành quyền quản trị viên, dùng hook parse_request để chạy lại yêu cầu Batch nhằm tạo quản trị viên mới, rồi tải lên ZIP plugin backdoor để đạt được thực thi mã
  • Chi phí tính theo tỷ lệ 50% hạn mức sử dụng hằng tuần của gói thuê bao 200 đô la/tháng là khoảng 25 đô la; vai trò của con người có khả năng sẽ chuyển sang chỉ đạo nghiên cứu ở cấp cao hơn như chọn sản phẩm, bề mặt tấn công và tinh chỉnh prompt

Quá trình phát hiện và điều kiện thử nghiệm

  • Prompt mà OpenAI công bố là đã dùng để giải quyết giả thuyết Cycle Double Cover được sửa đổi cho nghiên cứu bảo mật và đưa cho GPT5.6 Sol Ultra
  • Sao chép phiên bản ổn định mới nhất của WordPress vào main/, xóa thư mục .git, đồng thời chuẩn bị một thư mục third_party/ rỗng để có thể khảo sát mã phụ thuộc
  • Prompt yêu cầu dùng tối đa 4 agent chạy song song và duy trì nhiều hướng tấn công khác nhau trong ít nhất 6 giờ
    • Khám phá parsing đầu vào, bộ ký tự, tải tệp lên, xử lý lỗi, đường dẫn tích hợp, serialization, cache, race condition, mã hóa, kiểu dữ liệu, mass assignment, v.v.
    • Ghi nhận các họ cách tiếp cận; nếu agent dồn vào một chiến lược cụ thể thì phân bổ lại sang những vùng ít được khám phá hơn
    • Các lỗi cụ thể được agent đối kháng xác minh lại, và cả những hướng đã thất bại cũng được mở lại nếu xuất hiện cơ chế mới
  • Bị giới hạn phải tìm lỗ hổng mới từ chính mã nguồn, không dùng lịch sử thay đổi, khác biệt với bản vá hay manh mối trên Internet
  • Để tránh cấu hình phi thực tế hoặc tiền đề mà kẻ tấn công không thể đáp ứng, mục tiêu được nêu rõ là “RCE trước xác thực trên triển khai production thông thường dùng MySQL”
  • Sau khoảng 6 giờ, mô hình tìm ra SQL injection trước xác thực; việc tái hiện trên máy chủ WordPress từ xa mặc định đã trích xuất email quản trị viên trong vài phút
  • Khi yêu cầu nâng cấp lên RCE, khoảng 4 giờ sau mô hình hoàn thiện chuỗi từ SQL injection chỉ đọc lên quyền quản trị viên mà không cần cracking mật khẩu hay tính toán offline
  • Tổng thời gian làm việc là hơn 10 giờ một chút, tiêu thụ 50% hạn mức hằng tuần. Chi phí tính tỷ lệ từ gói thuê bao 200 đô la/tháng là khoảng 25 đô la
  • Trước khi công bố, người vận hành được cho thời gian cuối tuần để nâng cấp WordPress; trong thời gian đó Calif và Hacktron đã tái hiện độc lập toàn bộ chuỗi trước các PoC khác trên GitHub
  • Các instance đang vận hành có thể kiểm tra khả năng bị ảnh hưởng tại wp2shell.com

Sự không khớp kiểm tra trong Batch API

  • Batch API được giới thiệu trong WordPress 5.6 xử lý nhiều yêu cầu API ảo trong một yêu cầu duy nhất. Bản thân endpoint có thể truy cập không cần xác thực, nhưng thông tin xác thực được truyền cho từng yêu cầu con
  • Một yêu cầu REST thông thường được xử lý theo thứ tự sau
    • Kiểm tra giá trị bắt buộc và tính hợp lệ bằng has_valid_params()
    • Làm sạch giá trị bằng sanitize_params()
    • Chạy callback phân quyền
    • Chạy callback endpoint
  • Vì hiệu năng, Batch API tách kiểm tra và thực thi thành hai vòng lặp
    • Vòng lặp đầu tiên kiểm tra và làm sạch tất cả yêu cầu
    • Vòng lặp thứ hai kiểm tra kết quả kiểm tra rồi chạy callback phân quyền và endpoint
  • Phần triển khai giả định các chỉ mục tương ứng trong $matches, kết quả khớp route, và $validation, kết quả kiểm tra
  • Nếu một yêu cầu sai đi vào nhánh is_wp_error($single_request), một mục được thêm vào $validation, nhưng do continue nên không được thêm vào $matches
    • Sau đó mọi mục trong $matches bị lệch một ô
    • Có thể kiểm tra tham số của một yêu cầu bằng quy tắc của yêu cầu khác, rồi thực thi trong handler endpoint vốn không được dự định
  • Bằng cách lợi dụng sự không khớp chỉ mục này, có thể áp dụng kết quả kiểm tra của một endpoint khác không làm sạch tham số lên endpoint hỗ trợ Batch

SQL injection phát sinh từ author__not_in

  • GET /wp/v2/posts dùng biến truy vấn nội bộ author__not_in để loại trừ một số tác giả khỏi kết quả
  • Nếu giá trị là mảng, từng phần tử được áp dụng absint để chuyển thành số nguyên; nhưng nếu là giá trị vô hướng thì được implode nguyên dạng rồi chèn vào mệnh đề NOT IN của SQL
  • Khi gọi bình thường, tham số công khai author_exclude phải là mảng số nguyên nên vấn đề không lộ ra
  • Lợi dụng sự không khớp chỉ mục Batch, có thể kiểm tra chuỗi author_exclude bằng quy tắc DELETE /wp/v2/posts/1, vốn không nhận biết nó, rồi truyền sang GET /wp/v2/posts
  • Ràng buộc Batch API không cho phép yêu cầu con GET cũng được vượt qua bằng lời gọi Batch đệ quy
    • Ở Batch bên ngoài, gây lệch chỉ mục để bỏ qua kiểm tra method của yêu cầu bên trong
    • Ở Batch bên trong, lại gây lệch chỉ mục để vượt qua kiểm tra author_exclude
  • Chèn giá trị như 0) OR 1=1 -- sẽ trả về tất cả hàng bài viết, qua đó xác nhận có injection
  • Sau đó có thể dùng UNION-based injection để tạo hàng có cùng dạng với wp_posts và rò rỉ giá trị cơ sở dữ liệu tùy ý
  • Mật khẩu, token đặt lại, API key, v.v. được hash trong cơ sở dữ liệu, nên nếu mật khẩu quản trị viên không yếu thì chỉ rò rỉ dữ liệu chưa đủ để chiếm tài khoản

Thao túng cache bài viết trong một yêu cầu

  • WordPress lưu các đối tượng WP_Post được tham chiếu lặp lại trong cùng một yêu cầu vào cache trong bộ nhớ để giảm lượt truy cập cơ sở dữ liệu
  • Nếu trả về hàng bài viết giả bằng UNION injection, kẻ tấn công có thể đưa vào cache nhiều trường do mình định sẵn như ID bài viết, kiểu, trạng thái, quan hệ cha, nội dung, v.v.
  • Phản hồi API cũng hậu xử lý nội dung bài viết, nên nội dung bị thao túng có thể kích hoạt thêm các đường đi mã khác
  • Cache này biến mất khi yêu cầu kết thúc và bài viết giả cũng không tồn tại trong cơ sở dữ liệu, nên chỉ thao túng cache thì không thể bảo đảm tính tồn tại giữa các yêu cầu

Tạo hàng cơ sở dữ liệu bằng oEmbed cache

  • Tính năng embeds của WordPress chèn nội dung từ xa được hỗ trợ bằng cú pháp [embed]...[/embed] trong nội dung bài viết
  • Để tránh gửi HTTP request mỗi lần, kết quả được lưu vào cơ sở dữ liệu dưới dạng bài viết kiểu oembed_cache trong wp_posts
  • Nếu embed một bài viết WordPress cục bộ bằng đường dẫn tương đối, HTTP request sẽ bị bỏ qua và không kiểm tra ID bài viết được tham chiếu có thực sự tồn tại hay không
  • Ngay cả khi embed bài viết cục bộ không tồn tại như /?p=10, một hàng oembed_cache cho dữ liệu đó vẫn có thể được tạo
  • Khi truy vấn lại hàng đã tạo bằng SQL injection và thao túng kiểu bài viết trong bộ nhớ thành post hay tương tự, biểu diễn trong cơ sở dữ liệu và trong cache sẽ khác nhau
  • Khi điều hòa hai biểu diễn này, WordPress gọi wp_update_post(), và với các trường ngoài ID và post_content được chỉ định rõ, nó ưu tiên các giá trị trong bộ nhớ do kẻ tấn công tạo
  • Nhờ đó có thể đổi hàng oembed_cache thành bài viết thông thường, nhưng trong lời gọi này post_content bị ghi đè bằng kết quả embed nên kẻ tấn công chưa kiểm soát được cả nội dung

Quyền quản trị viên tạm thời qua customize_changeset

  • Bản nháp thao tác tùy biến giao diện được lưu trong wp_posts dưới dạng bài viết đặc biệt kiểu customize_changeset
  • post_content chứa JSON gồm giá trị thay đổi theo từng khóa thiết lập, kiểu dữ liệu và ID người dùng thực hiện thay đổi
  • Khi áp dụng changeset, WordPress đọc user_id của từng mục và tạm thời đổi người dùng hiện tại bằng wp_set_current_user()
  • Nếu kẻ tấn công áp dụng changeset có user_id: 1, họ có thể tạm thời dùng danh tính quản trị viên ngay cả trong yêu cầu ẩn danh
  • Lời gọi điều hòa oEmbed ở trên ghi đè post_content, nên cần một đường gọi wp_update_post() riêng để bảo toàn JSON changeset độc hại

Bảo toàn nội dung bằng vòng lặp cha của bài viết

  • Bài viết WordPress có thể có một cha, nhưng không cho phép cấu trúc vòng lặp trong đó cha là chính nó hoặc bài viết con
  • Filter wp_insert_post_parent đi theo cây cha để kiểm tra vòng lặp; nếu phát hiện vòng lặp, nó gọi wp_update_post() để đổi post_parent của bài viết đó thành 0
  • Lời gọi thứ hai này chỉ chỉ định ID và post_parent, không ghi đè post_content
  • Nếu dùng SQL injection để ngụy trang bài viết trong bộ nhớ thành customize_changeset có cha là chính nó, quá trình khôi phục vòng lặp sẽ ghi JSON changeset độc hại do kẻ tấn công chỉ định vào cơ sở dữ liệu
  • Tạo changeset có trạng thái future nhưng ngày trong quá khứ sẽ khiến WordPress áp dụng nó, và theo user_id: 1 thực hiện thay đổi thiết lập được chỉ định với quyền quản trị viên
  • Quyền quản trị viên chỉ tồn tại trong khi xử lý changeset; sau khi hoàn tất sẽ trở lại quyền khách

Chạy lại toàn bộ yêu cầu bằng hook động

  • Hook của WordPress được chia thành action và filter, cho phép plugin can thiệp vào nhiều điểm trong vòng đời như đăng nhập, đăng bài, đăng ký script, v.v.
  • Khi trạng thái bài viết thay đổi, WordPress thực thi action động dạng "{$new_status}_{$post->post_type}"
    • Với bài viết bình thường, tên sẽ như publish_post
    • Với bài viết giả trong bộ nhớ, có thể tùy ý đặt trạng thái và kiểu, từ đó tạo tên action mong muốn có ít nhất một dấu gạch dưới
  • Đối số hook bị giới hạn ở ID bài viết do kẻ tấn công đặt và đối tượng WP_Post, nên khó gọi trực tiếp một action tùy ý theo cách hữu dụng
  • Chuỗi tấn công thao túng trạng thái thành parse và kiểu thành request để gọi hook parse_request
  • parse_request là hook chạy ở giai đoạn đầu vòng đời yêu cầu, nên gọi lại nó sẽ khiến toàn bộ yêu cầu Batch API ban đầu được xử lý lại từ đầu
  • Việc xử lý lại diễn ra khi danh tính quản trị viên tạm thời do changeset thiết lập vẫn còn hiệu lực, nên yêu cầu chỉ dành cho quản trị viên thất bại vì thiếu quyền ở lần chạy đầu sẽ thành công ở lần chạy thứ hai

Chuỗi RCE hoàn chỉnh bằng hai yêu cầu

  • Exploit cuối cùng dùng hai HTTP request và gán cho bài viết giả một ID đủ lớn để không xung đột với bài viết thật

  • Yêu cầu thứ nhất: chuẩn bị hàng tồn tại lâu dài

    • Trả về một bài viết giả có ba embed cục bộ bằng SQL injection, tạo 3 hàng oembed_cache tương ứng với O, C, D
    • Ba embed trỏ đến cùng bài viết S nhưng dùng chuỗi truy vấn khác nhau để tạo các hash oEmbed cache riêng biệt

  • Yêu cầu thứ hai: lắp ghép sáu bài viết

    • Cấu hình sáu bài viết giả sau trong cache bộ nhớ
    • O: cache cũ có trạng thái/kiểu là publish/oembed_cache và cha là C
    • C: có trạng thái/kiểu là future/customize_changeset, cha là chính nó và chứa JSON changeset độc hại
    • P: draft/page có cha là D
    • D: có trạng thái/kiểu là parse/request và cha là chính nó
    • S: publish/post cung cấp dữ liệu embed
    • T: publish/post chứa embed bên ngoài
    • Embed của T truy vấn O, và do thời điểm sửa đổi cũ, buộc cache của S được làm mới
    • Trong quá trình cập nhật O, nếu phát hiện vòng lặp ở cha C, nó đổi cha của C thành 0 và ghi customize_changeset trong bộ nhớ cùng JSON độc hại vào cơ sở dữ liệu
    • Changeset future có ngày trong quá khứ được áp dụng, đăng P dưới danh tính quản trị viên user_id: 1
    • Việc cập nhật P phát hiện vòng lặp ở cha D, ghi D, rồi với trạng thái và kiểu bị thao túng, gọi action parse_request
    • Yêu cầu Batch ngay từ đầu đã bao gồm yêu cầu tạo quản trị viên mới
    • Lần xử lý đầu thất bại vì đang ở quyền khách
    • Khi chạy lại qua parse_request, quyền quản trị viên tạm thời vẫn còn nên yêu cầu thành công
    • Sau khi đăng nhập bằng tài khoản quản trị viên mới, tải lên ZIP plugin backdoor để cuối cùng đạt được thực thi mã từ xa

Vai trò thay đổi trong nghiên cứu bảo mật bằng AI

  • Những bước đặc biệt sáng tạo trong toàn chuỗi là vượt qua giới hạn GET bằng lời gọi Batch đệ quy, kết hợp cache với changeset để lấy quyền quản trị viên, và gọi parse_request bằng bài viết giả để chạy lại yêu cầu
  • Dù không thể khẳng định ưu thế chung, đánh giá là nếu không có AI thì một nhà nghiên cứu bảo mật khó có thể phát hiện và hoàn thiện cùng chuỗi này trong vòng 10 giờ
  • Ngay cả khi được cung cấp trước lỗi Batch ban đầu, cũng khó chắc chắn có thể dựng được RCE trong khoảng thời gian đó
  • GPT5.6 Sol Ultra được đánh giá đã tiến bộ lớn so với GPT5.5 trước đó ở khả năng tìm nhiều gadget mã rời rạc và nối chúng thành một chuỗi
  • Khi mô hình đảm nhiệm ngày càng nhiều phần phát triển exploit kỹ thuật, con người sẽ tập trung vào việc chọn sản phẩm và bề mặt tấn công cần khảo sát, thời gian đầu tư, hướng nghiên cứu và sửa sai khi mô hình đi lệch
  • Năng lực nghiên cứu meta như vậy hiện AI vẫn chưa xử lý tốt, và được dự đoán sẽ càng quan trọng khi năng lực kỹ thuật của mô hình tăng lên

Bài viết liên quan

1 bình luận

 
GN⁺ 14 giờ trước
Ý kiến trên Hacker News

  • Không có căn cứ nào cho thấy 500.000 USD đã được, hoặc sẽ được, trả cho exploit kiểu này. Bài viết nói họ chỉnh sửa prompt cẩn thận như Kinh Thánh, vậy có lẽ nên bán luôn prompt đó với giá 500.000 USD thì hơn
    Tác giả làm việc tại https://www.assetnote.io/, nơi cung cấp sản phẩm AI quét tự động

    • Có lẽ là đang ám chỉ https://www.crowdfense.com/exploit-acquisition-program/. Zerodium cũng từng đưa ra mức tối đa 300.000 USD vào năm 2021: https://www.securityweek.com/sites/default/files/images/Zero...
      Các bên môi giới kiểu này thường không trả một khoản lớn một lần, mà bán quyền truy cập cho các tác nhân nhà nước rồi trả dần trong thời gian lỗi chưa được vá. Cấu trúc này nhằm ngăn việc bán lại hoặc bị khai thác cạn kiệt sớm, nên có lẽ rất ít người có thể xác nhận liệu một lỗ hổng tương tự có thực sự được nhận đủ toàn bộ số tiền hay không
    • Đã xóa 500.000 USD khỏi tiêu đề
    • Ngay cả trước thời LLM, giao điểm giữa những người vừa có khả năng tìm ra lỗ hổng như vậy, vừa sẵn sàng bán cho môi giới, lại vừa ngu ngốc đến mức treo trên mạng xã hội một tấm biển khổng lồ ghi hãy bắt tôi đi có lẽ là cực kỳ nhỏ
      Ví dụ gần nhất là mấy thiếu niên ở Florida bị bắt vì nhét mã độc vào game Steam để đánh cắp tài khoản. Dù sao thì chúng cũng sẽ bị bắt, nhưng nếu không khoe khoang trên mạng xã hội thì cuộc điều tra hẳn đã mất nhiều thời gian hơn nhiều
    • Việc ai đó mua một chiếc Macintosh từng có giá 5.000 USD khi mới ra mắt với giá 25 USD trên chợ đồ cũ không làm cho phép so sánh giá trị đó trở nên hợp lý
    • Nói chỉnh sửa như Kinh Thánh có phải ý là dù rõ ràng mâu thuẫn hoặc suy đồi về đạo đức thì cũng tuyệt đối không sửa không nhỉ

  • Nhìn vào https://github.com/WordPress/WordPress/commit/3a640e1c5e39aa... thì đến năm 2026 vẫn còn SQL injection do nối chuỗi

    • Điều nghiêm trọng hơn nằm ở https://developer.wordpress.org/plugins/creating-tables-with...
      Họ bảo dùng dbDelta thay vì chạy SQL trực tiếp, nhưng lại yêu cầu các quy tắc định dạng cực kỳ khó chịu như mỗi trường phải nằm trên một dòng riêng, giữa PRIMARY KEY phải có hai khoảng trắng, dùng KEY thay vì INDEX, v.v. Tên trường không được dùng dấu nháy hay backtick, kiểu dữ liệu phải viết thường, từ khóa SQL phải viết hoa, và mọi tham số độ dài cũng đều phải chỉ định
    • Codebase của WordPress ở mức đáng xấu hổ. PHP giờ đã trở thành một ngôn ngữ rất tốt, nhưng WordPress dùng nó một cách tệ hại và còn từ chối cải thiện
    • Cách sửa cũng kinh khủng. Thật thắc mắc liệu WordPress vẫn còn tạo truy vấn SQL bằng nối chuỗi cơ bản và sprintf hay không
    • Cuối tuần này tôi đã thấy một cuộc tấn công dùng exploit này trên một site đang vận hành
      Payload trong các yêu cầu POST và GET có dạng /wp/v2/widgets?author_exclude=1%29+AND+1%3D0+UNION+ALL+SELECT...
    • Hồ sơ ghi Principal Software Engineer @ Bluehost, WordPress Core Committer, nhưng với kiểu code này thì chữ “principal” nghe thật mỉa mai

  • Tôi chán kiểu viết gây FOMO rồi. Không phải chỉ với 25 USD là phát hiện được; ở đây còn có chuyên môn ngành để biết nên nhìn vào đâu, thăm dò thế nào, cùng dữ liệu tích lũy qua nhiều năm
    Nên thôi lan truyền những câu chuyện kiểu đánh bạc và ảo tưởng rằng ai cũng đang bỏ lỡ cơ hội

    • Những bài như thế này có hại, giống Instagram phiên bản bài báo, chỉ đăng khoảnh khắc thành công khiến cả cuộc đời trông thật hào nhoáng. Phép tính 25 USD bỏ qua không chỉ nhiều năm kinh nghiệm mà cả vô số thất bại
    • Cách tính chi phí cũng không chính xác. Đó chỉ là chi phí token được trợ cấp thông qua gói thuê bao, tức 25 USD
    • Nếu tự làm thì chắc đã không quảng bá là “làm được miễn phí”, nên việc chỉ vì đã tiêu 25 USD tiền token mà cách nhìn về thành quả thay đổi cũng thật kỳ lạ

  • Phần đáng kinh ngạc là mức giá cao của một lỗ hổng đã được biết đến, và chuyện đó cũng có thể không đúng. WordPress thường được gọi là remote root shell có kèm tính năng blog

    • Tôi vẫn khó hiểu vì sao blog lại không thể chỉ dùng trang tĩnh là đủ. Đặc biệt là phần lớn vấn đề của WordPress đang được “giải quyết” bằng cách thêm cache
      Tôi hiểu rằng hướng dẫn người dùng phổ thông kéo-thả thì dễ hơn bảo họ commit vào repo GitHub rồi build bằng Hugo. Nhưng nhìn từ góc độ bảo mật, đó là một cấu trúc chỉ chờ một lỗ hổng xuất hiện trong core hoặc một trong hàng nghìn plugin để mở ra thực thi mã từ xa dạng dịch vụ
    • Muốn biết có thật hay không thì phải làm threat intelligence và thâm nhập các nhóm Telegram nơi môi giới hoạt động, mà khả năng tác giả đã làm vậy là thấp. Cũng có thể đã nhầm giữa lỗ hổng thông thường và zero-day
    • WordPress là một trong những mục tiêu được gia cố bảo mật nhiều nhất từ trước đến nay. Cũng có thể xem rằng phần lớn lỗi đã được phát hiện và vá, vì code cũ hầu như không thay đổi trong nhiều thập kỷ
    • Cũng có thống kê rằng gần 50% website trên Internet dùng WordPress, nên mức 500.000 USD cho một zero-day RCE không cần xác thực chưa công khai không phải là quá phi thực tế

  • Bài viết thú vị, và phát hiện cũng như công bố exploit dựa trên LLM là vấn đề thực sự đáng lo. Tôi từng khiến một mô hình tạo khá nhanh mã thoát container từ một lỗ hổng leo thang đặc quyền cục bộ trên Linux
    Tuy vậy, việc GPT-5.6 không chặn prompt bằng cơ chế an toàn là điều đáng ngạc nhiên. Từ GPT-5.5 trở lên có xu hướng né các tác vụ bảo mật tấn công như Opus 4.7+/Fable, nên có vẻ tác giả có thể đã được OpenAI phê duyệt an ninh mạng để nới lỏng cơ chế an toàn

  • Các công cụ kiểm thử bảo mật ứng dụng tĩnh (SAST) không dùng AI trước năm 2020 cũng đã bắt được rất nhiều lỗi SQL injection kiểu này, và ít nhất lẽ ra nó phải được phát hiện trong quá trình review code. Tôi tự hỏi liệu WordPress có không dùng review code hay SAST không

    • Cuộc tấn công này cần kết hợp nhiều lỗ hổng, nên có lẽ chỉ các công cụ như vậy thì không bắt được

  • Một website của tôi đã bị hack bằng lỗ hổng này, nhưng may là đó là nơi không có người dùng
    Kẻ tấn công đã tạo hai tài khoản quản trị trong cơ sở dữ liệu, và cài một web shell thực thi lệnh từ xa wp-core-[12 ký tự ngẫu nhiên].php trong wp-content/plugins/wp-core. Trong mu-plugins, chúng đặt backdoor firewall.php tạo quản trị viên bằng GET ?sergei, thêm cả backdoor cache-seo-helper.php, và dùng fixer.php để sửa số phiên bản WordPress trông như đã được vá. Cuối cùng tôi quyết định từ bỏ việc dùng WordPress

  • Đến cuối bài, tác giả bắt đầu gọi các bài viết bằng những cái tên kỳ lạ nên khó hiểu. Tôi thắc mắc vì sao lại đặt một ID là O, ID khác là 0, và dùng một ký tự đơn cùng OCPDST trông như ngẫu nhiên thay vì EMBED_01 hay ABCDEF

    • Tất cả đều là placeholder, và ý nghĩa đã được ghi trong phần nội dung. O nghĩa là publish/oembed_cache, C là future/customize_changeset, P là draft/page, D là parse/request, S là publish/post cung cấp dữ liệu nhúng, còn T là publish/post chứa nội dung nhúng bên ngoài

  • Phải chăng đang giả định rằng những người có thể trả 500 nghìn đô la không có năng lực tự tận dụng GPT-5.6?

    • Nếu vậy thì nên nghĩ xem vì sao một bài phân tích tương tự không xuất hiện sớm hơn. Việc kiểm tra đầu ra của LLM và biến nó thành một bằng chứng khái niệm thực sự hợp lệ vẫn cần chuyên môn
      Tôi cũng dùng LLM để tìm lỗ hổng bảo mật, nhưng không thể cứ nộp nguyên kết quả rồi coi như xong; có rất nhiều người muốn làm như vậy
    • Ngày càng có nhiều bài báo nói rằng cơ quan điều tra đã lấy nhật ký LLM trên đám mây để dùng làm bằng chứng truy tố hình sự; nếu là tội phạm chuyên nghiệp, nhiều khả năng họ sẽ rửa hoạt động của mình thông qua các bên trung gian tuy phi đạo đức nhưng hợp pháp
    • Người kiếm ra tiền và người viết code giỏi nhất không nhất thiết là cùng một người. Elon Musk cũng không tự viết code cho tên lửa, mà thuê người viết

  • GPT-5.6 Sol có siêu phàm hay không không phải là câu hỏi đơn giản có/không. Máy tính đã vượt con người trong cờ vua từ vài chục năm trước, và nhìn vào bài này thì giờ đây dường như chúng cũng đã vượt con người trong việc hiểu code

    • Trong tính toán số học thì chúng đã vượt con người từ lâu hơn thế nhiều