สรุปสั้น

บริษัทความปลอดภัย V12 เปิดเผยเมื่อวันที่ 22 ตุลาคม 2569 ว่า AI agent ที่จ่ายค่าเรียก API ผ่าน SDK ของ x402 อาจลงนามจ่ายเงินเต็มยอดโทเคนในกระเป๋า หาก API อันตรายร้องขอ ต้นเหตุคือไคลเอนต์ค่าเริ่มต้นของ SDK ไม่มีเพดานการจ่ายจนถึงรุ่นที่ออกเมื่อ 18 สิงหาคม 2569 ความเสี่ยงจำกัดอยู่ที่ agent ที่ลงนามจ่ายเงินอัตโนมัติและแอปไม่ได้ตั้งเพดานเอง จุดนี้เป็นหนึ่งใน 25 ข้อบกพร่องที่ V12 พบในโค้ด x402 และเป็นหนึ่งในสามจุดที่จัดเป็นระดับวิกฤต

อีกสองจุดวิกฤต คือ facilitator ของ SDK ภาษา TypeScript ยอมรับธุรกรรม Solana ที่ไม่ได้โอนโทเคนจริงว่าเป็นการชำระเงินที่ถูกต้อง และเซิร์ฟเวอร์อันตรายหลอกให้ agent ลงนามข้อความล็อกอินของเว็บไซต์อื่นได้ มูลนิธิ x402 แก้ครบทั้งสามจุดในรุ่นวันที่ 18 สิงหาคมแล้ว และยังไม่มีรายงานการโจมตีจริง แต่ไม่ได้ออก security advisory และ changelog ก็ไม่ได้ระบุว่าเป็นการแก้ด้านความปลอดภัย ผลคือนักพัฒนาที่พึ่ง npm audit หรือ PyPI จะไม่ได้รับคำเตือนให้อัปเกรด

รายละเอียดข่าว

เว็บไซต์ The Hacker News รายงานเมื่อวันที่ 23 ตุลาคม 2569 ว่า V12 พบข้อบกพร่องจากการรีวิวโค้ดและทดสอบในเครื่อง โดยอธิบายรายละเอียดเฉพาะสามจุดที่จัดเป็นระดับวิกฤต x402 เป็นมาตรฐานเปิดที่บริษัท Coinbase สร้างขึ้นและส่งมอบให้มูลนิธิ x402 ในปีนี้ มูลนิธิเป็นโครงการภายใต้ Linux Foundation ที่มีสมาชิกอย่าง Visa และ Mastercard และ Coinbase ถือที่นั่งอาวุโสที่สุดในคณะกรรมการกำกับทิศทางทางเทคนิค

มาตรฐานนี้ให้ซอฟต์แวร์รวมถึง AI agent จ่ายค่าเรียก API ได้ภายในคำขอเว็บเอง โดยไม่ต้องให้คนอนุมัติทุกครั้ง เซิร์ฟเวอร์ที่ต้องการค่าบริการจะตอบกลับด้วยรหัสสถานะ HTTP 402 Payment Required พร้อมรายการตัวเลือกการชำระ แต่ละตัวเลือกมีจำนวนเงิน โทเคน และผู้รับ ไคลเอนต์เลือกหนึ่งตัวเลือก ลงนามการชำระ แล้วส่งคำขอใหม่

ทั้ง V12 และมูลนิธิ x402 ยังไม่ได้รายงานการโจมตีที่ใช้ช่องโหว่เหล่านี้ ปัญหาหลักอยู่ที่วิธีเปิดเผย The Hacker News ตรวจสอบเมื่อวันที่ 23 ตุลาคมพบว่า npm audit ไม่แสดง advisory สำหรับรุ่น TypeScript สุดท้ายก่อนแก้ และ PyPI ไม่แสดงช่องโหว่สำหรับรุ่น Python สุดท้ายก่อนแก้ นักพัฒนาที่อาศัยเครื่องมือเหล่านี้จึงไม่รู้ว่าต้องอัปเกรด

รายละเอียดช่องโหว่

1. ไคลเอนต์ไม่มีเพดานจ่าย ไคลเอนต์ค่าเริ่มต้นเลือกตัวเลือกแรกในรายการเสมอ และก่อนการแก้ไม่มีเพดานจำนวนเงิน API ที่ไม่หวังดีจึงเปลี่ยนคำขอข้อมูลธรรมดาให้กลายเป็นการขอเงินเต็มยอดโทเคนที่รองรับในกระเป๋า การจ่ายเงินเล็กน้อยครั้งก่อนยังเผยที่อยู่กระเป๋า ทำให้เซิร์ฟเวอร์เช็กยอดก่อนได้ ถ้าแอปใช้ตัวลงนามอัตโนมัติและไม่ได้ตั้งนโยบายการจ่าย ไคลเอนต์จะลงนามจ่ายจำนวนนั้น และสำหรับโทเคนที่รองรับการโอนแบบลงนาม ผู้โจมตีนำการชำระที่ลงนามแล้วไปส่งและเก็บเงินได้ รุ่นวันที่ 18 สิงหาคมเพิ่ม spend controls ให้ไคลเอนต์ TypeScript, Python และ Go โดยค่าเริ่มต้นจำกัดการจ่ายครั้งละ 1 ดอลลาร์ และรับเฉพาะ stablecoin ดอลลาร์สหรัฐที่ SDK รู้จัก เช่น USDC

2. facilitator ฝั่ง Solana ยอมรับ token approval เป็นการชำระเงิน ใน x402 เซิร์ฟเวอร์ของร้านค้าพึ่ง facilitator ตรวจการชำระแต่ละครั้งและส่งเข้าบล็อกเชน บน Solana facilitator ยังจ่ายค่าธรรมเนียมธุรกรรมด้วย โค้ด facilitator ภาษา TypeScript ตรวจเพียงว่าการชำระเรียก token program ที่อนุญาต แล้วอ่านเป็นการโอนโดยไม่ตรวจชนิดคำสั่ง ขณะที่คำสั่ง approve ซึ่งอนุญาตให้บัญชีอื่นใช้โทเคนภายหลังแต่ไม่ได้โอนจริง ต่างจากคำสั่งโอนแค่ไบต์แรก ในการทดสอบในเครื่องของ V12 facilitator ยอมรับ approve เป็นการชำระที่ถูกต้อง ร้านค้าจึงอาจส่งมอบบริการโดยไม่ได้รับโทเคนเลย V12 เรียกว่า “การข้ามการชำระเงินโดยสมบูรณ์” ผู้โจมตีต้องมีแค่ token account ที่ไม่ต้องมียอด และ facilitator ยังต้องจ่ายค่าธรรมเนียมให้ทุกครั้ง SDK ภาษา Python และ Go ตรวจชนิดคำสั่งอยู่แล้ว ส่วน @x402/svm ทุกรุ่นตั้งแต่ 2.0.0 ถึง 2.22.0 ขาดการตรวจนี้ และรุ่น 2.23.0 ขึ้นไปมีแล้ว

3. agent ลงนามล็อกอินให้เว็บไซต์อื่น x402 มีส่วนขยายล็อกอินชื่อ Sign-In-With-X (SIWx) ให้ agent ล็อกอินด้วยการลงนามข้อความสั้นด้วยกระเป๋า เช่น เพื่อพิสูจน์ว่าเคยจ่ายแล้ว บน Ethereum ข้อความระบุชื่อเว็บไซต์ ที่อยู่กระเป๋า และรหัสใช้ครั้งเดียว แต่ไคลเอนต์อัตโนมัติลงนามโดยไม่ตรวจว่าเว็บไซต์ในข้อความตรงกับที่ติดต่ออยู่ เซิร์ฟเวอร์อันตรายจึงขอข้อความล็อกอินใหม่จากเว็บไซต์อื่น ส่งให้ agent ลงนาม แล้วนำลายเซ็นไปล็อกอินเว็บไซต์นั้นในนามกระเป๋าของ agent รุ่นวันที่ 18 สิงหาคมทำให้ไคลเอนต์ปฏิเสธการลงนามเมื่อเว็บไซต์ไม่ตรงกับที่ส่ง 402 มา และข้อกำหนด SIWx ก็ถูกแก้ให้บังคับเช่นนั้น

ผลกระทบ

กรณีนี้ชี้ความเสี่ยงเฉพาะของการชำระเงินแบบ agent-to-API คือ agent ทำธุรกรรมการเงินอัตโนมัติกับเซิร์ฟเวอร์ที่ไม่รู้จัก โดยเชื่อตัวเลือกที่เซิร์ฟเวอร์เสนอมาทั้งหมด ค่าเริ่มต้นที่ไม่มีเพดานจึงเท่ากับให้ API ทุกตัวที่ agent เรียกสั่งจ่ายเงินได้ไม่จำกัด ส่วนฝั่งร้านค้า บั๊กของ facilitator ทำให้บริการถูกใช้ฟรีและยังต้องเสียค่าธรรมเนียมให้ผู้โจมตีด้วย

อีกด้านคือการแก้แบบเงียบ (silent patch) การไม่ออก advisory และไม่ติดป้ายว่าเป็นการแก้ความปลอดภัยใน changelog ทำให้ห่วงโซ่เครื่องมือตรวจ dependency อย่าง npm audit และ Dependabot มองไม่เห็นปัญหา ซึ่งเป็นช่องว่างอันตรายสำหรับแพ็กเกจที่จัดการเงินจริง

คำแนะนำ

  • อัปเกรด SDK ของ x402 เป็นรุ่นล่าสุด ณ วันที่ 23 ตุลาคม 2569 คือ 2.28.0 สำหรับ @x402/core, @x402/svm, @x402/extensions, @x402/fetch และ @x402/axios, v2.28.0 สำหรับ Go module และ 2.25.0 สำหรับแพ็กเกจ Python ซึ่งรวมการแก้ payment bypass แยกต่างหากใน @x402/core 2.27.0 เมื่อเดือนกันยายนด้วย
  • ขั้นต่ำสำหรับ TypeScript: ไคลเอนต์อัปเดต @x402/fetch หรือ @x402/axios เป็น 2.23.0 ขึ้นไป แอปที่ใช้ SIWx ต้องใช้ @x402/extensions 2.23.0 ขึ้นไป และ facilitator ที่ตรวจการชำระ Solana ต้องใช้ @x402/svm 2.23.0 ขึ้นไป
  • โค้ด TypeScript ที่เรียก createSIWxPayload เองต้องส่ง URL ของคำตอบ 402 (หลัง redirect) เข้าไปด้วย ส่วน wrapper @x402/fetch และ @x402/axios ทำให้อัตโนมัติ
  • ห้ามตั้ง spendControls: false เพราะจะปิดการป้องกันทั้งหมด ถ้ายังอัปเกรดไม่ได้ ให้ลงทะเบียนนโยบายตัดตัวเลือกที่เกินจำนวนกำหนดด้วย registerPolicy (TypeScript/Go) หรือ register_policy และนโยบาย max_amount (Python)
  • ตั้งงบต่อการจ่ายแต่ละครั้งและงบรวม จำกัดโทเคน เครือข่าย และผู้รับที่ agent ยอมจ่าย และให้กระเป๋าของ agent ถือยอดเท่าที่จำเป็นเท่านั้น
  • อย่าพึ่ง npm audit หรือ PyPI เพียงอย่างเดียวสำหรับ dependency ที่จัดการเงิน ให้ติดตาม changelog และรายงานจากผู้วิจัยประกอบ

แหล่งอ้างอิง