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 ว่าบริดจ์ที่ปลอดภัยที่สุดมักเป็นบริดจ์ที่ยอมรับว่าตัวเองตรวจสอบได้น้อยแค่ไหน
บริดจ์ที่ป้องกันได้จริงมีหน้าตาอย่างไร
หากคุณกำลังสร้างหรือตรวจสอบบริดจ์ การตรวจสอบความถูกต้องของจำนวนเงินต้นทางคือจุดที่ควรทุ่มความระแวดระวังให้มากเป็นพิเศษ สิ่งที่ผมถือว่าขาดไม่ได้มีดังนี้:
- สัญญาปลายทางต้องตรวจสอบหลักฐานทางเข้ารหัสของเหตุการณ์ต้นทาง ไม่ใช่เชื่อคำพูดของ relayer เพียงอย่างเดียว ใช้ light-client หรือ zk proof แทน multisig attestation ทุกครั้งที่งบประมาณด้านเวลาแฝงอนุญาต
- การตรวจสอบจำนวนเงินต้องครอบคลุมทุก path อย่างสมบูรณ์ บั๊กประเภท
checkCCEValuesมักซ่อนตัวอยู่ใน branch ที่ input บางประเภทข้ามไป ให้ fuzz การเปรียบเทียบ อย่าเพียงแค่มองผ่านๆ - rate limit และ circuit breaker แยกตามแต่ละสินทรัพย์ เพื่อไม่ให้มูลค่าที่ถูกปลอมแปลงสามารถดูด reserve ทั้งหมดได้ในธุรกรรมเดียว เพดานที่หยุดการทำงานอัตโนมัติเมื่อเกิน 5% ของ TVL ต่อชั่วโมงน่าจะบรรเทาเหตุการณ์ส่วนใหญ่ในปี 2026 ได้
- การตรวจสอบ invariant อิสระที่คอยจับตายอดรวม minted เทียบกับยอดรวม locked แบบ real-time และหยุดทำงานทันทีเมื่อพบความคลาดเคลื่อน
ไม่มีอะไรแปลกใหม่ในข้อเหล่านี้ audit stack สำหรับตรวจจับปัญหาเหล่านี้มีอยู่แล้ว ซึ่งผมเจาะลึกไว้ใน the audit-stack piece ปัญหาคือบริดจ์ยังคงส่งมอบ validation เป็นสิ่งที่คิดทีหลังแทนที่จะทำให้มันเป็นตัวผลิตภัณฑ์เอง
การโจมตีบริดจ์ครั้งต่อไปของปี 2026 กำลังถูกเขียนขึ้นอยู่แล้ว มันจะมีชื่อฟังก์ชันที่ต่างออกไปแต่มีสาเหตุหลักเดิม และเราก็จะแสร้งทำเป็นประหลาดใจอีกครั้ง เราไม่ควรทำเช่นนั้น