SSRF ของ Azure MCP Server อาจทำให้โทเค็น Managed Identity รั่วไหลไปยัง URL

Microsoft เผยแพร่ CVE-2026-26118 เมื่อวันที่ 10 มีนาคม 2026: ช่องโหว่ server-side request forgery ในAzure MCP Server Tools ซึ่งเป็นแพ็กเกจที่ช่วยให้ AI agent และ MCP client ทำงานกับทรัพยากร Azure ได้ด้วยภาษาธรรมชาติ ผู้โจมตีที่สามารถโต้ตอบกับ agent ที่รองรับ MCP ได้อาจส่ง URL ที่เป็นอันตรายแทนตัวระบุทรัพยากร Azure ปกติ จากนั้นเซิร์ฟเวอร์จะส่งคำขอขาออกไปยังที่อยู่นั้น และตามคำของ Microsoft “อาจรวมโทเค็น managed identity ของตนไว้ด้วย” — ซึ่งเท่ากับมอบข้อมูลรับรองที่ผู้เรียกไม่ควรได้เห็นให้แก่ผู้เรียก Microsoft ให้คะแนนช่องโหว่นี้ที่CVSS 8.8 และจัดระดับเป็น Important โดยแพ็กเกจที่มีการแก้ไขคือ 1.0.2 และ 2.0.0-beta.17 คำแนะนำดังกล่าวไม่ได้บันทึกการถูกใช้ช่องโหว่หรือการเปิดเผยต่อสาธารณะก่อนการแพตช์ และไม่มีการบันทึกความเสียหายจริงใด ๆ สำหรับช่องโหว่นี้ เหตุการณ์นี้เป็นรายการหนึ่งในthe Orca AI Incident Archive ซึ่งเก็บบันทึกฉบับเต็มพร้อมแหล่งอ้างอิงที่อ้างถึง ระดับความรุนแรง และการประเมินความเชื่อมั่น

สิ่งที่คำแนะนำนั้นระบุไว้จริง ๆ

บันทึกของ Microsoft Security Response Center มีเนื้อหาสั้นกระชับ และรายละเอียดที่เผยแพร่เกือบทั้งหมดเกี่ยวกับช่องโหว่นี้ล้วนมีที่มาจากบันทึกดังกล่าว หรือจากคำตอบของ Microsoft ต่อคำถามติดตามผลจำนวนหนึ่ง คำอธิบายฉบับเต็ม: “การปลอมแปลงคำขอฝั่งเซิร์ฟเวอร์ (ssrf) ใน Azure MCP Server อนุญาตให้ผู้โจมตีที่ได้รับอนุญาตยกระดับสิทธิ์ผ่านเครือข่าย” บันทึก CVE ได้จองตัวระบุเมื่อวันที่ 11 กุมภาพันธ์ 2026 และเปิดเผยต่อสาธารณะเมื่อวันที่ 10 มีนาคม เวลา 14:00 UTC ทั้งบันทึกการเผยแพร่ของ Microsoft และรายการของ NVD ต่างระบุวันดังกล่าว NVD วิเคราะห์บันทึกและเผยแพร่เมื่อเวลา 18:18 UTC ในช่วงบ่ายวันเดียวกัน ประกาศของหน่วยงานกำกับดูแลเพียงฉบับเดียวที่พบสำหรับบทความนี้มาจากโมร็อกโก: หน่วย maCERT ของ DGSSI ได้ระบุ CVE-2026-26118 ไว้ในบูลเลตินลงวันที่ 11 มีนาคม 2026 โดยระบุ Azure MCP Server Tools เป็นหนึ่งในผลิตภัณฑ์ที่ได้รับผลกระทบภายใต้ระดับความเสี่ยงของหน่วยงานเองที่ Important โดยไม่มีคะแนนแยกต่างหาก และมีการอ้างอิงกลับไปยังประกาศของ Microsoft

จุดอ่อนนี้ถูกแมปไปยังCWE-918 ซึ่งเป็นการปลอมแปลงคำขอฝั่งเซิร์ฟเวอร์ และการจำแนกผลกระทบคือการยกระดับสิทธิ์ คะแนนฐานของ Microsoft คือ 8.8 บนเวกเตอร์ CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H โดยมีคะแนนเชิงเวลา 7.7 บน E:U/RL:O/RC:C — องค์ประกอบ E:U หมายความว่า Microsoft ไม่ทราบว่ามีโค้ดเอ็กซ์พลอยต์ในขณะที่กำหนดคะแนน และ RL:O หมายความว่ามีวิธีแก้ไขอย่างเป็นทางการแล้ว NVD มีคะแนนฐานเดียวกันและจัดอยู่ในระดับ High; มาตราส่วนสามขั้นของ Microsoft เองเรียกว่า Important

สองฟิลด์สำคัญไม่แพ้คะแนน บันทึกของ Microsoft ระบุว่า ถูกใช้ประโยชน์แล้ว: ไม่ และ เปิดเผยต่อสาธารณะ: ไม่ บันทึกการตัดสินใจ SSVC ของ CISA ในรายการ NVD ซึ่งประทับเวลา 5 มีนาคม 2026 เห็นพ้องในเรื่องการถูกใช้ประโยชน์ — ไม่มี — ขณะที่ประเมินผลกระทบทางเทคนิคเป็น ทั้งหมด และความสามารถในการทำงานอัตโนมัติเป็น ไม่ โมเดล FIRST EPSS ระบุความน่าจะเป็นของการถูกใช้ประโยชน์ใน 30 วันข้างหน้าอยู่ที่ประมาณ 1.0% ณ เปอร์เซ็นไทล์ที่ 62.8 ในการดึงข้อมูลเมื่อวันที่ 3 พฤศจิกายน 2026 นี่เป็นช่องโหว่ที่ถูกค้นพบและแก้ไขแล้ว ไม่ใช่ช่องโหว่ที่ทราบว่าถูกใช้ไปแล้ว

ตัวระบุทรัพยากรกลายเป็นคำขอขาออกได้อย่างไร

Azure MCP Server คือการนำ Model Context Protocol ไปใช้ของ Microsoft ซึ่งเป็นอินเทอร์เฟซที่เอเจนต์ AI ใช้เรียกเครื่องมือต่างๆ เครื่องมือของเซิร์ฟเวอร์นี้จะนำพารามิเตอร์ที่เอเจนต์จัดหาให้ — เช่น ชื่อบัญชีที่เก็บข้อมูล ตัวระบุการสมัครใช้งาน ชื่อฐานข้อมูล — ไปแปลงเป็นการเรียกไปยังระนาบการจัดการและระนาบข้อมูลของ Azure เอกสารของ Microsoft ระบุว่าเซิร์ฟเวอร์นี้ตรวจสอบสิทธิ์ผ่าน Entra ID โดยใช้ “ข้อมูลประจำตัวผู้ใช้ Azure หรือ managed identity ของคุณ” โดยการเข้าถึงถูกจำกัดด้วยการควบคุมการเข้าถึงตามบทบาทของ Azure

ข้อบกพร่องอยู่ตรงจุดที่พารามิเตอร์ซึ่งควรระบุชื่อทรัพยากร Azure กลับถูกยอมรับเป็น URL แทน คำอธิบายของ Microsoft เองระบุว่า ผู้โจมตี “อาจใช้ประโยชน์จากปัญหานี้โดยส่งข้อมูลที่สร้างขึ้นมาเป็นพิเศษไปยังเครื่องมือ Azure Model Context Protocol (MCP) Server ที่รับพารามิเตอร์ที่ผู้ใช้กำหนด หากผู้โจมตีสามารถโต้ตอบกับเอเจนต์ที่ทำงานบน MCP ได้ พวกเขาสามารถส่ง URL ที่เป็นอันตรายแทนตัวระบุทรัพยากร Azure ตามปกติได้” จากนั้นเซิร์ฟเวอร์จะส่งคำขอไปยังปลายทางที่ถูกสั่งไว้ แทนที่จะเป็นปลายทางที่เครื่องมือตั้งใจไว้

ส่วนที่เปลี่ยนเรื่องน่ารำคาญให้กลายเป็นการยกระดับสิทธิ์คือสิ่งที่ติดไปด้วย Microsoft กล่าวว่าคำขอขาออก “อาจรวมโทเค็น managed identity ของตน” ซึ่งทำให้ผู้โจมตีสามารถจับโทเค็นนั้นได้ “โดยไม่ต้องมีการเข้าถึงระดับผู้ดูแลระบบ” โทเค็น managed identity เป็นข้อมูลรับรองแบบ bearer: ใครก็ตามที่ถือมันไว้สามารถนำไปแสดงต่อบริการ Azure ที่ identity นั้นได้รับอนุญาตได้ จนกว่าจะหมดอายุ อีกครึ่งหนึ่งที่เป็นมาตรการบรรเทาในย่อหน้าเดียวกันก็สำคัญไม่แพ้กัน — ผู้โจมตีจะได้รับ “สิทธิ์ที่เชื่อมโยงกับ managed identity ของ MCP Server” และตามคำของ Microsoft “จะไม่ได้รับสิทธิ์ระดับ tenant หรือสิทธิ์ผู้ดูแลระบบที่กว้างขึ้น มีเพียงสิทธิ์ที่ผูกกับ managed identity ที่ถูกบุกรุกเท่านั้น” ขอบเขตผลกระทบคือทุกสิ่งที่ใครบางคนมอบให้ identity นั้น ซึ่งในทางปฏิบัติมักมากกว่าที่เครื่องมือเดียวต้องการ

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

การแก้ไข และแพ็กเกจที่นำการแก้ไขนี้มา

นี่ไม่ใช่การอัปเดตของ Windows Azure MCP Server Tools เผยแพร่เป็นแพ็กเกจ NuGet สำหรับ .NET แพ็กเกจ npm และแพ็กเกจ Python บน PyPI และวิธีแก้ไขคือการเพิ่มเวอร์ชันของแพ็กเกจที่ deployment ใช้งานอยู่ ประกาศคำแนะนำของ Microsoft ระบุช่วงที่ได้รับผลกระทบคือ 1.0.0 ขึ้นไปจนถึงแต่ไม่รวม 1.0.2 และ 2.0.0-beta.1 ขึ้นไปจนถึงแต่ไม่รวม 2.0.0-beta.17 ครอบคลุมทั้งการเผยแพร่ผ่าน NuGet, npm และ PyPI

วันที่ใน registry ของ npm แสดงว่าบิลด์ที่แก้ไขแล้วอยู่บน registry ก่อนประกาศคำแนะนำด้านความปลอดภัย เวอร์ชัน 1.0.2 ของ @azure/mcpเผยแพร่เมื่อวันที่ 6 มีนาคม 2026 ซึ่งเป็นสี่วันก่อนที่ CVE จะเป็นที่รู้จักต่อสาธารณะ; 2.0.0-beta.17 เผยแพร่เมื่อวันที่ 6 กุมภาพันธ์ 2026 ห้าวันก่อนที่ Microsoft จะจองตัวระบุ CVE และหนึ่งเดือนก่อนที่ประกาศคำแนะนำจะปรากฏขึ้น ไม่ว่าลำดับเหตุการณ์ภายใน Microsoft จะเป็นอย่างไร โค้ดที่แพตช์แล้วไม่ได้ถูกเขียนขึ้นเพื่อตอบสนองต่อวันเผยแพร่ NVD และฐานข้อมูลคำแนะนำด้านความปลอดภัยของ GitHub เห็นตรงกันเกี่ยวกับขอบเขตบนเหล่านั้น ทั้งสองแตกต่างกันเล็กน้อยที่ขอบล่างของช่วง PyPI — NVD ระบุว่า 2.0.0-beta.1 ขณะที่ประกาศคำแนะนำของ GitHub ระบุว่า 2.0.0b14 — เป็นความคลาดเคลื่อนที่บันทึกทั้งสองฉบับมีมาตั้งแต่เผยแพร่ และเป็นความคลาดเคลื่อนที่ส่งผลต่อเพียงว่าการติดตั้งใช้งาน Python ต้องย้อนกลับไปไกลแค่ไหนในการตรวจสอบ

ประกาศฉบับนี้ได้รับการแก้ไขเมื่อวันที่ 20 มีนาคม 2026 ซึ่งเป็นสิบวันหลังการเผยแพร่ โดยมีหมายเหตุว่า Microsoft ได้ “เพิ่มผลิตภัณฑ์ในตารางการอัปเดตความปลอดภัยที่บันทึกวิธีการแพ็กเกจต่างๆ ที่ใช้ในการส่งมอบ Azure MCP Server Tools” กล่าวอีกนัยหนึ่ง ประกาศฉบับแรกระบุชื่อผลิตภัณฑ์ แต่ไม่ได้ระบุทุกช่องทางที่จัดส่งผ่าน ซึ่งสำคัญเมื่อการแก้ไขคือ “อัปเกรดแพ็กเกจ” แทนที่จะเป็น “ติดตั้ง KB นี้”

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

ใครเป็นผู้ค้นพบ ทั้งประกาศของ Microsoft และบันทึกของ CVE.org ต่างไม่ได้ระบุชื่อผู้รายงาน ฟิลด์เครดิตใน CVE นั้นว่างเปล่า นั่นไม่ใช่หลักฐานว่าไม่มีใครได้รับเครดิตเป็นการส่วนตัว แต่เป็นเพียงว่าไม่มีเครดิตใดที่เป็นสาธารณะเท่านั้น

การนำไปใช้ประโยชน์ใด ๆไมโครซอฟต์ไม่พบบันทึกใด ๆ การประเมิน SSVC ของ CISA เห็นพ้องด้วย และไม่มีแหล่งข้อมูลใดที่ตรวจสอบสำหรับบทความนี้ระบุถึงตัวตนที่ถูกบุกรุกในการใช้งานจริง ฟิลด์ real-harm ของบันทึกมีค่าเป็น false ซึ่งสอดคล้องกับข้อนั้น EPSS ต่ำเป็นการคาดการณ์ ไม่ใช่ข้อค้นพบ และการไม่มีเหตุการณ์ที่ได้รับรายงานไม่ได้เป็นหลักฐานว่าไม่มีเหตุการณ์ใดเกิดขึ้นเลย

ว่ามี exploit สาธารณะอยู่หรือไม่ นี่คือจุดที่การรายงานข่าวจากแหล่งทุติยภูมิแตกแยกกัน โพสต์ในบล็อกของ Blueinfy เมื่อเดือนมีนาคม 2026 ระบุว่ามี “exploit แบบ proof-of-concept สาธารณะ เช่นที่อยู่บน GitHub” และเตือนถึง “การนำไปใช้เป็นอาวุธอย่างรวดเร็ว” แต่ไม่ได้ให้ลิงก์ เพย์โหลด หรือคำแนะนำแบบทีละขั้น และไม่ได้สาธิตช่องโหว่ดังกล่าว บันทึกของ Microsoft ระบุว่าช่องโหว่นี้ไม่ได้ถูกเปิดเผยต่อสาธารณะก่อนมีการแพตช์ การค้นหาที่เก็บ GitHub ด้วยตัวระบุ CVE เมื่อวันที่ 4 พฤศจิกายน 2026 ให้ผลลัพธ์หนึ่งที่เก็บ — ห้องแล็บตรวจจับของ Microsoft Sentinel ที่เผยแพร่เมื่อวันที่ 17 มีนาคม 2026 ไม่ใช่ exploit — และหน้าช่องโหว่ของ Mallory ระบุว่า exploit ที่เป็นตัวเลือกสองรายการถูกตรวจคัดกรองและปฏิเสธ ข้อกล่าวอ้างเรื่องโค้ด exploit สาธารณะที่ใช้งานได้นั้น เมื่อพิจารณาจากหลักฐานที่มีอยู่ ยังไม่มีหลักฐานยืนยัน ส่วนข้อกล่าวอ้างว่าไม่มีใครเคยลองก็พิสูจน์ไม่ได้เช่นกัน

การวางกรอบเรื่องนี้ หน้าเพจหนึ่งบน PolicyLayer ซึ่งเป็นเว็บไซต์สรุปเหตุการณ์ของผู้ขายรายหนึ่ง ได้นำเสนอ CVE-2026-26118 ใหม่ในรูปแบบของห่วงโซ่การโจมตีระยะไกลโดยไม่ต้องยืนยันตัวตนซึ่งจบลงด้วยการยึดครองผู้เช่า (tenant) ทั้งหมด โดยให้เครดิตแก่นักวิจัยที่ระบุชื่อและรายการสาธิตที่ RSAC 2026 แหล่งข้อมูลที่หน้าเพจนั้นอ้างถึงเองมีชื่อเรื่องว่าเป็น SSRF วันที่ในหน้านั้นไม่สอดคล้องกับไทม์ไลน์ของ CVE และทั้งคำแนะนำของ Microsoft และรายงานของ SecurityWeek ลงวันที่ 10 มีนาคม ก็ไม่ได้ระบุถึงการรันโค้ด บทความนี้ถือว่าคำอธิบายเรื่อง SSRF และโทเคนเป็นคำอธิบายที่ได้รับการยอมรับแล้ว และจะไม่กล่าวซ้ำกรอบการนำเสนอแบบ RCE

ทำไมโทเคนจึงเป็นข้อค้นพบ ไม่ใช่คำขอ

การปลอมแปลงคำขอฝั่งเซิร์ฟเวอร์ (server-side request forgery) เป็นหนึ่งในคลาสช่องโหว่ที่เก่าแก่ที่สุดในซอฟต์แวร์เว็บ และโดยตัวมันเองมักเป็นวิธีเข้าถึงระบบที่ผู้โจมตีไม่สามารถระบุที่อยู่ได้โดยตรง สิ่งที่ทำให้บันทึกนี้ควรค่าแก่การเก็บไว้คือข้อมูลรับรองที่แนบมากับคำขอ เซิร์ฟเวอร์ MCP เป็น confused deputy โดยการออกแบบ กล่าวคือ มันถือครองข้อมูลระบุตัวตนเพื่อให้เอเจนต์สามารถกระทำการในนามของผู้ใช้ได้ และพารามิเตอร์ทุกตัวที่เอเจนต์ส่งผ่าน มองจากมุมของเซิร์ฟเวอร์แล้ว ล้วนเป็นข้อความที่ได้รับอิทธิพลจากผู้โจมตี เมื่อพารามิเตอร์ตัวใดตัวหนึ่งกลายเป็นปลายทางแทนที่จะเป็นชื่อ ตัวแทนนั้นก็นำสิทธิ์อนุญาตของตนเองไปยังปลายทางนั้น

เอกสารของ Microsoft ทำให้เห็นชัดเจนขึ้นว่าความเสี่ยงนั้นกระจุกตัวอยู่ที่ใด โดยอธิบายว่าเซิร์ฟเวอร์ภายในเครื่องนั้น "มีไว้สำหรับการใช้งานของนักพัฒนาภายในองค์กรของคุณโดยเฉพาะ" ขณะเดียวกันก็เผยแพร่คู่มือการปรับใช้สำหรับเซิร์ฟเวอร์ระยะไกลที่โฮสต์เองใน Microsoft Foundry และ Copilot Studio แยกต่างหาก ซึ่งเป็นรูปแบบการกำหนดค่าที่โดยทั่วไปแล้ว managed identity คือข้อมูลรับรองที่ถูกใช้งาน แทนที่จะเป็นการลงชื่อเข้าใช้ของนักพัฒนาเอง เส้นทางการขโมยโทเค็นที่ระบุในคำเตือนนั้นเจาะจงที่ managed identity โดยเฉพาะ ไม่ได้ระบุว่าทุกการติดตั้งตกอยู่ในความเสี่ยง และไม่ได้ระบุว่ามีจำนวนเท่าใด

บทเรียนโดยรวมคือบทเรียนที่มาตรฐาน AI Security Verification Standard ของ OWASP ใช้กรณีนี้เป็นกรณีศึกษาในปัจจุบัน บทว่าด้วยการประสานงาน (orchestration) ของ AISVS อ้างถึง CVE-2026-26118 เป็นหนึ่งในตัวอย่างประกอบ และสรุปว่า “ต้องถือว่าพารามิเตอร์ของเครื่องมือ MCP ถูกควบคุมโดยผู้โจมตี และคำขอขาออกจากเซิร์ฟเวอร์ MCP ต้องผ่านนโยบาย egress และ origin ชุดเดียวกับที่คาดหวังสำหรับ I/O ที่ขับเคลื่อนโดยเอเจนต์อื่นใด” นั่นเป็นข้อเสนอแนะเชิงการควบคุม ไม่ใช่ข้อค้นพบเกี่ยวกับเหตุการณ์นี้ แต่เป็นคำตอบที่เป็นรูปธรรมที่สุดเท่าที่มีผู้เผยแพร่ต่อคำถามที่ว่าควรเปลี่ยนอะไร

อะไรเปลี่ยนไปหลังจากนั้น

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

สำหรับใครก็ตามที่ยังใช้งานบิลด์ที่ได้รับผลกระทบอยู่ การแก้ไขยังเหมือนเดิมและไม่หรูหราเลย: ย้ายไปใช้ 1.0.2 หรือใหม่กว่าบนสาย stable หรือ 2.0.0-beta.17 หรือใหม่กว่าบนสาย preview ในตัวจัดการแพ็กเกจทุกตัวที่ deployment เกี่ยวข้อง นอกจากนั้น ตรรกะในคำแนะนำด้านความปลอดภัยเองบ่งชี้ถึงมาตรการควบคุมสามข้อ — จำกัดสิ่งที่เซิร์ฟเวอร์สามารถเชื่อมต่อออกไปภายนอกได้ ให้ managed identity มีเพียงบทบาทที่เครื่องมือของมันจำเป็นจริง ๆ และถือว่าพารามิเตอร์ของเครื่องมือใดก็ตามที่กลายเป็น URL ได้เป็นอินพุตที่เป็นอันตราย ไม่มีมาตรการใดในสามข้อนี้ที่จำเป็นต่อการรอดพ้นจาก CVE-2026-26118 แต่ละข้อจะลดคุณค่าของอีกข้อหนึ่งที่มีต่อผู้โจมตี

คลังเก็บถาวรจัดประเภทสิ่งนี้อย่างไร

บันทึกนี้ถูกจัดประเภทเป็นช่องโหว่ — สิ่งที่ถูกค้นพบ ไม่ใช่สิ่งที่ทราบกันว่าเคยถูกใช้ประโยชน์แล้ว — โดยมีความเชื่อมั่นระดับ A ซึ่งหมายถึงมีเอกสารประกอบอย่างดีและแหล่งข้อมูลปฐมภูมิเห็นพ้องกัน และไม่ได้ถูกทำเครื่องหมายว่ามีข้อโต้แย้ง ฟิลด์ real-harm ของบันทึกนี้เป็น false และ AI involvement ได้รับการยืนยัน เนื่องจากผลิตภัณฑ์ที่ได้รับผลกระทบเป็นสะพานเชื่อมระหว่าง AI agent กับ cloud control plane ไม่ใช่บริการอเนกประสงค์ที่บังเอิญตั้งอยู่ใกล้เคียง วันที่ถูกบันทึกที่ความละเอียดระดับวัน คือ 10 มีนาคม 2026 โดยไม่มีวันที่สิ้นสุด เพราะนี่คือจุดเวลาเดียว ไม่ใช่แคมเปญ ภูมิภาคเป็น global และ landmark flag เป็น false

ฟิลด์หนึ่งแสดงค่าแตกต่างจากคะแนนที่เผยแพร่ ความรุนแรงของคลังข้อมูลบันทึกเป็น medium ตามสเกลของตนเอง ส่วนตัวเลขที่ทั้ง Microsoft และ NVD เผยแพร่คือ 8.8 ซึ่ง Microsoft เรียกว่า Important และ NVD จัดช่วงเป็น High สรุปของบันทึกขึ้นต้นด้วย 8.8 นั้น และความคลาดเคลื่อนนี้เป็นความแตกต่างในการจัดกลุ่มช่วง ไม่ใช่ความแตกต่างในข้อเท็จจริง

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