บัญชี GitHub นิรนามเผยแพร่ 0-day ที่ยังไม่เปิดเผยจำนวนมาก

• Exploitarium เป็น repository บน GitHub ที่รวบรวม proof-of-concept สาธารณะและบทความวิจัยช่องโหว่ไว้ในที่เดียว โดยรายการงานวิจัยใหม่จะถูกเพิ่มเป็นโฟลเดอร์แบบ self-contained
• repository นี้มี โฟลเดอร์ PoC ที่เกี่ยวข้องกับหลายโปรเจกต์ เช่น 7-Zip, AnyDesk, Docker, Firefox, FFmpeg, Ghidra, Gitea, ImageMagick, libssh2, Nmap, OpenVPN, PHP, RustDesk, VLC เป็นต้น
• รายการที่ย้ายมาจาก repository PoC เดี่ยวเดิมยังคงเก็บ README ต้นฉบับและไฟล์ที่ติดตามไว้ และจาก fresh GitHub clone ณ วันที่ 23 มิถุนายน 2026 ได้ตรวจสอบ 12 repository และ 96 รายการที่ติดตาม แล้วว่าไม่มีความไม่ตรงกัน
• การตรวจสอบไม่ได้ใช้ filesystem diff แบบหลวม ๆ แต่เปรียบเทียบข้อมูล Git tree โดยต้องมี relative path, ประเภท Git object, tree mode, executable bit และ Git blob ID เหมือนกันทั้งหมดจึงจะผ่าน
• เนื้อหาใน repository ระบุว่าเป็นงานวิจัยช่องโหว่สาธารณะโดยเจตนาดี และกำหนดว่า ห้ามใช้ในทางประสงค์ร้าย ไม่ว่ากรณีใด ๆ

---

วัตถุประสงค์ของ repository Exploitarium

• Exploitarium เป็น archive ที่รวม proof-of-concept สาธารณะและ writeup งานวิจัยช่องโหว่ไว้ด้วยกัน
• โฟลเดอร์ส่วนใหญ่บรรจุ PoC ที่เคยอยู่เป็น repository แยกต่างหาก และยังคงเก็บ README ต้นฉบับกับไฟล์ที่ติดตามไว้
• รายการงานวิจัยใหม่จะถูกเพิ่มโดยตรงภายใน repository นี้เป็น โฟลเดอร์แบบ self-contained
• คำอธิบาย repository มีข้อความ “New drops today ;) Biggest thing yet” และช่องทางติดต่อ Discord @ashdfrkl

PoC และรายการงานวิจัยที่รวมอยู่

• ตาราง Contents ของ repository แสดงรายการทั้งหมด 23 โฟลเดอร์
• รายการที่นำมาจาก repository เดี่ยวเดิมแสดง commit hash เป็น 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-ares-tcp-uaf-calc-poc: 24 มิถุนายน 2026
  • firefox-smartwindow-private-url-exfil-poc: 24 มิถุนายน 2026
  • floci-apigateway-vtl-rce-poc: 23 มิถุนายน 2026
  • ffmpeg-rasc-dlta-calc-poc: 26 มิถุนายน 2026
  • libssh2-cve-2026-55200-poc: 23 มิถุนายน 2026
  • libssh2-publickey-list-calc-poc: 25 มิถุนายน 2026
  • nghttp2-nghttpx-upgrade-queue-poison-poc: 26 มิถุนายน 2026
  • nmap-ipv6-extlen-wrap-poc: 23 มิถุนายน 2026
  • php857-streambucket-soap-rce-rpoc: 26 มิถุนายน 2026
  • rustdesk-session-permission-pocs: 25 มิถุนายน 2026
  • systeminformer-phsvc-trusted-host-lpe-poc: 24 มิถุนายน 2026

วิธีตรวจสอบการรวมศูนย์

• Consolidation Check ใช้กับรายการจาก repository เดี่ยวเดิมที่ระบุด้วย commit hash
• การตรวจสอบดำเนินการกับ fresh GitHub clone เมื่อวันที่ 23 มิถุนายน 2026 ก่อนที่จะลบ repository เดี่ยวเดิม
• วิธีเปรียบเทียบคือเทียบ HEAD tree ของแต่ละ repository เดี่ยวกับโฟลเดอร์ที่สอดคล้องกันภายใน Exploitarium โดยใช้ข้อมูล Git tree
• แต่ละรายการที่ติดตามต้องตรงตามเงื่อนไขต่อไปนี้
  • relative path เดียวกัน
  • ประเภท Git object เดียวกัน
  • tree mode เดียวกัน รวมถึง executable bit
  • Git blob ID เดียวกัน
• Git blob ID เดียวกันหมายความว่า ไบต์ของไฟล์ที่ติดตามเหมือนกัน

ผลการตรวจสอบและขอบเขตการเก็บรักษา

• การตรวจสอบครอบคลุม 12 repository และ 96 รายการที่ติดตาม และพบความไม่ตรงกัน 0 รายการ
• repository นี้เก็บรักษาเนื้อหาของ PoC เหล่านั้นไว้
• metadata ของ repository แยกยังคงอยู่ในประวัติของ repository ต้นฉบับ
  • stars
  • issues
  • pull requests
  • releases
  • separate Git history
• รายการที่เพิ่มโดยตรงจะถูกติดตามผ่าน commit history ของ repository นี้

ข้อจำกัดการใช้งาน

• repository ระบุว่าไม่ควรนำเนื้อหาไป ใช้ในทางประสงค์ร้าย ไม่ว่าในสถานการณ์ใด
• ระบุว่าวัตถุประสงค์ของเนื้อหาคือการวิจัยช่องโหว่สาธารณะโดยเจตนาดี และเพื่อให้ผู้คนสนใจด้านที่เกี่ยวข้องของไซเบอร์ซีเคียวริตี้มากขึ้น
• เน้นย้ำการห้ามนำไปใช้ในทางที่ผิดด้วยข้อความ “Cybercrime is cringe”

[GN⁺]

ความคิดเห็นใน Hacker News

• ฝั่ง Ghidra ผมลองเขียนเองแล้วดูคร่าว ๆ ไม่ค่อยน่าประทับใจเท่าไร: https://github.com/bikini/exploitarium/blob/main/ghidra-12.1...
  ข้อแรกคือต้องสามารถเขียนทับไบนารีในไดเรกทอรีเครื่องมือ Swift ได้ ถ้าเขียนทับไบนารีที่ Ghidra เรียกใช้งานได้ การรันโค้ดก็เป็นเรื่องแน่นอนอยู่แล้ว
  ข้อสอง ผมไม่ค่อยรู้เรื่อง TraceRMI เลยตัดสินยาก แต่ก็น่าชี้ว่า “RMI” คือการเรียกเมธอดจากระยะไกล (Remote Method Invocation)
  ข้อสามดูไม่นับเป็นช่องโหว่ แค่แสดงให้เห็นว่าสามารถไปถึงโค้ด 7zip parser แบบเนทีฟได้ ตัว 7zip parser อาจมีบั๊กก็จริง แต่ถ้าไม่มีบั๊กนั้นก็ไม่มีความหมาย

  • ฝั่ง nmap ผมไล่ดูแล้ว ดูเหมือนอาจมี ความรุนแรงสูง ได้ แม้ของจริงอาจไม่มีอะไรมาก แต่เพราะอยู่แถวโค้ด parser จึงมีโอกาสพอสมควรที่จะสร้าง flow การกระโดดได้
    ถ้าสามารถได้ reverse shell จากคนที่กำลังสแกนด้วย nmap ก็คงประชดประชันดี ถ้าโทเคนไม่จำกัด ผมคงให้ Claude เขียน exploit แล้วไปขุดประวัติว่าใครทำให้มันเกิดขึ้นได้
    เดาแบบหยาบ ๆ ว่าถ้ารันโค้ดตามอำเภอใจ (ACE) ได้จริง ก็ค่อนข้างเป็น บั๊กที่หน่วยข่าวกรองอยากได้ เช่น ใช้แพ็กเก็ต IPv6 ไม่กี่ชุดเพื่อเปลี่ยน trace ที่ผู้สังเกตกำลังจับอยู่ในกรณีที่ผู้สังเกตใช้ nmap หรือเข้าถึงพีซีของนักวิจัยที่ใช้ nmap ได้
  • ถ้าทั้งหมดนี้เป็น CVE ที่รู้กันอยู่แล้ว แล้วข้างในซ่อน Shai-Hulud ตัวถัดไปไว้ รอให้พวกสายงานอดิเรกด้านความปลอดภัยรีบดาวน์โหลดแล้วติดเชื้อ ก็คงตลกดีไม่น้อย
  • เคส Ghidra ค่อนข้างอ่อน แต่พอเช็กฝั่ง c-ares, libssh2, ffmpeg ที่ผมสนใจ ดูเหมือนว่าทั้งหมดจะยังทำงานได้แม้เทียบกับคอมมิต upstream ล่าสุด เลยแปลกอยู่
  • เห็นคำพูดอย่าง “ถ้าเขียนทับไบนารีที่ Ghidra เรียกใช้ได้ ก็รันโค้ดได้” หรือ “RMI คือการเรียกเมธอดจากระยะไกล” แล้วนึกถึงกรณีที่มีคนส่งรายงานช่องโหว่ที่เห็นชัดว่า vibe-coded มา แล้วอ้างว่าพบวิธีรัน SQL ตามอำเภอใจ
    โปรเจกต์เป้าหมายคือ SQL server: https://github.com/tursodatabase/turso/pull/4322
  • เคส Gitea น่าสนใจนิดหน่อย แต่ดูเหมือนจะนำไปใช้โจมตีจริงได้ยาก เว้นแต่ Gitea หรือระบบอื่นจะแยกงานใน VM เฉพาะไม่ถูกต้อง ถึงจะดูเป็นไปได้
    GitHub Actions ก็น่าจะทำงานคล้ายกัน และดูเหมือนจะไม่ถือว่า exploit ได้ เพราะสมมติว่าผู้ใช้มีสิทธิ์ root ในเครื่องอยู่แล้วโดยไม่ได้ถูกแยกด้วย namespace ภายในเครื่อง

• ผมดูอยู่หลายอันค่อนข้างละเอียด แต่ก็ไม่ได้ดูน่าสนใจนัก เคส Docker เป็นแค่บั๊กแปลก ๆ ไม่ใช่ช่องโหว่ และโดยเฉพาะก็ไม่ใช่อะไรที่ควรเรียกว่า “0-day”
  เคส nghttpx ของ nghttp2 น่าสนใจกว่าและอาจใช้กับฟิชชิงได้ แต่คิวคำขอเป็นแบบไม่กำหนดแน่นอน การเล็งเหยื่อเฉพาะรายจึงแทบเป็นไปไม่ได้
  เคส VLC ก็เป็นแค่ crash/บั๊กชัด ๆ อยู่แล้ว VLC ใช้โค้ดेकแปลก ๆ ก็ crash บ่อยเป็นปกติ ไม่ใช่เรื่องใหม่
  ไม่รู้ว่าผมพลาดอะไรไปหรือเปล่า

  • ถ้า VLC crash บนเครื่องผม และถ้าถึงขั้นที่ผมควรขอบคุณพระเจ้าทุกวันเพราะไม่ได้ใช้ VLC ผมก็คงดึงปลั๊กทันที แล้วคิดอย่างจริงจังว่าในเงื่อนไขแบบไหนถึงจะเปิดเครื่องใหม่ได้อย่างปลอดภัย

• ดูเหมือนต้องมีหมวดใหม่อย่าง 0-days-vibes-vulns แล้วล่ะ ในโลกช่องโหว่ใหม่อันกล้าหาญใบนี้ คงดีถ้ามีป้ายกำกับที่ช่วยตรวจจับและจัดการ em dash เพื่อให้ฟอสซิลเก่าอย่างผมยังเงยหน้าสนใจเฉพาะช่องโหว่แบบงานช่าง ทำด้วยมืออย่างประณีตได้
  ให้ความรู้สึกเหมือนป้ายไข่จากแม่ไก่เลี้ยงปล่อย

  • นี่เป็นส่วนที่น่ารำคาญที่สุดในโลกยุคนี้ em dash ทุกตัวถูกมองเหมือนเป็นสัญญาณ AI ไปหมดแล้ว สมัยก่อนในหมู่พวกเรา มันเคยเป็นเครื่องหมายแห่งความเคารพอย่างสูง
  • นั่นมันยังไม่ใช่ em dash ด้วยซ้ำ แต่แค่นั้นก็ทำให้เกิดเธรดใหญ่โตแล้ว
  • “แล้วได้โปรดอย่าใช้ M dash ตอนเขียน”… จากนั้น prompt ก็ลากยาวเป็นชั่วโมงเกี่ยวกับผลลัพธ์คุณภาพต่ำ

• AI มักมีแนวโน้มจะรายงานทุกอย่างว่าเป็น issue เพราะ “จำนวน” สิ่งที่ค้นพบถูกมองเหมือนเป็นตัวชี้วัดความฉลาด
  ใน code review ก็รายงาน สิ่งที่ไม่ใช่ประเด็น จำนวนมากเหมือนกัน ผลลัพธ์ของ Mythos ก็อาจถูกพองในลักษณะเดียวกัน และสิ่งที่ทำให้คนตกใจอาจเป็นจำนวน issue ที่ถูกรายงาน ไม่ใช่ความรุนแรง

  • ผมเป็นนักพัฒนาโอเพนซอร์ส และในช่วง 2 สัปดาห์ที่ผ่านมาได้รับแจ้งเตือน “CWE” สามรายการ ทั้งหมดก็ถูกต้องอยู่หรอก แต่เป็นเรื่องเล็กมาก ๆ เช่น “ถ้าไฟล์ debug log นี้เป็น symbolic link ก็อาจเขียนทับไฟล์ได้” หรือ “ถ้าผู้ใช้ใส่โค้ด OSC สำหรับหน้าจอลงในผลลัพธ์ Git ได้ ก็สามารถเขียนข้อมูลตามอำเภอใจบนหน้าจอได้”
    โมเดล AI พวกนี้กำลังทำให้ ทุกอย่างฟังดูเหมือน exploit ไปหมด ไม่แน่ใจว่าดีต่อระบบนิเวศหรือเปล่า
    ตอนนี้ผมเลยมองทุกอย่างที่เข้ามาด้วยความสงสัยมากขึ้น ว่านี่เป็น exploit จริง หรือเป็นการสะสมผลงานเพื่อจะบอกว่า “สัปดาห์ที่แล้วเราเปิด CWE ไป 39 รายการ จ้างบริษัท ‘ความปลอดภัย’ ของเราตรวจโค้ดสิ” กันแน่
  • ไม่ตรงกับที่ผมได้ยินจากคนที่ทำงานกับ Mythos โดยตรง พวกเขาบอกว่าช่องโหว่ที่สร้างขึ้นโดยมาก เป็นของจริงและมีนัยสำคัญ

• ทั้งหมดนี้เป็น 0-day จริง ๆ หรือเปล่า? จำนวนไม่น้อยดูเหมือนมาจาก CVE ที่เปิดเผยแล้ว หรือจากโค้ดที่ upstream แก้ไปแล้ว
  ทุกวันนี้คำว่า “0-day” แทบเสียความหมายไปมาก และดูเหมือนผู้คนใช้เรียก exploit อะไรก็ได้กันบ่อย

  • รีโพซิทอรีอ้างไว้แบบนี้
    “นี่คือคลังรวม PoC exploit สาธารณะและบทความวิจัยช่องโหว่แบบที่เดียวจบ ตอนที่ผมอัปโหลด ยังไม่มีการรายงานอะไรเลย คุณจะไปรายงานเองแล้วรับเครดิตเมื่อ CVE ออกมาก็ได้ lulz อย่านำไปใช้ในทางร้าย ที่ทำแบบนี้เพราะอยากดึงคนเข้ามาในสายนี้มากขึ้น และผมมองมาตลอดว่าวิธีนี้มีประสิทธิภาพที่สุด”
    ก็ถือว่าใกล้เคียงกับ นิยามของ zero-day อยู่พอสมควร ส่วนเนื้อหาในรีโพซิทอรีตรงกับคำกล่าวอ้างนั้นหรือไม่ เป็นอีกเรื่องหนึ่งโดยสิ้นเชิง
  • ในสถานการณ์แบบนี้ RCE ก็เสียความหมายไปแล้วเหมือนกัน ส่วนคำว่า “remote” ถ้าจะให้มีความหมาย ปกติก็ควรหมายถึงประมาณ SSH root session

• เมื่อ AI มีความซับซ้อนมากพอที่จะค้นพบสิ่งแบบนี้ได้ ข้อมูลลักษณะนี้คงจะทะลักออกมาอีกพักใหญ่ พอช่องโหว่จริง ๆ ถูกแก้ไขไปแล้ว ก็น่าจะค่อย ๆ ลดลงเอง
  แน่นอนว่าบางส่วนคงยังเหลืออยู่เสมอ แต่ระดับความรุนแรงจะต่ำลง และ exploit ที่ถูกค้นพบจะซับซ้อนขึ้นเรื่อย ๆ ตอนนี้คือ ช่วงเปลี่ยนผ่าน

  • ผมคิดว่าการพูดว่า “AI ฉลาดพอที่จะค้นพบได้” ทำให้เข้าใจผิดได้ มันไม่ได้ “ฉลาดขึ้น” แต่ถูกปรับให้เหมาะกับการใช้งานเฉพาะทางมากขึ้น มีชุดข้อมูลที่คัดสรรดีขึ้น มี harness ที่ดีขึ้น มี prompt ที่ดีขึ้น มีการติดป้ายกำกับผลลัพธ์ที่ดีขึ้น และมีการสะสมเอกสารของความล้มเหลวกับความสำเร็จมากขึ้น
    หวังว่าผลลัพธ์โดยรวมจะดีขึ้น แต่ ถ้อยคำแบบทำให้เป็นมนุษย์ แบบนี้ทำให้ฟังเหมือนตัว AI เอง somehow เปลี่ยนแปลงหรือวิวัฒนาการไป
    ความจริงคือแวดวงวิชาการที่ทำวิจัยพื้นฐาน อุตสาหกรรมที่นำไปเชิงพาณิชย์ และนักวิจัยความปลอดภัยที่รวมเครื่องมือกับกระบวนการเป็นบริการ กำลังลงมือทำให้มันดีขึ้นอย่างจริงจัง ไม่มี “มัน” ที่เป็นเอกเทศอยู่
  • ดูเหมือนว่าเราจะอยู่กลางขั้นนั้นแล้ว แต่แทนที่จะลดลง “การรายงาน” กลับเสียงดังและคลุมเครือขึ้น ทำให้ตัดสินระดับภัยคุกคามจริงหรือ เวกเตอร์การโจมตี ได้ยากขึ้น
  • การอัปเดตซอฟต์แวร์ทุกครั้งสร้างช่องโหว่แบบนั้นขึ้นใหม่ หรือนำมันกลับเข้ามาอีก
  • พูดตรง ๆ ความซับซ้อนในการลงมือทำก็ยิ่งกลายเป็นกำแพงที่ต่ำลงเรื่อย ๆ ตามเวลา

• ดูเหมือนมีใครสักคนรันโมเดลภาษาขนาดใหญ่แล้วเผยแพร่ผลลัพธ์ออกมา เพราะมีตั้งแต่เรื่องตลก ๆ อย่าง “ถ้าแก้ไบนารีของระบบก็รันโค้ดตามอำเภอใจได้!” ไปจนถึงสิ่งที่อาจเป็นของจริงปะปนกันกว้างมาก
  นี่เป็นผลลัพธ์ที่พบบ่อยเมื่อโยน prompt อย่าง “หา exploit แล้วเขียน PoC” ให้ LLM
  ถ้าเอารายงาน Metasploit ตลอด 15 ปีที่ผ่านมาไปฝึก ก็น่าจะหา bug แบบเดิม ๆ ที่ผู้คนเขียนกลับเข้าไปในโค้ดใหม่ได้
  [1] https://en.wikipedia.org/wiki/Metasploit

• มีข้อความบอกว่าอย่าใช้ข้อมูลใน repository นี้ในทางประสงค์ร้ายไม่ว่าในสถานการณ์ใด เป็นงานวิจัยช่องโหว่สาธารณะโดยสุจริต และมีเป้าหมายเพื่อให้คนสนใจสำรวจพื้นที่ไซเบอร์ซีเคียวริตี้นี้มากขึ้น
  ทำให้นึกถึงข้อความหน้าสูตรบางสูตรใน The Anarchist Cookbook ประมาณว่า “นี่อันตรายจริง ๆ อย่าทำเด็ดขาด วิธีทำคือแบบนี้”

  • หนังสือเก่าไม่ได้มีคำว่า “…ในทางประสงค์ร้าย” ไม่ใช่เหรอ?

• ถ้ามองเป็นช่องโหว่ความปลอดภัยก็ไม่ได้ประทับใจเท่าไร ส่วนใหญ่เรียกว่าเป็น bug ธรรมดา ๆ น่าจะเหมาะกว่า

  • ไม่เห็นด้วย การรันโค้ดใน FFmpeg นี่เลวร้ายจริง ๆ
  • ช่องโหว่ทั้งหมดสุดท้ายก็เป็นแค่ bug อยู่ดี

• ดูเหมือนเป็นการผสมกันระหว่างสำเนาที่เขียนซ้ำจาก CVE เดิม ๆ กับรายการใหม่ที่มีความรุนแรงต่ำ เหตุผลที่เรียกว่าความรุนแรงต่ำคือดูเหมือนผู้ใช้ต้องทำพฤติกรรมที่เสี่ยงโดยตัวมันเองอยู่แล้ว
  เป็นความเห็นแบบ 2 เซ็นต์หลังจากกวาดตาดูเร็ว ๆ
  ถึงอย่างนั้นก็เป็นการค้นพบที่น่าสนใจจริง ๆ บางรายการถ้านำมา chain กันอาจรุนแรงขึ้นได้
  ตัวอย่างเช่น กรณี ovpn อาจทำได้โดยลงทะเบียนแอป VPN เป็นแอปเริ่มต้นสำหรับเปิดไฟล์บน Windows หรือเป็นโปรแกรมเปิดโปรโตคอลสำหรับตำแหน่ง URL อย่าง openvpn:// แล้วผูกกับ iframe และ social engineering อย่างแนบเนียน แค่ความคิดที่ผุดขึ้นมาเท่านั้น

  • นั่นแหละคือจุดที่ชวนสับสน บางส่วนเหมือน noise ระดับต่ำ แต่บางส่วนก็ร้ายแรงจริง ๆ
    กรณี Floci, libssh2, c-ares, FFmpeg, PHP ดูเป็นของจริงทั้งหมด
    ส่วนกรณี Ghidra ไม่ค่อยใช่เท่าไร ผมสงสัยว่านี่อาจเป็นโฟลเดอร์งานวิจัยที่ทำไปได้ครึ่งทาง แล้วถูกปล่อยออกมาตามสภาพ