การแฮ็ก MoltBook: การตั้งค่า Supabase ผิดพลาดทำให้ API key 1.5 ล้านรายการรั่วไหล

• ฐานข้อมูลของ Moltbook แพลตฟอร์มโซเชียลที่ออกแบบมาสำหรับ AI agent โดยเฉพาะ ถูกตั้งค่าผิดพลาด ทำให้ โทเคนยืนยันตัวตน API 1.5 ล้านรายการ อีเมล 35,000 รายการ และข้อความส่วนตัวถูกเปิดเผยสู่ภายนอก
• ใน JavaScript ฝั่งไคลเอนต์มีการ hardcode Supabase API key เอาไว้ และไม่มีการตั้งค่า Row Level Security (RLS) ทำให้ใครก็ได้สามารถเข้าถึงฐานข้อมูลทั้งหมดแบบอ่านและเขียนได้
• ข้อมูลที่รั่วไหลมีข้อมูลของ ผู้ใช้จริง 17,000 คน และบัญชี agent 1.5 ล้านบัญชีที่พวกเขาดูแลอยู่ ทำให้เห็นสัดส่วนมนุษย์ต่อ agent อยู่ที่ 1:88
• ข้อมูลที่ถูกเปิดเผยรวมถึง OpenAI API key และข้อมูลรับรองของบุคคลที่สามอื่น ๆ, บทสนทนาส่วนตัว และสิทธิ์ในการแก้ไขโพสต์ ซึ่งก่อให้เกิดความเสี่ยงต่อ ความถูกต้องสมบูรณ์ของคอนเทนต์ บนแพลตฟอร์ม
• เหตุการณ์ครั้งนี้สะท้อนข้อจำกัดด้านความปลอดภัยของ ‘vibe coding’ ที่ขับเคลื่อนด้วย AI และชี้ให้เห็นถึงความจำเป็นในการ ทำให้ค่าความปลอดภัยพื้นฐานเป็นอัตโนมัติและเข้มงวดขั้นตอนการตรวจสอบ ในสภาพแวดล้อมการพัฒนาด้วย AI

---

ภาพรวมของ Moltbook และการเปิดเผยด้านความปลอดภัย

• Moltbook เป็น โซเชียลเน็ตเวิร์กที่เน้น AI ซึ่ง AI agent สามารถทำกิจกรรมผ่านการเขียนโพสต์ แสดงความคิดเห็น โหวต และคะแนนชื่อเสียง โดยชูตัวเองว่าเป็น “หน้าแรกของอินเทอร์เน็ตสำหรับ agent”
  • ผู้ร่วมก่อตั้ง OpenAI อย่าง Andrej Karpathy เคยกล่าวถึงมันว่าเป็น “ก้าวกระโดดแบบไซไฟที่น่าทึ่งที่สุด” จนได้รับความสนใจ
• ผู้ก่อตั้งแพลตฟอร์มระบุว่า “AI เป็นผู้เขียนโค้ดโดยตรง” และพัฒนาด้วยแนวทาง ‘vibe coding’
• ทีมวิจัยของ Wiz พบว่า ฐานข้อมูล Supabase ถูกตั้งค่าผิดพลาด ทำให้สามารถเข้าถึงข้อมูลทั้งหมดได้ทั้งแบบอ่านและเขียน และหลังจากแจ้งปัญหาไปก็มีการแก้ไขภายในไม่กี่ชั่วโมง

ข้อมูลรับรอง Supabase ที่ถูกเปิดเผย

• พบข้อมูลการเชื่อมต่อ Supabase ถูก hardcode ไว้ใน JavaScript bundle ฝั่งไคลเอนต์ ของเว็บไซต์ Moltbook
  • โปรเจกต์: ehxbxtjliybbloantpwq.supabase.co
  • API key: sb_publishable_4ZaiilhgPir-2ns8Hxg5Tw_JqZU_G6-
• Supabase อนุญาตให้เปิดเผย public key ได้ในตัวมันเอง แต่ หากไม่มีนโยบาย RLS ก็จะสามารถเข้าถึงฐานข้อมูลทั้งหมดได้
• Moltbook ปิดการใช้งาน RLS อยู่ ส่งผลให้ สิทธิ์อ่านและเขียนในทุกตารางถูกเปิดเป็นสาธารณะ

การเข้าถึงฐานข้อมูลโดยไม่ต้องยืนยันตัวตน

• ทีมวิจัยใช้ API key เพื่อเรียก REST API โดยตรง และพบว่าได้รับ การตอบกลับระดับผู้ดูแลระบบ
  • ตัวอย่างคำขอ: curl https://ehxbxtjliybbloantpwq.supabase.co/rest/v1/agents?...
• ในการตอบกลับมีทั้ง API key และโทเคนยืนยันตัวตน ของ agent ชั้นนำ ซึ่งทำให้ ยึดบัญชีได้อย่างสมบูรณ์
• ใช้ข้อความผิดพลาดของ PostgREST และ GraphQL introspection เพื่อทำความเข้าใจ schema ทั้งหมด และยืนยันว่ามี เร็กคอร์ดราว 4.75 ล้านรายการ ถูกเปิดเผย

ข้อมูลอ่อนไหวที่ถูกเปิดเผย

• ข้อมูลยืนยันตัวตนของ agent: มี api_key, claim_token, verification_code ของแต่ละบัญชี
  • ทำให้ผู้โจมตีสามารถล็อกอินเป็น agent ใดก็ได้ สร้างโพสต์ หรือส่งข้อความได้
• อีเมลผู้ใช้และข้อมูลระบุตัวตน: มีอีเมลของผู้ใช้มากกว่า 17,000 คนและแฮนเดิล X (Twitter) ถูกเปิดเผย
  • นอกจากนี้ยังพบอีเมล 29,631 รายการในตาราง observers
• ข้อความส่วนตัวและข้อมูลรับรองของบุคคลที่สาม: มี DM 4,060 รายการถูกเก็บไว้โดยไม่เข้ารหัส และบางส่วนมี OpenAI API key อยู่ในรูปแบบ plaintext
• การเปิดเผยสิทธิ์เขียน: สามารถแก้ไขโพสต์ได้โดยไม่ต้องยืนยันตัวตน ทำให้มีความเสี่ยงต่อการแทรกคอนเทนต์อันตรายหรือการดัดแปลงเว็บไซต์
  • ในการทดสอบจริงสามารถแก้ไขโพสต์ได้สำเร็จ ก่อนจะถูกป้องกันหลังจากมีการบังคับใช้นโยบาย RLS

บทเรียนด้านความปลอดภัย 5 ข้อสำหรับการพัฒนาแอป AI

• 1. ความเร็วในการพัฒนาที่สูง หากไม่มีค่าความปลอดภัยพื้นฐาน อาจสร้างความเสี่ยงเชิงระบบได้
  • การตั้งค่า Supabase เพียงบรรทัดเดียวกลายเป็นสาเหตุของการเปิดเผยทั้งหมด
• 2. จำเป็นต้องตรวจสอบตัวชี้วัดการมีส่วนร่วม
  • จาก agent 1,500,000 บัญชี มีมนุษย์จริงเพียง 17,000 คน ทำให้มีโอกาสที่กิจกรรมจะดูคึกคักเกินจริงในอัตรา 88:1
• 3. ผลกระทบแบบลูกโซ่ของการพังทลายของความเป็นส่วนตัว
  • การรั่วไหลของ DM ทำให้ ข้อมูลรับรองของบริการภายนอก เช่น OpenAI API key รั่วไหลตามไปด้วย
• 4. สิทธิ์เขียนเป็นภัยต่อความถูกต้องสมบูรณ์ที่ร้ายแรงกว่าการรั่วไหลของข้อมูลเพียงอย่างเดียว
  • ก่อให้เกิดความเสี่ยง เช่น การบิดเบือนคอนเทนต์, prompt injection และการควบคุมเนื้อหา
• 5. วุฒิภาวะด้านความปลอดภัยคือกระบวนการปรับปรุงซ้ำอย่างต่อเนื่อง
  • ทีม Wiz และ Moltbook แก้ไขและตรวจสอบหลายรอบจนสามารถปกป้องทุกตารางได้

ความท้าทายของ vibe coding และความปลอดภัย

• แม้ AI จะลดอุปสรรคในการพัฒนา แต่ อุปสรรคด้านความปลอดภัยยังคงสูงอยู่
• เครื่องมือพัฒนาด้วย AI ควรบังคับใช้ ค่าความปลอดภัยพื้นฐานโดยอัตโนมัติ เช่น การเปิดใช้ RLS และการสแกนข้อมูลรับรอง
• เมื่อความปลอดภัยกลายเป็น องค์ประกอบพื้นฐานที่ฝังอยู่ในการพัฒนา AI ก็จะสามารถสร้างระบบนิเวศซอฟต์แวร์ AI ที่ปลอดภัยและสร้างสรรค์ได้

ไทม์ไลน์

• 31 มกราคม 2026 21:48 UTC: ติดต่อผู้ดูแล Moltbook ครั้งแรก
• 22:06: รายงานการตั้งค่า Supabase RLS ผิดพลาด
• 23:29: แก้ไขครั้งที่ 1 (ปกป้องตาราง agents, owners, site_admins)
• 1 กุมภาพันธ์ 00:13: แก้ไขครั้งที่ 2 (ปกป้อง agent_messages และตารางอื่น ๆ)
• 00:31: พบช่องโหว่การแก้ไขโพสต์
• 00:44: แก้ไขครั้งที่ 3 เพื่อปิดกั้นสิทธิ์เขียน
• 00:50~01:00: พบตารางที่เปิดเผยเพิ่มเติมและแก้ไขขั้นสุดท้ายเสร็จสมบูรณ์

[iolothebard]

เต้นอย่างสนุกสนานไปแล้ว… แบบนั้นแหละ… ล่มไปซะ!

[rustkim]

สุดท้ายก็เหลือแค่ Mac mini นี่แหละ เพราะยังเป็นช่วงแรก ๆ เดี๋ยวคงมีตัวที่ดีกว่านี้ออกมาอีก

[gogokow27]

55555555555....

[kuthia]

ในที่สุด สิ่งที่ต้องมาก็มาจนได้

[crawler]

MoltBot นี่ทั้งเอเจนต์ก็มีประเด็นโดนแฮ็ก ตอนนี้ลามมาถึงแพลตฟอร์มอีกแล้ว 555

คิดว่าน่าจะถูกจดจำเป็นกรณีศึกษาของโปรเจกต์ที่ให้ไวบ์แย่ที่สุดในปี 2026 เลยครับ
ยังเพิ่งแค่เดือนกุมภาพันธ์ แต่ผมมั่นใจได้เลย 555

[bini59]

ปัญหาคือทุกวันนี้สามารถพัฒนาบริการขนาดใหญ่ได้แม้จะไม่ใส่ใจเรื่องความปลอดภัยเลยด้วยซ้ำเพราะอาศัย vibe ใช่ไหม

[kimjoin2]

ว้าว

[GN⁺]

ความเห็นจาก Hacker News

• ตอนแรกความสำเร็จของ Moltbot/Moltbook ดูน่าประหลาดใจ แต่ตอนนี้ก็พอเข้าใจแล้ว
  แก่นสำคัญคือมันเป็น "เอเจนต์แบบแพ็กมาให้พร้อม" สำหรับผู้ใช้ทั่วไปที่ไม่คุ้นกับเทคโนโลยี แนวทางแบบ "ซื้อ Mac mini แล้วคัดลอกไม่กี่บรรทัดเพื่อติดตั้ง" มีเสน่ห์มากในแง่การเข้าถึง
  แต่ความเข้าถึงง่ายแบบนี้ก็กำลังขยาย ฝันร้ายด้านความปลอดภัย ด้วย เมื่อมีผู้ใช้ที่ไล่ตามกระแสโดยไม่มีความเข้าใจเชิงเทคนิคมากขึ้น ความเสี่ยงที่สภาพแวดล้อมที่เปราะบางจะคงอยู่นานขึ้นก็สูงขึ้น

  • ก็ยังสงสัยว่าเรียกว่าประสบความสำเร็จได้จริงหรือไม่ มีการวิเคราะห์ว่าจริง ๆ แล้ว จากเอเจนต์ 1.5 ล้านตัว มีเจ้าของที่เป็นมนุษย์เพียง 17,000 คน เท่านั้น ส่วนหนึ่งไวรัลเพราะอินฟลูเอนเซอร์ชื่อดังพูดถึง
  • LLM ทุกตัว เปราะบางด้านความปลอดภัย โดยการออกแบบอยู่แล้ว สามารถถูกเลี่ยงได้ง่ายด้วย prompt injection หรือ reward hacking วิธีแก้ที่สมบูรณ์มีแค่ตัดอินพุตภายนอกและการเข้าถึงเครือข่ายออกทั้งหมด
  • คำว่า "ซื้อ Mac mini แล้วติดตั้ง" เป็นแค่ข้อความการตลาดเท่านั้น ในความเป็นจริงมีการตั้งค่าผิดพลาดบ่อยและ จัดการคอนเท็กซ์ได้แย่มาก มี log ก็จริงแต่ยังลืมบทสนทนาก่อนหน้า ไอเดียดีแต่การลงมือทำยังหยาบ
  • เหมือนตอน Dropbox ออกมาใหม่ ๆ ปัจจัยความสำเร็จคือ 'การเข้าถึงที่ถูกแพ็กมาให้' แต่ในโลกที่แม้แต่บริษัทยักษ์ใหญ่ยังกันการแฮ็กไม่ได้ misconfigured DB แบบนี้จึงถูกมองว่าไม่ใช่เรื่องใหญ่นัก ความสะดวกยังมาก่อนความปลอดภัย
  • ตอนนี้ยังไม่ชัดว่าเป็นความสำเร็จจริง หรือแค่เป็นกระแสเท่านั้น

• อย่างที่ Scott Alexander ชี้ไว้ สิ่งสำคัญคือปรากฏการณ์ที่เอเจนต์โต้ตอบกันแล้ว ก่อให้เกิดพฤติกรรมที่ซับซ้อน
  ถ้าสิ่งนี้เริ่มส่งผลต่อโลกจริง ก็อาจนำไปสู่ปัญหาเชิงภววิทยาได้
  ท้ายที่สุดมันคือโครงสร้างที่ทำให้ "ทุกอย่างที่เขียนว่า YES ไว้ใน AGENT.md" สามารถเกิดขึ้นจริงได้

  • ก็มีคนตอบว่าฟังแล้วไม่ค่อยเข้าใจว่าหมายถึงอะไร
  • เพราะแบบนี้ฉันเลยสร้าง nono.sh ขึ้นมา เพื่อให้เอเจนต์เริ่มต้นแบบ zero trust ภายใน sandbox ที่แยกด้วยเคอร์เนล
  • มนุษย์เองก็เป็นสิ่งมีชีวิตที่ "พูดซ้ำเหมือนนกแก้ว" อยู่ระดับหนึ่งเหมือนกัน Moltbook เลียนแบบ Reddit ขณะที่มนุษย์ก็คุยกันอยู่ในรูปแบบที่คาดเดาได้ สุดท้ายเราอาจไม่ได้ฉลาดอย่างที่คิด

• API ของ Moltbook เปิดให้ใครก็ได้เข้าถึง จึงสามารถใช้ prompt ง่าย ๆ เพื่อ ชักจูงให้รั่วไหลอีเมลหรือข้อมูลของผู้ใช้ ได้
  จึงมีความพยายามจะแยกมันไว้บน Mac mini แต่ตราบใดที่ยังเชื่อมต่อเครือข่าย ก็ไม่มีทางป้องกันได้สมบูรณ์

  • มันไม่ได้บ้าเลย LLM แยกไม่ออกชัดเจนระหว่างคำสั่งกับข้อมูล เป็นช่องโหว่แนว 'social engineering' แบบหนึ่ง
  • สุดท้ายปัญหาคือจะสั่งให้มันทำ งานที่มีประโยชน์โดยไม่เสี่ยง ได้หรือไม่ เช่น ถ้าจะให้ช่วยซื้อของหรือจองทริป ก็จำเป็นต้องเข้าถึงบัตรเครดิต
  • ฉันใช้งาน LLM โดยแยกไว้ใน สภาพแวดล้อม DMZ รันด้วยบัญชีที่ไม่มีดิสก์และไม่มีสิทธิ sudo ไม่สมบูรณ์แบบแต่ก็พอใช้ได้
  • ในทางปฏิบัติไม่มีมาตรการป้องกันที่สมบูรณ์ เพราะมีครบทั้ง 'สามประสานมรณะ' คือการเข้าถึงข้อมูล ข้อความที่ไม่น่าเชื่อถือ และการสื่อสารผ่านเครือข่าย
  • แต่ก็ยังพอทำ ชั้นการเฝ้าระวังและการอนุมัติ ได้ เช่น สร้างโครงสร้างที่อนุมัติหรือจำกัดการกระทำของ LLM คล้ายวงเงินบัตรเครดิต

• ลองใช้ OpenClaw แล้วพบว่า กินโทเคนมหาศาล
  เพื่อความปลอดภัย น่าจะใช้ อุปกรณ์เฉพาะทาง (เช่น Raspberry Pi) ที่มีสิทธิ API แบบจำกัดได้ ถ้า Pi รันโมเดลที่แรงกว่านี้ได้ก็น่าสนใจจะซื้อ

• Moltbook ไม่มีวิธีแยก AI ออกจากมนุษย์ ปัญหาคือจะทำ 'reverse CAPTCHA' อย่างไร

  • ลองเล่น ๆ ด้วยการให้ Claude รับ prompt ว่า "ลองหาแอ็กเคานต์สายสืบที่เป็นมนุษย์ดู" แล้วมันก็สร้างเธรด "Reverse Turing Problem" ขึ้นมาจริง แต่ตอนนี้ โดนสแปมถล่ม จนคุยกันแทบไม่ได้แล้ว
  • จำเป็นต้องมีวิธีทำให้ทุกอินพุตและเอาต์พุตของเซสชัน ถูกลงลายเซ็นและตรวจสอบย้อนหลังได้ รวมถึงต้องตามรอย prompt ที่มนุษย์ใส่เข้าไปได้ด้วย
  • อีกวิธีอาจเป็นการให้ทำงานที่ AI ทำได้ง่ายแต่มนุษย์ทำได้ยาก หลายครั้งในเวลาสั้น ๆ เพื่อใช้แยกแยะ
  • หรือจะใช้การยิง คำถามหายาก ที่ LLM น่าจะรู้อยู่แล้วอย่างรวดเร็วก็ได้
  • แต่สุดท้ายก็ยังแยกได้ยากอยู่ดีว่าเป็นพฤติกรรมที่มนุษย์ชี้นำผ่าน prompt หรือไม่

• แม้จะบอกว่าแก้ปัญหาความปลอดภัยของ Moltbook ได้ภายในไม่กี่ชั่วโมง แต่ประเด็นคือจะ อธิบายช่องโหว่ความปลอดภัยของโปรเจกต์ที่สร้างด้วย 'vibe coding' อย่างไร

  • มีการบอกว่า Claude เป็นคนสร้าง query สำหรับ Supabase แล้วมนุษย์ก็นำไปส่งต่อให้ทีมพัฒนา Moltbook เพื่อแก้ไข ฟังดูไม่น่าเชื่อแต่เป็นเรื่องจริง

• น่าแปลกใจที่มีคนพยายามวิเคราะห์ภายในของ Moltbook ทั้งที่เดิมทีมันเป็น 'โปรเจกต์ที่ทำขึ้นเล่น ๆ' และไม่มีใครคิดว่าจะโตขนาดนี้

  • แต่ถ้า PII ของผู้ใช้รั่วไหล มันก็ไม่ใช่เรื่องที่จะพูดขำ ๆ ได้อีกต่อไป และยังเป็นปัญหาทางกฎหมายด้วย วัฒนธรรม 'vibe coding' กำลังสร้าง บรรยากาศการพัฒนาที่ไร้ความรับผิดชอบ
  • Dogecoin ก็เริ่มจากเรื่องขำเหมือนกัน แต่ตอนนี้มีมูลค่าระดับหลายพันล้านดอลลาร์แล้ว
  • นักวิจัยด้านความปลอดภัยที่ไปหาช่องโหว่ก็อาจถือเป็นส่วนหนึ่งของ 'vibe' เหมือนกัน
  • แต่จะเอาคำว่า "มันเป็นเรื่องขำ" มาใช้กลบ ความเสียหายจริง ไม่ได้
  • ถ้าเป็นผลลัพธ์ที่ผู้สร้างตั้งใจทำขึ้น ข้ออ้างว่าเป็น 'เรื่องขำ' ก็ยิ่งฟังไม่ขึ้น

• เหตุการณ์ที่ OpenClaw instance ส่ง OpenAI key ไปยัง instance อื่น ทั้งตลกและชวนกังวล
  ยังไม่ชัดว่ามันส่งคีย์จริง ๆ หรือแค่แกล้งทำเป็นส่ง

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

• จากข้อมูลที่รั่วไหล ทำให้รู้ว่า จากเอเจนต์ 1.5 ล้านตัว มีมนุษย์เพียง 17,000 คน
  แต่นี่เป็นตัวเลขที่นักวิจัยได้มาจากการใช้ API key ไป query ตารางโดยตรง ดังนั้นการเปิดเผยเรื่องนี้จึงดูไม่ใช่แค่การรายงานบั๊ก แต่เป็น การวิจารณ์บริษัทโดยตรง มากกว่า
  วิธีแบบนี้อาจเสี่ยงทำลาย ความร่วมมือบนความไว้วางใจ ระหว่างนักวิจัยกับบริษัท