ช่องโหว่ SMS of Death บน Android ทำสายหลุดและทำให้โทรศัพท์วนแครชซ้ำ

ข้อความที่มองไม่เห็นอาจขัดจังหวะการโทร

ข้อความที่สร้างขึ้นเป็นพิเศษและมีความยาวเพียง 8 ไบต์ สามารถทำให้บริการโทรศัพท์ขัดข้องบนมือถือ Android ที่มีช่องโหว่ ตัดสายที่กำลังโทรอยู่ และหากส่งซ้ำหลายครั้ง ก็อาจทำให้เครื่องเริ่มทำงานตามปกติได้ยาก นักวิจัยด้านความปลอดภัย Mark Blaszczyk เปิดเผยช่องโหว่นี้เมื่อวันที่ 29 ตุลาคม 2026 หลังจากรายงานต่อ Google ครั้งแรกเมื่อวันที่ 5 พฤษภาคม

ช่องโหว่นี้มีชื่อว่า SMS of Death และระบุในรายงานด้านความปลอดภัยเป็น CVE-2026-58882 โดยกระทบซอฟต์แวร์ที่ประมวลผลข้อความขาเข้าบางประเภทก่อนส่งไปยังแอปส่งข้อความ ผู้รับไม่จำเป็นต้องเปิดอะไร ติดตั้งแอป หรือแตะลิงก์ ตามข้อมูลของ Blaszczyk ข้อความอันตรายนี้ไม่ปรากฏในกล่องข้อความและไม่มีการแจ้งเตือน

Blaszczyk ทำให้เกิดปัญหานี้ซ้ำได้บน Google Pixel 9 ที่ใช้เฟิร์มแวร์เดือนเมษายน 2026 และโทรศัพท์ Samsung Galaxy หลายรุ่น รวมถึงรุ่นในซีรีส์ Galaxy A เขารายงานว่าทำให้เกิดปัญหานี้ได้สำเร็จในการทดสอบทุกครั้งบนอุปกรณ์เหล่านั้น ข้อความเพียงข้อความเดียวทำให้บริการเครือข่ายมือถือหยุดชะงักราวหนึ่งถึงสองวินาที ระหว่างที่ Android เริ่มกระบวนการโทรศัพท์ขึ้นใหม่

Blaszczyk ซึ่งเป็นนักวิจัยด้านความปลอดภัยอิสระ อธิบายผลกระทบทันทีที่เกิดกับกระบวนการ Android ซึ่งรับผิดชอบฟังก์ชันโทรศัพท์ว่า:

WAP Push SMS ที่มีรูปแบบผิดเพียงข้อความเดียวทำให้ com.android.phone บน Android แครช ตัดสายที่กำลังโทรอยู่ (รวมถึงสายฉุกเฉิน) โดยผู้ใช้ไม่ต้องทำอะไรเลย

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

เหตุใดข้อความจึงไม่เข้ากล่องข้อความ

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

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

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

ตัวเลขขนาดใหญ่กลายเป็นค่าความยาวติดลบ

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

ในการทดสอบที่อธิบายไว้ ค่า 2,147,483,648 กลายเป็นค่าติดลบ 2,147,483,648 ระหว่างการแปลง จำนวนเต็มแบบมีเครื่องหมายขนาดดังกล่าวรองรับจำนวนบวกได้สูงสุดเพียง 2,147,483,647 ค่าที่สร้างขึ้นเป็นพิเศษนี้จึงเกินขีดจำกัดไปเพียงหนึ่ง

จากนั้น Android พยายามสำรองพื้นที่สำหรับข้อมูลก้อนหนึ่งโดยใช้ค่าความยาวติดลบ ขนาดติดลบใช้ไม่ได้กับการทำงานดังกล่าว ซอฟต์แวร์จึงเกิดข้อผิดพลาดที่เรียกว่า NegativeArraySizeException เนื่องจากไม่มีการจัดการข้อผิดพลาดนี้อย่างเหมาะสม จึงทำให้ com.android.phone ยุติการทำงาน

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

เหตุขัดข้องสั้น ๆ กลายเป็นปัญหาซ้ำได้อย่างไร

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

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

Blaszczyk อธิบายว่าเหตุใดการรีสตาร์ตอุปกรณ์จึงอาจไม่ช่วยยุติการหยุดชะงัก:

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

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

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

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

เหตุใดหน้าจอกู้คืนระบบจึงอาจหมายถึงข้อมูลสูญหาย

Android มีกลไกกู้คืนอัตโนมัติที่เรียกว่า RescueParty เมื่อองค์ประกอบสำคัญขัดข้องซ้ำ ๆ กลไกนี้จะพยายามกู้คืนระบบ และอาจทำให้โทรศัพท์เข้าสู่โหมดกู้คืนหลังผ่านไปราว 90 วินาที จากนั้นผู้ใช้อาจพบตัวเลือกให้ลบข้อมูลทั้งหมด

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

Blaszczyk อธิบายวิธีกู้คืนผ่าน Android Debug Bridge หรือ ADB ซึ่งเป็นเครื่องมือที่ช่วยให้คอมพิวเตอร์สื่อสารกับอุปกรณ์ Android เพื่อการพัฒนาและบำรุงรักษา ขั้นตอนของเขาเกี่ยวข้องกับการลบข้อมูล SMS ที่ได้รับผลกระทบในช่วงเวลาสั้น ๆ ที่ยังเข้าถึงโทรศัพท์ได้

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

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

Android เวอร์ชันใดที่ควรใส่ใจ?

ช่วงเวอร์ชันหลักที่ได้รับผลกระทบตามรายงานทางเทคนิคคือ Android 12 ถึง Android 16 บางรายงานครอบคลุมไปถึง Android 17 ด้วย การทดสอบระบุชื่ออุปกรณ์ Pixel และ Samsung Galaxy โดยเฉพาะ ขณะที่คาดว่าผลกระทบอาจกว้างกว่านั้น เพราะปัญหาอยู่ในโค้ดระบบโทรศัพท์ส่วนกลางของ Android

การแก้ไขที่มีรายงานเมื่อเดือนตุลาคม 2026 ครอบคลุม Android 14 ถึง Android 17 โทรศัพท์ที่ยังใช้ Android 12 หรือ Android 13 เป็นประเด็นด้านการสนับสนุนที่ชัดเจนที่สุด เนื่องจากมีรายงานว่าเวอร์ชันเหล่านี้อยู่นอกการสนับสนุนด้านความปลอดภัยในปัจจุบันของ Google ทำให้เจ้าของต้องพึ่งผู้ผลิตหรือผู้ให้บริการระบบปฏิบัติการรายอื่นในการออกการแก้ไข

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

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

การแก้ไขดำเนินไปคนละเส้นทางกับข้อร้องเรียน

Blaszczyk ระบุว่าในตอนแรก Google มองว่ารายงานของเขาไม่ใช่ปัญหาด้านความปลอดภัย และปิดเรื่องโดยไม่เห็นด้วยกับมาตรการที่เขาเสนอ บันทึกที่เขาเผยแพร่ระบุว่ามีการยื่นอุทธรณ์เพิ่มเติม และ Google จัดประเภทว่าไม่ใช่ปัญหาด้านความปลอดภัยอีกครั้งเมื่อวันที่ 29 ตุลาคม ขณะเดียวกัน วิศวกร Android กำลังพัฒนาการแก้ไขอยู่

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

• 5 พฤษภาคม 2026: Blaszczyk รายงานช่องโหว่ต่อ Google เป็นครั้งแรก
• 15 มิถุนายน: Google สร้างการแก้ไขทางวิศวกรรมสำหรับปัญหาการประมวลผลข้อความ
• กรกฎาคม: GrapheneOS ระบุว่าได้รับแพตช์ผ่านตัวอย่างอัปเดตความปลอดภัยและนำไปใช้ในเดือนนั้น
• 5 สิงหาคม: มีรายงานว่านำการแก้ไขเข้าสู่กระบวนการพัฒนาของ Google
• ตุลาคม: การเปลี่ยนแปลงเผยแพร่ต่อสาธารณะใน Android Open Source Project และรวมอยู่ในอัปเดตสำหรับ Android 14 ถึง Android 17
• 29 ตุลาคม: Blaszczyk เปิดเผยผลการค้นพบต่อสาธารณะ
• พฤศจิกายน: GrapheneOS ระบุว่าคาดว่าช่องโหว่จะปรากฏในประกาศด้านความปลอดภัยของ Android

GrapheneOS เสนอว่าปัญหาการสื่อสารภายในอาจเป็นสาเหตุให้ Google จัดการรายงานดังกล่าวในลักษณะนั้น คำอธิบายนี้เป็นการคาดการณ์ของนักพัฒนาระบบปฏิบัติการ โครงการนี้ระบุข้อมูลทั้งเรื่องข้อร้องเรียนที่ถูกปฏิเสธและการเปลี่ยนแปลงทางวิศวกรรมที่มุ่งหยุดการแครช

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

การแก้ไขเปลี่ยนอะไรบ้าง

การแก้ไขของ Google ตามรายงานเพิ่มการจัดการข้อยกเว้น เพื่อให้ Android จับข้อผิดพลาดขณะทำงานและลบข้อความที่มีรูปแบบผิดออกจากคิวรอดำเนินการ วิธีนี้ช่วยให้ระบบประมวลผลต่อได้ โดยไม่แครชซ้ำเพราะข้อมูลอันตรายรายการเดิม

Blaszczyk เสนอให้ตรวจสอบว่าความยาวส่วนหัวที่ระบุมานั้นถูกต้องหรือไม่ก่อนแปลงค่า ส่วนแนวทางทางวิศวกรรมที่มีรายงานเลือกจัดการความล้มเหลวและลบข้อความต้นเหตุออก ในทางปฏิบัติ การลบข้อมูลรายการนั้นยังช่วยแก้ปัญหาการประมวลผลซ้ำ ซึ่งอาจทำให้การส่งครั้งเดียวกลายเป็นปัญหาบริการต่อเนื่อง

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

การที่การแก้ไขปรากฏใน Android Open Source Project หมายความว่าโค้ดพื้นฐานพร้อมให้ผนวกเข้ากับซอฟต์แวร์ Android แล้ว แต่การส่งอัปเดตไปยังเจ้าของโทรศัพท์แต่ละเครื่องยังขึ้นอยู่กับการสร้างและเผยแพร่รุ่นอัปเดตที่เหมาะกับโทรศัพท์นั้น จึงควรตรวจสอบสถานะการสนับสนุนของรุ่นโทรศัพท์โดยเฉพาะควบคู่ไปกับการทราบว่า Google แก้ไขโค้ดแล้ว

สิ่งที่เจ้าของโทรศัพท์ทำได้ตอนนี้

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

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

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

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

ประเด็นสำคัญ

• WAP Push SMS ที่มีรูปแบบผิดอาจทำให้บริการโทรศัพท์ของ Android แครช โดยผู้รับไม่ต้องทำอะไรเลย
• Blaszczyk ทำให้ช่องโหว่เกิดซ้ำได้บน Pixel 9 และอุปกรณ์ Samsung Galaxy โดยการหยุดชะงักแต่ละครั้งนานประมาณหนึ่งถึงสองวินาที
• การประมวลผลซ้ำและการส่งข้อความซ้ำจากผู้ให้บริการอาจทำให้เกิดการหยุดชะงักยาวนาน การแครชซ้ำ และหน้าจอแจ้งให้กู้คืนระบบ
• การแก้ไขที่มีรายงานเมื่อเดือนตุลาคม 2026 ครอบคลุม Android 14 ถึง Android 17 เจ้าของ Android 12 และ Android 13 ต้องพึ่งการสนับสนุนเพิ่มเติมจากผู้ให้บริการอุปกรณ์
• ยังไม่มีรายงานการโจมตีนอกการทดสอบ นักวิจัยเตือนว่าการโทรที่ถูกรบกวนอาจกระทบการเข้าถึงบริการฉุกเฉิน
• การรีเซ็ตเป็นค่าโรงงานจะลบข้อมูล และอาจมีการส่งข้อความอันตรายกลับมาอีก การกู้คืนทางเทคนิคอาจต้องใช้ ADB