2.93 พันล้านดอลลาร์ระเหยหายไป โดยไม่มีช่องโหว่ในโค้ด: การโจมตีแฮ็กที่ใหญ่ที่สุดในปี 2026 เผยให้เห็นจุดบอดด้านความปลอดภัยในการกำหนดค่า DVN

วันที่ 18 เมษายน 2026 โปรโตคอลการรีสเตคแบบลิควิดของ Kelp DAO ถูกโจมตีโดยผู้โจมตีที่ดึง rsETH จำนวน 116,500 โทเค็นออกจากบริดจ์ครอสเชนภายในเวลาไม่กี่ชั่วโมง ซึ่งมีมูลค่าประมาณ 293 ล้านดอลลาร์สหรัฐตามราคาในขณะนั้น กระบวนการทั้งหมดมีประสิทธิภาพสูงจนผิดปกติ ตั้งแต่การปลอมแปลงข้อความครอสเชนไปจนถึงการกระจายเงินที่ขโมยมาในสามโปรโตคอลการให้กู้ยืม ได้แก่ Aave V3, Compound V3 และ Euler เพื่อกู้ยืมสินทรัพย์จริง ผู้โจมตีถอนตัวออกไปในวันเดียวกันพร้อมกับ WETH มูลค่า 236 ล้านดอลลาร์สหรัฐ Aave, SparkLend และ Fluid ได้แช่แข็งตลาด rsETH ทันที

นี่คือเหตุการณ์การโจมตี DeFi ที่ใหญ่ที่สุดในปี 2026 จนถึงปัจจุบัน

แต่มีสิ่งหนึ่งที่ทำให้การโจมตีครั้งนี้แตกต่างจากเหตุการณ์แฮ็กเกอร์ส่วนใหญ่ สมาร์ทคอนแทรกต์ของ Kelp DAO ไม่มีช่องโหว่ใดๆ นักวิจัยด้านความปลอดภัย @0xQuit ที่เข้าร่วมในการสอบสวนเขียนบน X ว่า "จากสิ่งที่ฉันรู้ในตอนนี้ นี่คือการซ้อนทับของสองปัญหา: การกำหนดค่า DVN แบบ 1-of-1 และการที่โหนด DVN เองถูกบุกรุก" ทาง LayerZero อย่างเป็นทางการก็ไม่ได้กล่าวถึงโค้ดคอนแทรกต์ในแถลงการณ์เช่นกัน โดยระบุปัญหาว่าเป็น "ช่องโหว่ rsETH" ไม่ใช่ "ช่องโหว่ LayerZero"

293 ล้านดอลลาร์ ไม่ได้อยู่ในบรรทัดโค้ดใดๆ มันซ่อนอยู่ในพารามิเตอร์การกำหนดค่าที่กรอกผิดระหว่างการดีพลอย

ตรรกะทั่วไปของการตรวจสอบความปลอดภัย DeFi คือ: หาคอนแทรกต์ อ่านโค้ด หาช่องโหว่ ตรรกะนี้ทำงานค่อนข้างราบรื่นเมื่อรับมือกับช่องโหว่ตรรกะโค้ด เครื่องมือเช่น Slither และ Mythril มีความสามารถที่ค่อนข้างเป็นผู้ใหญ่ในการตรวจจับรูปแบบที่รู้จัก เช่น การโจมตีซ้ำ (reentrancy) และการล้นของจำนวนเต็ม (integer overflow) การตรวจสอบโค้ดด้วยความช่วยเหลือของ LLM ที่ได้รับการส่งเสริมอย่างแข็งขันในช่วงสองปีที่ผ่านมา ก็มีความสามารถระดับหนึ่งต่อช่องโหว่ตรรกะธุรกิจ (เช่น เส้นทางอาร์บิทราจผ่านฟลัชโลน)

แต่มีสองแถวในเมทริกซ์นี้ที่เป็นสีแดง

ช่องโหว่ระดับการกำหนดค่า (Configuration layer) เป็นจุดบอดเชิงโครงสร้างในการตรวจสอบด้วยเครื่องมือ จุดที่ Kelp DAO มีปัญหาไม่ได้อยู่ในไฟล์ .sol แต่อยู่ในพารามิเตอร์หนึ่งที่เขียนระหว่างการดีพลอยของโปรโตคอล นั่นคือ เกณฑ์ DVN (DVN threshold) พารามิเตอร์นี้กำหนดว่าข้อความครอสเชนต้องได้รับการยืนยันจากโหนดตรวจสอบ (verifier node) กี่โหนด จึงจะถือว่าถูกต้อง มันไม่ได้เข้าไปในโค้ด ไม่ได้เข้าไปในขอบเขตการสแกนของ Slither และไม่ได้เข้าไปในเส้นทางการดำเนินการเชิงสัญลักษณ์ (symbolic execution path) ของ Mythril จากการศึกษาเปรียบเทียบของ Dreamlab Technologies, Slither และ Mythril ตรวจพบช่องโหว่ 5/10 และ 6/10 ตามลำดับในคอนแทรกต์ที่ทดสอบ แต่ผลลัพธ์นี้ตั้งอยู่บนสมมติฐานที่ว่า "ช่องโหว่อยู่ในโค้ด" จากการวิจัยของ IEEE แม้แต่ในระดับโค้ด เครื่องมือที่มีอยู่ก็สามารถตรวจจับช่องโหว่ที่สามารถใช้ประโยชน์ได้เพียง 8%-20% เท่านั้น

จากมุมมองของกระบวนทัศน์การตรวจสอบในปัจจุบัน ไม่มีเครื่องมือใดที่สามารถ "ตรวจจับว่าเกณฑ์ DVN สมเหตุสมผลหรือไม่" หากต้องการตรวจจับความเสี่ยงด้านการกำหนดค่าประเภทนี้ สิ่งที่ต้องการไม่ใช่ตัววิเคราะห์โค้ด แต่เป็นรายการตรวจสอบเฉพาะทาง: "จำนวน DVN ของโปรโตคอลครอสเชนที่ใช้ ≥ N?" "มีข้อกำหนดเกณฑ์ขั้นต่ำหรือไม่?" คำถามประเภทนี้ยังไม่มีเครื่องมือมาตรฐานครอบคลุม และยังไม่มีมาตรฐานอุตสาหกรรมที่ได้รับการยอมรับอย่างกว้างขวาง

ในพื้นที่สีแดงเดียวกันคือความปลอดภัยของคีย์และโหนด คำอธิบายของ @0xQuit กล่าวถึงโหนด DVN ว่า "ถูกบุกรุก" ซึ่งอยู่ในขอบเขตของความปลอดภัยในการดำเนินงาน (OpSec) และเกินขอบเขตการตรวจจับของเครื่องมือวิเคราะห์แบบคงที่ (static analysis) ไม่ว่าจะเป็นสถาบันตรวจสอบระดับแนวหน้าใดหรือเครื่องมือสแกน AI ล้วนไม่มีความสามารถที่จะทำนายว่าคีย์ส่วนตัวของผู้ให้บริการโหนดจะรั่วไหลหรือไม่

การโจมตีครั้งนี้ได้กระตุ้นทั้งสองพื้นที่สีแดงในเมทริกซ์พร้อมกัน

DVN คือกลไกการตรวจสอบข้อความครอสเชนของ LayerZero V2 ย่อมาจาก Decentralized Verifier Network (เครือข่ายผู้ตรวจสอบแบบกระจายศูนย์) ปรัชญาการออกแบบของมันคือการมอบอำนาจการตัดสินใจด้านความปลอดภัยให้กับเลเยอร์แอปพลิเคชัน: แต่ละโปรโตคอลที่เชื่อมต่อกับ LayerZero สามารถเลือกได้ด้วยตัวเองว่าต้องการให้โหนด DVN กี่โหนดยืนยันพร้อมกัน จึงจะอนุญาตให้ข้อความครอสเชนผ่านไปได้

"อิสระ" นี้สร้างสเปกตรัมขึ้นมา

Kelp DAO เลือกปลายซ้ายสุดของสเปกตรัมคือ 1-of-1 ซึ่งต้องการการยืนยันจากโหนด DVN เพียงโหนดเดียวเท่านั้น ซึ่งหมายความว่าอัตราการทนต่อข้อผิดพลาด (fault tolerance) เป็นศูนย์ ผู้โจมตีเพียงแค่ต้องบุกรุกโหนดนั้นเพียงโหนดเดียว ก็สามารถปลอมแปลงข้อความครอสเชนใดๆ ก็ได้ เปรียบเทียบกับ Apechain ที่เชื่อมต่อกับ LayerZero เช่นกัน แต่กำหนดค่าให้มี DVN ที่จำเป็นสองโหนดขึ้นไป และไม่ได้รับผลกระทบจากเหตุการณ์ครั้งนี้ LayerZero อย่างเป็นทางการใช้ถ้อยคำในแถลงการณ์ว่า "แอปพลิเคชันอื่นๆ ทั้งหมดยังคงปลอดภัย" ซึ่งคำพูดแฝงของประโยคนี้คือ: ปลอดภัยหรือไม่ ขึ้นอยู่กับว่าคุณเลือกการกำหนดค่าใด

คำแนะนำมาตรฐานของอุตสาหกรรมคืออย่างน้อย 2-of-3 ซึ่งผู้โจมตีต้องบุกรุกโหนด DVN อิสระสองโหนดพร้อมกันเพื่อปลอมแปลงข้อความ ทำให้อัตราการทนต่อข้อผิดพลาดเพิ่มขึ้นเป็น 33% การกำหนดค่าความปลอดภัยสูง เช่น 5-of-9 สามารถมีอัตราการทนต่อข้อผิดพลาดได้ถึง 55%

ปัญหาคือ ผู้สังเกตการณ์ภายนอกและผู้ใช้ไม่เห็นการกำหนดค่านี้ แม้จะเรียกว่า "รองรับโดย LayerZero" เหมือนกัน แต่เบื้องหลังอาจมีอัตราการทนต่อข้อผิดพลาด 0% หรือ 55% ก็ได้ ทั้งสองอย่างในเอกสารล้วนเรียกว่า DVN

นักลงทุนคริปโตอาวุโส Dovey Wan ผู้เคยผ่านเหตุการณ์ Anyswap มาแล้ว เขียนบน X โดยตรงว่า: "DVN ของ LayerZero กลายเป็น 1/1 validator ... บริดจ์ครอสเชนทั้งหมดควรดำเนินการตรวจสอบความปลอดภัยอย่างครอบคลุมทันที"

ในเดือนสิงหาคม 2022 มีคนค้นพบช่องโหว่ในบริดจ์ครอสเชน Nomad มีคนคัดลอกธุรกรรมการโจมตีครั้งแรก แก้ไขเล็กน้อย และพบว่ามันสำเร็จเช่นกัน ดังนั้นหลายร้อยที่อยู่จึงคัดลอกตามกันมา และดูดทรัพย์สินมูลค่า 190 ล้านดอลลาร์สหรัฐออกไปภายในเวลาไม่กี่ชั่วโมง

การวิเคราะห์หลังเหตุการณ์ของ Nomad เขียนว่า แหล่งที่มาของช่องโหว่คือ "ระหว่างการอัปเกรดตามปกติ ได้กำหนดค่า trusted root เริ่มต้นเป็น 0x00" นี่คือข้อผิดพลาดในการกำหนดค่า (configuration error) ที่เกิดขึ้นในขั้นตอนการดีพลอย ตรรกะการตรวจสอบ Merkle proof ไม่มีปัญหา โค้ดเองไม่มีปัญหา ปัญหาอยู่ที่ค่าตั้งต้นที่กรอกผิด

ครั้งนี้รวมกับ Nomad ช่องโหว่ประเภทการกำหนดค่า/การกำหนดค่าเริ่มต้น (configuration/initialization) ได้สร้างความเสียหายประมาณ 482 ล้านดอลลาร์สหรัฐแล้ว ในประวัติศาสตร์การโจรกรรมบริดจ์ครอสเชนทั้งหมด ขนาดของหมวดหมู่นี้สามารถเทียบเคียงได้กับหมวดหมู่การรั่วไหลของคีย์ (Ronin 624 ล้านดอลลาร์, Harmony 100 ล้านดอลลาร์, Multichain 126 ล้านดอลลาร์ รวมประมาณ 850 ล้านดอลลาร์)

แต่การออกแบบผลิตภัณฑ์ของอุตสาหกรรมการตรวจสอบโค้ดไม่เคยมุ่งเป้าไปที่หมวดหมู่นี้

สิ่งที่อุตสาหกรรมพูดถึงมากที่สุดยังคงเป็นช่องโหว่ตรรกะโค้ด Wormhole ถูกแฮ็ก 326 ล้านดอลลาร์เนื่องจากบายพาสการตรวจสอบลายเซ็น, Qubit Finance ถูกขโมย 80 ล้านดอลลาร์เนื่องจากเหตุการณ์การฝากเงินปลอม กรณีศึกษาเหล่านี้มีรายงานการวิเคราะห์ช่องโหว่ที่สมบูรณ์ มีการเปรียบเทียบหมายเลข CVE มี PoC ที่สามารถทำซ้ำได้ เหมาะสำหรับการฝึกอบรมและปรับปรุงเครื่องมือตรวจสอบ ปัญหาระดับการกำหนดค่าไม่ได้เขียนอยู่ในโค้ด จึงยากที่จะเข้าสู่วงจรการผลิตนี้

รายละเอียดหนึ่งที่น่าสังเกตคือ วิธีการกระตุ้นของเหตุการณ์ประเภทการกำหนดค่าทั้งสองครั้งแตกต่างกันโดยสิ้นเชิง Nomad เป็นการกรอกค่าตั้งต้นผิดโดยไม่ได้ตั้งใจระหว่างการอัปเกรดตามปกติ ซึ่งถือเป็นความผิดพลาด (mistake) ส่วนการกำหนดค่า 1-of-1 ของ Kelp DAO เป็นการเลือกกำหนดค่าโดยเจตนา (active configuration choice) — โปรโตคอล LayerZero ไม่ได้ห้ามตัวเลือกนี้ และ Kelp DAO ก็ไม่ได้ละเมิดกฎของโปรโตคอลใดๆ การเลือกกำหนดค่าที่ "เป็นไปตามข้อกำหนด" หนึ่งครั้ง และค่าตั้งต้นที่ "ผิดพลาด" หนึ่งครั้ง ในที่สุดก็นำไปสู่ผลลัพธ์เดียวกัน

ตรรกะการดำเนินการโจมตีครั้งนี้เรียบง่าย ข้อความครอสเชนปลอมหนึ่งข้อความบอกกับ Ethereum Mainnet ว่า "มีคนล็อคสินทรัพย์มูลค่าเท่ากันบนเชนอื่นแล้ว" ซึ่งกระตุ้นให้铸造 rsETH บน Mainnet rsETH ที่铸造ออกมาไม่มีสินทรัพย์ค้ำประกันจริง แต่บันทึกบนเชนของมัน "ถูกต้องตามกฎหมาย" และสามารถได้รับการยอมรับจากโปรโตคอลการให้กู้ยืมเป็นหลักประกันได้

ผู้โจมตีได้กระจาย rsETH จำนวน 116,500 โทเค็น ไปยัง Aave V3 (Ethereum และ Arbitrum), Compound V3 และ Euler และกู้ยืมสินทรัพย์จริงรวมมูลค่ากว่า 236 ล้านดอลลาร์สหรัฐออกมา ตามรายงานหลายแหล่ง ค่าประมาณหนี้เสียที่ Aave V3 เผชิญอยู่เพียงลำพังอยู่ที่ประมาณ 177 ล้านดอลลาร์สหรัฐ คลังสำรอง WETH ของโมดูลความปลอดภัย Umbrella ของ Aave ซึ่งสามารถใช้ดูดซับหนี้เสียได้ มีประมาณ 50 ล้านดอลลาร์สหรัฐ ซึ่งครอบคลุมไม่ถึงหนึ่งในสามของจำนวนดังกล่าว ส่วนที่เหลือจะต้องแบกรับโดยผู้ที่สเตค aWETH

บัญชีนี้ในที่สุดตกไปอยู่กับคนที่แค่อยากได้อัตราดอกเบี้ย WETH เพิ่มขึ้นอีกนิด

ทาง LayerZero อย่างเป็นทางการ ณ เวลาที่เขียนบทความนี้ ยังคงร่วมสอบสวนกับองค์กรตอบสนองเหตุฉุกเฉินด้านความปลอดภัย SEAL Org และระบุว่าจะเผยแพร่รายงานวิเคราะห์หลังเหตุการณ์ร่วมกับ Kelp DAO หลังจากได้รับข้อมูลทั้งหมด Kelp DAO ระบุว่ากำลังดำเนินการ "การแก้ไขเชิงรุก"

ช่องโหว่ 293 ล้านดอลลาร์ไม่ได้อยู่ในโค้ด สี่คำว่า "ผ่านการตรวจสอบ" ไม่ได้ครอบคลุมตำแหน่งที่พารามิเตอร์นั้นอยู่