JPCERT/CC เตือนข้อมูลส่วนบุคคลในญี่ปุ่นรั่วต่อเนื่องจาก API แอปมือถือถูกใช้ในทางมิชอบและ Metabase ถูกเจาะ — Macnica นับได้ 119 เหตุในปีนี้ Times Car รั่ว 6.6 ล้านบัญชี

สรุปสั้น

ศูนย์ประสานงาน JPCERT/CC ของญี่ปุ่นออกประกาศเตือนเมื่อวันที่ 8 ตุลาคม 2569 ว่าเหตุข้อมูลส่วนบุคคลรั่วไหลต่อเนื่องจากองค์กรญี่ปุ่นหลายแห่งช่วงราวเดือนกันยายน เกิดจากผู้โจมตีใช้ API ของแอปมือถือในทางมิชอบและเจาะช่องโหว่ซอฟต์แวร์ที่รู้จักอยู่แล้ว ระบบที่ถูกเจาะมีทั้งแอปสำหรับผู้บริโภค เครื่องมือ business intelligence (BI) และระบบจัดการภายในที่ผู้ดูแลไม่คาดว่าคนภายนอกจะเข้าถึงได้ ผลิตภัณฑ์เดียวที่ประกาศระบุชื่อคือ Metabase ซึ่งมีช่องโหว่ SQL injection CVE-2026-72898 คะแนน CVSS 10.0 ที่ถูกใช้โจมตีจริง JPCERT/CC ยอมรับว่าข้อมูลที่มี “จำกัดและเป็นเพียงบางส่วน” และไม่ได้ระบุชื่อผู้โจมตีหรือองค์กรที่ได้รับผลกระทบ

ตัวเลขที่ชัดที่สุดมาจากบริษัท Macnica ซึ่งนับได้ 119 เหตุในปีนี้จนถึง 6 ตุลาคม ที่ข้อมูลส่วนบุคคลถูกขโมยผ่านระบบเว็บขององค์กรญี่ปุ่น เทียบกับ 84 เหตุทั้งปี 2568 และ 62 เหตุในปี 2567 โดย 81 เหตุเกิดตั้งแต่กรกฎาคมเป็นต้นมา กรณีใหญ่คือบริษัท Park24 ที่แจ้งว่าข้อมูลราว 6.6 ล้านบัญชีของบริการรถเช่าร่วม Times Car ถูกดึงไป และเอกสารยืนยันตัวตน เช่น ภาพใบขับขี่ รั่วจากราว 1.6 ล้านบัญชี Macnica ยังพบเคสลักษณะเดียวกัน 99 เคสใน 13 ประเทศและภูมิภาค ส่วนคณะกรรมการคุ้มครองข้อมูลส่วนบุคคลของญี่ปุ่นออกคำเตือนแยกต่างหากเมื่อวันที่ 7 ตุลาคม

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

เว็บไซต์ The Hacker News รายงานเมื่อวันที่ 8 ตุลาคม 2569 ว่า JPCERT/CC จัดทำประกาศจากรายงานเหตุที่ได้รับและข้อมูลอื่น ๆ โดยระบุว่าคำอธิบายของตน “ไม่ได้หมายความว่าทุกเหตุใช้วิธีเดียวกัน” การโจมตีชุดนี้แยกจากแรนซัมแวร์และเหตุทั่วไป นำไปสู่การรั่วของข้อมูลส่วนบุคคลปริมาณมาก และอาจกำลังเพิ่มขึ้น ประกาศมี IP ต้นทาง 8 รายการ User-Agent 5 แบบ และมาตรการควบคุม API สำหรับผู้ดูแลระบบ

เป้าหมายขยายจากร้านค้าออนไลน์ไปยังบริการสมาชิก ระบบธุรกิจ และระบบบริการลูกค้า เคสล่าสุดรวมถึงระบบค้นหาหนังสือของห้องสมุดและระบบจองที่นั่งรถไฟท่องเที่ยว นอกจาก Park24 แล้ว บริษัท Monogatari Corporation ผู้บริหารเครือร้านปิ้งย่าง Yakiniku King แจ้งว่าข้อมูล 10,788,963 รายการรั่วจากระบบสมาชิกของแอป Yakiniku King ตามรายงานของ INTERNET Watch เมื่อ 5 ตุลาคม ทั้งสองบริษัทระบุว่ายังอยู่ระหว่างสอบสวนสาเหตุ

ตัวเลขของ Macnica นับเฉพาะเหตุที่บริษัทประเมินว่าคล้ายกับชุดปัจจุบัน ไม่รวมแรนซัมแวร์และเคสที่โยงกับกลุ่มอื่น และใน 81 เหตุตั้งแต่กรกฎาคม มีถึง 65 เหตุที่เปิดเผยรายละเอียดน้อยเกินกว่าจะบอกได้ว่าผู้โจมตีเข้ามาอย่างไร ส่วน 99 เคสนอกญี่ปุ่นส่วนใหญ่เกิดช่วงกรกฎาคมถึงกันยายน มีในเกาหลีใต้ 30 เคส ฝรั่งเศส 11 เคส และโปแลนด์ 8 เคส แต่ Macnica ไม่ทราบว่าญี่ปุ่นเป็นเป้าหมายเดียวหรือไม่ เพราะกฎหมายและแนวปฏิบัติการเปิดเผยเหตุต่างกันในแต่ละประเทศ

วิธีการโจมตี

รูปแบบที่ 1 — ใช้ API ของแอปในทางมิชอบ

JPCERT/CC ได้รับรายงานหลายฉบับถึง 3 วิธี ได้แก่ (1) วิเคราะห์แอปสมาร์ตโฟนที่เผยแพร่สาธารณะเพื่อหา endpoint และคีย์ API (2) โจมตี API ภายในที่ไม่ได้ใช้ผ่านหน้าจอแอป เช่น เปลี่ยนสิทธิ์ผู้ใช้ สร้างบัญชีโดยไม่ได้รับอนุญาต เปรียบเทียบการตอบสนองของเซิร์ฟเวอร์เมื่อเพิ่มหรือตัด header หรือส่ง token ยืนยันตัวตนที่ผิดรูปแบบ และหาข้อมูลบัญชีด้วย blind NoSQL injection และ (3) ใช้คีย์ API ที่ขโมยมาจากการเจาะระบบอื่น บางกรณีคำขอเหล่านี้ยังแก้ไขข้อมูลด้วย Macnica รายงานวิธีเดียวกันจากงานรับมือเหตุและวิเคราะห์ล็อก โดยบางกรณีผู้โจมตีดึงคีย์ API จากแอปแล้วเรียก API ในลักษณะที่ดูเหมือนการใช้งานปกติ

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

รูปแบบที่ 2 — สแกนหาช่องโหว่หลายตัวต่อเป้าหมาย

JPCERT/CC ตั้งข้อสันนิษฐานว่าแทนที่จะพึ่งช่องโหว่ตัวเดียวที่ทุกเป้าหมายมีร่วมกัน ผู้โจมตีอาจสแกนแต่ละเป้าหมายหาช่องโหว่ที่รู้จักหลายตัวแล้วลองเจาะ รวมถึงอาจพยายามขโมยไฟล์คอนฟิกและไฟล์สำรองข้อมูลที่ดูแลไม่ดี

รูปแบบที่ 3 — Metabase CVE-2026-72898

CVE-2026-72898 เป็นช่องโหว่ SQL injection ใน Metabase เครื่องมือ BI โอเพนซอร์สที่องค์กรเชื่อมต่อกับฐานข้อมูล ผู้โจมตีไม่ต้องมีบัญชี สามารถ inject SQL เข้าฐานข้อมูลของแอปพลิเคชัน Metabase เองจนได้สิทธิ์แอดมิน แล้วขโมย credential ของฐานข้อมูลที่เชื่อมต่อไว้เพื่ออ่านหรือส่งออกข้อมูล ช่องโหว่ถูกใช้เป็นซีโรเดย์กับบริการคลาวด์ของ Metabase เอง (โพสต์ 2026/08/050 ) และ CISA เพิ่มเข้า KEV เมื่อ 11 สิงหาคม ประกาศใหม่ของ JPCERT/CC เพิ่ม IP ต้นทาง 3 รายการที่ถูกใช้ตั้งแต่ต้นสิงหาคมถึงต้นกันยายน การโจมตียังดำเนินต่อหลังแพตช์ออกแล้ว เช่น AhaSlides ที่ถูกเจาะผ่าน Metabase และผู้โจมตีเข้าถึงได้ตั้งแต่ 12 สิงหาคมถึง 7 กันยายน เช่นเดียวกับเคส Mathspace ที่แพตช์ช้า (โพสต์ 2026/09/053 )

Metabase ระบุว่าเซิร์ฟเวอร์น่าจะถูกเจาะแล้วหากล็อกแสดงคำขอ POST /api/session/reset_password ที่ได้ 400 ตามด้วย GET /api/user/current ที่ได้ 200 หลังแพตช์รอบ 6 สิงหาคม บริษัทออกประกาศวิกฤตอีกฉบับเมื่อ 11 สิงหาคมสำหรับปัญหาที่พบเอง และยกเวอร์ชันขั้นต่ำที่ถือว่าปลอดภัยขึ้น (เวอร์ชันต่ำกว่า 58 ไม่ได้รับผลกระทบจาก CVE-2026-72898)

ตารางเป็นรุ่นโอเพนซอร์ส · รุ่น Enterprise ใช้เลข 1.x แทน 0.x

สิ่งที่ยังไม่ยืนยัน

ทั้ง JPCERT/CC และ Macnica ไม่ได้ระบุชื่อบุคคลหรือกลุ่มที่อยู่เบื้องหลัง และไม่ได้บอกว่าเป็นกลุ่มเดียว Macnica ประเมินว่าผู้โจมตีลองเจาะระบบเว็บสาธารณะใดก็ได้ที่มีข้อมูลส่วนบุคคล อาจนำวิธีที่สำเร็จกับเป้าหมายหนึ่งไปใช้กับเป้าหมายอื่น และบางกรณีใช้ IP ต้นทางร่วมกัน ยังไม่มีการยืนยันการใช้ซีโรเดย์ที่ AI ค้นพบ Macnica ระบุว่า “สิ่งที่เกิดขึ้นจริงคือการไล่หาและเจาะจุดอ่อนพื้นฐาน เช่น สิทธิ์การเข้าถึง การตั้งค่า และการยืนยันตัวตน รวมถึงช่องโหว่ที่รู้จัก” แม้ไม่มีล็อกพิสูจน์ว่าใช้ AI แต่ผู้เขียนมองว่าตัด AI ออกได้ยาก เพราะการตรวจเว็บจำนวนมากขนาดนี้ด้วยมือไม่สมจริง

ผลกระทบ

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

กรณี Metabase ยังย้ำว่าการแพตช์ช่องโหว่ที่ถูกโจมตีแล้วไม่พอ หากผู้โจมตีเข้ามาก่อนแพตช์ credential ฐานข้อมูลที่ถูกขโมยไปยังใช้ได้ต่อ ส่วนเคสในเกาหลีใต้ ฝรั่งเศส และโปแลนด์ ชี้ว่าแคมเปญลักษณะนี้ไม่จำกัดอยู่ที่ญี่ปุ่น

คำแนะนำ

API และแอปมือถือ (ตาม JPCERT/CC และ OWASP API Security Top 10)

• จำกัดจำนวนคำขอต่อหน่วยเวลา และตั้งขีดจำกัดแยกสำหรับฟังก์ชันที่ถูกใช้ผิดง่าย เช่น ล็อกอิน รีเซ็ตรหัสผ่าน ส่ง SMS และค้นหา
• บังคับควบคุมการเข้าถึงทุก endpoint รวมถึง API ที่ไม่เปิดสาธารณะ รับเฉพาะผู้ใช้และ HTTP method ที่อนุญาต
• ให้สิทธิ์ผู้ใช้และ token เท่าที่จำเป็น ตั้งวันหมดอายุ token และเพิกถอน token ที่ไม่ใช้หรืออาจรั่วได้ทันที
• ห้ามฝังคีย์ API ลับหรือ credential ฐานข้อมูลในแอปหรือโค้ดฝั่งเบราว์เซอร์ การ minify หรือ obfuscate ไม่ได้ซ่อนคีย์
• รวมฟังก์ชันแอดมินไว้ในขอบเขตการทดสอบเจาะระบบ ปิดฟังก์ชันแอดมินที่ไม่จำเป็นจากอินเทอร์เน็ต จำกัดการเข้าถึงตามภูมิภาคหากให้บริการเฉพาะพื้นที่ และลบข้อมูลที่เกินระยะเวลาเก็บรักษา

Metabase

• อัปเกรดเป็นรุ่นขั้นต่ำที่ปลอดภัยตามตาราง หากยังอัปเกรดไม่ได้ให้บล็อก /api/session/reset_password ชั่วคราว
• หาก endpoint นี้เคยเข้าถึงได้จากอินเทอร์เน็ต ให้เพิกถอนเซสชันทั้งหมด ตรวจและลบคีย์ API ที่ไม่รู้จัก ตรวจบัญชีแอดมิน เปลี่ยน credential ของฐานข้อมูลที่เชื่อมต่อทุกตัว ตรวจล็อก data warehouse และประวัติคิวรีของ Metabase

ล่าภัยคุกคามจากล็อก (ย้อนหลังราว 1 เดือนตาม Macnica)

• ทราฟฟิก API ปริมาณมากจาก IP เดียว · error 403/404/503 พุ่งขึ้น · คำขอไปยังไฟล์หรือฟังก์ชันที่ไม่มีอยู่ · คำขอมากผิดปกติแม้ได้ 200
• การใช้ฟังก์ชันแอดมินจาก IP แปลกหรือโดยผู้ใช้ทั่วไป · โหลดฐานข้อมูลสูงพร้อมทราฟฟิก · ความพยายามล็อกอินเพิ่มขึ้น
• ตรวจ IP ในตาราง IoC โดยเริ่มที่ 210.149.87[.]120 และ 69.10.51[.]162 ก่อน

Indicators of Compromise (IoCs)

IP defang แล้ว ([.]) · JPCERT/CC ระบุว่าบางตัวอาจเป็นทางออก VPN ที่ผู้ใช้ทั่วไปร่วมใช้ และอาจใช้งานปกติอยู่ในปัจจุบัน คำขอจาก IP เหล่านี้จึงไม่ใช่หลักฐานการโจมตีด้วยตัวเอง

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

• JPCERT/CC — ประกาศเตือน at260030
• Macnica — Web incidents 2026
• Metabase — Security update 6 Aug 2026
• Metabase — GHSA-r495-55cx-fjh7
• Park24 — ประกาศ 28 ก.ย. 2569
• Personal Information Protection Commission — คำเตือน 7 ต.ค. 2569 (PDF)
• The Hacker News — Japan Sees Sharp Rise in Web Data Leaks Amid Mobile API Abuse and Metabase Attacks