Der 9,9-Autorisierungsfehler des Azure SRE Agent hätte einem Aufrufer ermöglichen können, dessen Identität zu übernehmen.

CVE-2026-62830 ist eine Schwachstelle der fehlenden Autorisierung im Azure SRE Agent, Microsofts KI-gestütztem Agenten für Azure-Site-Reliability-Teams, der Vorfälle triagiert, Telemetrie abfragt und, wenn konfiguriert, Behebungsmaßnahmen ausführt. Microsoft hat sie im August 2026 offengelegt und nach CVSS 3.1 mit 9,9 von 10 bewertet – Kritisch. Jeder Azure-Tenant, der den Agenten betrieb, lag im Geltungsbereich des Fehlers; das Incident-Archiv verzeichnet weder einen bestätigten Betroffenen noch eine Ausnutzung. Microsofts Beschreibung der Schwachstelle besteht aus einem Satz: „Fehlende Autorisierung im Azure SRE Agent ermöglicht einem autorisierten Angreifer, Privilegien über ein Netzwerk zu erhöhen.“ Der Dienst wurde serverseitig behoben, und Microsoft sagt, Kunden hätten nichts zu patchen gehabt. Der vollständige Eintrag mit seinen Schweregrad- und Vertrauensbewertungen steht im Orca AI Incident Archive neben den benachbarten Vorfällen dieser Serie.

Was Microsoft veröffentlicht hat – und was es ausgelassen hat

Microsofts Eintrag im Security Update Guide für CVE-2026-62830 verzeichnet eine Rechteerweiterung in Azure SRE Agent, Schwachstelle CWE-862 (Missing Authorization), einen Basisscore von 9,9 und einen Temporal Score von 8,6. Der Vektor – 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 – beschreibt einen Netzwerkangriff, der nur niedrige Berechtigungen erfordert, keine Benutzerinteraktion benötigt und hohe Auswirkungen auf Vertraulichkeit, Integrität und Verfügbarkeit hat. Microsoft dankt Sicherheitsforscher wtm von Offensi für den Fund in den Danksagungen des Advisory.

Zwei Teile dieses Vektors erzählen die Geschichte. Die Scope-Metrik ist Changed (S:C), was laut Microsofts eigener Metrikdokumentation den Fall bezeichnet, in dem die verwundbare Komponente und die betroffene Komponente unterschiedlich sind und von unterschiedlichen Sicherheitsinstanzen verwaltet werden. Die Temporal-Metriken sind Unproven Exploit Code, Official Fix und Confirmed, weshalb der Temporal-Score unter dem Base-Score liegt.

Die FAQ des Advisories erklärt, warum es eine 9.9 gibt, ohne dass ein Download-Link vorhanden ist: „Diese Schwachstelle wurde von Microsoft bereits vollständig entschärft. Für Nutzer dieses Dienstes besteht kein Handlungsbedarf. Der Zweck dieser CVE besteht darin, für mehr Transparenz zu sorgen." Microsoft kennzeichnet das Produkt als ausschließlich gehosteten Dienst, weshalb der Eintrag weder eine Build-Nummer noch einen Bereich betroffener Versionen enthält.

Die Exploitability-Tabelle ist so klar wie die FAQ. Öffentlich offengelegt: Nein. Ausgenutzt: Nein. Einschätzung der Ausnutzung: Weniger wahrscheinlich. Was der Advisory nicht beschreibt, ist der On-Behalf-Of-Flow, die Managed Identity oder Runbooks. Ebenso wenig gibt er einen Versionsbereich an: Die CPE ist das Produkt ohne Version, und die einzig aufgeführte betroffene Version ist ein Bindestrich. Alles, was ein Leser über den Mechanismus wissen möchte, muss von woanders kommen, und dieses Woanders ist größtenteils der eigene Eintrag des Archivs.

Was der Agent ist und warum seine Identität das Erstrebenswerte ist

Der Azure SRE Agent ist kein Chatbot, der an ein Dashboard angeflanscht wurde. Die Dokumentation zum Azure SRE Agent von Microsoft beschreibt einen Agenten, der sich mit Azure-Ressourcen, Observability-Tools, Incident-Plattformen und Quellcode-Repositories verbindet, Signale sammelt, Bereitstellungen korreliert, Gegenmaßnahmen vorschlägt und – abhängig vom Ausführungsmodus, den ein Kunde festlegt – diese ausführt. Im Review-Modus genehmigt ein Administrator die Schreibaktionen; im Autonomous-Modus wendet der Agent sie ohne zu warten an. Seine Reichweite wird durch Skills und Runbooks, Azure-CLI-Vorgänge, benutzerdefinierte Agenten, Python-Tools, MCP-Connectors und Agent-Hooks erweitert.

Dieselbe Dokumentation nennt den Umstand, der die CVE interessant macht: „Der Agent authentifiziert sich mit einer verwalteten Identität und agiert unter Azure Role-Based Access Control (RBAC).“ Eine verwaltete Identität ist eine Entra-Identität, die einem Dienst zugewiesen wird, und sie kann genau das tun, was ihre Rollenzuweisungen zulassen. Die Berechtigung des Agenten ist daher keine Eigenschaft seines Codes, sondern der Rollen, die dieser Identität zugewiesen sind – und genau diese Grenze würde eine fehlende Autorisierungsprüfung nicht schützen.

Eine separate technische Abhandlung, der Eintrag von HackTricks Cloud zur Privilegienausweitung beim Azure SRE Agent, beschreibt die strukturelle Version dieses Problems, ohne CVE-2026-62830 zu zitieren. Er listet Control-Plane-Operationen auf, mit denen ein Aufrufer einen Agenten steuern kann – einen Thread öffnen, eine vorgeschlagene Behebung genehmigen, die Konfiguration des Agenten neu binden, einen Datenconnector neu ausrichten – und fasst das Ergebnis als Confused Deputy auf: Der Aufrufer benötigt nicht die Berechtigungen des Agenten, sondern nur eine Möglichkeit, den Agenten dazu zu bringen, sie zu verwenden. Dieser Eintrag handelt nicht von dieser CVE und sollte nicht als Bestätigung für sie gelesen werden. Er ist aus demselben Grund nützlich wie die Bewertung: Er zeigt, wo die Autorität tatsächlich liegt.

Der Mechanismus: was das Archiv beschreibt und was der Anbieter bestätigt

Der Archiveintrag beschreibt die Schwachstelle als Fehler in dem, was er den Scope-Changed-OBO-(On-Behalf-Of)-Flow nennt. Ein On-Behalf-Of-Flow ist ein Tokentausch, bei dem ein Dienst die Anmeldeinformationen eines Aufrufers gegen ein Token eintauscht, mit dem er einen nachgelagerten Dienst im Namen dieses Aufrufers aufrufen kann. Wenn die Berechtigungsprüfung bei diesem Austausch fehlschlägt, so heißt es im Archiveintrag, kann der nachgelagerte Aufruf auf die eigene mandantenbezogene verwaltete Identität des Agenten statt auf die Identität des Aufrufers zurückfallen. Ein Aufrufer mit geringen Berechtigungen, aber gültiger Authentifizierung würde dann die Berechtigungen des Dienstprinzipals des Agenten erben und könnte Runbooks, Telemetrie und Infrastruktur ändern — nicht nur den Agenten, sondern jede Azure-Ressource, für die die verwaltete Identität eine Rolle besitzt.

Diese Beschreibung ist mit allem, was Microsoft tatsächlich veröffentlicht hat, stimmig, und sie steht nicht in dem, was Microsoft veröffentlicht hat. Der Text des Anbieters bestätigt drei Punkte: Die Autorisierungsprüfung fehlte, der Aufrufer benötigt nur geringe Berechtigungen, und die Auswirkung überschreitet eine Grenze der Sicherheitszuständigkeit. Er bestätigt weder den Token-Austausch noch die Identitätsvererbung noch die Runbook- und Telemetriebeispiele. Der Eintrag des Archivs ist die Quelle dafür, und das Archiv ist ein sekundärer Datensatz, nicht der Anbieter.

Eine Suche nach unabhängiger Berichterstattung fördert denselben Absatz an mehr als einer Stelle zutage: Die Schlagzeile über den OBO-Flow und den Blast Radius erscheint unter anderem syndiziert auf forkast.news und auf Yahoo Tech. Durch Syndizierung wird diese Berichterstattung zu einer Quelle, nicht zu mehreren. Keines der für diesen Artikel geprüften Medien veröffentlichte eigene Telemetrie, einen Proof of Concept oder eine Reproduktion des Mechanismus.

Was gesichert ist, was beschrieben wird und was nie behauptet wurde

Das Archiv bewertet diesen Eintrag mit A – gut dokumentiert, die Primärquellen stimmen überein – und kennzeichnet ihn nicht als umstritten. Es verzeichnet keinen Schaden in der realen Welt. Diese Bewertung bezieht sich auf die Kernfakten des Eintrags, und diese stimmen tatsächlich über die Quellen hinweg überein; sie ist nicht die Behauptung, dass jeder Satz im Eintrag unabhängig reproduziert worden ist.

• Vom Anbieter festgestellt. CVE-2026-62830 betrifft Azure SRE Agent, ist CWE-862 Missing Authorization, hat einen CVSS-3.1-Basisscore von 9,9 und einen Temporal Score von 8,6, erforderte keine Kundenaktion, wurde nicht öffentlich offengelegt und wurde nicht als ausgenutzt verzeichnet.

• Durch unabhängige Sicherheitsberichterstattung und -anreicherung bestätigt.Die Patch-Tuesday-Zusammenfassung von Cisco Talos für August 2026 führt die CVE mit derselben 9,9 und derselben Schwachstelle der fehlenden Autorisierung auf und ordnet sie Microsofts Einschätzung der Ausnutzung als „weniger wahrscheinlich“ zu. Die über NVD erfasste SSVC-Bewertung von CISA stuft die Ausnutzung als keine, die Automatisierbarkeit als nein und die technische Auswirkung als total ein. Die Anreicherung von OpenCVE führt einen EPSS-Wert von 0,00778 auf und verzeichnet, dass die CVE nicht im Known Exploited Vulnerabilities-Katalog von CISA enthalten ist.

• Beschrieben, nicht unabhängig bestätigt. Der OBO-Token-Exchange-Fehler, die Vererbung der verwalteten Identität des Agenten sowie die Auswirkungen auf Runbook, Telemetrie und Infrastruktur stammen aus dem Eintrag des Archivs und aus syndizierter Sekundärberichterstattung. Die Advisory von Microsoft nennt sie nicht. Sie sind der nützlichste und zugleich am wenigsten dokumentierte Teil der Aufzeichnung.

• Nirgendwo belegt. Keine Ausnutzung, kein Opfer, kein öffentlicher Proof of Concept, keine Buildnummer und kein Bereich betroffener Versionen. Microsofts Einschätzung zur Ausnutzbarkeit – öffentlich offengelegt: Nein, ausgenutzt: Nein, weniger wahrscheinlich – kommt einem Statusbericht am nächsten.

• Eine Mainstream-Berichterstattung fehlt. Suchen nach dieser CVE in der allgemeinen Technologie- und Sicherheitspresse lieferten keinen Artikel von The Register, BleepingComputer, SecurityWeek oder Help Net Security. Ihre öffentliche Sichtbarkeit besteht aus dem Herstellerhinweis, Schwachstellendatenbanken, einer Patch-Tuesday-Zusammenfassung und dem syndizierten Beitrag. Für eine 9,9 ist das ungewöhnlich, und es ist eine Tatsache über den Eintrag und kein Urteil über das Risiko.

Die Fehlerbehebung und die Prüfungen, die sie überdauern

Da Azure SRE Agent ein gehosteter Dienst ist, wurde die Korrektur auf Microsofts Seite angewendet. Es gibt kein Update zu installieren, keine Buildnummer, die mit einem Inventar abgeglichen werden könnte, und keine Möglichkeit für einen Kunden, von außen zu bestätigen, dass ein Tenant vor einem bestimmten Datum geschützt war. Microsofts Position ist, dass keine Maßnahme erforderlich ist, und für die Schwachstelle selbst ist diese Position korrekt.

Der Eintrag des Archivs ergänzt Hinweise, die der Sicherheitshinweis nicht ausdrücklich nennt: Prüfen Sie Zuweisungen verwalteter Identitäten, überprüfen Sie RBAC im Abgleich mit dem, was der Agent tatsächlich benötigt, und überwachen Sie anomale Rechteausweitungen. Diese Hinweise stammen vom Archiv und sind kein Zitat von Microsoft.

Die praktische Konsequenz ergibt sich aus der Architektur und nicht aus einer Empfehlung irgendeiner Quelle; behandeln Sie sie daher als Schlussfolgerung. Wenn die Berechtigung des Agenten in seinen Rollenzuweisungen besteht, dann sind die dauerhaften Kontrollen der Umfang dieser Zuweisungen und die Aufbewahrung der Control-Plane-Protokolle, die deren Verwendung belegen würden. Eine dienstseitige Korrektur schließt den Pfad; sie verengt nicht rückwirkend eine verwaltete Identität, die übermäßig bereitgestellt wurde, und sie kann einer Organisation nicht helfen, die die Protokolle nicht aufbewahrt hat. Beides sind Dinge, die ein Kunde auch nach dem Schließen der CVE noch besitzt.

Wo es in der August-2026-Charge liegt

Die Zusammenfassung von Talos macht den Vergleich unumgänglich. In diesem Monat listet sie außerdem CVE-2026-59118 in Copilot Cowork auf, eine Rechteausweitung durch unsachgemäße Autorisierung mit einer Bewertung von 9,3, sowie CVE-2026-56162 in Azure SQL Database, eine Rechteausweitung mit einer Bewertung von 10,0. Die einzige Schwachstelle, die Talos in diesem Monat als in freier Wildbahn ausgenutzt meldet, war keine von beiden: Es handelte sich um CVE-2026-68820 in Windows AFD for WinSock. Die Einträge zu KI-Produkten in Talos' Liste sind Autorisierungsfehler, und genau das ist die spezifische Ausprägung des Risikos, das dieser Eintrag dokumentiert.

Nichts davon macht CVE-2026-62830 zu einem Sicherheitsvorfall. Es ist ein Transparenz-CVE für einen Dienst, der bereits behoben wurde, veröffentlicht, damit Kunden sehen können, was falsch war, und ihre eigenen Konfigurationen überprüfen können. Der Wert dieses Eintrags liegt in der Konfigurationsfrage, die er hinterlässt – was die Identität des Agenten erreichen konnte und ob jemand bemerkt hätte, wenn sie verwendet würde – nicht in einem einzuplanenden Patch.