สรุปสั้น
บริษัท Redis ผู้พัฒนาฐานข้อมูลแบบ in-memory ที่ได้รับความนิยมสูงในงานแคช (Cache) และคิวข้อมูล ได้ออกแพตช์ความปลอดภัยพร้อมกันถึง 7 เวอร์ชันเมื่อวันที่ 23 กรกฎาคม 2026 หลังจากนักวิจัยเผยแพร่ Proof-of-Concept (PoC) หรือโค้ดสาธิตการโจมตีที่สามารถรันโค้ดจากระยะไกล (Remote Code Execution — RCE) บน Redis รุ่นมาตรฐานถึง 4 สายพันธุ์ ได้แก่ 6.2.22, 7.4.9, 8.6.4 และ 8.8.0 โดยทุกสายการโจมตีต้องอาศัยคำสั่ง RESTORE ซึ่งเป็นคำสั่งที่ผู้โจมตีต้องผ่านการยืนยันตัวตน (Authenticated) ก่อน แล้วอาศัยการโหลดข้อมูลที่ถูกดัดแปลงให้บิดเบี้ยวเพื่อทำให้เกิดความเสียหายในหน่วยความจำ จุดบกพร่องกระจายอยู่ 2 ตำแหน่งหลัก คือกลไก Redis Streams และโมดูลเสริม RedisBloom โดย Redis ระบุว่าจุดบกพร่องหน่วยความจำเหล่านี้อาจนำไปสู่การรันโค้ดจากระยะไกลได้จริง
จุดที่ทำให้ข่าวนี้ได้รับความสนใจเป็นพิเศษ คือมันถูกอ้างว่าค้นพบโดยเอเจนต์ปัญญาประดิษฐ์ (AI Agent) ที่ชื่อ Kimi K3 ซึ่งนาย Chaofan Shou ระบุผ่านแพลตฟอร์ม X ว่าเอเจนต์ชุดนี้ค้นพบช่องโหว่ zero-day ใน Redis ถึง 19 จุดภายในเวลาราว 90 นาที และอีกรอบหนึ่งสามารถสร้าง exploit สำหรับ Redis 8.8.0 ได้ในเวลาเพียง 27 นาที อย่างไรก็ตามตัวเลขจำนวนช่องโหว่ ระยะเวลา และระดับความอัตโนมัติที่อ้างมานั้นยังเป็นข้อมูลที่รายงานด้วยตนเองทั้งหมด บันทึกสาธารณะของ Redis ยืนยันได้เพียงว่าช่องโหว่และแพตช์มีอยู่จริง แต่ไม่ได้ยืนยันจำนวน zero-day หรือระดับความเป็นอิสระในการทำงานของ AI ตามที่กล่าวอ้าง ณ วันที่ 24 กรกฎาคม 2026 ยังไม่พบการโจมตีจริงในธรรมชาติ และยังไม่มีการออกเลข CVE ใหม่สำหรับช่องโหว่ชุดนี้
รายละเอียดข่าว
เว็บไซต์ The Hacker News รายงานเมื่อวันที่ 24 กรกฎาคม 2569 ว่า บริษัท Redis ได้ปล่อยแพตช์ความปลอดภัยชุดใหญ่ในวันที่ 23 กรกฎาคม หลังกลุ่มวิจัยที่ใช้ชื่อว่า Bera Buddies ซึ่งอธิบายตัวเองว่าเป็น “AI Agent Research” เผยแพร่สคริปต์สาธิตการโจมตีต่อสาธารณะ โดยทั้ง 4 สายการโจมตีล้วนต้องใช้คำสั่ง RESTORE ส่วนสายที่เจาะ Redis Streams ยังต้องใช้คำสั่ง EVAL และ XGROUP เพิ่มเติม ขณะที่สายของ 8.8.0 ต้องใช้ EVAL ร่วมกับโมดูล RedisBloom ที่มาพร้อมตัวติดตั้ง
แพตช์ที่ออกมาแบ่งการแก้ตามสาย ได้แก่ Redis 6.2.23, 7.2.15 และ 7.4.10 แก้ปัญหา use-after-free แบบ shared-NACK ใน Streams ส่วน Redis 8.2.8, 8.4.5 และ 8.6.5 แก้ทั้งปัญหา Streams และปัญหาการเขียนข้อมูลนอกขอบเขต (out-of-bounds write) ในโมดูล RedisBloom และ TDigest ขณะที่ Redis 8.8.1 แก้ที่ตัวโหลดของ RedisBloom และ TDigest โดยที่การป้องกันฝั่ง Streams มีอยู่แล้วตั้งแต่ Redis 8.8.0 ประเด็นที่น่ากังวลคือ เป้าหมาย PoC สองรุ่นคือ Redis 6.2.22 และ 7.4.9 นั้น แท้จริงเป็นแพตช์ความปลอดภัยที่ Redis เคยบอกให้ผู้ใช้ติดตั้งไปแล้วเมื่อเดือนพฤษภาคม แต่รุ่นดังกล่าวกลับยังไม่มีกลไกป้องกันเรื่องความเป็นเจ้าของ shared-NACK ทำให้ผู้ที่คิดว่า “เพิ่งอัปเดตไปแล้ว” อาจยังตกเป็นเป้าอยู่ นักวิจัยจึงย้ำว่าให้ตรวจเวอร์ชันของ branch ที่ใช้งานจริงให้ตรง ไม่ใช่ดูเพียงว่าเพิ่งแพตช์มาหมาดๆ
รายละเอียดช่องโหว่
ช่องโหว่แบ่งเป็น 2 เส้นทางหลักที่ล้วนผ่านคำสั่ง RESTORE เส้นทางแรกอยู่ในกลไก Redis Streams เป็นจุดบกพร่องเรื่องความเป็นเจ้าของร่วม (shared-ownership) โดยออบเจ็กต์ RDB ที่ถูกดัดแปลงสามารถทำให้ผู้บริโภคข้อมูล (consumer) สองรายชี้ไปยังเรกคอร์ดรายการค้าง (pending-entry) ตัวเดียวกัน ซึ่งภายในแทนด้วยโครงสร้าง streamNACK เมื่อลบ consumer รายแรกออก ออบเจ็กต์จะถูกคืนหน่วยความจำ (free) แต่ consumer รายที่สองยังถือ pointer ที่ชี้ไปยังหน่วยความจำที่ถูกคืนไปแล้ว (dangling pointer) จากนั้นสคริปต์จะสั่งลบ consumer รายที่สองด้วย ทำให้หน่วยความจำก้อนเดียวถูกคืนซ้ำสองครั้ง (double-free) สคริปต์ที่เผยแพร่ถูกออกแบบให้เปลี่ยนความเสียหายนี้เป็นการเข้าถึงหน่วยความจำตามอำเภอใจ แล้วปนเปื้อนฟังก์ชันแฮชของฐานข้อมูลจนคำสั่ง GET ที่ปั้นขึ้นมาสามารถเรียก system() ได้ ที่น่าสังเกตคือ The Hacker News ตรวจซอร์สโค้ด Redis 8.6.4 ที่ติดแท็กไว้แล้วพบว่า ยังขาดกลไกตรวจสอบความเป็นเจ้าของซ้ำที่ควรจะเพิ่มเข้ามาตาม PR #15081 โดยกลไกดังกล่าวเพิ่งปรากฏใน Redis 8.6.5 ที่ออกวันที่ 23 กรกฎาคม
เส้นทางที่สองอยู่ในตัวโหลด TDigest RDB ของโมดูล RedisBloom เป็นการเขียนนอกขอบเขต โดยตัวโหลดจัดสรรอาร์เรย์เก็บจุดศูนย์กลาง (centroid) จากค่าการบีบอัดที่ถูก serialize มา แต่กลับไปเชื่อค่าความจุ (capacity) อีกตัวหนึ่งที่ผู้โจมตีควบคุมได้ในการตัดสินใจว่าจะโหลดข้อมูลกี่โหนด เมื่อจับคู่การจัดสรรจริงขนาดเล็กเข้ากับ metadata ที่ปั่นให้ใหญ่เกินจริง ก็เกิดการเขียนนอกขอบเขตขึ้น สคริปต์สำหรับ Redis 8.8.0 ถูกออกแบบให้เปลี่ยนการเขียนนี้เป็น primitive สำหรับอ่านและเขียนหน่วยความจำ รั่วที่อยู่ของ Redis และ libc แล้วเรียก system() แพตช์เดือนกรกฎาคมของ Redis จึงบังคับให้ค่าความจุ TDigest ที่โหลดต้องตรงกับการจัดสรรที่คำนวณจากค่าการบีบอัด พร้อมจำกัดขอบเขตตัวนับโหนดก่อนอ่านอาร์เรย์ ทั้งนี้ที่เก็บ PoC เรียกปัญหา Streams ว่าเป็นส่วนหนึ่งของตระกูล “การแก้ไม่สมบูรณ์” ของ CVE-2026-25589 แต่ Redis จับคู่ CVE นั้นกับความเสียหายหน่วยความจำใน RedisBloom ระหว่าง RESTORE ไม่ใช่จุด shared-NACK ใน Streams และบันทึกการออกแพตช์เดือนกรกฎาคมของ Redis ก็ไม่ได้ระบุเลข CVE หรือคะแนน CVSS สำหรับจุดบกพร่องใหม่ทั้งสองประเภทเลย ณ วันที่ 24 กรกฎาคม การค้นหาของ The Hacker News ก็ไม่พบบันทึกใน NVD สำหรับจุด shared-NACK หรือ TDigest ที่เพิ่งพบ และไม่พบรายการในบัญชี Known Exploited Vulnerabilities (KEV) ของ CISA เช่นกัน
ผลกระทบต่อไทย
Redis เป็นหนึ่งในฐานข้อมูล in-memory ที่องค์กรไทยจำนวนมากใช้เป็นระบบแคชและคิวข้อมูลเบื้องหลังทั้งเว็บแอปพลิเคชัน อีคอมเมิร์ซ ระบบธนาคาร ฟินเทค และบริการภาครัฐ เพราะให้ประสิทธิภาพสูง แม้ช่องโหว่ชุดนี้จะต้องผ่านการยืนยันตัวตนก่อน (authenticated) และต้องใช้คำสั่งเฉพาะอย่าง RESTORE จึงจำกัดผู้โจมตีให้อยู่ในวงที่มีสิทธิ์ระดับหนึ่ง แต่ในสภาพแวดล้อมจริงหลายแห่ง Redis มักถูกตั้งค่าแบบไม่มีรหัสผ่านหรือเปิดพอร์ตให้เข้าถึงได้กว้างเกินจำเป็น โดยเฉพาะในระบบภายในที่เชื่อว่าปลอดภัยอยู่แล้ว หากผู้โจมตีเจาะเข้าเครือข่ายภายในได้ ก็อาจต่อยอดเป็นการรันโค้ดบนเซิร์ฟเวอร์ Redis เพื่อเข้าถึงข้อมูลในแคชหรือขยับต่อไปยังระบบอื่น นอกจากนี้ประเด็นที่รุ่นเดือนพฤษภาคม (6.2.22 และ 7.4.9) ยังคงมีช่องโหว่ ทำให้ทีมที่คิดว่าอัปเดตแล้วอาจประมาทได้ องค์กรไทยจึงควรตรวจสอบเวอร์ชันจริงของทุก instance ไม่ใช่แค่เชื่อว่าเพิ่งอัปเดต
คำแนะนำ
ผู้ดูแลระบบควรอัปเกรด Redis เป็นเวอร์ชันที่แก้แล้วให้ตรงกับ branch ที่ใช้งานอยู่ทันที ได้แก่ 6.2.23, 7.2.15, 7.4.10, 8.2.8, 8.4.5, 8.6.5 หรือ 8.8.1 ตามสายที่ติดตั้ง ระหว่างที่ยังอัปเกรดไม่เสร็จ ให้เพิกถอนสิทธิ์คำสั่ง RESTORE ออกจากบัญชีที่ไม่จำเป็นต้องใช้จริง เพราะการจำกัด RESTORE จะตัดทั้งสองเส้นทางการโจมตีที่เปิดเผยออกไปได้ พร้อมทั้งบล็อกการเข้าถึงจากเครือข่ายที่ไม่น่าเชื่อถือ ควรตั้งรหัสผ่านและเปิดใช้การยืนยันตัวตนกับ Redis ทุก instance ไม่เปิดพอร์ตออกสู่อินเทอร์เน็ตโดยตรง และแยกเครือข่าย (segmentation) ให้เฉพาะแอปพลิเคชันที่จำเป็นเท่านั้นเข้าถึงได้ ที่สำคัญคือให้ตรวจสอบหมายเลขเวอร์ชันของ branch ที่ deploy อยู่จริง อย่าเชื่อเพียงว่า “เพิ่งแพตช์ไปเมื่อเร็วๆ นี้” เพราะรุ่นเดือนพฤษภาคมยังไม่มีการป้องกันครบถ้วน