การโจมตี Polymarket: กุญแจที่รั่วไหล ไม่ใช่บั๊กในสัญญา
เมื่อวันที่ 22 พฤษภาคม 2026 นักสืบออนเชน ZachXBT ตรวจพบการดูดเงินออกจากกระเป๋าเงินใบหนึ่งของ Polymarket การประมาณการเบื้องต้นอยู่ที่ราว 520,000 ดอลลาร์ เมื่อทีมงานยืนยันรายละเอียด ตัวเลขก็ขยับขึ้นไปใกล้ 660,000 ถึง 700,000 ดอลลาร์ ไม่มี reentrancy ไม่มีการปั่น oracle ไม่มีกระบวนการ flash-loan ที่ซับซ้อน แค่ private key ที่ไปปรากฏในที่ที่ไม่ควรอยู่
การโจมตี Polymarket ไม่ได้แตะส่วนของ stack ที่ทุกคนจ้าง Trail of Bits และ OpenZeppelin มาเฝ้าตรวจสอบ แต่กลับโจมตีกระเป๋าเงินเติมเงินภายใน บัญชีปฏิบัติการที่ใช้สำหรับเติมเงินรางวัลและขับเคลื่อนการทำงาน เป็นกระเป๋าเงินประเภทที่ไม่เคยปรากฏในขอบเขตการตรวจสอบ เพราะมันไม่ใช่ contract แต่คือ key ที่วางอยู่บน infrastructure ของใครบางคน
นั่นคือส่วนที่ทำให้รู้สึกอึดอัด หลังจากปีที่พาดหัวข่าวเต็มไปด้วยเรื่อง bridge และ DVN misconfiguration ตลาดทำนายที่ได้รับเงินทุนสูงสุดในโลกก็ถูกดูดเงินออกผ่านรูปแบบความล้มเหลวที่พื้นฐานที่สุดในตำรา
สิ่งที่เกิดขึ้นจริงบน Polygon
บัญชีที่ถูกดูดเงินเป็นกระเป๋าเงินปฏิบัติการ ไม่ใช่เงินของผู้ใช้ที่เก็บไว้ใน core contract ของโปรโตคอล ตามรายงานของ CoinDesk ZachXBT พบเงินราว 520,000 ดอลลาร์กำลังเคลื่อนออก และทีม Polymarket ระบุว่าเงินของลูกค้าปลอดภัย ผู้โจมตีกวาด POL และทรัพย์สินอื่น ๆ ออกจากกระเป๋าเงินบน Polygon จากนั้นทำในสิ่งที่ผู้โจมตีมักทำเสมอ คือบริดจ์และกระจายเงินออกไปก่อนที่ใครจะสามารถอายัดได้
Decrypt ประเมินตัวเลขใกล้ 700,000 ดอลลาร์ และระบุว่าเป็นกระเป๋าเงินเติมเงินภายในโดยเฉพาะ ความแตกต่างของตัวเลขเป็นเรื่องปกติใน 24 ชั่วโมงแรก แต่กลไกไม่มีข้อโต้แย้ง มีคนได้ key ไป
นี่เป็นการโจมตี Polygon POL เฉพาะในแง่ที่ว่า POL คือทรัพย์สินที่อยู่ในกระเป๋าเงิน เชนไม่ได้ล้มเหลว contract ไม่ได้ล้มเหลว การดูแล key ปฏิบัติการใบเดียวต่างหากที่ล้มเหลว
เหตุใด UMA CTF Adapter จึงไม่ใช่ปัญหา
การแก้ไขตลาดของ Polymarket ทำงานผ่าน optimistic oracle ของ UMA โดยผ่าน UMA CTF Adapter ซึ่งเป็นคอนแทรกต์ที่โพสต์คำถาม จัดการข้อพิพาท และตัดสินผลลัพธ์ นั่นคือส่วนที่บนกระดาษแล้วมีความเสี่ยงต่อการโจมตีมากที่สุด มันผ่านการตรวจสอบมาแล้ว มันผ่านการทดสอบจริงในตลาดนับพันแห่ง
แต่มันไม่มีส่วนเกี่ยวข้องกับเรื่องนี้เลยแม้แต่น้อย
ผมคิดว่านี่คือรายละเอียดที่คนจะมองข้ามไปโดยไม่ควรทำเช่นนั้น ชั้น smart contract ยืนหยัดได้ Oracle ยืนหยัดได้ สิ่งที่พังคือ wallet ที่มนุษย์ควบคุมด้วย key ที่มนุษย์ (หรือ CI pipeline หรือ hot signing service) สามารถเข้าถึงได้ เราใช้ช่วงตลาดขาขึ้นทั้งหมดไปกับการเสริมความแข็งแกร่งให้ส่วนที่มี formal verification แต่กลับเพิกเฉยต่อส่วนที่มีแค่ไฟล์ .env
Operational key คือพื้นที่โจมตีที่แท้จริงในตอนนี้
นี่คือรูปแบบที่เห็นในเหตุการณ์ต่างๆ ตลอดปี 2026 Solidity กำลังดีขึ้นเรื่อยๆ ผู้ตรวจสอบทำงานได้ดี Formal methods จับบั๊ก reentrancy ที่เคยดูดเงินเก้าหลักไปได้ ดังนั้นผู้โจมตีจึงเคลื่อนย้าย
พวกเขาเคลื่อนไปยังเนื้อเยื่ออ่อน:
- Hot wallet ที่ใช้สำหรับรางวัล เติม gas และ market-making
- Deployer key ที่ไม่เคยถูกหมุนเวียนหลังจาก launch
- ผู้ลงนาม multisig ที่ใช้แล็ปท็อปเครื่องเดียวกันทั้งสำหรับลงนามและท่องเว็บ
- CI/CD secret ที่สามารถลงนามธุรกรรมในระบบ production ได้
ไม่มีสิ่งใดในรายการนั้นอยู่ในรายงานการตรวจสอบ เมื่อผมประเมินขอบเขตงานด้านความปลอดภัยที่ตลาดแลกเปลี่ยนที่อยู่ภายใต้การกำกับดูแล การตรวจสอบคอนแทรกต์อาจเป็นแค่หนึ่งในสามของงานทั้งหมด ที่เหลือคือ HSM การแยกผู้ลงนาม เอกสาร key ceremony และคำถามที่น่าเบื่อแต่สำคัญมากว่า "ใครสามารถโอนเงินได้ตอนตีสามและอะไรที่จะหยุดพวกเขาได้" ส่วนสุดท้ายนั้นคือจุดที่ทีมส่วนใหญ่มีความเปราะบาง
นี่คือบทเรียนเดียวกับการสูญเสีย Kelp DAO LayerZero ที่หายไป 292 ล้านดอลลาร์ไม่ใช่จากบั๊กในคอนแทรกต์ แต่จากการตั้งค่าผิดพลาดใน operational layer กลไกต่างกัน สาเหตุรากเดียวกัน: ส่วนที่น่าเบื่อที่ไม่มีใครตรวจสอบ
ops wallet มูลค่า $660K ควรมีหน้าตาเป็นอย่างไร
ถ้ากุญแจเดียวสามารถขยับเงิน 660,000 ดอลลาร์ได้ นั่นคือการตัดสินใจด้านการออกแบบ ไม่ใช่เรื่องโชคร้าย สิ่งเหล่านี้ควรเป็นมาตรฐานขั้นต่ำสำหรับกระเป๋าเงินปฏิบัติการที่ถือมูลค่าสำคัญ:
- วงเงินการใช้จ่ายในตัว logic ของกระเป๋าเงินเอง กระเป๋าเงินสำหรับเติม rewards ไม่มีเหตุผลใดที่จะส่งยอดคงเหลือทั้งหมดในธุรกรรมเดียว กำหนด rate limit ไว้บน chain
- Threshold signing สำหรับทุกอย่างที่เกินขั้นต่ำ การจ่ายอัตโนมัติรายย่อยใช้แบบ hot ได้ แต่อะไรก็ตามที่เกิน 10,000 ดอลลาร์ควรต้องการ signer คนที่สอง Safe multisig ที่มี threshold ต่ำสำหรับการโอนจำนวนมากไม่ใช่เรื่องยาก
- แยก key ออกจาก app environment signing key ของกระเป๋าเงินปฏิบัติการไม่ควรอยู่ในที่ที่ application code, dependencies หรือ CI runner ที่ถูกโจมตีสามารถอ่านได้
- การติดตามที่แจ้งเตือนมนุษย์เมื่อมีการไหลออกผิดปกติ ZachXBT พบเรื่องนี้ก่อนทีมงานจะประกาศเอง ระบบแจ้งเตือนของคุณเองควรตรวจจับได้เร็วกว่าบุคคลที่สามที่จับตา mempool
ไม่มีอะไรใหม่ในนี้เลย นี่คือสิ่งที่ถูกตัดออกเมื่อทีมกำลังเร่งพัฒนาและกระเป๋าเงินนั้น "แค่ใช้สำหรับ rewards"
ช่องว่างใน audit stack ที่ไม่มีใครดูแล
ปัญหาที่ลึกกว่านั้นคือเรื่องเขตอำนาจภายใน ความปลอดภัยของ smart contract มีเจ้าของที่ชัดเจน: บริษัท audit ความปลอดภัยของ operational key มีเจ้าของคือ... ใครก็ตามที่ตั้งค่ากระเป๋าเงินไว้ มักจะทำภายใต้แรงกดดันด้านเวลา และมักไม่เคยได้รับการทบทวนอีก ฉันเขียนถึงช่องว่างนี้ในบริบทของ DeFi's broken audit stack ใบรับรองครอบคลุม contract และหยุดอยู่แค่ขอบเขตของ contract ทุกอย่างที่เป็น operational อยู่นอกขอบเขตและนอกความสนใจ
จนกว่าหน่วยงานกำกับดูแลหรือบริษัทประกันจะบังคับให้ความปลอดภัยด้านปฏิบัติการเป็นรายการค่าใช้จ่ายที่มีเจ้าของ เรื่องนี้จะเกิดขึ้นซ้ำแล้วซ้ำเล่า ความปลอดภัย DeFi ด้านปฏิบัติการในปี 2026 อยู่ในจุดที่ใกล้เคียงกับที่ความปลอดภัยของ smart contract อยู่ในปี 2019: รู้ว่าสำคัญ ไม่มีเจ้าของ ได้รับการจัดสรรงบประมาณเป็นอันดับสุดท้าย
Polymarket จะรอดได้ 660,000 ดอลลาร์เป็นตัวเลขที่แพลตฟอร์มขนาดนี้รับได้ และน่าชื่นชมที่พวกเขาสื่อสารได้รวดเร็วและชัดเจน แต่ทีมถัดไปที่เผชิญเหตุการณ์แบบนี้อาจไม่มีทุนสำรองมากพอจะรับมือ การโจมตีที่จะดูดเงินออกจากคลังของโครงการมากกว่าแค่กระเป๋ารางวัลกำลังจะมา และมันจะไม่ใช่บั๊กใน Solidity แต่จะเป็นคีย์ที่วางอยู่บนแล็ปท็อปเครื่องหนึ่ง