Redis เผยแพร่คำเตือนความปลอดภัยถึงช่องโหว่ CVE-2025-49844 ซึ่งเกิดจากบั๊ก “use-after-free” ในเครื่องยนต์ Lua ทำให้สคริปต์ที่ออกแบบมาเฉพาะสามารถหลุดออกจาก sandbox และรันโค้ดบนโฮสต์ได้ ผู้โจมตีที่มีสิทธิ์รันสคริปต์ใน Redis จะสามารถเปิด reverse shell ขยายสิทธิ์ ขโมยคีย์ SSH/โทเคน/ใบรับรอง และเคลื่อนที่ด้านข้างในระบบได้ ผลกระทบครอบคลุม Redis ทุกสายที่รองรับ Lua โดยเวอร์ชันที่อ่อนไหวคือ ≤ 8.2.1 และได้รับการแก้ไขแล้วใน 8.2.2 (ประกาศทาง NVD ระบุชัดเจน รวมถึงทางเลือกชั่วคราวคือ “ห้ามรัน Lua” โดยปิด EVAL/EVALSHA) ในขณะที่ Redis ออก release notes ยืนยันว่า 8.2.2 เป็นอัปเดตด้านความปลอดภัยเร่งด่วน (SECURITY update) สำหรับช่องโหว่นี้และบั๊ก Lua อื่น ๆ ที่เกี่ยวข้องด้วย และ Redis Cloud ได้แพตช์ฝั่งผู้ให้บริการให้ลูกค้าแล้วตั้งแต่ต้นเดือน ต.ค. 2025
งานวิจัยของ Wiz อธิบายลำดับการโจมตี (RediShell) ว่าผู้โจมตีส่ง Lua script ที่เจาะจงเพื่อจัดการ garbage collector ให้เกิด use-after-free แล้วหลุด sandbox มาควบคุมเครื่อง พร้อมระบุบริบทความเสี่ยงว่ามีอินสแตนซ์ Redis ที่เปิดสู่สาธารณะจำนวนมาก ทำให้โอกาสถูกโจมตีสูงขึ้น สื่อไอทีบางแหล่งสรุปภาพรวมว่ามีอินสแตนซ์เปิดกว้างนับแสนและหลายหมื่นเครื่องไม่มีการยืนยันตัวตน ยิ่งตอกย้ำความจำเป็นต้องแพตช์และปิดสคริปต์ Lua หากยังอัปเดตไม่ได้ทันที
สำหรับผู้ดูแลที่ยังต้องใช้สาย LTS หรือสาขาเก่า มีผู้ให้ข้อมูลสรุปเวอร์ชันที่ “ปลอดภัยแล้ว” ของหลายสาขา เช่น OSS/CE/Stack: 8.2.2 ขึ้นไป, 8.0.4 ขึ้นไป, 7.4.6 ขึ้นไป, 7.2.11 ขึ้นไป และ 6.2.20 ขึ้นไป (ส่วน Enterprise มีหมายเลข build ที่ได้รับการแพตช์แยกต่างหาก) เพื่อให้วางแผนอัปเกรดได้เหมาะกับสภาพแวดล้อมปัจจุบันขององค์กรคุณ
แนวทางแก้ไขแบบ “ทำทันที” (Quick Fix & Hardening)
redis-server --version
redis-cli INFO server | grep redis_version
ถ้าเป็น ≤ 8.2.1 หรือสาขาที่ยังไม่ได้รับแพตช์ ให้จัดลำดับงานอัปเกรดด่วนเป็น 8.2.2 หรือเวอร์ชันที่ทางผู้ผลิตระบุว่าปลอดภัยในสาขานั้น ๆ ตาม release notes/ตารางเวอร์ชันด้านบน
ถ้ายังอัปเดตไม่ได้ทันที ให้ “ปิด Lua ชั่วคราว” ด้วย ACL
redis-cli ACL SETUSER default -EVAL -EVALSHA
redis-cli ACL LIST | grep -i 'eval'
หมายเหตุ: หากใช้เวอร์ชันเก่ามากที่ไม่มี ACL ให้บล็อกคำสั่งผ่าน proxy/WAF หรือลดสิทธิ์ผู้ใช้ที่มี @scripting ทั้งหมดชั่วคราวแทน
จำกัดการเข้าถึงทางเครือข่ายให้เข้มงวด
- เปิด
protected-mode yes, ใช้bind 127.0.0.1หรือระบุเครือข่ายให้ชัดเจน - ปิดพอร์ตสาธารณะด้วยไฟร์วอลล์/SG/NACL, อนุญาตเฉพาะแอป/โหนดที่จำเป็น
- ถ้าอยู่ใน Kubernetes ใช้ NetworkPolicy จำกัด egress/ingress ของ Pod ที่รัน Redis
ตรวจร่องรอยการโจมตี
- ตรวจสถิติคำสั่ง
EVAL/EVALSHAผิดปกติ (INFO commandstats) - ค้นหา process แปลก ๆ ที่รันภายใต้ผู้ใช้
redisและการเชื่อมต่อออกนอก (reverse shell) - ตรวจ log/telemetry ช่วงตั้งแต่ต้น ต.ค. 2025 และก่อนหน้าไม่นาน หากพบ IOC ให้ “rotate” คีย์/โทเคนทั้งหมด
อัปเดตแบบถาวร (แนะนำที่สุด)
- อัปเกรด Redis ตามสาขาที่องค์กรใช้ไปยังรุ่นที่มีแพตช์: OSS/CE/Stack ≥ 8.2.2 (หรือ ≥ 7.4.6/7.2.11/6.2.20 สำหรับสาขาเก่า), Enterprise ตาม build ที่ผู้ผลิตระบุ
- ทดสอบ regression กับงานจริง (สคริปต์ Lua เดิม, replication, persistence, Sentinel/Cluster) ก่อน deploy ผลิตจริง
สถานะความเสี่ยงเพิ่มเติม
NVD ให้คำอธิบายตรงไปตรงมาว่า “แก้ด้วย 8.2.2” และแนวทางชั่วคราวคือป้องกันการรัน Lua ส่วนแหล่งวิจัยเอกชนรายงานไทม์ไลน์การเปิดเผย ตั้งแต่เวที Pwn2Own ถึงประกาศทางการเมื่อ 3 ต.ค. 2025 พร้อมตัวอย่างการโจมตีระดับระบบ (reverse shell) ขณะเดียวกันบางแหล่งระบุว่ามี PoC เผยแพร่ต่อสาธารณะแล้ว ยิ่งทำให้ความเร่งด่วนสูงมากในการแพตช์/ปิด Lua และลดพื้นผิวโจมตีทันที
ที่มา : Redis
