ช่องโหว่ SlugFest: แค่จดชื่อ repo เก่า ก็ปล่อยอัปเดตแทนแพ็กเกจ npm กว่า 1,500 ตัวได้

แพ็กเกจ npm กว่า 1,500 ตัว เปิดช่องให้คนแปลกหน้าปล่อยอัปเดตแทนเจ้าของได้ แปลว่าไม่ต้องขโมยรหัสผ่านครับ (Help Net Security) วันที่ 13 ตุลาคม 2026 Bloom Security เปิดชื่อ SlugFest (Help Net Security)

Trusted Publishing คือวิธีปล่อยแพ็กเกจแบบไม่เก็บรหัสยาว และช่องนี้อยู่ที่การจำชื่อคลังบน GitHub แทนเลขถาวร (Help Net Security) npm คือที่แจกชิ้นส่วนของภาษา JavaScript ส่วนแพ็กเกจคือชิ้นส่วนที่ใช้ประกอบเว็บหรือแอป

กลุ่มนี้มียอดดาวน์โหลดรวมมากกว่า 10 ล้านครั้ง แปลว่าถูกใช้ในงานจริง (Help Net Security) ยอดรายเดือนรวมมากกว่า 1 ล้านครั้ง แปลว่าแต่ละเดือนมีรอบติดตั้งจำนวนมาก (CSO Online)

GitHub ซึ่งเป็นเจ้าของ npm บอกว่าส่งตัวแก้แล้ว (Help Net Security) ประกาศนั้นลงวันที่ 2 ตุลาคม 2026 (GitHub Blog) ผมยังไม่ได้ลองเอง และ Bloom ไม่เปิดรายชื่อ (Help Net Security) ระบบที่ควรปิดทางขโมยรหัส กลับให้คนไม่มีรหัสเจ้าของปล่อยของได้ยังไง?

สรุป 30 วินาที: เกิดอะไรขึ้น

Trusted Publishing เปิดใช้ทั่วไปตั้งแต่กรกฎาคม 2025 และช่องนี้อยู่ที่การจำชื่อคลังแทนเลขถาวร (Help Net Security)

เส้นเวลาเป็นวัน ไม่มีนาฬิกาให้แปลงเป็นเวลาไทยครับ

• 6 มิถุนายน 2026 Bloom แจ้งผ่าน HackerOne (HackerNoon)
• 9 มิถุนายน 2026 GitHub ตรวจรับรายงาน (Help Net Security)
• 8 กรกฎาคม 2026 เป็นคำตอบล่าสุดตามที่ Bloom บอก ก่อนทวงอีกหกครั้งแล้วเงียบ (Help Net Security)
• 2 ตุลาคม 2026 มีประกาศตัวแก้ (GitHub Blog)
• 13 ตุลาคม 2026 ข่าวถึงสาธารณะ (Help Net Security)

การตั้งค่าที่ยังไม่ยืนยันหมดอายุใน 48 ชั่วโมง แปลว่ามีเวลาประมาณสองวัน (GitHub Blog) npm ปฏิเสธโทเคนที่เกิดจากการคอมเมนต์ใต้ประเด็น เรียกว่า issue_comment และมีข้อจำกัดเดิมของ pull_request_target ซึ่งเป็นการรันงานจากคำขอแก้โค้ดของคนนอก (GitHub Blog)

Bloom ปล่อยเวอร์ชันได้บนของที่ควบคุมเอง (CSO Online) นอกแล็บยังไม่มีคำตอบ (Help Net Security) กลุ่มที่ว่าคือแพ็กเกจที่ตั้งฟีเจอร์นี้แล้วเข้าข่าย ไม่ใช่ทั้งคลัง npm (HackerNoon)

ทำไมเรื่องนี้เกี่ยวกับคุณ

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

เรื่องมาถึงคุณทางเครื่องคนทำระบบ และเครื่อง CI ที่ติดตั้งแล้วทดสอบโค้ดให้ เวอร์ชันไม่ดีพก postinstall ได้ คือคำสั่งที่ npm รันเองทุกครั้งที่ติดตั้งอัปเดต (Help Net Security) แปลว่าโค้ดของคนปล่อยเวอร์ชันมีทางเริ่มบนเครื่องนั้น โดยคุณไม่ได้กดเอง

เครื่องคนทำเว็บมักวางคีย์ฐานข้อมูลหรืออีเมล ถ้าโค้ดตอนติดตั้งอ่านคีย์ บริการที่คุณใช้ถึงจะเดือดร้อนได้ CSO เขียนว่ามีทางรันโค้ดผู้โจมตีผ่านฮุคติดตั้ง (CSO Online) ยังไม่มีแหล่งรอบนี้ยืนยันว่า SlugFest ทำให้รั่วจริง

ในชุดที่ Bloom พบ มีเครื่องมือสแกนช่องโหว่ เครื่องมือตรวจตัวตน และชิ้นส่วนเข้ารหัสอยู่ด้วย (CSO Online) ไม่มีชื่อให้เปิดดู Bloom ชี้ว่าเอเจนต์ AI หรือตัวช่วยเขียนโค้ด ติดตั้งแพ็กเกจเองโดยคนไม่ได้นั่งตรวจ (Help Net Security) Myers บอก Help Net Security ความหมายประมาณว่าเอเจนต์เปลี่ยนเกม เพราะผู้ใช้ไม่เหลือแค่นักพัฒนา คำแปลเป็นของผม (Help Net Security)

ก่อนหน้านี้มีเคส GHAPPIER ที่ยึด trusted publishing อีกแบบ คนละเรื่อง อย่าปนตัวเลข ในแหล่งรอบนี้ไม่มีประกาศหน่วยงานไทย

ทำงานยังไง

ของเก่าคือโทเคนอยู่ได้นาน รหัสที่เก็บในระบบอัตโนมัติแล้วใช้ปล่อยซ้ำ ถ้าหลุดคนถือใช้ต่อจนเจ้าของหมุนรหัส (npm Docs) ของใหม่ใช้ OIDC คือบัตรที่ออกให้เฉพาะงาน งานบน GitHub ขอโทเคนลงลายมือชื่อ แล้วแลกเป็นสิทธิ์ที่หมดอายุภายในไม่กี่นาที (Help Net Security)

ตอนตั้งค่า เจ้าของบอกว่าคลังไหนและไฟล์ขั้นตอนชื่ออะไรปล่อยของนี้ได้ (Help Net Security) ชื่อรูป owner/repo คือ slug ที่คนอ่านออก GitHub มีเลขถาวรของคลังและเจ้าของ ซึ่งไม่เปลี่ยนตอนเปลี่ยนชื่อหรือโอน และใส่เลขนั้นในโทเคนแล้ว (Help Net Security) npm บันทึกด้วยชื่อ และไม่ได้เอาเลขมาตรวจ (Help Net Security)

บทความของ Bloom เองบน HackerNoon อยู่ใต้ Business Blogging จึงไม่ใช่ข่าวสืบสวนแยก บทความบอกว่าเลขถาวรถูกจำเมื่อปล่อยสำเร็จครั้งแรก ถ้ายังไม่เคยปล่อยและชื่อว่าง คนจองชื่อมีทางรับความเชื่อใจ (HackerNoon)

CISO HQ รายงานเงื่อนไขเดียวกัน (CISO HQ) ไม่ต้องมีรหัสของเจ้าของ (HackerNoon) Bloom ลองด้วยของตัวเอง แล้วปล่อยจากคลังของอีกองค์กร (Help Net Security) ผมไม่ลงขั้นตอนให้ทำตาม

เอกสาร npm บอกว่าไม่ตรวจตอนบันทึก ความผิดโผล่ตอนปล่อย (npm Docs) เปรียบร้านออนไลน์ที่จำลูกค้าจากป้ายร้าน ไม่จำเลขผู้เสียภาษีครับ พอร้านเดิมเปลี่ยนชื่อ ใครจดป้ายเก่าก็รับของแทนได้ ทั้งที่เลขคนละชุด ป้ายกับเลขภาษีไม่ใช่สิ่งเดียวกัน แต่สมุดนี้จำแค่ป้าย

Bloom ไม่ได้บอกว่าบัตรอายุสั้นพังทั้งความคิด จุดอ่อนอยู่ที่การจำตัวคลังตอนแรก (HackerNoon) CISO HQ อ้าง Bloom ว่า Warehouse ของ PyPI ซึ่งเป็นคลังภาษา Python ผูกเลขถาวรอยู่แล้ว (CISO HQ) ในเจ็ดแหล่งรอบนี้ไม่มีเลข CVE

จุดหักมุม: ใบรับรองถูกต้อง แต่คนถือป้ายไม่ใช่ร้านเดิม

ฟังดูเหมือนของทางนี้จะไม่มีลายเซ็นครับ แต่ปล่อยไม่ได้แบบนั้น

เอกสาร npm บอกว่าการปล่อยผ่าน GitHub Actions หรือ GitLab ได้ใบรับรองแหล่งที่มาอัตโนมัติ (npm Docs) Bloom พบว่าเวอร์ชันทดสอบยังถือใบที่ถูกต้อง และใบชี้คลังของคนจองชื่อ (Help Net Security) เครื่องที่เช็กแค่มีลายเซ็นจะเห็นว่าผ่าน CISO HQ แยกไว้ว่ามีใบไม่เท่ากับมาจากคลังที่ถูกคน (CISO HQ)

GitHub ดึงชื่อกลับบางกรณี คือคลังที่ถูกโคลนมากกว่า 100 ครั้งในสัปดาห์ก่อนบัญชีเจ้าของเปลี่ยนชื่อหรือถูกลบ (Help Net Security) แปลว่ากันได้บางคลัง ไม่ใช่ทุกการเปลี่ยนชื่อคลัง Myers บอกว่านับเฉพาะชื่อที่ยังจองได้ (Help Net Security)

แต่การทดสอบไม่ได้อยู่บนกระดาษ (CSO Online) ตัวแก้ก็ไม่ได้ปิดแถวเก่าทุกแถว CSO เขียนว่ามันจัดการแถวที่ยังไม่ยืนยัน ส่วนผู้ดูแลยังต้องทบทวนของเดิม (CSO Online)

เรื่องเงิน / ผลกระทบ

ไม่มีราคาบาทหรือดอลลาร์ และไม่มีเงินรางวัลในแหล่งที่อ่านครับ ยังไม่มีราคาไทยอย่างเป็นทางการ เพราะไม่มีราคาให้ประกาศ อย่าแปลงยอดดาวน์โหลดเป็นบาท

Help Net Security คำนวณเฉลี่ยหลายร้อยดาวน์โหลดต่อเดือนต่อแพ็กเกจ (Help Net Security) แปลว่าหลายตัวไม่ได้ดังทั้งวงการ แต่ตัวเดียวที่ถูกสลับก็พอ เพราะ postinstall รันทุกเครื่องที่ติดตั้ง

CSO อ้าง Bloom ว่ามีตัวหนึ่งมากกว่า 200,000 ครั้งต่อเดือน (CSO Online) แปลว่าความเสี่ยงไม่เท่ากันทุกตัว เลขนี้แหล่งเดียวและไม่มีชื่อแพ็กเกจ ต้นทุนเลยเป็นเวลาตามเครื่องกับคีย์ ไม่ใช่ค่าไลเซนส์

ตัวเลขเอเจนต์เป็น telemetry ของ Bloom ไม่ใช่สำมะโนคนนอก เครื่องทั่วไปโดนติดตั้งตรงราว 70 แพ็กเกจต่อเดือน (Help Net Security) แปลว่าของเข้าตลอดเดือน และไม่นับแพ็กเกจลูก ชุดนี้มาจากองค์กรหลายสิบแห่งในข้อมูลสำนักข่าวเดียวกัน (Help Net Security)

เครื่องนักพัฒนาเข้าใกล้ 350 แพ็กเกจต่อเดือน (Help Net Security) แปลว่าถี่กว่าเครื่องทั่วไปในชุดเดียวกัน Myers บอกว่าของที่ถูกยึดแค่ต้องเป็นตัวที่เอเจนต์เลือก (CSO Online) ไม่มีแหล่งให้ยอดชั้นลูก

ข้อมูลที่ยังไม่ชัด และจุดที่แหล่งข่าวพูดไม่ตรงกัน

ช่วงเงียบไม่ตรงกันครับ Bloom ผ่าน Help Net Security บอกว่าคำตอบล่าสุดคือ 8 กรกฎาคม 2026 แล้วทวงหกครั้ง รวมขอให้ HackerOne ไกล่เกลี่ย โดยไม่มีตอบ (Help Net Security) โฆษก GitHub บอกสำนักเดียวกันว่าตรวจรายงานแล้วส่งตัวแก้ ไม่มีคำขอโทษในถ้อยแถลงนั้น (Help Net Security)

บทความ Bloom บอกว่าทดสอบซ้ำแล้วพบตัวแก้ และ npm ขอโทษที่สื่อสารช้า (HackerNoon) CISO HQ เติมว่าคำตอบวันนั้นกำลังแก้และประเมินความเสี่ยง (CISO HQ) Myers บอก CSO ว่าตัวแก้ส่งวันที่ 2 ตุลาคม 2026 (CSO Online) ข้อขัดคือใครเล่าช่วงเงียบ ไม่ใช่ว่ามีตัวแก้หรือไม่

การใช้จริงไม่นิ่ง Myers บอก Help Net Security ว่ายังไม่ทราบว่ามีคนใช้นอกแล็บ (Help Net Security) เขาบอก CSO ว่ายังไม่พบ แต่ทดสอบตัวเองทำได้ (CSO Online) บทความ Bloom ว่าเคยบล็อกเอเจนต์ลูกค้าที่ติดตั้งแพ็กเกจซึ่งเข้าข่าย (HackerNoon) เป็นคำกล่าวของ Bloom ไม่มีชื่อลูกค้า และไม่ได้แปลว่าของนั้นเป็นโค้ดร้าย

การผูกย้อนหลังโล่ง Help Net Security เขียนว่า GitHub ไม่ได้บอกว่าแถวเก่าถูกผูกเลขย้อนหลังหรือไม่ (Help Net Security) ThreatTicker สรุปข่าวชิ้นนั้น โดยไม่ได้ไปนับใหม่ แล้วย้ำว่าจุดนี้ไม่ชัด (ThreatTicker) เอกสาร npm ว่าของใหม่ต้องปล่อยสำเร็จภายในสองวันจึงผูกตัวตนถาวร (npm Docs) ประกาศ GitHub ใช้หน้าต่าง 48 ชั่วโมง เปลี่ยนตัวตนคลังต้องเริ่มใหม่ และการแก้ไฟล์ธรรมดาไม่รีเซ็ตนาฬิกา (GitHub Blog)

ไม่มีรายชื่อให้เทียบ (Help Net Security) CISO HQ ว่าตอนวิจัยยังพบบ่อยจึงไม่ปล่อยชื่อ (CISO HQ) Bloom ว่าช่องยังใช้ได้มากกว่า 120 วันหลังแจ้ง (HackerNoon) แปลว่านานหลายเดือน ไม่มีชั่วโมงที่ระบบปิด ผมไม่บวกลบวันเอง

ฝั่ง GitLab Bloom ว่ามีจุดอ่อนแบบเดียวกัน (Help Net Security) แต่ประกาศตัวแก้ไม่ได้เอ่ย GitLab (GitHub Blog) ยังไม่มีผลทดสอบซ้ำหลังประกาศ

ขนาดความเสี่ยงคนละไม้ครับ Help Net Security เตือนว่าตัวเดียวก็พอ (Help Net Security) CSO ยกแพ็กเกจที่ Bloom บอกว่ายอดสูงเด่น (CSO Online) โฆษก GitHub เน้นว่ากฎ 48 ชั่วโมงจำกัดความเสี่ยง แปลว่าเหลือกรอบประมาณสองวัน (Help Net Security) ในแหล่งรอบนี้ไม่มีรายงานความเสียหายเป็นเงินมาตัดสิน

คำเรียกกลุ่มไม่ตรงกัน CSO ใช้ potentially vulnerable (CSO Online) Help Net Security ใช้ exposed (Help Net Security) Bloom ใช้ vulnerable (HackerNoon)

สำนักข่าวบอกว่าชุดเอเจนต์มาจากองค์กรหลายสิบแห่ง (Help Net Security) แปลว่าไม่ใช่ทั้งวงการ บทความ Bloom บอกว่าเป็นเอเจนต์นับล้าน (HackerNoon) แปลว่าคนละสเกลกับชุดที่สำนักข่าวเล่า

ถ้าไม่มีรายชื่อ และยังไม่รู้ว่าของเก่าถูกผูกย้อนหลังหรือไม่ ทีมควรเริ่มจากแพ็กเกจตัวไหนก่อน?

แล้วเราควรทำอะไร

ยังไม่ต้องปิดเว็บทั้งร้านครับ ยังไม่มีรายชื่อ และยังไม่มีรายงานการใช้จริง

คนทั่วไปและเจ้าของธุรกิจที่จ้างทำเว็บหรือแอป

ทำตามได้เลย

1. ให้คนทำเว็บบอกว่าล็อกเวอร์ชันในไฟล์ล็อก หรือดึงของใหม่ทุกครั้ง ตามคำเตือนของ ThreatTicker เรื่องแพ็กเกจที่เงียบมานาน (ThreatTicker)
2. ให้บอกสถานะเอเจนต์ที่ติดตั้งแพ็กเกจเอง และคนที่ตรวจรายการเดือนนี้ CSO แนะนำให้กำหนดกรอบว่าติดตั้งอะไรได้ (CSO Online)
3. ถ้าเขาปล่อยแพ็กเกจเอง ให้บอกว่าไล่ trusted publisher หลังเปลี่ยนชื่อคลังแล้ว อย่ารอรายชื่อ Bloom (Help Net Security)

ทีมที่ใช้แพ็กเกจและทีม IT

ทำตามได้เลย

1. ถ้ามีใบรับรอง ให้อ่านชื่อคลังบนใบ อย่าหยุดแค่มีลายเซ็น (Help Net Security) การมีใบกับมาจากคลังที่ถูกคนเป็นคนละงาน (CISO HQ)
2. คลังส่วนตัวและ CircleCI ไม่ได้ใบนี้ และปิด provenance ได้ (npm Docs) การไม่มีใบจึงไม่เท่ากับถูกแฮก
3. ล็อกเวอร์ชันของแพ็กเกจที่เงียบมานาน (ThreatTicker) แล้วไล่ของที่เอเจนต์ติดตั้ง รวมส่วนขยายนอกไฟล์หลัก (HackerNoon)

นักพัฒนาที่ดูแลแพ็กเกจ

ทำตามได้เลย

1. รัน npm trust list แล้วเช็กว่าทุกคลังยังเป็นของคุณ ผมยังไม่ได้รันบนของคนอื่น (Help Net Security)
2. คลังที่เปลี่ยนชื่อหรือถูกโอน ให้ลบแล้วสร้างใหม่ เพราะแก้ของเดิมตรงๆ ไม่ได้ (npm Docs) และถอดการผูกก่อนลบคลัง (Help Net Security)
3. ย้ายออกจาก issue_comment ไปการส่งโค้ด (push) การออกเวอร์ชัน (release) หรือการกดรันเอง (workflow_dispatch) (GitHub Blog)
4. ปล่อยสำเร็จครั้งแรกภายใน 48 ชั่วโมง ไม่งั้นหมดอายุ (GitHub Blog) ของหมดอายุไม่นับเพดาน และมีได้สูงสุด 10 รายการต่อแพ็กเกจ (npm Docs)
5. ถ้าต้องการให้ของยังไม่สาธารณะจนกว่าเจ้าของจะกดยืนยัน ให้ใช้ stage พร้อม 2FA คือรหัสชั้นที่สอง ตามเอกสาร npm (npm Docs) เป็นท่าทั่วไป ไม่ใช่ตัวปิดช่องชื่อ

ผมมองว่า…

ผมมองว่าเรื่องนี้ไม่ใช่แค่บั๊กของชื่อ repo แต่คือระบบที่ยังเชื่อป้ายซึ่งคนอื่นรับช่วงได้ ในวันที่เครื่องช่วยติดตั้งของให้เอง เลขถาวรมีในโทเคนที่ GitHub ส่งมาแล้ว (Help Net Security) ช่องนี้เลยไม่ใช่การไม่มีเครื่องมือ มันคือการไม่ได้ใช้เลขนั้นตอนตัดสิน

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

ปิดท้าย: สิ่งที่ต้องจับตา

ป้ายที่อ่านออกไม่เคยเท่ากับตัวคนที่ถือป้าย และใบที่เซ็นถูกก็ยังอาจชี้คนที่เพิ่งมารับป้าย

จับตาว่าแถวที่ปล่อยสำเร็จก่อนวันที่ 2 ตุลาคม 2026 ถูกผูกเลขย้อนหลังหรือไม่ ยังไม่มีวันนัด (Help Net Security) อีกจุดคือรายชื่อที่ Bloom ยังไม่เปิด และสถานะ GitLab ที่ประกาศวันเดียวกันไม่ได้เขียนตรงๆ (GitHub Blog)

ในงานที่คุณรับผิดชอบ มีคนตอบได้ไหมว่าอัปเดตครั้งล่าสุดมาจากคลังที่ทีมตั้งใจไว้?

Recap

• เกิดอะไรขึ้น: 13 ตุลาคม 2026 Bloom เปิด SlugFest ว่า Trusted Publishing จำชื่อคลังแทนเลขถาวร คนจองชื่อเก่ามีทางปล่อยอัปเดตโดยไม่ขโมยรหัส GitHub ประกาศแก้ 2 ตุลาคม 2026
• ตัวเลขที่ต้องจำ: กว่า 1,500 แพ็กเกจ ยอดรวมมากกว่า 10 ล้านครั้ง รายเดือนรวมมากกว่า 1 ล้านครั้ง ไม่ใช่ทั้งคลัง การตั้งค่าที่ไม่ยืนยันหมดอายุใน 48 ชั่วโมง
• ใครเห็นต่าง: Bloom เล่าช่วงเงียบและการทวงหกครั้ง โฆษก GitHub เน้นว่าตรวจแล้วส่งตัวแก้ บทความ Bloom กับ CISO HQ ว่ามีคำขอโทษ แต่ถ้อยแถลงที่ Help Net Security ได้ยินไม่มี ขนาดความเสี่ยงถูกเล่าทั้งแบบค่าเฉลี่ยและแบบแพ็กเกจตัวดัง
• ยังไม่รู้อะไร: การใช้จริงนอกแล็บ การผูกย้อนหลัง รายชื่อ สถานะ GitLab ระบบไทยที่โดน และความเสียหายเป็นเงิน
• กระทบคุณยังไง: เว็บที่จ้างทำพึ่งชิ้นส่วน npm ได้ อัปเดตที่ถูกสลับมีทางรันโค้ดตอนติดตั้งบนเครื่องคนทำระบบ ยังไม่มีเคสยืนยันและไม่มีราคาบาท
• สิ่งที่ต้องจับตา: คำชี้แจงย้อนหลังหลัง 2 ตุลาคม 2026 รายชื่อที่ยังไม่เปิด และฝั่ง GitLab
• แหล่งอ้างอิง: [1] Help Net Security [2] CSO Online [3] GitHub Blog [4] npm Docs [5] HackerNoon บทความของ Bloom [6] ThreatTicker [7] CISO HQ