Google เพิ่มค่าหัวบั๊ก Chrome สี่เท่า แต่หลักฐานต้องทำซ้ำได้

Google ประกาศปรับ Chrome VRP เมื่อ 13 ตุลาคม 2026 ให้มีผลทันที โดยเพิ่มฐานรางวัลสำหรับช่องโหว่ memory corruption เป็น 2,000 ดอลลาร์ หรือสี่เท่าจากเดิม เกณฑ์ใหม่แยกเงินรางวัลตามกระบวนการของ Chrome ที่ได้รับผลกระทบ และตามระดับการอ่านหรือเขียนหน่วยความจำที่นักวิจัยสาธิตได้ รายงานที่ทำให้เบราว์เซอร์ล่มจึงอยู่คนละระดับกับรายงานที่พิสูจน์การเขียนหน่วยความจำแบบควบคุมได้

รายงานของ Help Net Security วันที่ 14 ตุลาคม 2026 สรุปการเพิ่มรางวัลครั้งเดียวกัน รวมถึงเพดาน 20,000 ดอลลาร์สำหรับ sandbox escape ที่มีผลกระทบสูงและไม่ได้เกิดจากปัญหา memory safety สำหรับผู้ส่งบั๊ก ประเด็นสำคัญจึงอยู่ที่การแสดงว่าปัญหาเกิดในส่วนใด เข้าถึงได้ด้วยวิธีใด และผลด้านความปลอดภัยเกิดขึ้นซ้ำได้จริงเพียงใด เพดานของหมวดเป็นวงเงินที่อาจได้รับเมื่อเข้าเงื่อนไข ไม่ใช่ยอดจ่ายอัตโนมัติให้ทุกกรณี

กระบวนการและหลักฐานกำหนดเพดานรางวัล

อัตราใหม่ให้ความสำคัญกับตำแหน่งที่บั๊กทำงาน เพราะข้อผิดพลาดในกระบวนการ browser, network หรือ GPU อาจมีผลต่างจากข้อผิดพลาดที่ถูกจำกัดไว้ใน renderer หรือกระบวนการภายใน sandbox อื่น การจัดหมวดต้องดูพฤติกรรมที่ตัวอย่างทดสอบทำให้เกิดขึ้นจริงด้วย ชื่อช่องโหว่เพียงอย่างเดียวจึงยังบอกอัตรารางวัลไม่ได้ รายการต่อไปนี้จับคู่ประเภทปัญหา หลักฐานที่ใช้แยกหมวด กระบวนการที่ได้รับผลกระทบ และเพดานที่ประกาศไว้

• การอ่านหน่วยความจำหรืออาการล่ม: ในกระบวนการ browser, network และ GPU เพดานอยู่ที่ 4,000 ดอลลาร์ หลักฐานต้องทำให้เกิดปัญหาในกระบวนการเป้าหมายและช่วยระบุตำแหน่งข้อผิดพลาดได้ อาการล่มแสดงว่ามีความผิดปกติ แต่ยังไม่แสดงว่าผู้โจมตีเลือกข้อมูลที่จะอ่านหรือเลือกตำแหน่งที่จะเขียนได้
• การเขียนหน่วยความจำหรือ use-after-free: ในกระบวนการ browser, network และ GPU เพดานอยู่ที่ 10,000 ดอลลาร์ รายงานต้องแสดงข้อผิดพลาดที่เกิดซ้ำได้และหลักฐานว่าการเข้าถึงหน่วยความจำเข้าหมวดนี้ use-after-free หมายถึงการใช้พื้นที่หน่วยความจำหลังโปรแกรมปล่อยพื้นที่นั้นแล้ว ซึ่งอาจมีผลต่างกันตามสภาพแวดล้อมที่กระตุ้นบั๊ก
• Controlled read: ในกระบวนการ browser, network และ GPU เพดานอยู่ที่ 10,000 ดอลลาร์ เงื่อนไขที่เพิ่มจากรายงานการอ่านทั่วไปคือการสาธิตว่าควบคุมการอ่านได้อย่างน่าเชื่อถือด้วยกลไก --vrp-flags ของโครงการ ผลตรวจที่พบการอ่านผิดพลาดอย่างเดียวไม่เพียงพอสำหรับหมวดควบคุมการอ่าน
• Controlled write: ในกระบวนการ browser, network และ GPU เพดานอยู่ที่ 20,000 ดอลลาร์เมื่อแสดงการเขียนที่ควบคุมได้จากเว็บคอนเทนต์ภายใต้เงื่อนไข --vrp-flags รายงานต้องทำให้ผลนั้นเกิดซ้ำได้ใน Chrome รุ่นที่เผยแพร่แล้ว การมีหลักฐานว่าเกิดการเขียนผิดพลาดยังไม่เท่ากับพิสูจน์การควบคุมการเขียน
• Renderer: การอ่านหรืออาการล่มอยู่ที่ 3,000 ดอลลาร์ ส่วนการเขียนหรือ use-after-free อยู่ที่ 8,000 ดอลลาร์ หมวด V8 logic กำหนด 4,000 ดอลลาร์ และปัญหา V8 sandbox กำหนดอัตราคงที่ 5,000 ดอลลาร์ รายงานต้องแสดงพฤติกรรมให้ตรงกับหมวด V8 ที่อ้าง ไม่ควรนำตัวเลขของกระบวนการ browser ไปใช้กับบั๊กที่อยู่ใน renderer
• กระบวนการอื่นภายใน sandbox: การอ่านหรืออาการล่มอยู่ที่ 2,000 ดอลลาร์ ส่วนการเขียนหรือ use-after-free อยู่ที่ 3,000 ดอลลาร์ หลักฐานควรระบุชื่อกระบวนการที่เกิดปัญหาและวิธีกระตุ้นให้ชัด เพื่อให้แยกจาก renderer และจากกระบวนการที่มีสิทธิ์สูงกว่าได้
• Sandbox escape ที่ไม่ใช่ปัญหา memory safety: กรณีที่มีผลกระทบสูงมีเพดาน 20,000 ดอลลาร์ สิ่งที่ต้องพิสูจน์คือการข้ามขอบเขตความปลอดภัยของ sandbox และผลที่เกิดจากการข้ามขอบเขตนั้น หมวดนี้พิจารณาผลของการหลุดออกจากข้อจำกัด ไม่ได้อาศัยเพียงชื่อเทคนิคหรืออาการล่ม
• ปัญหาที่ไม่ใช่ memory safety และมีความรุนแรงระดับปานกลาง: อัตราคงที่คือ 2,000 ดอลลาร์เมื่อรายงานมีวิธีแก้ไข หรือข้อมูลในรายงานนำไปสู่การระบุวิธีแก้ไขโดยตรง เงื่อนไขเรื่องวิธีแก้ไขทำให้รายงานหมวดนี้ต่างจากการเสนอความเป็นไปได้ที่ยังตรวจสอบผลกระทบไม่ได้

คำว่าเพดานมีผลมากที่สุดในหมวดที่ต้องพิสูจน์การควบคุมเพิ่มเติม บั๊กต้นเหตุเดียวกันอาจมีหลักฐานเพียงพอสำหรับอัตราของการล่มหรือการเขียนทั่วไป แต่ยังไม่ผ่านเกณฑ์ controlled write ความต่างนี้ไม่ได้ตัดสินจากความซับซ้อนที่ผู้วิจัยคาดว่าบั๊กอาจพัฒนาไปถึงได้ หากผลที่ยื่นยังทำซ้ำไม่ได้ ระดับรางวัลก็ต้องอิงผลที่ตรวจสอบได้

Memory corruption, controlled write และ sandbox escape วัดคนละผล

Memory corruption เป็นกลุ่มข้อผิดพลาดที่โปรแกรมจัดการหน่วยความจำผิดไปจากที่ควร เช่น อ่านข้อมูลนอกขอบเขต เขียนข้อมูลผิดตำแหน่ง หรือใช้พื้นที่ที่ถูกปล่อยแล้ว ผลเบื้องต้นอาจปรากฏเป็นการล่มพร้อมรายงานจากเครื่องมือตรวจหน่วยความจำ หลักฐานลักษณะนี้มีค่าต่อการระบุและแก้บั๊ก แต่ไม่ได้แปลโดยตัวมันเองว่าผู้โจมตีเลือกค่าหรือตำแหน่งของการเข้าถึงหน่วยความจำได้

Controlled write เป็นคำอธิบายผลที่สาธิตได้มากกว่าชื่อของบั๊กต้นเหตุ นักวิจัยต้องแสดงว่าควบคุมการเขียนในกระบวนการเป้าหมายได้อย่างเชื่อถือได้ ไม่ใช่เพียงทำให้เครื่องมือตรวจพบการเขียนผิดพลาด สำหรับเพดานสูงสุดของกระบวนการ browser, network และ GPU การสาธิตต้องเริ่มจากเว็บคอนเทนต์ จึงต้องเชื่อมเส้นทางจากสิ่งที่หน้าเว็บกระตุ้นไปถึงผลที่เกิดในกระบวนการนั้นให้ครบ

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

ความต่างระหว่างสามคำนี้ช่วยอ่านตารางรางวัลได้ตรงขึ้น memory corruption บอกลักษณะข้อผิดพลาด controlled write บอกระดับการควบคุมที่พิสูจน์ได้ ส่วน sandbox escape บอกผลต่อขอบเขตความปลอดภัย รายงานหนึ่งฉบับอาจเกี่ยวข้องกับหลายแนวคิด แต่การขอพิจารณาอัตราใดต้องมีหลักฐานรองรับผลของหมวดนั้นโดยเฉพาะ การคาดการณ์ว่าบั๊กอาจนำไปต่อยอดได้ยังไม่ใช่การสาธิตผลที่โครงการให้รางวัลในหมวดสูงกว่า

รายงานแรกต้องทำให้ทีม Chrome เกิดผลซ้ำได้

คู่มือรายงาน Chrome VRP ของ Chromium กำหนดให้ส่งผ่าน Google Bug Hunters โดยเลือก Chrome VRP พร้อมระบุรุ่น Chrome ระบบปฏิบัติการ ช่องทางเผยแพร่ที่พบปัญหา และขั้นตอนทำซ้ำที่สั้นและเรียงลำดับชัดเจน ไฟล์ proof of concept ควรแนบกับรายงานโดยตรงและลดเหลือส่วนที่จำเป็นต่อการกระตุ้นบั๊ก การให้เพียงลิงก์ไปยังเว็บที่โฮสต์ตัวอย่างไว้ไม่ตรงกับแนวทางรับรายงาน

สำหรับปัญหาหน่วยความจำ ผล ASAN ควรมีสัญลักษณ์ครบและข้อมูลเพิ่มเติมที่ช่วยชี้ว่าปัญหาเกิดตรงไหน ข้อมูลนี้ทำให้ทีมตรวจสอบแยกข้อผิดพลาดที่กระทบ Chrome ออกจากการล่มที่อธิบายไม่ได้ รายงานที่มีเพียงไฟล์ทดสอบขนาดใหญ่โดยไม่ลดขนาด หรือมีเพียง crash dump โดยไม่มีตัวอย่างกระตุ้นปัญหา อาจไม่เพียงพอให้ตรวจสอบได้ ข้อกล่าวอ้างจากการอ่านโค้ดอย่างเดียวก็ยังต้องมีหลักฐานว่าปัญหาแสดงผลใน Chrome จริง

ผู้ที่ยื่นหมวด controlled read หรือ controlled write ต้องแนบไฟล์ vrp-flag.json ซึ่งบอกชนิดผลที่ต้องการสาธิต กระบวนการเป้าหมาย รุ่น Chrome ระบบปฏิบัติการ สถาปัตยกรรม และคำสั่งที่จำเป็น คู่กันนั้นต้องมีตัวอย่างขนาดเล็กที่ทำให้ ASAN ตรวจพบบั๊ก และตัวอย่างอีกชุดที่แสดงการควบคุมการอ่านหรือเขียน หากตัวอย่างควบคุมผลทำซ้ำไม่ได้ แต่ตัวอย่าง ASAN ยังแสดงข้อผิดพลาด รายงานอาจได้รับการประเมินตามอัตราปกติของบั๊กนั้น

หลักฐาน controlled read หรือ controlled write ต้องมากับรายงานแรก เพราะโครงการไม่พิจารณาตัวอย่างที่เติมภายหลังเพื่อขอหมวดดังกล่าว เงื่อนไขนี้เฉพาะเจาะจงกว่าการส่ง exploit ที่ทำงานได้ในภายหลัง ซึ่ง FAQ เปิดช่องให้พิจารณาแยกต่างหาก ผู้วิจัยจึงต้องตัดสินใจให้ชัดตั้งแต่ยื่นว่ากำลังรายงานบั๊กพื้นฐานหรืออ้างผลการควบคุมที่ทดสอบซ้ำได้แล้ว การเปิดรายการเปล่าไว้ก่อนเพื่อรักษาเวลาไม่ช่วยให้รายงานกลายเป็นรายการที่ดำเนินการได้

ตัวอย่าง controlled read หรือ controlled write ต้องมุ่งที่ Chrome ช่องทาง Stable, Beta หรือ Dev ซึ่งเผยแพร่แล้ว เงื่อนไขรับตัวอย่างยังจำกัดการใช้แฟล็กสำหรับดีบักหรือแฟล็กที่ลดความปลอดภัย และไม่รับวิธีที่ต้องแก้ renderer ด้วยแพตช์เพื่อสาธิตผล การระบุสภาพแวดล้อมครบจึงสำคัญพอ ๆ กับตัวอย่างทดสอบ เพราะทีมตรวจสอบต้องรู้ว่าผลนั้นเกิดในรุ่นที่ผู้ใช้ได้รับ ไม่ใช่เกิดเฉพาะในเครื่องทดลองที่ปรับแต่งไว้

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

อัตราใหม่ครอบคลุมรายงานค้างประเมินบางส่วน

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

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

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