Azure SRE Agents auktoriseringsfel på 9,9 kunde ha låtit en anropare överta dess identitet

CVE-2026-62830 är en auktoriseringsbrist i Azure SRE Agent, Microsofts AI-drivna agent för Azure-team som arbetar med site reliability, vilken triagerar incidenter, ställer frågor mot telemetrin och, när det är konfigurerat, utför reparationsåtgärder. Microsoft offentliggjorde den i augusti 2026 och gav den 9,9 av 10 – kritisk – enligt CVSS 3.1. Alla Azure-klientorganisationer som körde agenten låg inom buggens omfattning; incidentarkivet registrerar varken något bekräftat offer eller någon exploatering. Microsofts beskrivning av felet är en mening: "Bristande auktorisering i Azure SRE Agent gör att en auktoriserad angripare kan eskalera privilegier över ett nätverk." Tjänsten åtgärdades på serversidan, och Microsoft säger att kunderna inte hade något att patcha. Den fullständiga posten, med sina allvarlighets- och konfidensgrader, finns i Orca AI Incident Archive tillsammans med de närliggande incidenterna i den här serien.

Det Microsoft publicerade – och vad man utelämnade

Microsofts post i Security Update Guide för CVE-2026-62830 registrerar en privilegieeskalering i Azure SRE Agent, svagheten CWE-862 (Missing Authorization), en baspoäng på 9,9 och en temporal poäng på 8,6. Vektorn – 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 – beskriver en nätverksattack som endast kräver låga behörigheter, ingen användarinteraktion och som ger hög påverkan på konfidentialitet, integritet och tillgänglighet. Microsoft krediterar säkerhetsforskaren wtm på Offensi för fyndet i säkerhetsmeddelandets tackavsnitt.

Två delar av vektorn berättar historien. Scope-måttet är Changed (S:C), vilket Microsofts egen dokumentation för måttet definierar som ett fall där den sårbara komponenten och den påverkade komponenten är olika och hanteras av olika säkerhetsmyndigheter. De temporala måtten är Unproven exploit code, Official fix och Confirmed, och därför ligger temporalpoängen under baspoängen.

Rådgivningens FAQ förklarar varför ett 9.9 finns utan nedladdningslänk: "Den här sårbarheten har redan fullständigt mildrats av Microsoft. Det finns inga åtgärder för användare av den här tjänsten att göra. Syftet med denna CVE är att ge ytterligare transparens." Microsoft märker produkten som en uteslutande värdbaserad tjänst, vilket är varför posten inte har något buildnummer och inget intervall för berörda versioner.

Exploateringstabellen är lika tydlig som FAQ. Offentligt avslöjad: Nej. Exploaterad: Nej. Exploateringsbedömning: Mindre sannolikt. Det som rådgivningen inte beskriver är on-behalf-of-flödet, den hanterade identiteten eller runbooks. Inte heller anger den ett versionsintervall: CPE:n är produkten utan version, och den enda påverkade version som listas är ett streck. Allt en läsare skulle vilja veta om mekanismen måste komma från någon annanstans, och det är mestadels arkivets egen post.

Vad agenten är, och varför dess identitet är det som är värt att nå

Azure SRE Agent är inte en chattbot som sitter påklistrad på en instrumentpanel. Microsofts dokumentation för Azure SRE Agent beskriver en agent som ansluter till Azure-resurser, observerbarhetsverktyg, incidentplattformar och källkodsarkiv, samlar in signaler, korrelerar distributioner, föreslår åtgärder och – beroende på vilket körläge en kund anger – utför dem. I Review-läge godkänner en administratör skrivåtgärderna; i autonomt läge tillämpar agenten dem utan att vänta. Dess räckvidd utökas genom färdigheter och runbooks, Azure CLI-åtgärder, anpassade agenter, Python-verktyg, MCP-anslutningar och agenthooks.

Samma dokumentation anger det faktum som gör CVE:n intressant: "Agenten autentiserar med hanterad identitet och arbetar under Azure rollbaserad åtkomstkontroll (RBAC)." En hanterad identitet är en Entra-identitet som tilldelats en tjänst, och vad den kan göra är exakt vad dess rolltilldelningar tillåter. Agentens behörighet är därför inte en egenskap i agentens kod utan i de roller som är kopplade till identiteten – vilket är den gräns som en saknad auktoriseringskontroll skulle misslyckas med att skydda.

En separat teknisk redogörelse, HackTricks Clouds post om privilegieeskalering i Azure SRE Agent, beskriver den strukturella versionen av detta problem utan att citera CVE-2026-62830. Den listar kontrollplansoperationer som låter en anropare styra en agent – öppna en tråd, godkänna en föreslagen åtgärd, binda om agentens konfiguration, peka om en datakoppling – och framställer resultatet som en förvirrad ställföreträdare: anroparen behöver inte agentens behörigheter, bara ett sätt att få agenten att använda dem. Den posten handlar inte om detta CVE och bör inte läsas som en bekräftelse av det. Den är användbar av samma skäl som poängen: den visar var auktoriteten faktiskt ligger.

Mekanismen: vad arkivet beskriver och vad leverantören bekräftar

Arkivposten beskriver felet som ett fel i det som kallas Scope-Changed OBO (on-behalf-of)-flödet. Ett on-behalf-of-flöde är ett tokenutbyte där en tjänst byter ut anroparens autentiseringsuppgift mot en token som låter den anropa en nedströms tjänst som den anroparen. Om auktoritetskontrollen vid utbytet misslyckas, säger arkivet, kan nedströmsanropet falla tillbaka på agentens egen klientorganisationsbegränsade hanterade identitet i stället för anroparens identitet. En autentiserad anropare med låga privilegier skulle då ärva agentens behörigheter kopplade till tjänstens huvudnamn och kunde ändra runbooks, telemetri och infrastruktur – inte bara agenten, utan varje Azure-resurs som den hanterade identiteten har en roll på.

Den beskrivningen stämmer överens med allt som Microsoft faktiskt publicerade, och den finns inte i det som Microsoft publicerade. Leverantörens text bekräftar tre delar: auktoriseringskontrollen saknades, anroparen behöver endast låga privilegier, och påverkan går över en gräns för säkerhetsbehörighet. Den bekräftar inte tokenutbytet, identitetsarvet eller runbook- och telemetriexemplen. Arkivets post är källan till dessa, och arkivet är en sekundär datamängd, inte leverantören.

En sökning efter oberoende rapportering ger samma stycke på mer än ett ställe: rubriken om OBO-flödet och blast radius förekommer syndikerad på forkast.news och Yahoo Tech, bland annat. Syndikering gör att den bevakningen är en källa, inte flera. Ingen av de medier som granskades för den här artikeln publicerade sin egen telemetri, sitt eget konceptbevis eller sin egen reproduktion av mekanismen.

Vad som är fastställt, vad som beskrivs och vad som aldrig påstods

Arkivet betygsätter denna post som A – väl dokumenterad, primärkällorna stämmer överens – och markerar den inte som omtvistad. Det registrerar ingen verklig skada. Betyget avser postens kärnfakta, och de stämmer överens mellan källorna; det är inte ett påstående att varje mening i posten har återgetts oberoende.

• Fastställd av leverantören. CVE-2026-62830 påverkar Azure SRE Agent, är av typen CWE-862 saknad auktorisering, har ett CVSS 3.1-basvärde på 9.9 och ett temporalvärde på 8.6, krävde ingen åtgärd från kunden, offentliggjordes inte och har inte registrerats som utnyttjad.

• Fastställd genom oberoende säkerhetsrapportering och berikning.Cisco Talos sammanställning för Patch Tuesday i augusti 2026 listar CVE:n med samma 9,9 och samma svaghet i form av saknad auktorisering, och placerar den under Microsofts bedömning "mindre sannolikt" för exploatering. CISA:s SSVC-bedömning, registrerad via NVD, klassar exploatering som ingen, automatiserbarhet som nej och teknisk påverkan som total. OpenCVE:s berikning listar en EPSS-poäng på 0,00778 och registrerar att CVE:n inte finns i CISA:s katalog över kända exploaterade sårbarheter (Known Exploited Vulnerabilities).

• Beskrivet, inte oberoende bekräftat. Felet med OBO-tokenutbyte, arvet av agentens hanterade identitet samt konsekvenserna för runbook, telemetri och infrastruktur kommer från arkivets post och från syndikerad sekundär täckning. Microsofts rådgivning namnger dem inte. De är den mest användbara delen av protokollet och den minst dokumenterade delen av det.

• Inte fastställt någonstans. Ingen exploatering, inget offer, inget offentligt proof of concept, inget buildnummer och inget intervall för påverkade versioner. Microsofts exploaterbarhetsrad – offentligt avslöjad: Nej, exploaterad: Nej, mindre sannolikt – är det närmaste en statusrapport som finns.

• Det saknas bevakning i mainstreammedier. Sökningar efter denna CVE i allmän teknik- och säkerhetspress gav inga artiklar från The Register, BleepingComputer, SecurityWeek eller Help Net Security. Dess offentliga avtryck består av leverantörens säkerhetsmeddelande, sårbarhetsdatabaser, en Patch Tuesday-sammanställning och den syndikerade artikeln. För en 9,9 är det ovanligt, och det är ett faktum om vad som finns dokumenterat snarare än en bedömning av risken.

Rättningen, och kontrollerna som överlever den

Eftersom Azure SRE Agent är en värdbaserad tjänst tillämpades korrigeringen på Microsofts sida. Det finns ingen uppdatering att installera, inget buildnummer att jämföra med en inventering och inget sätt för en kund att utifrån bekräfta att en klientorganisation var skyddad före ett visst datum. Microsofts ståndpunkt är att ingen åtgärd krävs, och för själva sårbarheten är den ståndpunkten korrekt.

Arkivposten tillför vägledning som rådgivningen inte uttryckligen anger: granska tilldelningar av hanterad identitet, granska RBAC mot vad agenten faktiskt behöver och övervaka onormal privilegieeskalering. Den vägledningen är arkivets egen, inte ett citat från Microsoft.

Den praktiska konsekvensen följer av arkitekturen snarare än av någon källas rekommendation, så behandla den som en slutledning. Om agentens behörighet är dess rolltilldelningar, är de bestående kontrollerna omfattningen av dessa tilldelningar och bevarandet av kontrollplansloggarna som skulle visa att de används. En åtgärd på tjänstesidan stänger vägen; den minskar inte i efterhand en hanterad identitet som var överprovisionerad, och den kan inte hjälpa en organisation som inte bevarade loggarna. Båda dessa är saker som en kund fortfarande äger efter att CVE:n har stängts.

Var det ligger i augusti 2026-omgången

Talos sammanställning gör jämförelsen oundviklig. Den månaden listar den även CVE-2026-59118 i Copilot Cowork, en behörighetseskalering genom otillbörlig auktorisering med betyg 9,3, och CVE-2026-56162 i Azure SQL Database, en behörighetseskalering med betyg 10,0. Den enda sårbarhet som Talos rapporterar som utnyttjad i verkligheten den månaden var ingen av dessa: det var CVE-2026-68820, i Windows AFD för WinSock. AI-produktposterna i Talos lista är auktoriseringsbuggar, och det är den specifika formen av risk som denna post dokumenterar.

Inget av detta gör CVE-2026-62830 till ett intrång. Det är en transparens-CVE för en tjänst som redan var åtgärdad, publicerad så att kunder kan se vad som var fel och kontrollera sina egna konfigurationer. Värdet i posten ligger i den konfigurationsfråga den lämnar efter sig – vad agentens identitet kunde nå, och huruvida någon skulle ha lagt märke till att den användes – inte i en patch att schemalägga.