ในรอบแปดเดือน รูปแบบการโจมตีของเวิร์ม npm แบบเดิมได้ผลถึงสามครั้ง ผู้โจมตีต่างกัน แพ็กเกจต่างกัน แต่กลไกเหมือนกัน และช่วงเวลาเดียวกันระหว่างการเผยแพร่และการตรวจพบที่ทำให้แต่ละครั้งเกิดขึ้นได้ หากคุณถามว่าเวิร์ม npm คืออะไร และทำไมรูปแบบนี้ถึงเกิดขึ้นซ้ำแล้วซ้ำเล่าแทนที่จะได้รับการแก้ไข นี่คือคำตอบที่ตรงไปตรงมา เหตุการณ์ กลไก และช่องโหว่ที่แม้แต่กรอบการป้องกันที่แข็งแกร่งก็ยังคงเปิดอยู่
npm Worm คืออะไร?
เวิร์ม npm คือโค้ดที่เป็นอันตรายซึ่งเผยแพร่ไปยังรีจิสทรี npm และจะแพร่กระจายไปยังแพ็กเกจอื่นๆ โดยอัตโนมัติเมื่อมันทำงาน โดยทั่วไปแล้วจะขโมยข้อมูลประจำตัวการเผยแพร่ของผู้ดูแลและใช้ข้อมูลเหล่านั้นเพื่อแทรกโค้ดที่เป็นอันตรายเดียวกันเข้าไปในทุกแพ็กเกจที่ผู้ดูแลนั้นควบคุมอยู่ มันคือ "เวิร์ม" ในความหมายดั้งเดิม: มันไม่รอให้ใครติดตั้งมันโดยเจตนา มันแพร่กระจายด้วยตัวเองจากแพ็กเกจหนึ่งไปยังอีกแพ็กเกจหนึ่ง จากบัญชีหนึ่งไปยังอีกบัญชีหนึ่ง ด้วยความเร็วของเครื่อง
การแพร่กระจายตัวเองนี้เองที่เป็นสิ่งที่ทำให้เหตุการณ์เวิร์ม npm แตกต่างจากแพ็กเกจที่เป็นอันตรายทั่วไป แพ็กเกจที่ไม่ดีเพียงแพ็กเกจเดียวเปรียบเสมือนเข็มในกองฟาง แต่เวิร์ม npm จะเปลี่ยนผู้ดูแลระบบที่ได้รับผลกระทบทั้งหมดให้กลายเป็นจุดกระจายใหม่ และกองฟางก็จะเริ่มสร้างเข็มขึ้นมาเองเรื่อยๆ
เหตุการณ์เวิร์ม npm ครั้งใหญ่ที่สุดเท่าที่เคยเกิดขึ้น
ปีที่ผ่านมา รูปแบบ npm worm ได้รับการทดสอบใช้งานจริงถึงสามครั้ง โดยแต่ละครั้งมีประสิทธิภาพมากขึ้นกว่าครั้งก่อน:
- ชัยฮูลุด (กันยายน 2025) นี่คือเวิร์ม npm ตัวแรกที่แพร่กระจายตัวเองได้ โดยมีการบันทึกไว้ มันเจาะระบบข้อมูลประจำตัวของผู้ดูแลแพ็กเกจ จากนั้นใช้ข้อมูลเหล่านั้นในการเผยแพร่เวอร์ชันที่เป็นอันตรายของทุกแพ็กเกจที่อยู่ภายใต้การควบคุมของผู้ดูแลรายนั้น ทำให้เหล่านักพัฒนาเองกลายเป็นกลไกในการส่งต่อเวิร์มในขั้นตอนต่อไป
- axios (มีนาคม 2026) มัลแวร์จากรัฐชาติซ่อนอยู่ภายในแพ็กเกจที่ถูกดาวน์โหลดประมาณ 100 ล้านครั้งต่อสัปดาห์ ไม่ใช่เวิร์มในความหมายของการแพร่กระจายอย่างแท้จริง แต่เป็นหลักฐานที่แสดงให้เห็นว่าโมเดลความไว้วางใจของระบบนิเวศ npm ที่ Shai-Hulud ใช้ประโยชน์นั้น สามารถบรรทุกเพย์โหลดในปริมาณมหาศาลได้จริง ๆ
- SAP npm (เมษายน 2026) ในเวลานั้นมีการอธิบายว่าเป็น "ไช่ฮูลุดขนาดเล็ก" คือ รูปแบบหนอนแบบเดียวกัน เกิดขึ้นซ้ำในขนาดที่ใหญ่ขึ้น ไม่ถึงหนึ่งปีหลังจากเหตุการณ์ครั้งแรก กลไกไม่ได้เปลี่ยนแปลงไป ระบบป้องกันส่วนใหญ่ก็ยังคงเหมือนเดิม
เกิดเหตุการณ์ไวรัส npm ระบาด 3 ครั้ง รูปแบบที่ซ้ำกันหนึ่งรูปแบบ: เจาะระบบสำนักพิมพ์ที่น่าเชื่อถือ ใช้ข้อมูลประจำตัวของพวกเขาในการเผยแพร่โดยอัตโนมัติ และอาศัยช่องว่างระหว่างการเผยแพร่และการตรวจจับของชุมชนเพื่อดำเนินการส่วนที่เหลือ
รูปแบบที่ซ้ำกัน
หากตัดรายละเอียดปลีกย่อยออกไป เหตุการณ์ไวรัส npm ทุกครั้งจะดำเนินไปตามขั้นตอนพื้นฐานสี่ประการเหมือนกัน:
- บัญชีถูกแฮ็ก โทเค็นการเผยแพร่ของผู้ดูแลระบบ npm loginหรือข้อมูลประจำตัว CI ถูกขโมย ซึ่งมักเกิดขึ้นจากการฟิชชิ่ง การรั่วไหลของข้อมูลลับ หรือการบุกรุกของส่วนประกอบที่อยู่สูงขึ้นไปในห่วงโซ่ของพวกเขาเอง
- การฉีดแบบเงียบ ผู้โจมตีจะแทรกโค้ดที่เป็นอันตรายเข้าไปในเวอร์ชันใหม่ของแพ็กเกจที่ถูกต้องและน่าเชื่อถือ โดยมักจะซ่อนไว้ในสคริปต์หลังการติดตั้งหรือสคริปต์วงจรชีวิตอื่นๆ ที่ทำงานโดยอัตโนมัติทันทีที่ผู้ใช้ติดตั้งแพ็กเกจนั้น
- การแพร่กระจายอัตโนมัติ หากผู้ดูแลระบบที่ถูกบุกรุกควบคุมแพ็กเกจอื่น ๆ หรือหากสคริปต์ที่เป็นอันตรายเก็บรวบรวมข้อมูลประจำตัวเพิ่มเติมได้ เวิร์มก็จะแพร่กระจายไปยังแพ็กเกจถัดไปและผู้ดูแลระบบรายถัดไปโดยไม่ต้องมีการดำเนินการใด ๆ เพิ่มเติมจากผู้โจมตี
- ความล่าช้าในการตรวจจับ แพ็กเกจดังกล่าวจะยังคงอยู่ในรีจิสทรี สามารถติดตั้งได้โดยใครก็ได้ จนกว่าจะมีคนสังเกตเห็น รายงาน และมันถูกลบออกไป ช่วงเวลาล่าช้านั้น ซึ่งอาจใช้เวลาหลายชั่วโมงในบางกรณี หรือหลายวันในบางกรณี คือช่วงเวลาทั้งหมดที่เวิร์มต้องการ
การตระหนักว่าจังหวะที่สี่นั้นคือสิ่งที่สำคัญอย่างแท้จริงสำหรับการป้องกัน กลยุทธ์การบรรเทาผลกระทบทุกอย่างสำหรับเหตุการณ์เวิร์ม npm นั้น โดยพื้นฐานแล้วคือความพยายามที่จะลดหรือหลีกเลี่ยงความล่าช้าในการตรวจจับนั้น
กรอบแนวคิดที่ควรค่าแก่การอ้างอิง: คำตอบของ SIP สำหรับปัญหาการลดระยะเวลาการรอคอย
ไม่ใช่ทุกการตอบสนองต่อรูปแบบนี้จะมาจากผู้ขาย หนึ่งในคำตอบที่ชัดเจนที่สุดคือ SIP หรือแผนรักษาความปลอดภัยฉุกเฉินของโมฮัมหมัด-อาลี อาราบีกรอบการควบคุมฉุกเฉินห้าประการสำหรับความเสี่ยงในห่วงโซ่อุปทานซอฟต์แวร์ ซึ่งเกิดขึ้นจากคำถามเชิงปฏิบัติที่ถามขึ้นในตอนท้ายของการประชุม SafeDev ว่า “ถ้าเราทำได้เพียงไม่กี่อย่าง เราควรทำอะไรก่อนเป็นอันดับแรก”
มาตรการควบคุมข้อที่สองของ SIP มุ่งเป้าไปที่ปัญหาเวิร์ม npm โดยตรง นั่นคือ การระงับการใช้งาน dependency ที่ไม่ได้รับการตรวจสอบ โดยมีระยะเวลาคูลดาวน์ห้าวัน และปิดใช้งานสคริปต์วงจรชีวิต เพื่อป้องกันไม่ให้ postinstall ที่เป็นอันตรายทำงานโดยอัตโนมัติระหว่างการติดตั้ง ในทางปฏิบัติแล้ว นั่นคือ min-release-age=5 และ ignore-scripts=true ในโครงการหนึ่ง .npmrcมีการบังคับใช้ใน CI เพื่อป้องกันไม่ให้ไฟล์ล็อกแก้ไขแพ็กเกจที่เผยแพร่เมื่อวานนี้โดยไม่ได้รับอนุญาต นี่เป็นการควบคุมที่ได้ผลดีและใช้ความพยายามน้อย และมุ่งเป้าไปที่ความล่าช้าในการตรวจจับซึ่งเป็นสาเหตุของปัญหาไวรัส npm ทุกครั้ง ลองศึกษาดู:
จุดที่ช่วงเวลาคูลดาวน์ยังคงมีช่องโหว่
ระยะเวลาการรอคอยเป็นเหมือนการเดิมพันว่าชุมชนจะสังเกตเห็นและรายงานแพ็กเกจที่เป็นอันตรายก่อนที่ระยะเวลาการรอคอยจะสิ้นสุดลง ส่วนใหญ่แล้ว การเดิมพันนี้ได้ผล แพ็กเกจที่ถูกบุกรุกจำนวนมากจะถูกตรวจพบภายในไม่กี่วันแรกหลังจากเผยแพร่ ซึ่งเป็นเหตุผลว่าทำไมระยะเวลาห้าวันจึงเป็นค่าเริ่มต้นที่เหมาะสม
But an npm worm doesn’t behave like a typical malicious package, and that changes what a fixed cooldown can and can’t do for you.
To be precise about speed: a fast-propagating worm doesn’t actually defeat the cooldown itself. If you enforce a strict minimum release age, packages published during that initial wave are still too new to enter a build, no matter how many packages the worm compromises in the meantime. Speed matters, but it matters for everyone downstream who isn’t running a cooldown, not for beating one that’s already enforced.
The real limitation is patience. A more careful payload can sit dormant past the cooldown period, activating only once the days have cleared and the package has aged into the “trusted” zone, precisely because it knows a cooldown is watching. That’s the scenario where a fixed cooldown alone isn’t enough, and exactly where something like MEW’s evidence-based detection needs to sit alongside it, not instead of it.
ความล้มเหลวทั้งสองแบบนั้นไม่ใช่ข้อบกพร่องในแนวคิดของ SIP การชะลอการทำงานเป็นการพึ่งพาการตรวจจับจากชุมชน และการตรวจจับจากชุมชนก็มีขีดจำกัด คือไม่สามารถตรวจจับสิ่งที่ยังไม่มีใครรายงานได้ นี่ไม่ใช่ข้อบกพร่องเฉพาะของ SIP แต่เป็นข้อจำกัดเชิงโครงสร้างของระบบป้องกันใดๆ ที่รอให้มีลายเซ็น คำแนะนำ หรือรายงานสาธารณะก่อนจึงจะดำเนินการ
MEW ช่วยลดช่องว่างระหว่างช่วงเวลาคูลดาวน์ได้อย่างไร
นี่คือก่อนcisช่องว่าง ระบบเตือนภัยมัลแวร์ล่วงหน้าของ Xygeni (MEW) MEW ถูกสร้างขึ้นเพื่อปิดช่องโหว่ แทนที่จะรอรายงานจากชุมชนหรือลายเซ็นที่เผยแพร่ MEW จะสแกน NPM, PyPI และ Maven อย่างต่อเนื่องเมื่อมีการเผยแพร่แพ็กเกจและเวอร์ชันใหม่ โดยวิเคราะห์พฤติกรรมแทนที่จะเปรียบเทียบกับภัยคุกคามที่รู้จัก เมื่อมีสิ่งใดที่ดูเหมือนเป็นอันตราย มันจะถูกกักกัน และการค้นพบจะได้รับการยืนยันโดยนักวิจัยด้านความปลอดภัยก่อนที่จะเปิดเผยต่อสาธารณะ ไม่ใช่หลังจากนั้น
ความแตกต่างนี้มีความสำคัญสำหรับโหมดความล้มเหลวของเวิร์ม npm ทั้งสองแบบข้างต้น สำหรับเวิร์มที่แพร่กระจายอย่างรวดเร็ว การตรวจจับก่อนการลงลายเซ็นไม่จำเป็นต้องใช้เวลาห้าวันตามที่ระบบกำหนดระยะเวลาคูลดาวน์ไว้ สำหรับเพย์โหลดที่อยู่นิ่งเฉย การวิเคราะห์พฤติกรรมของ MEW ไม่ได้มองหาอายุหรือชื่อเสียง แต่จะมองหาสิ่งที่โค้ดทำจริง ๆ ดังนั้นการรอให้ครบระยะเวลาคูลดาวน์จึงไม่มีประโยชน์อะไรสำหรับผู้โจมตี
Dependency Firewall ของ MEW ขยายขีดความสามารถนี้ไปจนถึงขั้นตอนการติดตั้ง โดยจะบล็อกแพ็กเกจที่เป็นอันตรายแบบเรียลไทม์ แม้ว่าจะหลุดรอดการตรวจสอบในรอบแรกไปได้ก็ตาม และเลเยอร์การตรวจจับเดียวกันนี้ยังครอบคลุมถึง... CI/CD ด้านหนึ่งของเหตุการณ์ไวรัส npm: รูปแบบ unlock-branch, inject, re-lock ที่ทำให้ผู้โจมตีสามารถผลักดันมัลแวร์เข้าไปได้ commit และปกปิดร่องรอยอย่างเงียบๆ โดยมีหลักฐานการตรวจสอบอย่างครบถ้วนหากเหตุการณ์นั้นเกิดขึ้นจริง
SIP และ MEW กำลังตอบคำถามเดียวกัน แต่ในระดับที่แตกต่างกัน
ทั้งหมดนี้ไม่ได้ทำให้การควบคุมคูลดาวน์ของ SIP ผิด และควรกล่าวอย่างตรงไปตรงมาว่า คูลดาวน์ห้าวันโดยปิดใช้งานสคริปต์วงจรชีวิตยังคงเป็นหนึ่งในวิธีการป้องกันที่เร็วและถูกที่สุดที่ทีมสามารถนำมาใช้เพื่อรับมือกับเหตุการณ์เวิร์ม npm ทั่วไป และควรอยู่ในแผนการเสริมความแข็งแกร่งของห่วงโซ่อุปทานที่จริงจังใดๆ สิ่งที่ไม่สามารถทำได้ตามที่ออกแบบไว้คือ การตรวจจับสิ่งที่ชุมชนยังไม่พบ นั่นเป็นหน้าที่ของการตรวจจับแบบต่อเนื่องตามพฤติกรรมที่ทำงานอยู่เบื้องหลังคูลดาวน์ ไม่ใช่แทนที่คูลดาวน์
เมื่อนำทั้งสองวิธีมาผสานรวมกัน จะช่วยแก้ปัญหาเดียวกันได้ทั้งสองด้าน กล่าวคือ SIP ช่วยเสริมความแข็งแกร่งให้กับโครงสร้าง pipelineในขณะที่การตรวจจับล่วงหน้าของ MEW ครอบคลุมเหตุการณ์เวิร์ม npm ที่ยังไม่ได้รับการเปิดเผย ซึ่งเป็นเหตุการณ์ที่กรอบเวลาคูลดาวน์ไม่สามารถตรวจจับได้ตามตรรกะของมันเอง
คำถามที่พบบ่อย
ในประโยคเดียว npm worm คืออะไร?
โค้ดที่เป็นอันตรายซึ่งเผยแพร่ไปยัง npm จะแพร่กระจายไปยังแพ็กเกจอื่น ๆ โดยอัตโนมัติ โดยทั่วไปแล้วจะขโมยข้อมูลประจำตัวของผู้ดูแลระบบและใช้ข้อมูลเหล่านั้นเพื่อแทรกโค้ดที่เป็นอันตรายเดียวกันไปยังที่อื่นโดยไม่ต้องมีการดำเนินการใด ๆ เพิ่มเติมจากผู้โจมตี
แพ็กเกจ npm ที่เป็นอันตรายทุกตัวเป็นเวิร์ม npm หรือไม่?
ไม่ใช่ แพ็กเกจที่เป็นอันตรายที่ไม่แพร่กระจายเองนั้นถือเป็นการโจมตีห่วงโซ่อุปทาน แต่ไม่ใช่เวิร์ม สิ่งที่กำหนดลักษณะของเหตุการณ์เวิร์ม npm โดยเฉพาะคือขั้นตอนการแพร่กระจายด้วยตนเอง: การโจมตีครั้งหนึ่งจะนำไปสู่การโจมตีครั้งต่อไปโดยอัตโนมัติ
การกำหนดช่วงเวลาพักการพึ่งพา (dependency cooldown period) สามารถหยุดยั้งไวรัส npm ได้หรือไม่?
มันช่วยลดความเสี่ยงได้อย่างมาก เพราะแพ็กเกจที่เป็นอันตรายส่วนใหญ่จะถูกรายงานภายในไม่กี่วันแรกหลังจากเผยแพร่ แต่การกำหนดช่วงเวลาพักนั้นเป็นการเสี่ยงดวงกับความเร็วในการตรวจจับของชุมชน และเวิร์ม npm ที่แพร่กระจายอย่างรวดเร็วหรือจงใจทำให้ไม่ทำงานสามารถถูกสร้างขึ้นมาโดยเฉพาะเพื่อหลีกเลี่ยงช่วงเวลานั้นได้
อะไรคือสิ่งที่สามารถดักจับไวรัส npm ได้ก่อนช่วงเวลาคูลดาวน์?
การสแกนอย่างต่อเนื่องโดยอิงตามพฤติกรรม ซึ่งไม่ขึ้นอยู่กับลายเซ็นหรือรายงานสาธารณะที่มีอยู่แล้ว นั่นคือช่องว่างเฉพาะที่เครื่องมือตรวจจับก่อนลายเซ็น เช่น MEW ของ Xygeni ถูกสร้างขึ้นมาเพื่อปิด
