Skip to content
DeFi

Verus Ethereum Bridge Exploit: ช่องโหว่ $11.58M เดิม

By Anurag Verma•May 22, 2026
Verus Ethereum Bridge Exploit: ช่องโหว่ $11.58M เดิม

เมื่อวันที่ 18 พฤษภาคม 2026 มีผู้ดูดเงินออกจากสะพาน Verus-Ethereum ไปเป็นมูลค่า 11.58 ล้านดอลลาร์ ตามรายงานของ CoinDesk นี่คือการแฮกสะพานครั้งที่แปดของปี การโจมตี Verus Ethereum bridge ครั้งนี้ไม่ได้อาศัยรูปแบบการโจมตีแปลกใหม่แต่อย่างใด มันคือความล้มเหลวแบบเดิมที่เราเฝ้าดูมันทำลายสะพานต่าง ๆ มาตั้งแต่ปี 2021 นั่นคือสัญญาอัจฉริยะปล่อยเงินออกจากเชนหนึ่งโดยไม่ได้ตรวจสอบอย่างถูกต้องว่าเกิดอะไรขึ้นจริง ๆ บนอีกเชนหนึ่ง

คราวนี้ฟังก์ชันที่มีช่องโหว่มีชื่อชัดเจน นั่นคือ checkCCEValues ฟังก์ชันนี้ควรจะทำหน้าที่ยืนยันว่าค่า export ข้ามเชนตรงกับความเป็นจริงก่อนที่จะมิ้นต์หรือปล่อยเงินฝั่ง Ethereum แต่มันไม่ทำหน้าที่ของตัวเอง และผู้โจมตีก็ลอยนวลไป

ผมใช้เวลาสี่ปีสร้างโครงสร้างพื้นฐานที่เกี่ยวข้องกับสะพานในบริบทที่มีการกำกับดูแล และส่วนที่น่าหดหู่ที่สุดคือมันกลายเป็นเรื่องที่คาดเดาได้ขนาดนี้ เราแค่เปลี่ยนชื่อแผลเดิมซ้ำแล้วซ้ำเล่า

การโจมตี Verus Ethereum bridge คือความล้มเหลวด้านการตรวจสอบแหล่งที่มา

ถ้าตัดเรื่องแบรนด์ออกไป สะพานทุกตัวทำสิ่งเดียวกัน มันสังเกตเหตุการณ์บนเชน A (การฝาก การล็อก การ export) แล้วสร้างการกระทำที่สอดคล้องกันบนเชน B (การมิ้นต์ การปลดล็อก การปล่อย) โมเดลความปลอดภัยทั้งหมดพังทลายลงที่คำถามเดียว: เชน B เชื่อสิ่งที่เชน A บอกจริง ๆ ไหม และมันตรวจสอบแล้วหรือเปล่า?

เมื่อการตรวจสอบที่ยืนยันจำนวนเงินฝั่งต้นทางผิดพลาด คำตอบก็กลายเป็น "ไม่" ผู้โจมตีปลอมแปลงหรือพองค่า export ที่อ้างไว้ สัญญาปลายทางเชื่อมัน และโทเค็นที่ไม่มีสินทรัพย์หนุนหลังก็ถูกมิ้นต์หรือปล่อยออกมา The Block รายงานว่าความสูญเสียอยู่ที่ประมาณ 11.58 ล้านดอลลาร์ ถูกดูดออกผ่านช่องโหว่ทางบัญชีแบบนี้ในการตรวจสอบ export ข้ามเชนพอดี

นี่คือการตรวจสอบจำนวนเงินต้นทางในสะพาน และมันคือฟังก์ชันที่รับภาระหนักที่สุดในระบบทั้งหมด ผิดพลาดแค่การเปรียบเทียบเดียว สะพานก็กลายเป็นเครื่องพิมพ์เงินฟรี

checkCCEValues เป็นแค่ชื่อใหม่ของช่องโหว่เก่า

ช่องโหว่ checkCCEValues มีโครงสร้างเหมือนกันทุกประการกับบั๊กที่สร้างความเสียหายให้วงการไปแล้วหลายพันล้านดอลลาร์ ชื่อเรียกเปลี่ยนไปเรื่อยๆ แต่กลไกไม่เคยเปลี่ยน

  • Wormhole, 2022: ช่องว่างในการตรวจสอบลายเซ็นทำให้ผู้โจมตีสามารถสร้าง wrapped ETH ได้ถึง 120,000 ETH โดยไม่มีการฝากเงินจริง
  • Nomad, 2022: การตั้งค่า merkle root ที่ผิดพลาดทำให้ทุกข้อความผ่านการตรวจสอบว่าเป็นความจริง และบริดจ์ก็ถูกก็อปปี้โค้ดกันต่อจนพังย่อยยับ
  • Multichain, 2023: คีย์และข้อสมมติเรื่องความน่าเชื่อถือที่ไม่มีใครสามารถยืนยันได้จากภายนอก

ทั้งหมดนี้มีแก่นเหมือนกัน คือเชนปลายทางปล่อยมูลค่าออกไปโดยไม่มีหลักฐานที่น่าเชื่อถือว่าเหตุการณ์บนเชนต้นทางเกิดขึ้นจริง checkCCEValues คือการสะกดคำเดิมในปี 2026

ผมคิดว่าวงการยังคงมองปัญหาเหล่านี้เป็นข้อผิดพลาดด้านวิศวกรรมรายกรณี ทั้งที่มันคือความล้มเหลวเชิงหมวดหมู่ คุณจะแก้ปัญหาเชิงหมวดหมู่ด้วยการออดิตฟังก์ชันเดียวให้ละเอียดขึ้นไม่ได้

กระเป๋าเงินของผู้โจมตีถูกเติมเงินผ่าน Tornado Cash ซึ่งบ่งบอกถึงเจตนา

กระเป๋าเงินของผู้โจมตีถูกเติมเงินผ่าน Tornado Cash ก่อนการโจมตี รายละเอียดนี้มีความสำคัญน้อยกว่าในแง่การระบุตัวตน แต่สำคัญมากในแง่ที่บ่งบอกถึงการเตรียมการ นี่ไม่ใช่ whitehat ที่ลองแงะสัญญาแล้วบังเอิญพบผลลัพธ์ที่คาดไม่ถึง รูปแบบของผู้โจมตีที่เติมเงินผ่าน Tornado Cash คือลายเซ็นของคนที่วางแผนปิดบังตัวตนมาหลายวันล่วงหน้า และรู้อยู่แล้วว่าเงินจะต้องผ่านกระบวนการฟอกในภายหลัง

นั่นคือสิ่งที่ฝ่ายป้องกันประเมินค่าต่ำเกินไป เมื่อถึงเวลาที่ธุรกรรมการโจมตีเกิดขึ้น ช่องทางถอนเงินถูกสร้างไว้เรียบร้อยแล้ว การติดตามย้อนหลังช่วยอัยการได้บ้าง แต่แทบไม่ช่วยอะไรโปรโตคอลที่เพิ่งสูญเสียเงินไปหลักแปดหลัก

ความล้มเหลวด้านความปลอดภัยของ bridge กลายเป็นภาษีรายเดือนไปแล้ว

มองให้กว้างขึ้น การถูกแฮกของ Verus ก็แค่รายการหนึ่งในบัญชี ไม่ใช่เหตุการณ์ผิดปกติ ตามข้อมูลของ PeckShield ที่ Bitcoin.com อ้างอิง การโจมตี crypto bridge รวมกันสูงถึงราว 328 ล้านดอลลาร์ในเดือนพฤษภาคม 2026 เพียงเดือนเดียว มีเหตุการณ์บริดจ์ถูกโจมตีถึงแปดครั้งในเวลาไม่ถึงห้าเดือนของปีนี้

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

สำหรับผู้ที่โอนมูลค่าจริง บทสรุปนั้นน่าอึดอัดใจ: บริดจ์ส่วนใหญ่คือข้อสมมติฐานเรื่องความเชื่อใจที่สวมชุดคณิตศาสตร์ไว้ ผมเคยโต้แย้งก่อนหน้านี้ใน How Stablecoin Bridges Actually Fail ว่าบริดจ์ที่ปลอดภัยที่สุดมักเป็นบริดจ์ที่ยอมรับว่าตัวเองตรวจสอบได้น้อยแค่ไหน

บริดจ์ที่ป้องกันได้จริงมีหน้าตาอย่างไร

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

  1. สัญญาปลายทางต้องตรวจสอบหลักฐานทางเข้ารหัสของเหตุการณ์ต้นทาง ไม่ใช่เชื่อคำพูดของ relayer เพียงอย่างเดียว ใช้ light-client หรือ zk proof แทน multisig attestation ทุกครั้งที่งบประมาณด้านเวลาแฝงอนุญาต
  2. การตรวจสอบจำนวนเงินต้องครอบคลุมทุก path อย่างสมบูรณ์ บั๊กประเภท checkCCEValues มักซ่อนตัวอยู่ใน branch ที่ input บางประเภทข้ามไป ให้ fuzz การเปรียบเทียบ อย่าเพียงแค่มองผ่านๆ
  3. rate limit และ circuit breaker แยกตามแต่ละสินทรัพย์ เพื่อไม่ให้มูลค่าที่ถูกปลอมแปลงสามารถดูด reserve ทั้งหมดได้ในธุรกรรมเดียว เพดานที่หยุดการทำงานอัตโนมัติเมื่อเกิน 5% ของ TVL ต่อชั่วโมงน่าจะบรรเทาเหตุการณ์ส่วนใหญ่ในปี 2026 ได้
  4. การตรวจสอบ invariant อิสระที่คอยจับตายอดรวม minted เทียบกับยอดรวม locked แบบ real-time และหยุดทำงานทันทีเมื่อพบความคลาดเคลื่อน

ไม่มีอะไรแปลกใหม่ในข้อเหล่านี้ audit stack สำหรับตรวจจับปัญหาเหล่านี้มีอยู่แล้ว ซึ่งผมเจาะลึกไว้ใน the audit-stack piece ปัญหาคือบริดจ์ยังคงส่งมอบ validation เป็นสิ่งที่คิดทีหลังแทนที่จะทำให้มันเป็นตัวผลิตภัณฑ์เอง

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

แหล่งอ้างอิง