PHP พบช่องโหว่ร้ายแรงระดับอินเทอร์เน็ต จุดอ่อนนอกเชนของ Web3 จะแก้ไขอย่างไร?

ชื่อเรื่องต้นฉบับ: 《PHP พบช่องโหว่ร้ายแรงระดับอินเทอร์เน็ต จุดอ่อนนอกเชนของ Web3 จะแก้ไขอย่างไร?》
ผู้เขียนต้นฉบับ: ทีมความปลอดภัย SlowMist

เกิดอะไรขึ้น

เมื่อวันที่ 21 ตุลาคม โปรเจกต์ PHP ได้ออกอัปเดตความปลอดภัยฉุกเฉินเพื่อแก้ไขช่องโหว่ร้ายแรงสองรายการคือ CVE-2026-109618 และ CVE-2026-109619 ซึ่งสามารถนำไปสู่การเรียกใช้โค้ดจากระยะไกล (RCE) โดยไม่ต้องรับรองความถูกต้อง ทั้งสองรายการได้รับคะแนน CVSS v4.0 9.2 คะแนน PHP ระบุอย่างเป็นทางการว่าก่อนการแก้ไข การติดตั้ง PHP ทั้งหมดที่ให้บริการเว็บภายนอกอาจได้รับผลกระทบ

เมื่อวันที่ 20 ตุลาคม รายละเอียดช่องโหว่รั่วไหลก่อนการเปิดเผยอย่างเป็นทางการ และแพตช์ยังไม่ได้เผยแพร่ ทีมความปลอดภัย PHP จึงต้องเลื่อนการเผยแพร่เวอร์ชันฉุกเฉินจากเดิมวันที่ 22 ตุลาคม มาเป็นวันที่ 21 ตุลาคม เวลา 14:00 น. (UTC)

ที่น่ากังวลยิ่งกว่าคือ การโจมตีอาจเกิดขึ้นก่อนการเปิดเผย ทีมข่าวกรองภัยคุกคามของ Amazon รายงานว่าพวกเขาสังเกตเห็นความพยายามใช้ประโยชน์จาก php2shell ในเครือข่ายฮันนีพอต MadPot ของตนเองตั้งแต่วันที่ 17 ตุลาคม ซึ่งเร็วกว่าการเปิดเผยต่อสาธารณะถึงสี่วัน

慢霧 (SlowMist) ยังได้ออกคำเตือนและคำแนะนำด้านความปลอดภัยทันทีหลังจากการประกาศอย่างเป็นทางการของ PHP

ช่องโหว่ทั้งสองคืออะไร

CVE-2026-109618 (OOM Memory Corruption): เมื่อหน่วยความจำของ PHP หมด กระบวนการประมวลผลจะถูกขัดจังหวะ และข้อมูลที่อยู่ในมือเตรียมไว้เพียงครึ่งเดียว ในระหว่างการทำความสะอาด PHP กลับนำข้อมูลครึ่งๆ กลางๆ เหล่านี้มาใช้เป็นข้อมูลที่สมบูรณ์ ส่งผลให้หน่วยความจำเกิดความเสียหาย

CVE-2026-109619 (Stale Global State): หลังจากประมวลผลคำขอหนึ่งเสร็จ หน่วยความจำถูกปล่อยคืนแล้ว แต่สถานะที่เกี่ยวข้องยังคง "ค้างอยู่" เมื่อเวิร์กเกอร์โปรเซสเดียวกันรับคำขอถัดไป อาจใช้สถานะที่ล้าสมัยนี้ก่อนการเริ่มต้นปกติ ทางการยืนยันแล้วว่าสามารถใช้โจมตี PHP-FPM และเรียกใช้โค้ดจากระยะไกลได้

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

ขอบเขตผลกระทบ: PHP 5.4 ถึง 8.5.11 ได้รับผลกระทบทั้งหมด เวอร์ชันที่แก้ไขคือ 8.5.12, 8.4.27, 8.3.36 และ 8.2.35 PHP 8.1 และเวอร์ชันก่อนหน้าได้หยุดการสนับสนุนปกติจาก upstream แล้ว ไม่สามารถคาดหวังแพตช์จากช่องทางปกติได้ ควรย้ายไปยังเวอร์ชันที่ยังได้รับการสนับสนุน

ทำไมทั่วโลกถึงตื่นตระหนก?

เพราะ PHP แพร่หลายมาก ตามสถิติของ W3Techs ในบรรดาเว็บไซต์ที่สามารถระบุภาษาฝั่งเซิร์ฟเวอร์ได้ 69.3% ใช้ PHP ระบบที่คุ้นเคยอย่าง WordPress, WooCommerce, Magento ล้วนใช้ PHP เป็นพื้นฐาน

ปฏิกิริยาของประเทศต่างๆ ก็บ่งบอกถึงปัญหา—ศูนย์ความมั่นคงปลอดภัยไซเบอร์แห่งชาติเนเธอร์แลนด์เคยปิดเว็บไซต์เชิงป้องกัน; สำนักงานประธานาธิบดีเกาหลีใต้จัดการประชุมความมั่นคงปลอดภัยไซเบอร์ฉุกเฉิน และรัฐบาลปรับเพิ่มระดับการเตือนภัยความมั่นคงปลอดภัยไซเบอร์

นอกจากนี้ มีรายงานว่าเว็บไซต์ทางการเกือบทั้งหมดของเกาหลีเหนือ รวมถึงสื่อทางการและพอร์ทัลรัฐบาล ออฟไลน์นานกว่า 24 ชั่วโมงแล้ว ยังไม่ทราบว่าเกี่ยวข้องกับเหตุการณ์ช่องโหว่นี้หรือไม่

ผลกระทบต่อ Web3

นี่ไม่ใช่ปัญหาเฉพาะการดำเนินงานเว็บไซต์แบบดั้งเดิม สำหรับ Web3 แม้สัญญาบนเชนจะไม่มีช่องโหว่ แต่ "ส่วนนอกเชน" จำนวนมากที่ทำงานรอบสัญญา เช่น หน้าฟรอนต์เอนด์, API, กระเป๋าเงิน custodial, บริการลงนาม, หน้าแจก airdrop, แบ็กเอนด์ปฏิบัติการ และบริการข้อมูล หลายส่วนสร้างด้วย PHP (WordPress, WooCommerce, Magento เป็นต้น) การที่สัญญาไม่มีช่องโหว่ ไม่ได้หมายความว่าส่วนเหล่านี้ปลอดภัย

ตามสถิติจาก MistEye ระบบข่าวกรองภัยคุกคามภายใต้ 慢霧 (SlowMist) จากโดเมนที่เกี่ยวข้องกับอุตสาหกรรมคริปโต 1488 โดเมนที่สแกน พบ 793 โดเมนมีลายนิ้วมือ PHP โดยตรง คิดเป็นประมาณ 53.3% ต้องเน้นว่านี่เพียงบ่งบอกว่าใช้ PHP ไม่ได้หมายความว่าเว็บไซต์เหล่านี้มีช่องโหว่หรือถูกโจมตีแล้ว

1. ฝั่งแพลตฟอร์ม: เส้นทางความเสี่ยงทั่วไปหลายประการ

ฟรอนต์เอนด์ถูกแก้ไข ผู้ใช้ถูกชักจูงให้ลงนาม

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

การรั่วไหลของคีย์และข้อมูลรับรอง

หลังจากเซิร์ฟเวอร์ถูกควบคุม ผู้โจมตีอาจอ่านไฟล์คอนฟิก รหัสผ่านฐานข้อมูล API Token ตัวแปรสภาพแวดล้อม ฯลฯ หากแบ็กเอนด์ใช้ PHP เชื่อมต่อกับ RPC ของโหนดหรือบริการ hot wallet เมื่อ API Key หรือ session token รั่วไหล อาจยกระดับเป็นการโอนสินทรัพย์ hot wallet หรือการใช้สิทธิ์การลงนามในทางที่ผิด

แบ็กเอนด์และ API ถูกยึด

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

การเคลื่อนที่แนวราบในซัพพลายเชน

สิทธิ์ของโปรเซส PHP มักไม่เท่ากับสิทธิ์สูงสุดของเซิร์ฟเวอร์ แต่หากสามารถอ่านคีย์ CI/CD, socket รันไทม์ของคอนเทนเนอร์, ข้อมูลรับรองฐานข้อมูล หรือโทเค็นการเข้าถึงคลาวด์ ขอบเขตการโจมตีอาจขยายจากเว็บโหนดหนึ่งไปยังฐานข้อมูล ระบบ build หรือแม้แต่บัญชี production ทั้งหมด

ปลั๊กอินการชำระเงินและบริการบุคคลที่สาม

เป็นที่ทราบกันว่าโซลูชันการชำระเงินคริปโตอย่าง Binance Pay, Crypto.com Pay, BitPay, CoinGate, CoinPayments มีการผสานรวมกับ WooCommerce หากเซิร์ฟเวอร์ไม่ได้รับการแพตช์ก็มีความเสี่ยงร้ายแรง บริการบุคคลที่สาม เช่น RPC, บล็อก explorer, แพลตฟอร์มวิเคราะห์ข้อมูล หากแบ็กเอนด์หรือระบบปฏิบัติการรันบนสภาพแวดล้อม PHP ที่ได้รับผลกระทบ ก็อาจเป็นช่องทางเข้าได้ แน่นอนว่าโหนด RPC, สัญญาอัจฉริยะ, บล็อก explorer และกระเป๋าเงินเองไม่ได้พึ่งพา PHP โดยธรรมชาติ ขึ้นอยู่กับ technology stack ของผลิตภัณฑ์นั้นๆ

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

2. ผู้ใช้ทั่วไป: ควรถอนเหรียญออกหรือไม่?

ไม่จำเป็น

เหตุผลง่ายๆ:

ช่องโหว่นี้ส่งผลต่อสภาพแวดล้อมเซิร์ฟเวอร์ที่ตรงตามเงื่อนไขเฉพาะ ไม่ได้หมายความว่ากระเป๋าเงินของผู้ใช้ทุกคนมีความเสี่ยง

การเรียกดูเว็บไซต์ การเชื่อมต่อกระเป๋าเงิน ไม่เหมือนกับการรั่วไหลของ private key ช่องโหว่เองไม่สามารถเจาะกระเป๋าเงินหรือการลงนามของผู้ใช้ได้โดยตรง

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

หากโปรเจกต์ยืนยันอย่างเป็นทางการว่าเว็บไซต์หรือแบ็กเอนด์ถูกบุกรุก ให้พิจารณาตามผลกระทบจริงที่ประกาศว่าจะหยุดการโต้ตอบ ตรวจสอบธุรกรรมผิดปกติ เพิกถอนการอนุญาตที่น่าสงสัยหรือไม่ หากยืนยันว่า private key หรือ seed phrase รั่วไหล ให้จัดการเป็นเหตุการณ์คีย์รั่วไหล การเปลี่ยนรหัสผ่านหรือตัดการเชื่อมต่อเว็บไซต์เพียงอย่างเดียวไม่เพียงพอ ผู้ใช้ที่ใช้บอทเทรด เครื่องมืออัตโนมัติ หรือบริการคลาวด์ ควรติดตามว่าบริการที่เกี่ยวข้องประกาศเวอร์ชันที่ได้รับผลกระทบหรือการหมุนเวียนข้อมูลรับรองหรือไม่

วิธีรับมือ

1. แพลตฟอร์มและฝ่ายโปรเจกต์:

ขั้นแรก: สำรวจสินทรัพย์ อัปเกรดโดยเร็ว

ตรวจสอบสินทรัพย์ PHP ทั้งหมดในเครือข่ายสาธารณะและภายใน: โฮสต์, อิมเมจคอนเทนเนอร์, เวิร์กโหลด Kubernetes, CMS เดิม, แบ็กเอนด์การจัดการ, สภาพแวดล้อมโฮสติ้งของพันธมิตร, ปลั๊กอินบุคคลที่สาม และบริการโฮสติ้ง ลายนิ้วมือทางเทคนิคเป็นเพียงเบาะแส ไม่สามารถสรุปได้โดยตรงว่า "ยืนยันว่ามีช่องโหว่"

อัปเกรดเป็น 8.2.35 / 8.3.36 / 8.4.27 / 8.5.12 หรือใช้แพตช์เทียบเท่าจาก distro ผู้ให้บริการคลาวด์ หรือผู้ให้บริการโฮสติ้ง หากใช้เวอร์ชัน 8.1 หรือก่อนหน้า ต้องขอ backport จากผู้จำหน่ายหรือย้ายโดยเร็ว "สภาพแวดล้อมเก่าเสถียร" "แอปพลิเคชันไม่ค่อยอัปเดต" ไม่สามารถลดความเสี่ยงของช่องโหว่นี้ได้

หลังอัปเกรด ให้ rebuild อิมเมจคอนเทนเนอร์ rolling restart หรือแทนที่เวิร์กเกอร์โปรเซส PHP ทั้งหมด และตรวจสอบเวอร์ชันรันไทม์ที่ประมวลผลคำขอจริงบน production ไม่ใช่แค่เวอร์ชันในเครื่อง build หรือ command line

ขั้นที่สอง: ถ้ายังอัปเกรดไม่ได้ชั่วคราว

ลดพื้นที่โจมตีก่อนเพื่อซื้อเวลา แต่ไม่สามารถแทนที่แพตช์ได้:

แยกแอปพลิเคชัน PHP ที่เปิดเผยต่ออินเทอร์เน็ตสาธารณะ หรือเพิ่มการรับรองความถูกต้องเครือข่ายและการควบคุมการเข้าถึงที่ชั้น ingress

ปิดการอัปโหลดไฟล์ที่ไม่จำเป็น ปฏิเสธคำขอ multipart/form-data ที่ไม่จำเป็นที่ชั้น WAF หรือเว็บเซิร์ฟเวอร์

คำแนะนำด้านความปลอดภัยบางส่วนยังรวมถึง: ตั้งค่า memory_limit=-1 ปิด session.upload_progress.enabled และบน PHP 8.5 ปิด fatal_error_backtraces การตั้งค่าเหล่านี้มีผลข้างเคียงทางธุรกิจและความพร้อมใช้งาน ต้องทดสอบก่อน และรีสตาร์ท PHP worker ทั้งหมดหลังการเปลี่ยนแปลงทุกครั้ง

ขั้นที่สาม: ตรวจสอบว่าถูกบุกรุกหรือไม่ และล้างข้อมูลรับรอง

สำหรับบริการที่ได้รับผลกระทบซึ่งเคยเปิดเผยต่ออินเทอร์เน็ตสาธารณะ ให้ตรวจสอบจากล็อก การเฝ้าระวัง endpoint และการเชื่อมต่อเครือข่ายที่ผิดปกติ เช่น โปรเซส PHP เริ่มเรียกใช้คำสั่งระบบอย่างกะทันหัน หากพบการบุกรุกที่ต้องสงสัย ให้เก็บหลักฐานก่อน แล้วจัดการตามกระบวนการตอบสนองเหตุการณ์

สมมติสถานการณ์เลวร้ายที่สุด: สำหรับเซิร์ฟเวอร์ที่ไม่ได้รับการแพตช์ทันเวลา ให้หมุนเวียน API key, session key, ใบรับรอง TLS, รหัสผ่านฐานข้อมูล, โทเค็นการเข้าถึงคลาวด์, ข้อมูลรับรอง CI/CD, RPC/API Key, Webhook key และโทเค็นบุคคลที่สาม และตรวจสอบบันทึกการใช้งานที่ผิดปกติ

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

ขั้นที่สี่: ปกป้องพื้นผิวการควบคุมสินทรัพย์

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

แยก private key ของ hot wallet, กระเป๋าเงินรวบรวม และบริการลงนามสำคัญ ออกจากเว็บโหนดโดยสิ้นเชิง ใช้ HSM, MPC, เครือข่ายการลงนามเฉพาะ หรือนโยบาย KMS ที่มีสิทธิ์น้อยที่สุด

แยกเว็บเซอร์วิส บริการลงนาม โหนดบนเชน ฐานข้อมูล และระบบ build ออกเป็น network segment และ identity boundary ที่แตกต่างกัน

ระหว่างเหตุการณ์ ให้เข้มงวดการดำเนินการที่มีความเสี่ยงสูงชั่วคราว เช่น การถอน การเปลี่ยน whitelist ที่อยู่ การยกระดับสิทธิ์ผู้ดูแล การสร้าง API Key การแก้ไขกฎควบคุมความเสี่ยง หากจำเป็นให้เปิดใช้การตรวจสอบโดยมนุษย์หรือการมีผลล่าช้า

บริการที่ทำงานอัตโนมัติบนเชน อาจใช้การลงนามอิสระ การอนุมัติ multisig การจำกัดวงเงินธุรกรรม และกลไกหยุดฉุกเฉินตามธุรกิจ

ตรวจสอบทรัพยากร static ของเว็บไซต์, แพ็กเกจ JavaScript, การตั้งค่า reverse proxy, กฎ DNS/CDN และบริการสร้างธุรกรรม เพื่อยืนยันว่าไม่มีการแทรกสคริปต์ที่เป็นอันตรายหรือถูกแทนที่

2. ผู้ใช้ทั่วไป:

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

อย่าดูแค่โดเมนและอินเทอร์เฟซ: แม้แต่โดเมน dApp ที่คุ้นเคย สคริปต์หน้าเว็บ พารามิเตอร์ธุรกรรม การตั้งค่า RPC ก็อาจถูกแทนที่โดยผู้บุกรุกฝั่งเซิร์ฟเวอร์

ตรวจสอบทีละรายการก่อนลงนาม: ที่อยู่ผู้รับ เชนที่อยู่ วงเงินการอนุญาต สัญญาที่เรียกใช้ และผลการจำลองธุรกรรม ระวัง approve และ setApprovalForAll เป็นพิเศษ ยิ่งต้องระวังการอนุญาตแบบไม่จำกัดวงเงิน

ระวัง "การชดเชย" "การย้าย" "การยืนยันใหม่": ระหว่างเหตุการณ์อาจมีข้อความเช่น "เข้าสู่ระบบใหม่" "ยืนยันกระเป๋าเงินใหม่" "ย้ายสินทรัพย์" "รับการชดเชย" อย่าดำเนินการตามป๊อปอัปในเว็บเพียงอย่างเดียว ต้องตรวจสอบข้ามช่องทางทางการหลายช่องทางของโปรเจกต์

แบ่งชั้นสินทรัพย์: ใช้ hardware wallet เก็บสินทรัพย์จำนวนมาก ใช้กระเป๋าเงินแยกต่างหากที่มีวงเงินจำกัดสำหรับการโต้ตอบรายวัน และล้างการอนุญาตเป็นประจำ วิธีนี้แม้ฟรอนต์เอนด์หรือแพลตฟอร์มหนึ่งมีปัญหา ความเสียหายต่อครั้งก็มีขีดจำกัด

มีสิ่งผิดปกติให้หยุดก่อน: หากพบคำขอลงนามที่ผิดปกติ ข้อความแจ้งการอนุญาตที่ไม่คาดคิด หรือพฤติกรรมเว็บไซต์ไม่ถูกต้อง ให้หยุดก่อน แล้วตรวจสอบผ่านช่องทางทางการ

ส่งท้าย

ช่องโหว่การเรียกใช้โค้ดจากระยะไกลแบบไม่ต้องล็อกอินอย่าง PHP2Shell เมื่อเจาะผ่านเว็บเลเยอร์ได้ การบุกรุกเซิร์ฟเวอร์แบบดั้งเดิมอาจพัฒนาเป็นการวางยาพิษฟรอนต์เอนด์ การปลอมแปลงตัวตน การใช้สิทธิ์การลงนามในทางที่ผิด ความเสี่ยง hot wallet หรือแม้แต่การเจาะแนวราบในระดับซัพพลายเชน

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