DEV Community

Cover image for axios 1.14.1 โดนโจมตี: วิธีรับมือและป้องกัน
Thanawat Wongchai
Thanawat Wongchai

Posted on • Originally published at apidog.com

axios 1.14.1 โดนโจมตี: วิธีรับมือและป้องกัน

#javascript #news #npm #security

สรุปโดยย่อ

ในวันที่ 30–31 มีนาคม 2026, axios เวอร์ชัน 1.14.1 และ 0.30.4 ถูกโจมตีบน npm ด้วยแพ็คเกจที่พึ่งพาซึ่งเป็นอันตราย และแพ็คเกจนั้นได้ติดตั้งโทรจันสำหรับเข้าถึงระยะไกล (RAT) บนเครื่องที่ติดเชื้อ ทั้งสองเวอร์ชันถูกถอนการเผยแพร่แล้ว เวอร์ชันที่ปลอดภัยคือ 1.14.0 หากคุณติดตั้ง axios@1.14.1 หรือ 0.30.4 ให้ถือว่าเครื่องของคุณถูกบุกรุกและเปลี่ยนข้อมูลประจำตัวทั้งหมดทันที

ลองใช้ Apidog วันนี้

axios คืออะไร และทำไมเรื่องนี้ถึงสำคัญ

axios มีการดาวน์โหลด 100 ล้านครั้งต่อสัปดาห์บน npm เป็น HTTP client ที่ใช้ในเฟรมเวิร์กส่วนหน้าจำนวนนับไม่ถ้วน, บริการ Node.js ส่วนหลังบ้าน, และแอปพลิเคชันระดับองค์กร เมื่อแพ็คเกจที่เป็นรากฐานสำคัญขนาดนี้ถูกบุกรุก ผลกระทบก็มหาศาล — นักพัฒนาที่รัน npm install ในช่วงเวลาสั้นๆ ระหว่างวันที่ 30-31 มีนาคม ได้ดึงมัลแวร์เข้าสู่เครื่องของตนโดยไม่รู้ตัว

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

หากทีมของคุณใช้ axios และคุณใช้ Apidog เพื่อออกแบบและทดสอบการรวม HTTP client ของคุณ โปรดอ่านสิ่งนี้ก่อนการปรับใช้ครั้งถัดไป

ไทม์ไลน์ของการโจมตี

30 มีนาคม 2026 — 23:59:12 UTC: แพ็คเกจที่เป็นอันตรายชื่อ plain-crypto-js@4.2.1 ถูกเผยแพร่ไปยัง npm โดยบัญชีที่ใช้ nrwise@proton.me เวอร์ชันก่อนหน้า (4.2.0) ที่สะอาด ถูกเผยแพร่ไปเมื่อ 18 ชั่วโมงก่อนหน้านั้น โดยเป็นการสร้างชื่อที่คล้ายคลึงกับไลบรารี crypto-js ที่ถูกต้องเพื่อหลอกลวง (typosquat)

31 มีนาคม 2026 — 00:05:41 UTC: ระบบตรวจจับมัลแวร์อัตโนมัติของ Socket ได้ตั้งค่าสถานะ plain-crypto-js@4.2.1 ว่าเป็นอันตราย — เพียงหกนาทีหลังจากที่มันถูกเผยแพร่

31 มีนาคม 2026 — หลังเที่ยงคืนไม่นาน: axios@1.14.1 ถูกเผยแพร่ไปยัง npm โดยดึง plain-crypto-js@4.2.1 เป็นแพ็คเกจที่พึ่งพา การเผยแพร่ครั้งนี้ไม่ปรากฏในแท็กอย่างเป็นทางการของ GitHub repository ของ axios แท็กที่ถูกต้องล่าสุดยังคงเป็น v1.14.0

31 มีนาคม 2026 — เช้า: ปัญหา GitHub หมายเลข #10604 ถูกเปิดเผยต่อสาธารณะ โดยรายงานว่า axios@1.14.1 และ axios@0.30.4 ถูกบุกรุก ผู้ดูแล axios ยืนยันว่าในเบื้องต้นไม่สามารถเพิกถอนการเข้าถึงของผู้โจมตีได้ — บัญชีที่ถูกบุกรุกมีสิทธิ์ npm สูงกว่าผู้ดูแลที่ถูกต้องตามกฎหมาย

31 มีนาคม 2026: ทั้ง axios@1.14.1 และ axios@0.30.4 ถูกถอนการเผยแพร่จาก npm ผู้ดูแล axios เริ่มเพิกถอนโทเค็น, เพิ่มความเข้มงวดในการควบคุมการเผยแพร่, และกำลังตรวจสอบว่าโทเค็น npm ที่มีอายุการใช้งานยาวนานถูกใช้ประโยชน์อย่างไรเพื่อเข้าถึงการเผยแพร่โดยไม่ได้รับอนุญาต

การโจมตีทำงานอย่างไร

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

เวอร์ชันใหม่ได้เพิ่ม plain-crypto-js@4.2.1 เป็นแพ็คเกจที่พึ่งพา ชื่อแพ็คเกจถูกออกแบบมาให้ดูเหมือนยูทิลิตีการเข้ารหัสที่ถูกต้องตามกฎหมาย; เวอร์ชัน 4.2.0 ที่สะอาดก่อนหน้านี้ถูกสร้างขึ้นเพื่อสร้างประวัติสั้นๆ เพื่อลดความสงสัย

ภายใน plain-crypto-js@4.2.1 การวิเคราะห์ของ Socket พบว่ามี เพย์โหลดแบบหลายขั้นตอน:

  1. ขั้นตอนที่ 1 — การดำเนินการ: แพ็คเกจจะรันโค้ดเมื่อทำการติดตั้ง (ผ่านสคริปต์ npm lifecycle) เพื่อปล่อยเพย์โหลดรอง
  2. ขั้นตอนที่ 2 — การติดตั้ง RAT: เพย์โหลดจะติดตั้งโทรจันสำหรับเข้าถึงระยะไกล (RAT) ที่เปิดแบ็คดอร์แบบถาวร
  3. ขั้นตอนที่ 3 — การดึงข้อมูลออก: RAT สามารถรันคำสั่งเชลล์ใดๆ ที่ส่งมาจากเซิร์ฟเวอร์ C2, อ่านตัวแปรสภาพแวดล้อมและความลับจากระบบไฟล์, และส่งข้อมูลระบบออกไปทางเครือข่าย

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

ฉันได้รับผลกระทบหรือไม่?

คุณอาจได้รับผลกระทบหาก:

  • คุณรัน npm install axios หรือ npm install (โดยมี axios อยู่ใน package.json) ระหว่างประมาณ 30 มีนาคม, 23:59 UTC ถึง 31 มีนาคม 2026 เที่ยง UTC
  • node_modules/axios/package.json ของคุณแสดงเวอร์ชัน 1.14.1 หรือ 0.30.4
  • package-lock.json หรือ yarn.lock ของคุณระบุ axios เป็น 1.14.1 หรือ 0.30.4

ตรวจสอบทันที:

# ตรวจสอบเวอร์ชันที่ติดตั้ง
npm list axios

# ตรวจสอบใน lock file
grep '"axios"' package-lock.json | head -5

# ตรวจสอบการมีอยู่ของ plain-crypto-js
npm list plain-crypto-js
ls node_modules/plain-crypto-js 2>/dev/null && echo "INFECTED" || echo "Not found"
Enter fullscreen mode Exit fullscreen mode

หาก plain-crypto-js ปรากฏอยู่ใน node_modules ของคุณ แสดงว่าคุณได้รันเวอร์ชันที่เป็นอันตราย

สิ่งที่ต้องทำตอนนี้

1. อัปเดต axios ทันที 

npm install axios@1.14.0
# หรือ pin ไปที่เวอร์ชันล่าสุดที่ปลอดภัย
npm install axios@latest
Enter fullscreen mode Exit fullscreen mode

ตรวจสอบอีกครั้ง:

npm list axios
# ควรแสดง 1.14.0 หรือสูงกว่า (เมื่อมี clean 1.14.x ออก)
Enter fullscreen mode Exit fullscreen mode

2. หากคุณติดตั้งเวอร์ชันที่ถูกบุกรุก

อย่าถือว่านี่เป็นแค่การอัปเดตแพ็คเกจที่พึ่งพา ให้ถือว่าเครื่องของคุณถูกบุกรุก:

  • เปลี่ยนความลับทั้งหมด ที่สามารถเข้าถึงได้จากเครื่องนั้น เช่น API key, ข้อมูลประจำตัวฐานข้อมูล, คีย์ SSH, โทเค็นคลาวด์, ตัวแปร .env
  • ตรวจสอบตัวแปรสภาพแวดล้อม — RAT มุ่งเป้าความลับใน environment และไฟล์ระบบ
  • ตรวจสอบการเชื่อมต่อเครือข่ายขาออก ในช่วงเวลาที่ได้รับผลกระทบ — มองหา connection ไปยัง IP แปลกๆ
  • สแกนหาความคงทน — ตรวจสอบ cron jobs, สคริปต์ startup, และ systemd service ที่ถูกเพิ่มในช่วงเวลานั้น
  • ติดตั้งอิมเมจใหม่ให้กับเครื่อง สำหรับ CI runner หรือ production server หากเป็น laptop นักพัฒนา ให้เปลี่ยนข้อมูลประจำตัวทั้งหมดก่อนถือว่าเครื่องสะอาด

3. ตรวจสอบ CI/CD Pipelines ของคุณ

หาก pipeline ของคุณรัน npm install ในช่วงเวลาดังกล่าว CI environment ของคุณอาจถูกบุกรุก ตรวจสอบดังนี้:

# ตรวจสอบ build logs สำหรับช่วงเวลาที่มีปัญหา
# มองหา axios@1.14.1 ใน output การติดตั้ง

# ตรวจสอบว่า node_modules ใน CI ปัจจุบันสะอาด
npm list axios plain-crypto-js
Enter fullscreen mode Exit fullscreen mode

เปลี่ยนความลับที่ CI pipeline เข้าถึงได้ เช่น deployment keys, cloud provider credentials, registry tokens

4. ตรวจสอบไฟล์ lock ของคุณ

ไฟล์ lock (package-lock.json, yarn.lock) ควรระบุเวอร์ชันที่แน่นอน หาก lock file ของคุณมี 1.14.1 ให้สร้างใหม่:

# ลบและ regenerate
rm package-lock.json
npm install
Enter fullscreen mode Exit fullscreen mode

ตรวจสอบ lock file ใหม่ว่าระบุ axios เป็นเวอร์ชันที่ปลอดภัยก่อน commit

การใช้ Apidog เพื่อตรวจสอบการเรียก API ของ axios ของคุณ

หากคุณใช้ axios เป็น HTTP client สำหรับการเรียก API, Apidog สามารถช่วยคุณยืนยันว่าการรวมของคุณยังคงส่งคำขอที่ถูกต้องหลังจากอัปเดตแพ็คเกจที่พึ่งพา

หลังจากอัปเดตเป็น axios@1.14.0 ให้นำเข้า API endpoints ที่มีอยู่ของคุณไปยัง Apidog และรัน regression test อย่างรวดเร็วเพื่อยืนยันว่าพฤติกรรมไม่เปลี่ยนแปลง การยืนยันการตอบกลับของ Apidog ช่วยให้คุณตรวจสอบค่าฟิลด์, เฮดเดอร์, และรหัสสถานะที่แน่นอนได้:

// Apidog post-response assertion
pm.test("Response is clean — no injected fields", () => {
    const body = pm.response.json();
    pm.expect(body).to.not.have.property('__injected');
    pm.expect(pm.response.headers.get('X-Injected-Header')).to.be.null;
});
Enter fullscreen mode Exit fullscreen mode

รันชุดทดสอบทั้งหมดของคุณกับ axios รุ่นใหม่ใน Apidog จะช่วยให้คุณมี baseline ที่สะอาดก่อน deploy ขึ้น production

ลองใช้ Apidog ฟรีเพื่อตั้งค่าการทดสอบ HTTP client regression

ทำไมการโจมตี Supply Chain บน npm จึงยากที่จะหยุดยั้ง

การโจมตี axios ไม่ใช่กรณีแรก — นี่คือเหตุการณ์ supply chain ที่เคยเกิดขึ้น:

  • event-stream (2018): ผู้ดูแลที่เป็นอันตรายเพิ่มเพย์โหลดที่กำหนดเป้าหมายกระเป๋าเงิน Bitcoin
  • ua-parser-js (2021): ถูกบุกรุกเพื่อติดตั้ง cryptominer และขโมยรหัสผ่าน
  • node-ipc (2022): ผู้ดูแลจงใจเพิ่มโค้ดที่เป็นอันตรายซึ่งกำหนดเป้าหมาย IP ของรัสเซีย/เบลารุส
  • xz utils (2024): แคมเปญวิศวกรรมสังคมสองปีเพื่อแทรกแบ็คดอร์เข้าสู่ไลบรารีการบีบอัดหลักของ Linux
  • axios (2026): ข้อมูลประจำตัวของผู้ดูแลที่ถูกบุกรุกถูกใช้เผยแพร่ RAT ผ่านแพ็คเกจที่พึ่งพาซึ่งเป็นอันตราย

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

มาตรการที่ควรพิจารณา:
| มาตรการ | สิ่งที่ทำ |
|-------------------------------|-------------------------------------------------------------------|
| ไฟล์ Lock (package-lock.json) | ระบุเวอร์ชันที่แน่นอน, ป้องกันการอัปเกรดแบบไม่รู้ตัว |
| npm audit ใน CI | ตรวจจับช่องโหว่ที่ทราบก่อน deploy |
| Socket.dev / Snyk | วิเคราะห์พฤติกรรม — ตรวจจับแพ็คเกจที่น่าสงสัยแม้ไม่มี CVEs |
| 2FA บน npm | ทำให้การบุกรุกข้อมูลประจำตัวทำได้ยากขึ้น |
| โทเค็น publish ที่มีอายุสั้น | จำกัดช่วงเวลาเสี่ยงหากโทเค็นรั่วไหล |
| ตรวจ lock file ใน PR review | ตรวจสอบการเปลี่ยนแปลงแพ็คเกจที่พึ่งพาในการตรวจสอบโค้ด |

ทีม axios ยอมรับว่าโทเค็น npm ที่มีอายุการใช้งานยาวนานเป็นปัญหา และกำลังดำเนินมาตรการควบคุมการเผยแพร่ที่เข้มงวดขึ้น แต่การแก้ไขต้องมาจากระบบนิเวศโดยรวม ไม่ใช่แค่แพ็คเกจเดียว

ตัวบ่งชี้การบุกรุก (IOCs)

สรุปจากการวิเคราะห์ของ Socket:

  • แพ็คเกจที่เป็นอันตราย: plain-crypto-js@4.2.1, axios@1.14.1, axios@0.30.4
  • อีเมลผู้เผยแพร่: nrwise@proton.me
  • พฤติกรรม: มี network connection ตอนติดตั้ง npm, RAT คงทน, ดึง env variable
  • เวอร์ชัน axios ที่ปลอดภัย: 1.14.0 และต่ำกว่า (ยกเว้น 0.30.4), 1.13.x, 1.12.x

หากสงสัยว่าเครื่องติดเชื้อ ให้รายงานไปที่ security@npmjs.com และเก็บ log ไว้

สรุป

กรณี axios 1.14.1 ถูกบุกรุก เป็นเครื่องเตือนใจว่าสาย supply chain ต้องป้องกันตลอดเวลา — ล็อกเวอร์ชัน, ใช้เครื่องมือวิเคราะห์เช่น Socket ใน CI, เปลี่ยน credentials เมื่อมีสิ่งผิดปกติ, ตรวจ lock file เสมอในการ review

หากคุณต้องการสร้างความมั่นใจในการรวม API หลังอัปเดต axios, Apidog มีชุดทดสอบ, การยืนยัน, และ mock tools เพื่อยืนยันพฤติกรรม HTTP client ของคุณก่อน deploy

คำถามที่พบบ่อย

axios เวอร์ชันใดบ้างที่ถูกบุกรุก?

axios@1.14.1 และ axios@0.30.4 ถูกถอนการเผยแพร่จาก npm แล้ว เวอร์ชันที่ปลอดภัยคือ 1.14.0 (หรือ 1.13.x, 1.12.x)

เพย์โหลดที่เป็นอันตรายของ axios ทำอะไร?

มันดึง plain-crypto-js@4.2.1 ซึ่งติดตั้งเพย์โหลดแบบหลายขั้นตอนรวมถึง RAT ที่สามารถรันคำสั่งใดๆ จากเซิร์ฟเวอร์ C2, ดึง env และ secrets ออกไป, และคงอยู่แม้รีบูตเครื่อง

ฉันจะรู้ได้อย่างไรว่าฉันติดตั้งเวอร์ชันที่ถูกบุกรุก?

รัน npm list axios — หากแสดง 1.14.1 หรือ 0.30.4 แสดงว่าคุณได้รับผลกระทบ ตรวจสอบ npm list plain-crypto-js ด้วย — หากมี แสดงว่าโค้ดอันตรายรันไปแล้ว

การอัปเดต axios อย่างเดียวเพียงพอหรือไม่?

ไม่พอ RAT อาจคงอยู่ในเครื่องแล้ว ต้องเปลี่ยน secrets และตรวจหา persistence mechanism

ผู้โจมตีเผยแพร่ไปยัง npm ได้อย่างไรโดยที่ไม่ได้เป็นผู้ดูแล?

ผู้โจมตีอาจได้ credentials ของผู้ดูแลและใช้โทเค็น npm ที่มีอายุยาวซึ่งมีสิทธิ์ publish

ความแตกต่างระหว่างสิ่งนี้กับช่องโหว่ทั่วไปคืออะไร?

ช่องโหว่คือ bug ในโค้ดปกติ การโจมตี supply chain คือการแทรกโค้ดอันตรายผ่านช่องทาง publish ที่เชื่อถือได้ โค้ดอันตรายไม่เคยอยู่ใน GitHub — มันถูก inject ใน npm publish

ฉันจะปกป้องโปรเจกต์ของฉันจาก supply chain attack ได้อย่างไร?

ใช้ lock file, รัน npm audit ใน CI, วิเคราะห์พฤติกรรมด้วย Socket.dev, เปิด 2FA ใน npm, ใช้โทเค็น publish ที่อายุสั้น, ตรวจ lock file diff ใน code review

Top comments (0)