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

สรุปโดยย่อ

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

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

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

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

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

button

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

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 — การดำเนินการ: แพ็คเกจจะรันโค้ดเมื่อทำการติดตั้ง (ผ่านสคริปต์ npm lifecycle) เพื่อปล่อยเพย์โหลดรอง
ขั้นตอนที่ 2 — การติดตั้ง RAT: เพย์โหลดจะติดตั้งโทรจันสำหรับเข้าถึงระยะไกล (RAT) ที่เปิดแบ็คดอร์แบบถาวร
ขั้นตอนที่ 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

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

# Check installed version
npm list axios

# Check lock file
grep '"axios"' package-lock.json | head -5

# Check for plain-crypto-js presence
npm list plain-crypto-js
ls node_modules/plain-crypto-js 2>/dev/null && echo "INFECTED" || echo "Not found"

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

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

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

npm install axios@1.14.0
# or pin to latest safe
npm install axios@latest

ตรวจสอบ:

npm list axios
# Should show 1.14.0 or higher (once a clean 1.14.x is published)

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

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

เปลี่ยนความลับทั้งหมด ที่สามารถเข้าถึงได้จากเครื่องนั้น: คีย์ API, ข้อมูลประจำตัวฐานข้อมูล, คีย์ SSH, โทเค็นของผู้ให้บริการคลาวด์, ตัวแปร .env
ตรวจสอบตัวแปรสภาพแวดล้อมของคุณ — RAT กำหนดเป้าหมายเฉพาะความลับในสภาพแวดล้อมของโปรเซสและระบบไฟล์
ตรวจสอบการเชื่อมต่อเครือข่ายขาออก จากช่วงเวลาที่ได้รับผลกระทบ — มองหาการเชื่อมต่อไปยัง IP ที่ไม่รู้จัก
สแกนหาความคงทน — ตรวจสอบ cron jobs, สคริปต์เริ่มต้น, และบริการ systemd ที่ถูกเพิ่มเข้ามาในช่วงเวลาที่ถูกบุกรุก
ติดตั้งอิมเมจใหม่ให้กับเครื่อง หากเป็น CI runner หรือเซิร์ฟเวอร์ Production ที่ติดตั้งเวอร์ชันที่ถูกบุกรุก หากเป็นแล็ปท็อปของนักพัฒนา ให้ถือว่าข้อมูลประจำตัวถูกเปิดเผยแล้วและเปลี่ยนทั้งหมดก่อนที่จะถือว่าเครื่องสะอาด

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

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

# Check build logs for the affected timeframe
# Look for axios@1.14.1 in any install output

# Verify current CI node_modules are clean
npm list axios plain-crypto-js

เปลี่ยนความลับใดๆ ที่ CI pipeline ของคุณเข้าถึงได้: คีย์การปรับใช้ (deployment keys), ข้อมูลประจำตัวของผู้ให้บริการคลาวด์ (cloud provider credentials), โทเค็นรีจิสทรี (registry tokens)

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

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

# Remove and regenerate
rm package-lock.json
npm install

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

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

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

หลังจากอัปเดตเป็น axios@1.14.0 ให้นำเข้า API endpoints ที่มีอยู่ของคุณไปยัง Apidog และรันการตรวจสอบ regression อย่างรวดเร็วเพื่อยืนยันว่าพฤติกรรมไม่เปลี่ยนแปลง สิ่งนี้มีประโยชน์อย่างยิ่งหากคุณกังวลว่าเวอร์ชันที่เป็นอันตรายอาจแก้ไขเพย์โหลดของคำขอหรือการตอบกลับ — การยืนยันการตอบกลับของ 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;
});

การรันชุดทดสอบทั้งหมดของคุณกับเวอร์ชัน axios ที่อัปเดตแล้วใน Apidog จะช่วยให้คุณมีข้อมูลพื้นฐานที่สะอาด (clean baseline) ก่อนที่จะปรับใช้สู่ Production

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

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

การโจมตี axios ไม่ใช่เรื่องผิดปกติ มันเป็นรูปแบบที่เกิดขึ้นซ้ำๆ:

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

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

มาตรการบรรเทาผลกระทบที่ช่วยได้จริง:

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

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

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

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

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

หากคุณสงสัยว่าติดเชื้อ ให้รายงานไปยัง npm security ที่ security@npmjs.com และเก็บรักษาบันทึก (logs) ไว้

สรุป

การถูกบุกรุกของ axios 1.14.1 เป็นเครื่องเตือนใจว่าความปลอดภัยของแพ็คเกจที่พึ่งพาไม่ใช่การตรวจสอบเพียงครั้งเดียว — แต่มันเป็นกระบวนการต่อเนื่อง ล็อกเวอร์ชันของคุณ, รันเครื่องมือวิเคราะห์พฤติกรรมเช่น Socket ใน CI ของคุณ, เปลี่ยนข้อมูลประจำตัวเมื่อมีสิ่งผิดปกติ, และตรวจสอบไฟล์ lock ของคุณในการรีวิวโค้ด

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

button

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

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) RAT สามารถรันคำสั่งใดๆ จากเซิร์ฟเวอร์ C2 ระยะไกล, ดึงตัวแปรสภาพแวดล้อมและความลับออกไป, และคงอยู่แม้หลังจากรีบูตเครื่อง

ฉันจะรู้ได้อย่างไรว่าฉันติดตั้งเวอร์ชันที่ถูกบุกรุก?รัน npm list axios — หากแสดง 1.14.1 หรือ 0.30.4 แสดงว่าคุณได้รับผลกระทบ นอกจากนี้ ให้ตรวจสอบ npm list plain-crypto-js — หากแพ็คเกจนั้นมีอยู่ แสดงว่าโค้ดที่เป็นอันตรายได้รันบนเครื่องของคุณแล้ว

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

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

ความแตกต่างระหว่างสิ่งนี้กับช่องโหว่ทั่วไปคืออะไร?ช่องโหว่คือข้อบกพร่องในโค้ดที่ถูกต้องตามกฎหมาย การโจมตี Supply Chain เป็นการนำโค้ดที่เป็นอันตรายเข้ามาผ่านช่องทางการเผยแพร่ที่เชื่อถือได้ โค้ดที่ถูกบุกรุกไม่เคยอยู่ใน GitHub repository ของ axios — มันถูกฉีดเข้าไปในการเผยแพร่ npm โดยตรง

ฉันจะปกป้องโปรเจกต์ของฉันจากการโจมตี Supply Chain ในอนาคตได้อย่างไร?ใช้ไฟล์ lock, รัน npm audit ใน CI, เพิ่มเครื่องมืออย่าง Socket.dev สำหรับการวิเคราะห์พฤติกรรม, เปิดใช้งาน 2FA บนบัญชี npm, ใช้โทเค็นการเผยแพร่ที่มีอายุสั้น, และตรวจสอบความแตกต่างของไฟล์ lock ในการรีวิวโค้ด