ช่องโหว่ด้านการอนุญาตระดับ 9.9 ของ Azure SRE Agent อาจทำให้ผู้เรียกสืบทอดตัวตนของมันได้

CVE-2026-62830 เป็นช่องโหว่การขาดการอนุญาตใน Azure SRE Agent ซึ่งเป็นเอเจนต์ที่ขับเคลื่อนด้วย AI ของ Microsoft สำหรับทีม SRE ของ Azure โดยจะคัดแยกเหตุการณ์ สืบค้นข้อมูลเทเลเมทรี และเมื่อได้รับการกำหนดค่า จะดำเนินการแก้ไข Microsoft เปิดเผยช่องโหว่นี้ในเดือนสิงหาคม 2026 และให้คะแนน 9.9 จาก 10 — ระดับวิกฤต — ภายใต้ CVSS 3.1 เทแนนต์ Azure รายใดก็ตามที่รันเอเจนต์นี้อยู่ในขอบเขตของข้อบกพร่องนี้ คลังเหตุการณ์บันทึกว่าไม่มีเหยื่อที่ได้รับการยืนยันและไม่มีการใช้ประโยชน์จากช่องโหว่ คำอธิบายช่องโหว่ของ Microsoft มีเพียงประโยคเดียวว่า "การขาดการอนุญาตใน Azure SRE Agent ทำให้ผู้โจมตีที่ได้รับอนุญาตสามารถยกระดับสิทธิ์ผ่านเครือข่ายได้" บริการนี้ได้รับการแก้ไขฝั่งเซิร์ฟเวอร์ และ Microsoft กล่าวว่าลูกค้าไม่มีอะไรต้องแพตช์ รายการฉบับเต็มพร้อมระดับความรุนแรงและระดับความเชื่อมั่นอยู่ใน Orca AI Incident Archive ควบคู่กับเหตุการณ์ข้างเคียงในชุดนี้

สิ่งที่ Microsoft เปิดเผย และสิ่งที่ไม่ได้กล่าวถึง

รายการในคู่มืออัปเดตความปลอดภัยของ Microsoft สำหรับ CVE-2026-62830 บันทึกการยกระดับสิทธิ์ใน Azure SRE Agent โดยมีจุดอ่อน CWE-862 (Missing Authorization) คะแนนฐาน 9.9 และคะแนนชั่วคราว 8.6 เวกเตอร์ — CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:H/E:U/RL:O/RC:C — อธิบายการโจมตีผ่านเครือข่ายที่ต้องการเพียงสิทธิ์ต่ำ ไม่ต้องมีการโต้ตอบจากผู้ใช้ และส่งผลกระทบสูงต่อความลับ ความสมบูรณ์ และความพร้อมใช้งาน Microsoft ให้เครดิตการค้นพบนี้แก่ผู้วิจัยด้านความปลอดภัย wtm แห่ง Offensi ในกิตติกรรมประกาศของคำแนะนำ

สองส่วนของเวกเตอร์นี้เป็นตัวเล่าเรื่อง เมตริกขอบเขต (Scope) คือ Changed (S:C) ซึ่งเอกสารประกอบเมตริกของ Microsoft เองนิยามไว้ว่าเป็นกรณีที่องค์ประกอบที่มีช่องโหว่และองค์ประกอบที่ได้รับผลกระทบเป็นคนละส่วนกัน และอยู่ภายใต้การดูแลของหน่วยงานด้านความปลอดภัยที่แตกต่างกัน ส่วนเมตริกเชิงเวลา (temporal) คือ Unproven exploit code, Official fix และ Confirmed ซึ่งเป็นเหตุให้คะแนนเชิงเวลาต่ำกว่าคะแนนฐาน

คำถามที่พบบ่อยของประกาศคำเตือนอธิบายว่าเหตุใดจึงมีคะแนน 9.9 โดยไม่มีลิงก์ดาวน์โหลด: "ช่องโหว่นี้ได้รับการบรรเทาผลกระทบอย่างเต็มที่โดย Microsoft แล้ว ไม่มีการดำเนินการใดๆ สำหรับผู้ใช้บริการนี้ จุดประสงค์ของ CVE นี้คือเพื่อให้มีความโปร่งใสเพิ่มเติม" Microsoft กำหนดแท็กผลิตภัณฑ์เป็นบริการที่โฮสต์แบบเฉพาะ ซึ่งเป็นเหตุผลว่าทำไมรายการจึงไม่มีหมายเลขบิลด์และไม่มีช่วงเวอร์ชันที่ได้รับผลกระทบ

ตาราง exploitability ชัดเจนไม่แพ้ FAQ เปิดเผยต่อสาธารณะ: ไม่ ถูกใช้ประโยชน์แล้ว: ไม่ การประเมินการถูกใช้ประโยชน์: มีโอกาสน้อย สิ่งที่ advisory ไม่ได้อธิบายคือ on-behalf-of flow, managed identity หรือ runbooks และไม่ได้ระบุช่วงเวอร์ชันด้วย: CPE คือผลิตภัณฑ์ที่ไม่มีเวอร์ชัน และเวอร์ชันที่ได้รับผลกระทบเพียงรายการเดียวที่ระบุไว้คือเครื่องหมายขีด ทุกสิ่งเกี่ยวกับกลไกนี้ที่ผู้อ่านต้องการรู้จะต้องมาจากที่อื่น และที่อื่นนั้นส่วนใหญ่ก็คือรายการของ archive เอง

เอเจนต์คืออะไร และเหตุใดอัตลักษณ์ของมันจึงเป็นสิ่งที่ควรค่าแก่การไปให้ถึง

Azure SRE Agent ไม่ใช่แชตบอตที่ติดตั้งเพิ่มบนแดชบอร์ด เอกสาร Azure SRE Agent ของ Microsoft อธิบายถึงเอเจนต์ที่เชื่อมต่อกับทรัพยากร Azure เครื่องมือสังเกตการณ์ แพลตฟอร์มจัดการเหตุการณ์ และที่เก็บซอร์สโค้ด รวบรวมสัญญาณ เชื่อมโยงการปรับใช้ เสนอมาตรการบรรเทาผลกระทบ และ—ขึ้นอยู่กับโหมดการทำงานที่ลูกค้าตั้งไว้—ดำเนินการเหล่านั้น ในโหมด Review ผู้ดูแลระบบอนุมัติการดำเนินการเชิงเขียน ในโหมด Autonomous เอเจนต์จะดำเนินการโดยไม่ต้องรอ ขอบเขตความสามารถถูกขยายผ่าน skills และ runbooks การดำเนินการผ่าน Azure CLI เอเจนต์แบบกำหนดเอง เครื่องมือ Python ตัวเชื่อมต่อ MCP และฮุกของเอเจนต์

เอกสารเดียวกันนี้ระบุข้อเท็จจริงที่ทำให้ CVE นี้น่าสนใจว่า "เอเจนต์ตรวจสอบสิทธิ์ด้วย managed identity และทำงานภายใต้การควบคุมการเข้าถึงตามบทบาทของ Azure (RBAC)" managed identity คือข้อมูลประจำตัว Entra ที่กำหนดให้กับบริการ และสิ่งที่มันทำได้คือสิ่งที่การกำหนดบทบาทของมันอนุญาตเท่านั้น ดังนั้นอำนาจของเอเจนต์จึงไม่ใช่คุณสมบัติของโค้ดเอเจนต์ แต่เป็นคุณสมบัติของบทบาทที่ผูกกับข้อมูลประจำตัวนั้น ซึ่งเป็นขอบเขตที่การตรวจสอบการอนุญาตที่ขาดหายไปจะล้มเหลวในการปกป้อง

บทความทางเทคนิคแยกต่างหาก รายการของ HackTricks Cloud เกี่ยวกับการยกระดับสิทธิ์ของ Azure SRE Agent อธิบายเวอร์ชันเชิงโครงสร้างของปัญหานี้โดยไม่ได้อ้างอิง CVE-2026-62830 โดยระบุปฏิบัติการบน control plane ที่ทำให้ผู้เรียกสามารถชี้นำ agent ได้ — การเปิด thread การอนุมัติ remediation ที่เสนอไว้ การ rebind การกำหนดค่าของ agent การเปลี่ยนปลายทางการเชื่อมต่อ data connector — และตีความผลลัพธ์ว่าเป็น confused deputy: ผู้เรียกไม่จำเป็นต้องมีสิทธิ์ของ agent เพียงแต่ต้องมีวิธีทำให้ agent ใช้สิทธิ์เหล่านั้น บทความนั้นไม่ได้เกี่ยวกับ CVE นี้ และไม่ควรอ่านเป็นการยืนยันว่าเกี่ยวข้องกัน บทความนี้มีประโยชน์ด้วยเหตุผลเดียวกับคะแนน: มันแสดงให้เห็นว่าอำนาจนั้นอยู่ที่ใดจริง ๆ

กลไก: สิ่งที่คลังเอกสารระบุ และสิ่งที่ผู้จำหน่ายยืนยัน

บันทึกในอาร์ไคฟ์อธิบายช่องโหว่นี้ว่าเป็นความล้มเหลวในสิ่งที่เรียกว่าโฟลว์ Scope-Changed OBO (on-behalf-of) โฟลว์ on-behalf-of คือการแลกเปลี่ยนโทเค็นซึ่งบริการหนึ่งแลกเปลี่ยนข้อมูลรับรองของผู้เรียกเป็นโทเค็นที่ทำให้บริการนั้นเรียกบริการปลายทางในนามของผู้เรียกได้ หากการตรวจสอบสิทธิ์ ณ การแลกเปลี่ยนนั้นล้มเหลว อาร์ไคฟ์ระบุว่าการเรียกไปยังปลายทางอาจถอยไปใช้ managed identity ที่จำกัดขอบเขตตาม tenant ของเอเจนต์เอง แทนตัวตนของผู้เรียก ผู้เรียกที่ได้รับสิทธิ์ต่ำแต่ผ่านการรับรองตัวตนจะสืบทอดสิทธิ์ของ service principal ของเอเจนต์ และอาจแก้ไข runbook, ข้อมูลเทเลเมทรี และโครงสร้างพื้นฐาน — ไม่ใช่แค่เอเจนต์ แต่รวมถึงทุกทรัพยากร Azure ที่ managed identity มีบทบาทอยู่

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

การค้นหาการรายงานข่าวเชิงอิสระพบย่อหน้าเดียวกันในมากกว่าหนึ่งแห่ง: พาดหัวเกี่ยวกับ OBO flow และรัศมีผลกระทบปรากฏแบบถูกเผยแพร่ซ้ำบน forkast.news และ Yahoo Tech รวมถึงแหล่งอื่น ๆ การเผยแพร่ซ้ำทำให้รายงานชิ้นนั้นนับเป็นแหล่งเดียว ไม่ใช่หลายแหล่ง ไม่มีสำนักข่าวใดที่ถูกตรวจสอบสำหรับบทความนี้ที่เผยแพร่ข้อมูลเทเลเมทรี หลักฐานพิสูจน์แนวคิด หรือการจำลองกลไกของตนเอง

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

คลังข้อมูลให้เกรดบันทึกนี้เป็น A — มีเอกสารประกอบอย่างดี แหล่งข้อมูลปฐมภูมิเห็นตรงกัน — และไม่ได้ทำเครื่องหมายว่ามีข้อโต้แย้ง บันทึกนี้ไม่ได้ระบุถึงความเสียหายใด ๆ ในโลกจริง เกรดดังกล่าวเกี่ยวกับข้อเท็จจริงหลักของบันทึก และข้อเท็จจริงเหล่านั้นตรงกันในทุกแหล่งข้อมูล ไม่ได้เป็นการอ้างว่าทุกประโยคในรายการนี้ได้รับการทำซ้ำอย่างเป็นอิสระ

• ได้รับการยืนยันจากผู้จำหน่ายแล้ว CVE-2026-62830 ส่งผลกระทบต่อ Azure SRE Agent เป็นช่องโหว่ CWE-862 จากการขาดการตรวจสอบสิทธิ์ มีคะแนนพื้นฐาน CVSS 3.1 เท่ากับ 9.9 และคะแนนตามเวลาเท่ากับ 8.6 ไม่จำเป็นต้องมีการดำเนินการใด ๆ จากลูกค้า ไม่ได้รับการเปิดเผยต่อสาธารณะ และยังไม่มีการบันทึกว่าถูกนำไปใช้ประโยชน์

• ยืนยันโดยรายงานและการเสริมข้อมูลด้านความปลอดภัยจากแหล่งอิสระสรุป Patch Tuesday ประจำเดือนสิงหาคม 2026 ของ Cisco Talos ระบุ CVE นี้ด้วยคะแนน 9.9 เท่ากันและจุดอ่อนเรื่องการขาดการอนุญาตเดียวกัน และจัดให้อยู่ภายใต้การประเมินการถูกใช้ประโยชน์ในระดับ “less likely” ของ Microsoft การประเมิน SSVC ของ CISA ซึ่งบันทึกผ่าน NVD ระบุว่าการถูกใช้ประโยชน์เป็น none สามารถทำงานอัตโนมัติได้เป็น no และผลกระทบทางเทคนิคเป็น total การเสริมข้อมูลของ OpenCVE ระบุคะแนน EPSS ที่ 0.00778 และบันทึกว่า CVE นี้ไม่อยู่ในแค็ตตาล็อก Known Exploited Vulnerabilities ของ CISA

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

• ไม่มีการระบุไว้ที่ใดเลย ไม่มีการใช้ช่องโหว่ ไม่มีผู้เสียหาย ไม่มีหลักฐานเชิงประจักษ์ต่อสาธารณะ ไม่มีหมายเลขบิลด์ และไม่มีช่วงเวอร์ชันที่ได้รับผลกระทบ สิ่งที่ใกล้เคียงที่สุดกับรายงานสถานะที่มีอยู่คือบรรทัดประเมินความสามารถในการถูกใช้ประโยชน์ของ Microsoft — เปิดเผยต่อสาธารณะ: ไม่, ถูกใช้ประโยชน์แล้ว: ไม่, มีโอกาสน้อย

• ไม่มีการรายงานข่าวจากสื่อกระแสหลัก การค้นหา CVE นี้ในสื่อเทคโนโลยีทั่วไปและสื่อด้านความปลอดภัยไม่พบบทความใด ๆ จาก The Register, BleepingComputer, SecurityWeek หรือ Help Net Security สิ่งที่ปรากฏต่อสาธารณะมีเพียงคำแนะนำจากผู้ขาย ฐานข้อมูลช่องโหว่ บทสรุป Patch Tuesday และบทความที่ถูกนำไปเผยแพร่ซ้ำ สำหรับคะแนน 9.9 แล้ว ถือว่าไม่ปกติ และนี่เป็นข้อเท็จจริงเกี่ยวกับบันทึกข้อมูล มากกว่าจะเป็นการตัดสินเกี่ยวกับความเสี่ยง

การแก้ไข และการตรวจสอบที่คงอยู่ยาวนานกว่ามัน

เนื่องจาก Azure SRE Agent เป็นบริการที่โฮสต์โดย Microsoft การแก้ไขจึงถูกดำเนินการฝั่ง Microsoft ไม่มีอัปเดตให้ติดตั้ง ไม่มีหมายเลขบิลด์ให้เทียบกับรายการสินค้าคงคลัง และลูกค้าไม่สามารถยืนยันจากภายนอกได้ว่า tenant ได้รับการป้องกันก่อนวันที่กำหนดหรือไม่ จุดยืนของ Microsoft คือไม่จำเป็นต้องดำเนินการใดๆ และสำหรับตัวช่องโหว่นั้น จุดยืนนี้ถูกต้อง

รายการของคลังเก็บได้เพิ่มคำแนะนำที่เอกสารคำแนะนำไม่ได้ระบุไว้อย่างชัดเจน: ตรวจสอบการกำหนด managed identity ทบทวน RBAC เทียบกับสิ่งที่เอเจนต์จำเป็นต้องใช้จริง และเฝ้าติดตามการยกระดับสิทธิ์ที่ผิดปกติ คำแนะนำนั้นเป็นของคลังเก็บ ไม่ใช่การอ้างอิงจาก Microsoft

ผลลัพธ์ในทางปฏิบัติเกิดจากสถาปัตยกรรม ไม่ใช่จากคำแนะนำของแหล่งใด ๆ ดังนั้นให้ถือว่าเป็นการอนุมาน หากอำนาจของเอเจนต์คือการกำหนดบทบาทของเอเจนต์ มาตรการควบคุมที่คงทนก็คือขอบเขตของการกำหนดบทบาทเหล่านั้น และการเก็บรักษาบันทึกของ control plane ที่จะแสดงให้เห็นว่ามีการใช้งานบทบาทเหล่านั้น การแก้ไขฝั่งบริการปิดเส้นทางนั้น แต่ไม่สามารถลดขอบเขตของ managed identity ที่ได้รับการจัดสรรเกินความจำเป็นย้อนหลังได้ และไม่สามารถช่วยองค์กรที่ไม่ได้เก็บบันทึกไว้ได้ ทั้งสองสิ่งนี้เป็นสิ่งที่ลูกค้ายังคงต้องรับผิดชอบเองหลังจาก CVE ถูกปิดแล้ว

ตำแหน่งของมันในชุดเดือนสิงหาคม 2026

สรุปข่าวของ Talos ทำให้การเปรียบเทียบนี้หลีกเลี่ยงไม่ได้ ในเดือนนั้นยังระบุ CVE-2026-59118 ใน Copilot Cowork ซึ่งเป็นการยกระดับสิทธิ์ผ่านการอนุญาตที่ไม่เหมาะสมและได้คะแนน 9.3 และ CVE-2026-56162 ใน Azure SQL Database ซึ่งเป็นการยกระดับสิทธิ์และได้คะแนน 10.0 ช่องโหว่หนึ่งเดียวที่ Talos รายงานว่าถูกโจมตีจริงในสภาพแวดล้อมจริงในเดือนนั้นไม่ใช่ทั้งสองรายการนี้ แต่คือ CVE-2026-68820 ใน Windows AFD สำหรับ WinSock รายการผลิตภัณฑ์ AI ในรายการของ Talos เป็นบั๊กด้านการอนุญาต และนั่นคือรูปแบบเฉพาะของความเสี่ยงที่บันทึกนี้กล่าวถึง

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