Tài khoản GitHub ẩn danh công bố hàng loạt 0-day chưa được tiết lộ

 (github.com/bikini)
1 điểm bởi GN⁺ 4 giờ trước | 1 bình luận | Chia sẻ qua WhatsApp
  • Exploitarium là một kho GitHub tập hợp các proof-of-concept công khai và bài viết nghiên cứu lỗ hổng vào một nơi; các mục nghiên cứu mới được thêm dưới dạng thư mục tự chứa hoàn chỉnh
  • Kho chứa các thư mục PoC liên quan đến nhiều dự án như 7-Zip, AnyDesk, Docker, Firefox, FFmpeg, Ghidra, Gitea, ImageMagick, libssh2, Nmap, OpenVPN, PHP, RustDesk, VLC, v.v.
  • Các mục được chuyển từ những kho PoC độc lập trước đây vẫn giữ README gốc và các tệp được theo dõi; dựa trên bản fresh GitHub clone ngày 23/6/2026, đã xác minh 12 kho và 96 mục được theo dõi và không có sai lệch
  • Việc xác minh không dùng diff hệ thống tệp lỏng lẻo, mà so sánh dữ liệu Git tree; chỉ đạt khi đường dẫn tương đối, kiểu đối tượng Git, tree mode, bit thực thi và Git blob ID đều giống nhau
  • Tài liệu trong kho được nêu rõ là nghiên cứu lỗ hổng công khai với thiện chí và yêu cầu không sử dụng cho mục đích độc hại trong mọi trường hợp

Mục đích của kho Exploitarium

  • Exploitarium là một kho lưu trữ hợp nhất các proof-of-concept công khai và writeup nghiên cứu lỗ hổng
  • Phần lớn thư mục chứa các PoC từng tồn tại dưới dạng kho riêng trước đây, đồng thời giữ lại README gốc và các tệp được theo dõi
  • Các mục nghiên cứu mới được thêm trực tiếp vào kho này dưới dạng thư mục tự chứa hoàn chỉnh
  • Phần giới thiệu kho có cụm “New drops today ;) Biggest thing yet” và thông tin liên hệ Discord @ashdfrkl

Các PoC và mục nghiên cứu được bao gồm

  • Bảng Contents của kho liệt kê tổng cộng 23 thư mục
  • Các mục được lấy từ kho độc lập trước đây hiển thị commit hash làm Source
    • 7zip-rar5-motw-chain-poc
    • anydesk-printer-com-impersonation-poc
    • docker-cp-copyout-destination-escape
    • flowise-mcp-env-case-bypass-poc
    • ghidra-12.1.2-rce-ace-calc-poc
    • gitea-act-runner-container-options-poc
    • imagemagick-gs-delegate-hijack-poc
    • lunar-modrinth-chain-poc
    • mybb-limited-acp-to-admin
    • objdump-dlx-calc-poc
    • openvpn-connect-echo-script-ace-poc
    • vlc-vp9-reschange-crash-poc
  • Các mục được thêm trực tiếp hiển thị kèm ngày
    • c-ares-tcp-uaf-calc-poc: 24/6/2026
    • firefox-smartwindow-private-url-exfil-poc: 24/6/2026
    • floci-apigateway-vtl-rce-poc: 23/6/2026
    • ffmpeg-rasc-dlta-calc-poc: 26/6/2026
    • libssh2-cve-2026-55200-poc: 23/6/2026
    • libssh2-publickey-list-calc-poc: 25/6/2026
    • nghttp2-nghttpx-upgrade-queue-poison-poc: 26/6/2026
    • nmap-ipv6-extlen-wrap-poc: 23/6/2026
    • php857-streambucket-soap-rce-rpoc: 26/6/2026
    • rustdesk-session-permission-pocs: 25/6/2026
    • systeminformer-phsvc-trusted-host-lpe-poc: 24/6/2026

Phương thức xác minh khi hợp nhất

  • Consolidation Check được áp dụng cho các mục từ kho độc lập trước đây được liệt kê bằng commit hash
  • Việc xác minh được thực hiện trên bản fresh GitHub clone vào 23/6/2026, trước khi các kho độc lập trước đây bị gỡ bỏ
  • Cách so sánh là đối chiếu HEAD tree của từng kho độc lập với thư mục tương ứng trong Exploitarium bằng dữ liệu Git tree
  • Mỗi mục được theo dõi phải đáp ứng các điều kiện sau
    • Cùng đường dẫn tương đối
    • Cùng kiểu đối tượng Git
    • Cùng tree mode, bao gồm bit thực thi
    • Cùng Git blob ID
  • Cùng Git blob ID nghĩa là các byte của tệp được theo dõi giống hệt nhau

Kết quả xác minh và phạm vi bảo tồn

  • Việc xác minh được thực hiện trên 12 kho và 96 mục được theo dõi, với 0 sai lệch
  • Kho bảo tồn nội dung của các PoC đó
  • Metadata của các kho riêng vẫn nằm trong lịch sử kho gốc
    • stars
    • issues
    • pull requests
    • releases
    • separate Git history
  • Các mục được thêm trực tiếp được theo dõi bằng commit history của kho này

Hạn chế sử dụng

  • Kho nêu rõ rằng không được sử dụng tài liệu cho mục đích độc hại trong bất kỳ tình huống nào
  • Kho cho biết mục đích của tài liệu là nghiên cứu lỗ hổng công khai với thiện chí và thu hút thêm nhiều người quan tâm đến lĩnh vực này của an ninh mạng
  • Cụm “Cybercrime is cringe” được dùng để nhấn mạnh việc cấm lạm dụng

Bài viết liên quan

1 bình luận

 
GN⁺ 4 giờ trước
Các ý kiến trên Hacker News

  • Tôi đã tự dùng và xem xét phần Ghidra, nhưng không ấn tượng lắm: https://github.com/bikini/exploitarium/blob/main/ghidra-12.1...
    Cái đầu tiên yêu cầu phải có khả năng ghi đè binary trong thư mục công cụ Swift. Nếu ghi đè binary mà Ghidra chạy thì việc thực thi mã xảy ra là điều hiển nhiên
    Cái thứ hai thì tôi không rành TraceRMI nên khó đánh giá, nhưng đáng lưu ý là “RMI” là gọi phương thức từ xa (Remote Method Invocation)
    Cái thứ ba khó có thể xem là lỗ hổng, nó chỉ cho thấy có thể chạm tới mã parser 7zip native. Parser 7zip có thể có bug, nhưng nếu không có bug thì chuyện đó vô nghĩa

    • Phần nmap thì nhìn lướt qua có vẻ có khả năng mức độ nghiêm trọng cao. Thực tế có thể chẳng có gì, nhưng vì nằm quanh mã parser nên khả năng tạo luồng nhảy là khá lớn
      Sẽ khá mỉa mai nếu có thể lấy reverse shell từ người đang chạy quét nmap. Nếu token là vô hạn, có lẽ tôi sẽ bảo Claude viết exploit rồi đào lịch sử xem ai đã làm cho việc đó khả thi
      Phỏng đoán sơ bộ rằng có thể thực thi mã tùy ý (ACE), thì đây gần như là bug mà các cơ quan tình báo sẽ thèm muốn: nếu người quan sát dùng nmap, chỉ vài gói IPv6 có thể thay đổi trace đang bị quan sát hoặc giúp truy cập vào PC của nhà nghiên cứu đang dùng nmap
    • Sẽ khá buồn cười nếu tất cả những thứ này thực ra đều là các CVE đã biết, bên trong giấu Shai-Hulud tiếp theo, rồi chờ những người đam mê bảo mật vội vàng tải về và bị lây nhiễm
    • Vụ Ghidra thì khá yếu, nhưng tôi kiểm tra các phần c-ares, libssh2, ffmpeg mà mình quan tâm thì thấy lạ là tất cả dường như vẫn hoạt động ngay cả trên commit upstream mới nhất
    • Nghe những câu kiểu “nếu ghi đè binary mà Ghidra chạy thì sẽ thực thi mã”, “RMI là gọi phương thức từ xa”, tôi nhớ tới chuyện có người nộp một báo cáo lỗ hổng rõ ràng là vibe-code, tuyên bố đã tìm ra cách thực thi SQL tùy ý
      Dự án mục tiêu là một SQL server: https://github.com/tursodatabase/turso/pull/4322
    • Vụ Gitea hơi thú vị, nhưng có vẻ khó khai thác thực tế. Chỉ có vẻ hợp lý nếu Gitea hoặc hệ thống khác không cô lập công việc đúng cách trong VM riêng
      GitHub Actions có lẽ cũng sẽ có hành vi tương tự, và dường như không xem đó là có thể khai thác vì giả định người dùng vốn đã có quyền root cục bộ không bị cô lập bằng namespace

  • Tôi đã xem khá kỹ vài cái, nhưng chúng không thú vị đến vậy. Vụ Docker chỉ là một bug kỳ quặc chứ không phải lỗ hổng, và đặc biệt cũng không đáng gọi là “0-day”
    Vụ nghttpx của nghttp2 thú vị hơn và có thể dùng cho phishing, nhưng hàng đợi request không mang tính xác định nên gần như không thể nhắm trúng một nạn nhân cụ thể
    Vụ VLC chỉ là crash/bug rõ ràng. VLC vốn đã hay crash khi dùng codec kỳ lạ, nên không có gì mới
    Không biết tôi có bỏ sót gì không

    • Nếu VLC crash trên máy tôi, và nếu tôi đến mức phải cảm tạ Chúa mỗi ngày vì thực tế là tôi không dùng VLC, thì có lẽ tôi sẽ rút điện ngay và nghiêm túc nghĩ xem trong điều kiện nào bật lại máy mới an toàn

  • Có vẻ cần một phân loại mới kiểu 0-days-vibes-vulns. Trong thế giới lỗ hổng mới mẻ dũng cảm này, sẽ tốt nếu có một nhãn giúp phát hiện và xử lý dấu gạch ngang em dash, để những hóa thạch già như tôi vẫn chỉ phải ngẩng đầu trước các lỗ hổng thủ công, được chế tác tỉ mỉ theo kiểu nghệ nhân
    Cảm giác như nhãn trứng nuôi thả vậy

    • Đây là phần khó chịu nhất trong thế giới ngày nay. Mọi em dash giờ đều bị xem như tín hiệu AI. Ngày xưa, đó là dấu hiệu rất được kính trọng trong dân tộc chúng ta
    • Cái đó thậm chí còn không phải em dash, vậy mà chỉ riêng chuyện đó đã tạo ra một thread khổng lồ
    • “Và làm ơn đừng dùng M dash khi viết”… prompt cứ tiếp tục lê thê suốt một giờ về các kết quả rác

  • AI luôn có xu hướng báo cáo mọi thứ như một issue. Vì “số lượng” phát hiện được xem như thước đo trí thông minh
    Trong code review cũng vậy, nó báo rất nhiều non-issue. Output của Mythos có thể cũng bị thổi phồng theo cách đó, và điều khiến mọi người giật mình có thể là số issue được báo cáo chứ không phải mức độ nghiêm trọng

    • Tôi là nhà phát triển mã nguồn mở và trong 2 tuần qua đã nhận ba cảnh báo “CWE”. Tất cả đều đúng, nhưng chỉ là những thứ rất nhỏ như “nếu file log debug này là symlink thì có thể ghi đè file”, “nếu người dùng có thể chèn mã màn hình OSC vào output Git thì có thể ghi dữ liệu tùy ý lên màn hình”
      Các mô hình AI này đang khiến mọi thứ nghe như exploit. Không biết điều đó có tốt cho hệ sinh thái không
      Giờ tôi nhìn mọi thứ gửi đến với nhiều nghi ngờ hơn. Đây là exploit thật, hay chỉ là tích thành tích để nói “tuần trước chúng tôi mở 39 CWE, hãy thuê công ty ‘bảo mật’ của chúng tôi audit mã”
    • Điều đó khác với những gì tôi nghe từ những người đã làm việc trực tiếp với Mythos. Tôi nghe nói các lỗ hổng được tạo ra nhìn chung là có thật và có ý nghĩa

  • Tất cả những thứ này có thật sự là 0-day không? Khá nhiều cái có vẻ đến từ CVE đã công khai hoặc mã đã được sửa ở upstream
    Ngày nay thuật ngữ “0-day” hầu như đã mất phần lớn ý nghĩa, và có vẻ nhiều người dùng nó để chỉ bất kỳ exploit nào

    • Repository tuyên bố như sau
      “Đây là một kho lưu trữ thống nhất các PoC exploit công khai và bài viết nghiên cứu lỗ hổng. Tại thời điểm tôi đăng, chưa có gì được báo cáo. Bạn có thể tự báo cáo và nhận công nếu có CVE lulz. Đừng lạm dụng. Tôi làm vậy để kéo thêm nhiều người vào lĩnh vực này, và luôn cho rằng đây là cách hiệu quả nhất”
      Đại khái cũng gần với định nghĩa zero-day. Nội dung repository có khớp với tuyên bố đó hay không là một vấn đề hoàn toàn riêng
    • Trong tình huống như thế này, RCE cũng đã mất ý nghĩa. Phần “từ xa” thường, nếu có nghĩa, là kiểu phiên SSH root

  • Khi AI trở nên đủ tinh vi để tìm ra những thứ như thế này, các tài liệu kiểu này sẽ còn ồ ạt xuất hiện trong một thời gian. Tôi nghĩ khi các lỗ hổng thật sự được vá thì tự nhiên sẽ giảm bớt
    Tất nhiên lúc nào cũng sẽ còn lại ở mức nào đó, nhưng mức độ sẽ thấp hơn và các exploit được phát hiện sẽ ngày càng phức tạp hơn. Hiện giờ là giai đoạn chuyển tiếp

    • Tôi nghĩ cách nói “AI đủ thông minh để tìm ra” dễ gây hiểu lầm. Không phải nó “thông minh hơn”, mà là nó được tinh chỉnh phù hợp hơn cho các mục đích cụ thể, có các bộ dữ liệu được chọn lọc tốt hơn, harness tốt hơn, prompt tốt hơn, gán nhãn kết quả tốt hơn, và tích lũy tài liệu về thất bại cũng như thành công
      Hy vọng kết quả nói chung sẽ tốt hơn, nhưng những cách diễn đạt nhân cách hóa như vậy khiến người ta có cảm giác bản thân AI somehow đang thay đổi hay tiến hóa
      Trên thực tế, giới học thuật làm nghiên cứu nền tảng, ngành công nghiệp thương mại hóa, và các nhà nghiên cứu bảo mật đóng gói công cụ và quy trình thành dịch vụ đang chủ động làm cho mọi thứ tốt hơn. Không có một “thứ đó” độc lập nào cả
    • Có vẻ chúng ta đã ở ngay giữa giai đoạn đó rồi, nhưng thay vì giảm đi, việc “báo cáo” trở nên ồn ào và mơ hồ hơn, khiến việc đánh giá mức độ đe dọa thực tế hay vector tấn công khó hơn
    • Mọi bản cập nhật phần mềm đều tạo ra hoặc đưa trở lại những lỗ hổng như vậy
    • Thành thật mà nói, độ phức tạp khi thực thi cũng đang ngày càng trở thành rào cản thấp hơn theo thời gian

  • Trông như có ai đó đang chạy một mô hình ngôn ngữ lớn rồi công bố kết quả. Có đủ thứ lẫn lộn, từ những điều buồn cười kiểu “thay đổi binary hệ thống là thực thi mã tùy ý!” cho đến những thứ có thể là thật, nên mới có cảm giác như vậy
    Đây là kết quả thường thấy khi ném cho LLM một prompt kiểu “tìm exploit và viết PoC”
    Nếu huấn luyện nó bằng các báo cáo Metasploit trong 15 năm qua, có lẽ nó sẽ tìm được những lỗi tương tự mà người ta lại viết vào mã mới
    [1] https://en.wikipedia.org/wiki/Metasploit

  • Có dòng nói rằng trong bất kỳ hoàn cảnh nào cũng không được dùng tài liệu trong repository này cho mục đích xấu. Họ nói đây là nghiên cứu lỗ hổng công khai với thiện chí, nhằm khiến nhiều người hơn quan tâm đến việc khám phá lĩnh vực an ninh mạng này
    Nó làm tôi nhớ đến kiểu thông điệp trước một công thức nào đó trong The Anarchist Cookbook: “Cái này thật sự nguy hiểm nên tuyệt đối đừng làm. Cách làm như sau”

    • Chẳng phải trong cuốn sách cũ đó không có chữ “…với mục đích xấu” sao?

  • Với tư cách lỗ hổng bảo mật thì không mấy ấn tượng. Phần lớn nên gọi đơn giản là bug thì đúng hơn

    • Không đồng ý. Thực thi mã trong FFmpeg thật sự rất độc hại
    • Mọi lỗ hổng rốt cuộc cũng chỉ là bug

  • Trông như có sự pha trộn giữa các bản sao viết lại từ CVE hiện có và những lỗ hổng mới có mức độ nghiêm trọng thấp. Tôi gọi là nghiêm trọng thấp vì có vẻ người dùng vốn đã phải thực hiện những hành động về bản chất là nguy hiểm
    Ý kiến 2 xu sau khi lướt nhanh
    Dù vậy, đúng là các phát hiện này vẫn thú vị. Tôi nghĩ một số có thể trở nên nghiêm trọng hơn nếu được chain lại
    Ví dụ, với vụ ovpn, có thể kết hợp việc đăng ký ứng dụng VPN làm ứng dụng mở mặc định trên Windows, hoặc đăng ký nó làm trình xử lý giao thức cho vị trí URL kiểu openvpn://, rồi ghép với iframe và một chút social engineering tinh vi. Chỉ là ý nghĩ chợt nảy ra

    • Đó là điểm gây bối rối. Một số có vẻ chỉ là nhiễu mức thấp, nhưng một số thì thật sự chí mạng
      Các vụ Floci, libssh2, c-ares, FFmpeg, PHP đều trông có vẻ là thật
      Còn vụ Ghidra thì không hẳn. Tôi tự hỏi liệu đây có phải là một thư mục nghiên cứu còn dở dang một nửa, rồi cứ thế bị công khai không