Tencent BrowserSkill ตรวจสอบเพียงว่า ID ของส่วนขยายดูเหมือนของจริงเท่านั้น — ส่วนขยายใดก็สามารถป้อนหน้าที่ถูกปลอมแปลงให้ Agent ได้

เมื่อ 17 กันยายน 2026 ผู้ใช้ GitHub ที่โพสต์ในชื่อ carfeii ได้เปิด issue #273 ต่อโปรเจกต์โอเพนซอร์สของ Tencent ที่ชื่อ BrowserSkill ซึ่งมีข้อกล่าวอ้างแคบ ๆ ว่า: daemon ภายในเครื่องที่เชื่อมต่อส่วนขยายเบราว์เซอร์เข้ากับ AI agent ไม่ได้ตรวจสอบว่าส่วนขยายใดเชื่อมต่ออยู่ โดยตรวจเพียงว่าการเชื่อมต่อดูเหมือนส่วนขยายเท่านั้น สามวันต่อมา ในวันที่ 20 กันยายน VulnCheck ได้เผยแพร่ผลการค้นพบเป็น CVE-2026-94111 โดยอธิบายถึง daemon ที่ "ยอมรับ origin ของ chrome-extension ใดก็ได้ที่มี 32 อักขระในช่วง a-p" และจัดประเภทเป็น CWE-346 (ข้อผิดพลาดในการตรวจสอบ origin) และให้เครดิตแก่ George Chen เอกสารคำแนะนำให้คะแนนเป็น CVSS 4.0 6.9 ระดับปานกลาง โดยผลกระทบต่อความสมบูรณ์ถูกประเมินว่าสูง และผลกระทบต่อความลับและความพร้อมใช้งานต่ำ ไม่มีสิ่งใดในบันทึกที่บ่งชี้ว่าช่องโหว่นี้ถูกใช้งาน: คลังเก็บไม่บันทึกการโจมตีและให้ระดับความเชื่อมั่นของรายการเป็น A โดยมี real_harm เป็น false นี่คือหนึ่งบันทึกใน คลังเหตุการณ์ AI ซึ่งแต่ละรายการมีแหล่งที่มา ระดับความรุนแรง ระดับความเชื่อมั่น และธงข้อโต้แย้งของตัวเอง

การตรวจสอบรูปแบบที่ไม่เคยตรวจสอบตัวตนเลย

โค้ดที่อยู่ตรงกลางของบันทึกนั้นมีขนาดเล็ก ใน crates/bsk-cli/src/daemon/ws.rs ฟังก์ชัน origin_allowed() รับ Origin header ของการจับมือ WebSocket ตัดสตริง chrome-extension:// ออก แล้วคืนค่า true หากสิ่งที่เหลืออยู่มีความยาว 32 ตัวอักษรพอดี และทุกตัวอักษรอยู่ระหว่าง a และ p นั่นคือการทดสอบทั้งหมด มันถูกรันหนึ่งครั้ง ภายใน callback การอัปเกรด HTTP และหากล้มเหลวจะคืนค่า 403 ซึ่งข้อความระบุว่า "Origin not in chrome-extension allow-list" — แม้ว่าเมื่อเผยแพร่แล้วจะไม่มีรายการให้อยู่เลย

รูปแบบนี้ไม่ได้เกิดขึ้นโดยพลการ ID ของส่วนขยาย Manifest V3 ใน Chrome มี 32 อักขระซึ่งมาจากตัวอักษรสิบหกตัวเหล่านั้นพอดี ดังนั้นการตรวจสอบจึงจดจำรูปร่างของ origin ของส่วนขยายจริงได้อย่างถูกต้อง ข้อบกพร่องคือส่วนขยายทุกตัวมีรูปร่างแบบนั้น การตรวจสอบถามว่าผู้เรียกดูเหมือนส่วนขยายเบราว์เซอร์หรือไม่ แต่ไม่เคยถามว่าเป็นส่วนขยายเบราว์เซอร์ของโปรเจกต์นี้หรือไม่ และตัวระบุที่ควรใช้เปรียบเทียบนั้นเป็นข้อมูลสาธารณะอยู่แล้ว: README ของโปรเจกต์ลิงก์ไปยังรายการบน Chrome Web Store ซึ่งมี ID คือ hhcmgoofomhgciiibhipgmgkgnoenaoi และ ID ของ Edge Add-ons ที่อยู่ข้าง ๆ กัน ไม่มีสตริงใดปรากฏอยู่ที่ใดเลยในเกต

เดมอนรับฟังบนพอร์ตโลคอลแบบคงที่ 52800 ซึ่งประกาศเป็น DEFAULT_WS_PORT ใน CLI และถูกใช้โดยไม่มีการเปลี่ยนแปลงในเส้นทางการเชื่อมต่อภายในเครื่อง พอร์ตนี้มีเอกสารระบุไว้ เป็นค่าคงที่ และเข้าถึงได้โดยทุกสิ่งที่มีอยู่แล้วในโปรไฟล์เบราว์เซอร์ของผู้ใช้ ความเป็นโลคอลคือเหตุผลที่เวกเตอร์ของแอดไวซอรีขึ้นต้นด้วย AV:L — ผู้โจมตีจำเป็นต้องมีจุดยึดในเครื่อง และ PR:L บันทึกว่าสิทธิ์ต่ำก็เพียงพอ ส่วนขยายที่ติดตั้งในโปรไฟล์เดียวกันก็เป็นจุดยึดประเภทนั้นพอดี

ที่นั่งมีมูลค่าเท่าไร และมูลค่านั้นได้รับการยืนยันแล้วเพียงใด

ประโยคผลกระทบในคำแนะนำมีความกว้าง: ผู้โจมตีที่ลงทะเบียนส่วนขยายอันเป็นอันตรายเป็นไคลเอนต์เบราว์เซอร์สามารถ "ดักจับและจัดการเนื้อหาหน้าเว็บ, DOM และภาพหน้าจอที่ส่งกลับไปยัง AI agent" นั่นคือคำอธิบายที่ CVE, บันทึกคำแนะนำ GitHub GHSA-x6f2-qp26-2xrh และคลังเก็บทั้งหมดมีอยู่ และอธิบายถึงการให้คะแนนความสมบูรณ์ของ CVSS ในระดับสูง นอกจากนี้ยังเป็นบทสรุปที่เขียนโดยฝ่ายที่กำหนด CVE ไม่ใช่รายงานการโจมตีที่แสดงให้เห็นจริง

เรื่องเล่าที่รอบคอบกว่ามาถึงในสัปดาห์เดียวกัน ในเธรดของ issue นั้นเอง เมื่อ20 กันยายน ผู้แสดงความคิดเห็นที่โพสต์ในชื่อ bb6894 รายงานว่าได้ตรวจโค้ดซ้ำกับ main ที่คอมมิต fa953dc6 (18 กันยายน) และติดตามว่าลูกค้าภายนอกสามารถเข้าถึงอะไรได้จริงหลังแฮนด์เชก วิธีการเครื่องมือขาเข้าส่วนใหญ่ ความคิดเห็นระบุว่า จะคืนค่า UnknownMethod ให้กับเพียร์ WebSocket; คำขอตรวจสอบถูกจำกัดขอบเขตให้อยู่ในบันทึกของไคลเอนต์เอง; และการกระทำข้ามเซสชัน เช่น window_closed, user_interrupt และ update_interaction ถูกป้องกันไว้เมื่อเซสชันเป็นของเบราว์เซอร์อื่น สิ่งที่รอดจากตัวกรองนั้นแคบกว่า และสำหรับเอเจนต์แล้ว อาจแย่กว่าการถูกดักจับ: ส่วนขยายภายนอกสามารถยึดสล็อตเบราว์เซอร์ภายใต้ instance_id ที่ผู้โจมตีเลือก และหากมันเป็นเบราว์เซอร์เดียวที่ลงทะเบียนไว้ — การเริ่มแบบเย็นหรือการรีสตาร์ทเดมอน — มันจะได้รับคำขอเครื่องมือของเอเจนต์และตอบกลับด้วยเนื้อหาหน้าที่กุขึ้น DOM หรือภาพหน้าจอ ผู้แสดงความคิดเห็นเรียกสิ่งนี้ว่า "การปลอมผลลัพธ์ต่อเอเจนต์" และ "ช่องทางเข้าสู่การรับรู้ของเอเจนต์" ผลกระทบที่สองคือ denial of service: เมื่อมีเบราว์เซอร์จริงออนไลน์อยู่ด้วยและไม่มี selector การเริ่มเซสชันอาจล้มเหลวด้วย MultipleBrowsersOnline

ยังไม่มีการแสดงคำอธิบายใด ๆ จากทั้งสองฉบับต่อสาธารณะ ผู้สื่อข่าวระบุถึง proof of concept ว่า “มีให้เมื่อร้องขอ” ไม่มีใครเผยแพร่สักฉบับ และไม่มีการบันทึกการโจมตีใด ๆ ดังนั้นความแตกต่างระหว่างคำอธิบายทั้งสองจึงเป็นความแตกต่างระหว่างการตีความสองแบบของไฟล์ต้นฉบับเดียวกัน ไม่ใช่ความแตกต่างระหว่างทฤษฎีกับ exploit ที่ใช้งานได้ — และบทความรายงานทั้งสองแบบแทนที่จะเลือกข้าง สิ่งที่พูดได้อย่างไม่มีเงื่อนไขคือ หลังแฮนด์เชกไม่เคยมีการตรวจสอบตัวตนครั้งที่สองอีก ดังนั้นไม่ว่าเกตจะยอมให้สิ่งใดผ่านเข้ามา สิ่งนั้นก็ยังคงผ่านเข้ามาต่อไปตลอดอายุการเชื่อมต่อ

โค้ดรู้อยู่แล้ว

เอกสารที่ทำให้รู้สึกอึดอัดที่สุดในบันทึกนี้ไม่ใช่คำแนะนำด้านความปลอดภัย (advisory) แต่เป็นคอมเมนต์ที่อยู่เหนือฟังก์ชันโดยตรง ซึ่งถูกจัดส่งในรีลีสที่ติดแท็กซึ่งคำแนะนำนั้นชี้ไปถึง คอมเมนต์ดังกล่าวระบุช่องว่างนี้เป็น TODO(M10/M12) ตั้งชื่อ allow-list ที่ตั้งใจจะสร้าง — ชุด DaemonConfig::allowed_extension_ids ที่ถูกเติมข้อมูลจากไฟล์คอนฟิกหรือขั้นตอนการจับคู่ (pairing flow) — จากนั้นระบุเหตุผลที่ถูกเลื่อนออกไปว่า "ช่องว่างการป้องกันเชิงลึก (defense-in-depth gap) ที่ยอมรับได้ในตอนนี้ เพราะการจับคู่เกิดขึ้นผ่านป็อปอัป แต่ส่วนขยายที่โหลดจากภายนอก (side-loaded extension) บนเครื่องเดียวกันยังผ่านด่านนี้ได้ในปัจจุบัน"

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

ห้าสัปดาห์ต่อมา ประตูยังไม่เปลี่ยนแปลง

ช่วงที่ได้รับผลกระทบตามบันทึกคือ "ถึง 0.3.0" และนั่นคือช่วงที่ CNA กำหนดไว้ ไม่ใช่จุดสิ้นสุดของเรื่องในรีโพซิทอรี รีลีส 0.3.0 ของ CLI ถูกแท็กเมื่อวันที่ 17 กันยายน เวลา 02:22 UTC; issue ถูกยื่นในวันเดียวกันเวลา 15:14 UTC ประมาณสิบสามชั่วโมงถัดมา มีรีลีส CLI เพิ่มเติมอีกสามรายการที่เผยแพร่ตั้งแต่ — 0.3.1 เมื่อวันที่ 23 กันยายน, 0.3.2 เมื่อวันที่ 30 กันยายน และ 0.3.3 เมื่อวันที่ 15 ตุลาคม — และฟังก์ชัน origin_allowed() ที่แต่ละแท็กเหล่านั้นคือการตรวจสอบแบบเดียวกับที่อธิบายไว้ข้างต้น โดยยังมี TODO อยู่ด้านบนของมัน สาขา main ก็มีสิ่งนี้เช่นกัน ณ วันที่ 27 ตุลาคม

มีการแก้ไขอยู่แล้ว แต่เป็นเพียงข้อเสนอเท่านั้น เมื่อ28 กันยายน ผู้ร่วมพัฒนาที่โพสต์ในนาม dangzitouได้เปิด pull request #363 จากฟอร์กส่วนตัว ชื่อ "fix(daemon): ผูกเกตต้นทาง WS ไว้กับ ID ส่วนขยายของ BrowserSkill เอง" โดยแทนที่การทดสอบรูปแบบด้วยการเปรียบเทียบกับ ID ของสโตร์ทั้งสอง และเพิ่ม BSK_ALLOWED_EXTENSION_IDS เป็นเส้นทางการอนุญาตอย่างชัดเจนสำหรับบิลด์ที่ติดตั้งแบบ sideload และบิลด์สำหรับพัฒนา ซึ่ง ID ที่ยังไม่แพ็กจะได้มาจากเส้นทางการติดตั้ง เนื้อหาของ pull request อ้างว่าปิดทั้งช่องทางการปลอมแปลงและ denial of service แบบ MultipleBrowsersOnline ณ วันที่ 27 ตุลาคม มันยังเปิดอยู่และยังไม่ถูก merge และ issue ยังคงเปิดอยู่โดยไม่มีคำแถลงจากผู้จัดจำหน่ายแนบมาด้วย

ผลในทางปฏิบัติคือไม่มีเวอร์ชันใดให้อัปเกรดไปแล้วมีแพตช์แก้ไขนั้น ผู้ใดที่แนะนำให้ "อัปเกรดข้าม 0.3.0 ไป" กำลังแนะนำขั้นตอนที่ยังไม่มีอยู่จริง รีลีสที่ออกมาทีหลังนั้นใหม่กว่า แต่ไม่ได้แก้ไข ควรอ่านช่วงในบันทึกนี้ว่าเป็นช่วงที่ CNA ประเมินเมื่อวันที่ 20 กันยายน ไม่ใช่เป็นคำยืนยันว่า 0.3.1 และเวอร์ชันหลังจากนั้นปลอดภัยแล้ว

สิ่งที่ได้รับการยืนยันแล้ว และสิ่งที่ยังไม่ได้รับการยืนยัน

• ยืนยันแล้ว:ซอร์สที่เผยแพร่แล้ว ณ แท็ก cli-v0.3.0 มีเกตตรวจสอบ origin ที่ยอมรับ origin ของ chrome-extension ความยาว 32 อักขระในช่วง a–p ใดก็ได้ ผู้รายงาน CNA และไฟล์เองเห็นพ้องต้องกัน และโค้ดเป็นสาธารณะ

• สร้างแล้ว: เกตทำงานเพียงครั้งเดียว ณ การอัปเกรด WebSocket โดยไม่มีการตรวจสอบตัวตนในภายหลัง บนพอร์ตโลคอลคงที่ 52800

• ยืนยันแล้ว: ความคิดเห็นในซอร์สโค้ดของโครงการเองยอมรับว่าส่วนขยายที่ติดตั้งแบบไซด์โหลดจะผ่านได้ และได้เลื่อนรายการที่อนุญาตออกไป

• ระบุแล้ว: CVSS 4.0 6.9 และ CVSS 3.1 6.6 เป็นคะแนนของ VulnCheck ทั้งคู่ ซึ่ง NVD บันทึกไว้เป็นข้อมูลทุติยภูมิ สถานะของรายการนี้ตามที่ NVD ระบุคือ Deferred หมายความว่า NVD ได้เผยแพร่ข้อมูลของ CNA โดยไม่ได้เพิ่มการวิเคราะห์ที่ NVD จัดทำขึ้นเอง

• ระบุ:การประเมิน SSVC ของ CISA ลงวันที่ 21 กันยายน บันทึกการถูกนำไปใช้ประโยชน์เป็นไม่มี ความสามารถในการทำงานอัตโนมัติเป็นไม่ และผลกระทบทางเทคนิคเป็นบางส่วน EPSS ของ FIRST ระบุความน่าจะเป็นของการถูกนำไปใช้ประโยชน์ภายในสามสิบวันข้างหน้าอยู่ที่ 0.00135 ซึ่งเป็นเปอร์เซ็นไทล์ที่ 2.9 ณ วันที่ 26 ตุลาคม

• ยังไม่ได้รับการยืนยัน:การใช้งานจริงใด ๆ ไม่มีการใช้ประโยชน์จากช่องโหว่ ไม่มีหลักฐานแนวคิดที่เผยแพร่ และไม่มีจำนวนการติดตั้งที่ได้รับผลกระทบ เมตริกของที่เก็บโค้ดของโปรเจกต์ไม่ใช่จำนวนการติดตั้ง และยังไม่มีใครเผยแพร่จำนวนดังกล่าว

• ยังไม่ได้รับการยืนยัน:ว่าคำอธิบายผลกระทบใดจึงจะถูกต้อง "การดักจับและจัดการ" ของ CNA และ "การปลอมแปลงผลลัพธ์พร้อมกับการปฏิเสธการให้บริการ" ของกระทู้ ต่างระบุขีดสูงสุดที่แตกต่างกัน และยังไม่มีข้อใดได้รับการพิสูจน์นอกเหนือจากการอ่านโค้ด

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

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

ทำไม transport ถึงเป็นเป้าหมายที่น่าสนใจ

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

นั่นก็เป็นเหตุผลที่ระดับความรุนแรงออกมาอยู่ที่ระดับนี้แทนที่จะสูงกว่านี้ การโจมตีนี้เป็นแบบภายในเครื่อง โดยถือว่ามีส่วนขยายที่ติดตั้งอยู่ในโปรไฟล์แล้วหรือมีโค้ดภายในเครื่องอื่นอยู่แล้ว และต้องมี daemon ทำงานอยู่โดยเปิดการเชื่อมต่อภายในเครื่องไว้ เงื่อนไขเหล่านั้นเป็นเรื่องปกติสำหรับผู้ใช้ที่เครื่องมือนี้มุ่งหมาย และเป็นเรื่องผิดปกติสำหรับคนอื่น ๆ ระดับความรุนแรงปานกลางของ archive และการบันทึกว่าไม่มีความเสียหายนั้นสอดคล้องกับลักษณะดังกล่าว: การขยายขอบเขตความไว้วางใจจริง ณ ขอบเขตที่การออกแบบควรจะกำกับดูแลอยู่พอดี โดยไม่มีหลักฐานว่าใครได้เดินผ่านช่องทางนั้นไป

คำแนะนำเชิงปฏิบัติแบบแคบๆ ที่ตามมาข้างล่างนี้ไม่ใช่มาตรการบรรเทาที่ใครเผยแพร่ไว้ แต่เป็นเพียงขอบเขตที่โค้ดปล่อยให้คงอยู่เท่านั้น เนื่องจากการรับเข้าถูกตัดสินเพียงครั้งเดียวตอนแฮนด์เชกบนพอร์ตที่เปิดเผย พื้นผิวที่เข้าถึงได้จึงถูกกำหนดโดยส่วนขยายใดบ้างที่ติดตั้งอยู่ในโปรไฟล์ที่รันเดมอน และโดยว่าเดมอนนั้นกับการเชื่อมต่อภายในของส่วนขยายถูกเปิดอยู่หรือไม่ในเวลานั้น จนกว่าจะมีรายการอนุญาตไอดีส่วนขยายออกมา ข้อเท็จจริงสองข้อนั้นก็คือการควบคุมทั้งหมด

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