ปล่อยอัปเดตช่องโหว่ซีโร่เดย์ของ CSS สำหรับ Chrome เวอร์ชัน Windows/Mac

 (chromereleases.googleblog.com)
3 คะแนน โดย GN⁺ 2026-02-20 | 2 ความคิดเห็น | แชร์ทาง WhatsApp
  • Google ออกรุ่นอัปเดต Stable Channel ของ Chrome เวอร์ชันเดสก์ท็อป ซึ่งรวม ช่องโหว่ซีโร่เดย์ที่เกี่ยวข้องกับ CSS ที่ระบุเป็น CVE-2026-2441
  • Google ยืนยันว่าช่องโหว่นี้ กำลังถูกนำไปใช้โจมตีจริง (in the wild) และผู้ใช้ควร อัปเดตเป็นเวอร์ชันล่าสุดทันที เพื่อลดความเสี่ยงด้านความปลอดภัย
  • ขณะนี้อัปเดตกำลังทยอยปล่อยให้ Chrome บน Windows, macOS และ Linux

ภาพรวมอัปเดตช่องเสถียรของ Chrome

  • Google ประกาศอัปเดต Stable Channel ของ Chrome สำหรับเดสก์ท็อป
    • Windows/macOS เป็น 145.0.7632.75/76, Linux เป็น 144.0.7559.75
    • อัปเดตถูกปล่อยสำหรับแพลตฟอร์ม Windows, macOS และ Linux
    • มีกำหนดทยอยติดตั้งผ่านการอัปเดตอัตโนมัติ

ช่องโหว่ความปลอดภัย CVE-2026-2441

  • เวอร์ชันนี้มีช่องโหว่ความปลอดภัยที่กำหนดเป็น CVE-2026-2441
    • ยืนยันแล้วว่าเป็น ช่องโหว่ซีโร่เดย์ที่เกิดขึ้นในกระบวนการประมวลผล CSS
    • Google ระบุชัดว่าช่องโหว่นี้ กำลังถูกนำไปใช้โจมตีจริง

คำแนะนำสำหรับผู้ใช้

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

การปล่อยอัปเดตและการสนับสนุน

  • อัปเดตนี้ ทยอยปล่อยเป็นขั้นผ่าน Stable Channel
    • ผู้ใช้บางรายอาจต้องใช้เวลาสักระยะกว่าจะได้รับอัปเดต
  • ทีม Chrome ยังคงดำเนินการปรับปรุงความปลอดภัยเพิ่มเติมและเพิ่มเสถียรภาพอย่างต่อเนื่อง

บทความที่เกี่ยวข้อง

2 ความคิดเห็น

 
xguru 2026-02-20

อัปเดตแล้ว แต่ฝั่ง Mac ไปถึงเวอร์ชัน 145.0.7632.110 แล้วนะ

เป็นช่องโหว่ที่ระหว่างจัดการฟอนต์ภายใน CSS เกิด Use-After-Free จากการใช้แอดเดรสที่ถูกทำให้ใช้ไม่ได้แล้วซ้ำต่อไป จนสามารถยึดระบบได้ ดังนั้นแค่เปิดเว็บไซต์ก็โดนได้เลย แถมยังมีรายงานว่ามีการนำช่องโหว่นี้ไปใช้โจมตีจริงแล้วด้วย
 
GN⁺ 2026-02-20
ความคิดเห็นจาก Hacker News

  • พบ ช่องโหว่ use-after-free ใน CSS ของ Google Chromium
    เป็นปัญหาที่ผู้โจมตีระยะไกลสามารถทำให้ heap เสียหายได้ผ่านหน้า HTML อันตราย และอาจกระทบไม่ใช่แค่ Chrome แต่รวมถึงเบราว์เซอร์ที่อิง Chromium อย่าง Edge, Opera เป็นต้น
    ดูเป็นปัญหาที่ค่อนข้างร้ายแรง และก็สงสัยว่านักวิจัยได้รับ bug bounty เป็นเงินเท่าไร

    • น่าจะไม่เกิน 20,000 ดอลลาร์
      เมื่อคิดถึงความพยายามที่ต้องใช้ในการหาช่องโหว่ร้ายแรงแบบนี้และสร้าง exploit ที่ทำซ้ำได้ ก็รู้สึกว่าค่าตอบแทนต่ำเกินไป
    • ดูเหมือนว่า Firefox จะไม่ได้รับผลกระทบ
    • แอป Electron ก็น่าจะได้รับผลกระทบด้วย
      เพราะส่วนใหญ่จะตรึงเวอร์ชัน Chrome เอาไว้ (pinning)
    • ถ้าจะให้เป็นการโจมตีที่มีความหมายจริง ๆ ต้องมี sandbox escape ด้วย
      แต่คำว่า “พบในภาคสนาม” อาจหมายความว่ามีห่วงโซ่การโจมตีที่รวม sandbox escape อยู่แล้วก็ได้
    • คิดว่าบรรยากาศที่ยังมอง use-after-free เป็นเรื่องเล็กคือปัญหา
      การที่ภาษาระดับระบบในศตวรรษที่ 21 ยังจัดการบั๊กแบบนี้ไม่ได้เป็นเรื่องน่าอับอาย

  • ดูเหมือนว่าใน มุมมืดของโค้ดเบส Chromium/Blink ยังน่าจะมีบั๊กลักษณะนี้ซ่อนอยู่อีก
    สำหรับโปรเจ็กต์แกนหลักแบบนี้ควรมีบุคลากรเฉพาะทางคอยตรวจสอบโค้ดทั้งชุดอย่างต่อเนื่อง
    คิดว่าการลงทุนด้านความปลอดภัยแบบนี้คุ้มค่ากว่าฟีเจอร์อย่างการเชื่อมต่อกับตู้เย็นอัจฉริยะมาก

    • Chromium ทำ fuzzing แบบเข้มข้น อยู่แล้ว
      ถ้าเป็น fuzzer ที่ทรงพอ ก็มองว่าแทบไม่มีส่วนไหนที่เข้าไม่ถึง

  • คำว่า “Use after free in CSS” ฟังดูตลกนิด ๆ

    • น่าจะหมายถึงฝั่ง CSS parser หรือ CSSOM มากกว่า
    • เลยสงสัยว่าทำไมถึงใช้คำแบบนั้น

  • ยังไม่ค่อยเข้าใจว่าช่องโหว่นี้ส่งผลอะไรได้จริงบ้าง
    ถ้าไม่มีการหลุดออกจากแซนด์บ็อกซ์หรือ XSS ก็ดูแทบไม่มีพิษภัย แต่จาก โค้ด PoC ระบุว่าสามารถโจมตีได้หลายแบบ เช่น
    การรันโค้ดตามอำเภอใจภายในโปรเซส renderer, การรั่วไหลของข้อมูล, การขโมยคุกกี้และเซสชัน, การดัดแปลง DOM, การดักพิมพ์แป้นพิมพ์ เป็นต้น

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

  • น่าประหลาดใจที่ยังมีช่องโหว่หน่วยความจำแบบนี้ออกมาอยู่
    เลยสงสัยว่าไม่มีเครื่องมือสำหรับสร้าง ไบนารีที่ผ่านการตรวจสอบแล้ว แบบภาษาที่ปลอดภัยต่อหน่วยความจำหรือ
    ตอนนี้ CSS ก็ซับซ้อนขึ้นจากการมีตัวแปร, สโคป, และฟีเจอร์แนว preprocessor เพิ่มขึ้นเรื่อย ๆ จนทำให้อาจต้องมีส่วนขยายแบบ “no-style” คล้าย “no-script” ด้วย
    ก็เลยสงสัยว่ารายงานครั้งนี้เป็นแค่ความผิดพลาดธรรมดา หรือเป็นห่วงโซ่การโจมตีหลายขั้นตอน

    • ไม่ใช่ว่าไม่มีเครื่องมือพวกนั้น แต่ Chromium ก็ใช้ sanitizer และ fuzzing ทุกอย่างที่เป็นไปได้อยู่แล้ว
      ปัญหาคือ test coverage โค้ดเบสมีขนาดใหญ่มากจนยากจะครอบคลุมได้สมบูรณ์ และช่องโหว่แบบนี้ก็เกิดขึ้นตามช่องว่างนั้น
    • “no-style” ใช้จริงแทบเป็นไปไม่ได้
      CSS เป็นแกนหลักของเว็บ ถ้าถอดออกเว็บไซต์ส่วนใหญ่ก็แทบพังหมด
      ทางเลือกอาจเป็นการรันแบบ isolation
      ถ้าสตรีมเซสชันเบราว์เซอร์จากเซิร์ฟเวอร์ระยะไกล ต่อให้มี zero-day ก็จะกระทบแค่อินสแตนซ์ระยะไกล ไม่ใช่เครื่องโลคัล
      ถึงจะไม่สมบูรณ์แบบ แต่ก็เป็นกลยุทธ์ defense in depth ที่ช่วยลดพื้นที่โจมตีได้

  • ในรายการเครื่องมือความปลอดภัยที่ทีม Chromium ใช้ มีการพูดถึง AddressSanitizer, MemorySanitizer, libFuzzer ฯลฯ แต่ที่น่าสนใจคือไม่มี OSS-Fuzz

    • OSS-Fuzz ไม่ใช่ fuzzer โดยตัวมันเอง แต่เป็นแพลตฟอร์มที่ รวม sanitizer และเอนจิน fuzzing ที่พูดถึงข้างต้นเข้าไว้ด้วยกัน

  • อยากเห็น โค้ด PoC หลังจากแพตช์ถูกปล่อยแล้ว

  • มีมุกว่า Chromium ควร เขียนใหม่ด้วย Rust

    • จริง ๆ แล้วบางส่วนของเอนจิน Blink ก็ถูกเขียนใหม่ด้วย GC-based C++ เพื่อหวังผลคล้ายกัน
    • อีกความเห็นบอกว่าน่าจะเอาเงินไปลงทุนกับ เอนจิน Servo ของ Mozilla มากกว่า

  • ลองค้น CVE แล้วพบว่ามี หน้าประเด็นปัญหา อยู่
    แต่แสดงข้อความว่า “Access is denied”
    ดูเหมือนจะเป็นสถานะแบบปิดที่ต้องล็อกอินก่อนจึงจะเข้าถึงได้