CVSS 10.0. Nichts zu patchen.
Ein kritischer CVSS-Basiswert bedeutet nicht automatisch, dass im eigenen Betrieb ein Update fehlt. Microsoft hat CVE-2026-109469 in Entra Device Registration bereits dienstseitig behoben.
Der Höchstwert und die Zuständigkeit
Eine 10,0 im Schwachstellenbericht zieht Aufmerksamkeit auf sich. Für die Bearbeitung brauche ich danach aber eine konkrete Antwort: Wer betreibt die betroffene Komponente, was ist bereits behoben und welche Maßnahme verlangt der Hersteller? Der Zahlenwert allein füllt kein sinnvolles Änderungsticket.
Microsoft veröffentlichte CVE-2026-109469 am 5. November 2026 für Entra Device Registration. MSRC bewertet die Rechteausweitung als kritisch mit einem CVSS-3.1-Basiswert von 10,0. Die Beschreibung nennt einen Authorization Bypass über einen vom Nutzer kontrollierten Schlüssel, eingeordnet als CWE-639.
Microsoft hat den Dienst bereits korrigiert
Die Hersteller-FAQ ist hier eindeutig: Microsoft hat die Schwachstelle bereits vollständig mitigiert. Nutzer des Dienstes müssen dafür keine Maßnahme ergreifen. Der CVE-Eintrag dient nach Microsofts Angabe der Transparenz.
Für die eigene Bearbeitung würde ich deshalb den Herstellerstatus und das Datum der Prüfung dokumentieren. Eine lokale Patchsuche wäre aus dieser Meldung nicht abzuleiten. Ebenso wenig würde ich pauschal Konfigurationen verändern, wenn dafür weder ein Herstellerauftrag noch ein konkreter Befund vorliegt.
Statusangaben ohne zusätzliche Geschichte lesen
Im am 8. November geprüften MSRC-Eintrag stehen öffentlich offengelegt und ausgenutzt jeweils auf „No“. Die Ausnutzbarkeit wird als „Exploitation Less Likely“ bewertet. Das sind die Angaben des Herstellers zum Eintrag; daraus entsteht kein Nachweis über die Vergangenheit eines bestimmten Mandanten.
Microsoft beschreibt eine mögliche Rechteausweitung über das Netzwerk, veröffentlicht dort aber keinen detaillierten Angriffsablauf. Ich würde deshalb keine erfundenen Voraussetzungen, Täter oder betroffenen Kunden ergänzen. Gerade bei einem hohen Schweregrad gehört diese Grenze zur Einordnung.
Eine freiwillige Geräteprüfung sauber benennen
Unabhängig von dieser CVE würde ich bei einer ohnehin anstehenden Tenant-Prüfung neue Geräteobjekte und vorhandene Audit-Einträge zur Registrierung ansehen. Passen die Einträge zu den erwarteten Vorgängen? Sind Verantwortliche und Registrierungswege nachvollziehbar?
Das ist meine allgemeine Empfehlung zur Bestandsprüfung. Sie ist keine zusätzliche Microsoft-Maßnahme für diese bereits behobene Lücke und kein Hinweis auf deren Ausnutzung. Ein unerwarteter Eintrag wäre zunächst eine offene Frage, die mit dem zuständigen Team geklärt werden muss.
Für die Dokumentation würde ich festhalten, welcher Zeitraum anhand verfügbarer Protokolle geprüft werden konnte und welche Fragen offenbleiben. Fehlende Daten sollten sichtbar bleiben, statt durch eine pauschale Entwarnung ersetzt zu werden.
Cloud-Meldungen brauchen einen passenden Abschluss
Mein Abschluss wäre hier ein nachvollziehbarer Vermerk: Dienstseitig behoben laut aktuellem Herstellerhinweis, keine Kundenmaßnahme gefordert, Quelle und Prüfzeitpunkt dokumentiert. Eine zusätzlich durchgeführte Bestandsprüfung würde ich getrennt festhalten.
So bleibt erkennbar, was aus der Sicherheitsmeldung folgt und was zur eigenen laufenden Betriebshygiene gehört. Die kritische Einstufung wird damit ernst genommen, ohne eine bereits erledigte Anbietermaßnahme als fehlendes Kundenupdate auszugeben.