- Claude Opus 4.6 ค้นพบ ช่องโหว่ 22 รายการ ใน Firefox ผ่านความร่วมมือกับ Mozilla โดยในจำนวนนี้ 14 รายการถูกจัดเป็น ระดับความรุนแรงสูง
- พิสูจน์ให้เห็นว่าโมเดล AI สามารถตรวจจับ ช่องโหว่ซีโร่เดย์ ในซอฟต์แวร์ที่ซับซ้อนได้อย่างรวดเร็ว และมีการรวมการแก้ไขไว้ใน Firefox เวอร์ชัน 148.0
- Claude วิเคราะห์ไฟล์หลายพันไฟล์ในส่วนของโค้ด รวมถึง JavaScript engine และส่ง รายงาน 112 ฉบับ โดย Mozilla นำไปใช้ในการแก้ไข
- ยืนยันว่า AI มีความสามารถ ในการตรวจจับ ช่องโหว่ได้โดดเด่น แต่ความสามารถในการเขียน เอ็กซ์พลอยต์ (โค้ดโจมตี) จริงยังมีข้อจำกัด
- Anthropic นำเสนอ โมเดลความร่วมมือด้านงานวิจัยความปลอดภัยที่ขับเคลื่อนด้วย AI และเรียกร้องให้เสริมความปลอดภัยแบบ ยึดผู้ป้องกันเป็นศูนย์กลาง ผ่านความร่วมมือกับระบบนิเวศโอเพนซอร์ส
ภาพรวมความร่วมมือกับ Mozilla
- Claude Opus 4.6 ค้นพบ ช่องโหว่ใน Firefox 22 รายการ จากการวิเคราะห์ตลอด 2 สัปดาห์ โดย Mozilla จัดให้ 14 รายการเป็นความเสี่ยงสูง
- คิดเป็นราว 20% ของช่องโหว่ความเสี่ยงสูงที่ได้รับการแก้ไขใน Firefox ระหว่างปี 2025
- การแก้ไขถูกบรรจุใน Firefox 148.0 และเผยแพร่ไปยังผู้ใช้หลายร้อยล้านคน
- Mozilla ตรวจสอบรายงานจาก Anthropic พร้อมแบ่งปัน เกณฑ์และกระบวนการของ bug report เพื่อสร้างระบบการตรวจสอบร่วมกัน
- ความร่วมมือนี้ถูกยกเป็นตัวอย่างของ โมเดลการทำงานร่วมกันระหว่างนักวิจัยความปลอดภัยที่ใช้ AI กับผู้ดูแลรักษาโครงการ
กระบวนการตรวจจับช่องโหว่ด้วยโมเดล AI
- Anthropic สร้าง ชุดข้อมูล Firefox CVE เพื่อใช้ทดสอบในสภาพแวดล้อมจริงที่ก้าวข้ามเบนช์มาร์ก CyberGym
- Firefox เป็นโครงการโอเพนซอร์สที่มีความซับซ้อนและมีความปลอดภัยสูง จึงเหมาะสำหรับตรวจสอบความสามารถในการค้นหาของ AI
- Claude ทำการจำลอง CVE ในอดีตก่อน จากนั้นจึงท้าทายตัวเองด้วยการค้นหา ช่องโหว่ใหม่ในเวอร์ชันล่าสุด
- ภายใน 20 นาทีแรกก็พบ ช่องโหว่หน่วยความจำแบบ Use After Free และหลังการตรวจสอบแบบอิสระจึงรายงานให้ Mozilla
- จากนั้น Claude วิเคราะห์ ไฟล์ C++ กว่า 6,000 ไฟล์ และส่ง รายงานที่ไม่ซ้ำกัน 112 ฉบับ
- ปัญหาส่วนใหญ่ได้รับการแก้ไขใน Firefox 148 และบางส่วนมีแผนแก้ในเวอร์ชันถัดไป
การทดลองทำเอ็กซ์พลอยต์ช่องโหว่
- เพื่อประเมิน ขีดจำกัดสูงสุดของความสามารถด้านความปลอดภัย ของ Claude จึงมีการทดลองว่าสามารถเปลี่ยนช่องโหว่ที่ค้นพบให้เป็น โค้ดโจมตีจริง ได้หรือไม่
- ใช้การทดสอบหลายร้อยครั้งและมีค่าใช้จ่าย API ราว 4,000 ดอลลาร์
- ผลลัพธ์คือมีเพียง 2 กรณี ที่เอ็กซ์พลอยต์สำเร็จจริง แสดงให้เห็นว่าความสามารถในการสร้างการโจมตียังต่ำกว่าความสามารถในการตรวจจับ
- เอ็กซ์พลอยต์ที่สำเร็จนั้น ทำงานได้เฉพาะในสภาพแวดล้อมทดสอบ ซึ่งมีการถอด ฟีเจอร์ความปลอดภัยแบบ sandbox ของเบราว์เซอร์ออก
- ระบบป้องกันหลายชั้นของ Firefox สามารถช่วยบรรเทาการโจมตีลักษณะนี้ได้
- Anthropic ใช้การทดลองนี้เพื่อเตือนถึง ความเป็นไปได้ที่ AI จะสร้างเครื่องมือโจมตีได้แบบอัตโนมัติ
แนวปฏิบัติที่ดีสำหรับงานวิจัยความปลอดภัยที่ขับเคลื่อนด้วย AI
- Anthropic พัฒนาวิธีให้ LLM สามารถแก้ไขและตรวจสอบบั๊กได้ ผ่านงานวิจัยเรื่อง patching agent
- ใช้เครื่องมือเสริมชื่อ Task verifier เพื่อตรวจสอบผลลัพธ์ของ AI แบบเรียลไทม์
- ทดสอบอัตโนมัติว่าช่องโหว่ถูกกำจัดแล้วหรือไม่ และฟังก์ชันของโปรแกรมยังคงทำงานปกติหรือไม่
- องค์ประกอบสำคัญ 3 อย่างของรายงานที่ Mozilla เชื่อถือมีดังนี้
- เคสทดสอบสำหรับทำซ้ำปัญหาในระดับขั้นต่ำ
- Proof-of-Concept ที่มีรายละเอียด
- โค้ดแพตช์ ที่เป็นไปได้
- มีการแนะนำให้นักวิจัยแนบ หลักฐานด้านการตรวจสอบได้และการทำซ้ำได้ มาพร้อมกับรายงานช่องโหว่ที่อิง LLM
แนวโน้มต่อจากนี้และความจำเป็นในการยกระดับความปลอดภัย
- Claude Opus 4.6 ค้นพบช่องโหว่ได้ไม่เพียงใน Firefox แต่ยังรวมถึง โครงการหลักอย่าง Linux kernel
- ปัจจุบัน AI มี ความสามารถด้านการตรวจจับและการแก้ไข ที่เหนือกว่า ความสามารถในการสร้างเอ็กซ์พลอยต์ ซึ่งเป็นสถานการณ์ที่เอื้อต่อฝ่ายป้องกัน
- อย่างไรก็ตาม เมื่อพิจารณาจากความเร็วในการพัฒนาโมเดล ก็มี ความเป็นไปได้ที่ช่องว่างด้านความสามารถในการโจมตีจะลดลงอย่างรวดเร็ว
- Anthropic กำลังเปิดให้บริการความสามารถด้านการตรวจจับช่องโหว่และการแพตช์แก่ผู้วิจัยและผู้ดูแลรักษา ผ่าน Claude Code Security
- บริษัทเรียกร้องให้นักพัฒนาใช้ประโยชน์จาก ช่วงเวลาทองของการยกระดับความปลอดภัย โดยมีแผน
- ร่วมมือกันค้นหาช่องโหว่
- พัฒนาเครื่องมือจัดหมวดหมู่ bug report
- ขยายความสามารถในการเสนอแพตช์อัตโนมัติ
2 ความคิดเห็น
Mozilla Foundation Security Advisory 2026-13
นี่สุดยอดมากจริง ๆ
ดูเหมือนเป็นอีกกรณีหนึ่งที่ย้ำเตือนอีกครั้งว่าชุดทดสอบที่เข้มงวดสำคัญมากแค่ไหน
ความคิดเห็นจาก Hacker News
ถ้าคุณเป็นคนรับผิดชอบ การดูแลความปลอดภัย ของโปรเจกต์โอเพนซอร์ส ก็แนะนำให้ลองขอให้ Claude Code ช่วยทำ security audit
สำหรับโปรเจกต์ขนาดใหญ่อย่าง Firefox อาจจะยาก แต่โปรเจกต์ส่วนใหญ่มีค่าโทเคนราว 3 ดอลลาร์เท่านั้น
มีความเป็นไปได้สูงว่าฝั่งผู้โจมตีก็ทำการตรวจสอบแบบนี้กันไปแล้ว ดังนั้นการไม่ทำเองจึงไม่ใช่ท่าทีที่รับผิดชอบอีกต่อไป
ตอนตรวจสอบโค้ดหลักของ Zulip นั้น ได้ขอให้โมเดล ทบทวนผลลัพธ์ของตัวเอง สำหรับแต่ละรายการ ซึ่งช่วยตัด false positive ออกไปได้เกือบทั้งหมด
หลังจากนั้นปัญหาที่เหลือก็แทบหายไปในการตรวจสอบรอบถัดมา ด้วยการเพิ่มคอมเมนต์ในโค้ดเพื่ออธิบายเจตนาของโมเดลด้านความปลอดภัยให้ชัดเจน
การขอให้มัน “ทำงานที่ปกติต้องใช้เวลาหนึ่งสัปดาห์ให้เสร็จในไม่กี่วินาที” เป็นเรื่องที่เป็นไปไม่ได้ในทางปฏิบัติ
ผลลัพธ์อาจดูน่าเชื่อถือ แต่ความจริงอาจไม่ใช่แบบนั้น
ถ้ามอง AI เป็นเหมือน เด็กฝึกงาน ก็จะไม่ผิดหวัง — คุณจะมอบหมายให้เด็กฝึกงานตรวจสอบความปลอดภัยของโปรแกรมขนาดมหึมาทั้งหมดหรือ?
บางกรณีมันทำงานได้ดีมาก แต่บางกรณีก็แทบไร้ประโยชน์โดยสิ้นเชิง
ความต่างดูเหมือนจะขึ้นอยู่กับคุณภาพของ context engineering และ test harness เป็นหลัก
กรณีนี้ก็น่าสนใจ แต่ถ้ามีคำอธิบายที่เจาะจงกว่านี้ก็คงดี
ผมเองก็เพิ่งเปิดซอร์สโปรเจกต์ล่าสุดเหมือนกัน แล้วมีผู้ใช้ Reddit เอา Claude ไปรัน security audit ทั้งชุดจนเจอ ช่องโหว่ 15 จุด
ทั้ง FTS injection, LIKE wildcard injection, การขาดการยืนยันตัวตนของ API, การขาดการคุ้มครองความเป็นส่วนตัว และอีกหลายอย่างที่ผมพลาดไป
สิ่งที่น่าทึ่งคือผลลัพธ์มีความ เป็นระบบมาก — มีทั้งการจัดระดับความรุนแรง ระบุพาธไฟล์กับเลขบรรทัด และชี้ให้เห็นความไม่ตรงกันระหว่างเอกสารกับโค้ดจริง
โดยเฉพาะการวิเคราะห์ “ช่องว่างระหว่างสเปกกับของจริง” ที่มีประโยชน์ที่สุด
คุณค่าที่แท้จริงของ LLM ในการตรวจสอบความปลอดภัย ไม่ใช่การหา zero-day ใหม่ ๆ แต่คือการช่วยทำงานตรวจเช็กซ้ำ ๆ รายละเอียดเยอะ ๆ ที่มนุษย์มักขี้เกียจทำ
มีไม่กี่คนที่เข้าใจ ความซับซ้อน ของปัญหาช่องโหว่ในเบราว์เซอร์อย่าง Firefox
แค่ยกระดับ UAF ธรรมดาให้กลายเป็น wasm shellcode ก็ใช้เวลาหลายวันแล้ว
การแข่งขันด้านขีดความสามารถไซเบอร์ของ AI ยังดู เงียบ ๆ อยู่ตอนนี้ แต่คิดว่าน่าจะเปลี่ยนไปภายในปีนี้
ผมเองก็เคยลองแบบ Anthropic คือให้ Claude มีทั้ง VM และ verifier แล้วขอให้มัน สร้าง exploit ซึ่งในสภาพแวดล้อม kctf-eval มันทำได้ค่อนข้างดี
แต่ก็ยังไม่ชัดว่าโมเดล “เข้าใจ” สิ่งที่ทำจริง ๆ หรือแค่ เลียนแบบตามสัญญาณรางวัล เท่านั้น
น่าสนใจที่ Mozilla อัปเดต ประกาศด้านความปลอดภัย
ก่อนหน้านี้สงสัยว่าคนที่เจอช่องโหว่ 22 จุดในรีลีสเดียวคือใคร ตอนนี้เพิ่งรู้
ถ้าแค่ระดับทำให้ไฟล์หล่นออกมาก็คงไม่ใช่ภัยคุกคามใหญ่ แต่ถ้าเป็นอย่าง การขโมยข้อมูลเซสชัน แบบนั้นน่าสนใจกว่ามาก
แปลกดีที่ไม่มีการพูดถึงรายละเอียดของบั๊ก
อยากรู้ว่าเป็นแค่ edge case ธรรมดา หรือเป็นปัญหาที่มีนัยสำคัญจริง
LLM เก่งในการหาพวก รูปแบบความล้มเหลว ที่คุ้นเคย แต่ไม่ได้แปลว่าสิ่งนั้นสำคัญเสมอไป
ผมไม่ใช่ผู้เชี่ยวชาญด้านความปลอดภัย แต่ก็ดูไม่ใช่เรื่องที่จะปัดตกด้วยคำว่า “ก็แค่ LLM” ได้
ประสบการณ์ที่ได้จากการใช้ AI agent นั้น ปะปนกันไป
มันมีประโยชน์ในการขยาย test coverage, ตั้งค่า fuzz test และเซ็ตเครื่องมือ static analysis
แต่บางครั้งมันก็ฟันธงว่า “ปลอดภัยมาก” ทั้งที่จริงแล้วไม่มีขอบเขตความปลอดภัยอยู่จริง
มันจับ บั๊กเฉพาะจุด ได้ดี แต่แทบจับช่องโหว่เชิงประกอบที่เกิดจากหลายฟีเจอร์ทำงานร่วมกันไม่ได้
สุดท้ายแล้ว คำกล่าวอ้างเรื่องความปลอดภัย ของโมเดลก็ยังต้องตรวจสอบเสมอ
คุณค่าของวิธีนี้อยู่ที่มันให้ test case ที่ตรวจสอบได้
ซึ่งมีประสิทธิภาพกว่ารายงานวิเคราะห์ธรรมดามาก
เมื่อก่อนคำพูดที่ว่า “จับได้แค่บั๊กเฉพาะจุด” นั้นถูกต้อง แต่สถานการณ์เปลี่ยนไปแล้วเพราะ agentic SDK
ถ้า coverage สูงอยู่แล้ว ส่วนที่เหลือก็มักเป็นพื้นที่ที่ยากโดยเนื้อแท้
โดยเฉพาะบางครั้งสามารถจับได้ถึง ช่องโหว่ใน business logic
บั๊กเฉพาะจุดมักมองเห็นง่าย แต่ขอบเขตความปลอดภัยที่ไม่สมบูรณ์มักดูเหมือนเพียงพอในตอนแรก
เหตุผลที่ Anthropic เลือก Firefox นั้นชัดเจน
เพราะมันเป็นโอเพนซอร์สที่ถูกใช้งานอย่างแพร่หลาย และเป็น โปรเจกต์ที่มีการตรวจสอบความปลอดภัยอย่างเข้มข้น
Chromium ใช้ Gemini ของ Google ส่วน Safari มีวัฒนธรรมการพัฒนาแบบปิด จึงร่วมมือได้ยากกว่า
ตามบทความของ Anthropic exploit ที่ Claude เขียนขึ้นใช้งานได้เฉพาะใน สภาพแวดล้อมทดสอบ เท่านั้น
เพราะมีการเอาฟังก์ชัน sandbox ของเบราว์เซอร์จริงออกไป
ดังนั้น การป้องกันหลายชั้น (defense in depth) ของ Firefox น่าจะช่วยบรรเทาการโจมตีแบบนี้ได้
Chrome ก็ใช้นโยบายคล้ายกัน
ดูเอกสารที่เกี่ยวข้องได้ที่ Security Severity Ratings
เพราะ การหนีออกจาก sandbox ก็ยังเป็นไปได้ ดังนั้นทุกบั๊กต้องได้รับการแก้ไข
เพราะผู้โจมตีสามารถสะสม partial zero-day แบบนี้ไว้แล้วนำมาประกอบกันใช้ได้
การแก้ครั้งนี้จึงเป็น ความก้าวหน้าด้านความปลอดภัย อย่างชัดเจนในการลดความเสี่ยงดังกล่าว
ผมเองก็ปล่อย AI agent ทำงานข้ามคืนเพื่อเขียนเทสต์ และเคยลองให้ Claude ทำ formal verification ด้วย
ดูเหมือน Anthropic จะใช้แนวทางคล้ายกัน
ต่อไปก็มีแผนจะเพิ่มพรอมป์ต์สำหรับทำ property testing และ fuzz testing แบบอัตโนมัติ
ผมคิดว่าปัญหาที่ตัวเองดูแลอยู่ไม่จำเป็นต้องใช้ของหนักระดับนั้น แต่อาจจะตัดสินใจผิดก็ได้
สักวันน่าจะมีระบบตรวจสอบความปลอดภัยอัตโนมัติสำหรับโปรเจกต์โอเพนซอร์สสำคัญ ๆ แบบเดียวกับ OSS-Fuzz ของ Google
ตอนนี้ Anthropic ก็เปิดให้ผู้ดูแล OSS เข้าถึง Claude ได้ฟรีอยู่แล้ว
LLM ทำให้โปรแกรม bug bounty มีปัญหา รายงานมั่วจำนวนมาก ล้นเข้ามา แต่โมเดลรุ่นใหม่ ๆ ตอนนี้เริ่มแยก ช่องโหว่จริง ได้ในระดับที่ใช้งานได้แล้ว
ถ้าไปประเมินด้วยโมเดลฟรีหรือรุ่นราคาถูก คุณภาพก็ย่อมดูต่ำเป็นธรรมดา
แต่ถ้าเปิด โปรแกรม security audit ที่ใช้ LLM ระดับสูง ก็พอจะรับประกันคุณภาพได้
ถ้าอยากกู้ระบบ bug bounty ก็อาจต้องใช้วิธี เก็บค่าสมัครเข้าร่วม หรือเพิ่มการตรวจสอบด้วย LLM
ลิงก์ที่เกี่ยวข้อง
เช่น สั่งเปิด VM แล้วให้ agent ทำ การทดสอบเพื่อยืนยันการทำซ้ำ