Stellen Sie sich vor, Ihr Schliesssystem fuer das gesamte Unternehmen ist ein hochwertiges, biometrisches Türschloss. Und dann erfahren Sie, dass derselbe Hersteller – ohne Ihr Wissen – einen Wartungsschacht in jeder Tür eingebaut hat, durch den jemand mit der richtigen Stimme einen Schlüsselrohling herausreichen kann. Genau diese Form von strukturellem Vertrauensbruch hat Microsoft am 13. Mai 2026 mit der Offenlegung von CVE-2026-41615 in der eigenen Authenticator-App quittiert. Eine Schwachstelle, die nicht eine Random-User-Schicht oder ein Randszenario betrifft, sondern den Mechanismus, der in deutschen Mittelständlern flaechendeckend als zweite Faktor-Linie zwischen einem geleakten Kennwort und der Microsoft-365-Mailbox des Geschaeftsfuehrers steht.

Was die Schwachstelle technisch macht

CVE-2026-41615 ist im Microsoft-Sprachgebrauch eine Information Disclosure Vulnerability. Klingt unspektakulaer. Die Information, die hier offengelegt wird, ist allerdings ein gueltiges Sign-in Access Token fuer das Arbeitskonto eines Anwenders. Microsoft selbst weist der Luecke einen CVSS-Score von 9.6 zu (NIST stuft sie milder mit 7.4 ein – der Unterschied ergibt sich aus der Bewertung des Confidentiality-Impacts auf das gesamte Identitaetsoekosystem). Beide Werte sind im operativen Alltag des Mittelstands hoch relevant. Denn ein Access-Token in einer modernen Entra-ID-Umgebung ist genau das Artefakt, das die zweite Faktor-Pruefung bereits hinter sich hat. Wer ihn besitzt, ist authentifiziert. Punkt.

Der Angriffspfad sieht in Microsofts Beschreibung so aus: Der Angreifer kontaktiert den Nutzer ueber einen vorgelagerten Social-Engineering-Schritt, etwa eine ueberzeugend gefaelschte Compliance-Mail oder eine fingierte Helpdesk-Konversation. Das Opfer bekommt eine Push-Benachrichtigung in der Authenticator-App, die wie eine normale Sign-in-Bestaetigung wirkt. Bestaetigt der Nutzer den Request, gibt die App – und das ist der eigentliche Bug – das resultierende Access-Token nicht ausschliesslich an den vom legitimen Service aufgerufenen Endpunkt zurueck, sondern erlaubt unter bestimmten Konstellationen, dass es an einen vom Angreifer kontrollierten Endpunkt weitergereicht wird. Der Nutzer sieht keine eindeutige Information, an welchen Empfaenger der Token gerade ausgestellt wird.

Warum das Ihr Mittelstands-Setup betrifft – nicht nur "die anderen"

Die typische Entra-ID-Architektur eines deutschen Mittelstaendlers sieht heute folgendermassen aus: Hybrid Join, Sync ueber Entra Connect, Conditional Access mit der Anforderung "Compliant Device" oder "MFA required", und als zweiter Faktor in 80 bis 90 Prozent der Faelle die Microsoft Authenticator App, oft mit aktivierter Number-Matching-Pflicht. Genau in dieser Konfiguration entfaltet CVE-2026-41615 sein volles Schadpotenzial:

  • Ein durch CVE-2026-41615 erbeutetes Token ist nicht "irgendein" Cookie, sondern ein bereits MFA-erfuellter Zugang – Conditional-Access-Regeln, die "MFA required" verlangen, greifen nach der Token-Ausstellung nicht mehr.
  • Wenn das Token mit dem Scope einer Office-365-Session ausgestellt wurde, reicht es typischerweise fuer Outlook Web Access, SharePoint Online und Teams. Das ist exakt der Datenkorpus, ueber den interne Compliance-Vorfaelle und Faktur-Manipulationen laufen.
  • Der Angriff hinterlaesst in den Sign-in-Logs einen einzelnen Eintrag, der wie eine regulaere Anmeldung aussieht. Klassische Token-Replay-Detection bei der Sentinel-Korrelation schlaegt nur dann an, wenn das Token aus einem deutlich abweichenden Geoblock oder von einem nicht registrierten Device kommt – beides laesst sich mit billigen Residential-Proxies maskieren.

Aus unserer Praxisbeobachtung in Projekten zur Informationssicherheit: Die meisten Mittelstaendler haben in ihren Conditional-Access-Policies aktuell keine Token-Lifetime-Restriktionen unter 24 Stunden konfiguriert. Ein gestohlenes Access-Token bleibt also rund einen Tag aktiv – mehr als genug fuer Datenexfiltration, Mail-Forwarding-Regeln oder den Bau persistenter Inbox-Rules, die spaeter den Mensch-in-der-Mitte-Angriff (AiTM) auf weitere Konten ermoeglichen.

Welche Versionen geheilt sind

Microsoft hat den Fix bereits in die App Stores eingespielt. Damit Sie nicht im Sicherheitsbeauftragten-Daily zu fruh oder zu spaet beruhigen, hier die belastbaren Versionsangaben:

  • Android: Microsoft Authenticator 6.2605.2973 und neuer
  • iOS: Microsoft Authenticator 6.8.47 und neuer

Die Verteilung ueber Apple App Store und Google Play laeuft seit dem 13. Mai. Wer die "Automatische App-Aktualisierung" auf den Endgeraeten erlaubt, hat – statistisch betrachtet – innerhalb von 48 Stunden die geheilte Version. Genau hier liegt aber das Problem fuer den geregelten Unternehmenseinsatz: BYOD- und CYOD-Geraete ohne Intune-Compliance-Pflicht haengen oft drei bis vier Wochen mit veralteten App-Versionen herum. Wer die Authenticator-App auf privaten Geraeten der Mitarbeiter laufen laesst (was viele KMU aus Kostengruenden tun), kann die Patch-Verteilung nicht erzwingen.

Die fuenf konkreten Schritte fuer die naechsten 72 Stunden

Aus der Analyse vergleichbarer Token-Disclosure-Faelle aus den vergangenen achtzehn Monaten (Storm-2372-Kampagne, Midnight-Blizzard-Token-Theft Mitte 2025, der Sentry-Vorfall vom Mai 2026) hat sich ein klarer Reaktionsablauf bewaehrt:

1. Sofortige Inventarisierung Ihrer Authenticator-Population

Im Microsoft Entra Admin Center finden Sie unter "Authentication Methods" > "User Registration Details" einen Export der bei den Nutzern aktiven MFA-Methoden. Filtern Sie auf Microsoft Authenticator (push) und ziehen Sie eine CSV. Im Intune-Tenant koennen Sie ueber die App-Inventory abfragen, welche Authenticator-Version pro Geraet installiert ist. Geraete mit Versionen unterhalb der oben genannten Werte sind aktuell verwundbar.

2. Conditional-Access-Policy nachschaerfen

Aktivieren Sie – falls noch nicht geschehen – Token Protection (Token Binding) als Anforderung in Conditional-Access fuer die hochsensiblen Apps (Exchange Online, SharePoint, Teams). Token Protection bindet ein ausgestelltes Access-Token kryptografisch an das Geraet, auf dem es ausgestellt wurde. Selbst ein durch CVE-2026-41615 geleaktes Token kann dann nicht von einem anderen Endgeraet aus eingesetzt werden. Die Funktion ist seit Mitte 2024 GA – nur eingeschaltet ist sie in den meisten Mittelstands-Tenants nicht.

3. Sign-In Logs aktiv durchsehen

Im Entra Sign-In-Log greifen Sie auf einen 30-Tage-Fenster mit den Filtern Status: Success, Authentication Details: MFA via Authenticator push, sortiert nach IP-Adressen. Suchen Sie nach Anmeldungen aus untypischen Subnetzen, Anmeldungen mit ungewoehnlicher User-Agent-Kette oder gehaeuften Logins aus zwei geografisch weit entfernten Standorten innerhalb kurzer Zeit. Microsoft Sentinel hat seit dem 14. Mai eine vorgefertigte Analytics Rule veroeffentlicht ("Authenticator Token Disclosure – Suspicious Sign-in Pattern"), die genau dieses Muster aufgreift.

4. Token-Lifetime-Policy nachjustieren

Der Default fuer Refresh-Token in Entra ID liegt bei 90 Tagen, fuer Access-Token bei einer Stunde mit Sliding Window. Fuer hochwertige Rollen (Geschaeftsfuehrung, CFO, IT-Admins) sollte das Refresh-Token-Lifetime auf 24 Stunden, das Sign-In-Frequency-Intervall auf 4 Stunden gesetzt werden. Die zusaetzliche Anmeldefriktion ist diskutabel, der Sicherheitsgewinn ist erheblich – ein geleaktes Token verfaellt deutlich schneller.

5. Migration zu phishing-resistenter Authentifizierung

Strategisch ist CVE-2026-41615 ein weiteres Argument, die Authenticator-App als alleinige zweite Faktor-Linie zu verlassen. FIDO2-Sicherheitsschluessel und Windows Hello for Business (Passkey) liefern phishing-resistente Authentifizierung, weil das kryptografische Material das Endgeraet nicht verlaesst und Tokens an die Origin (Domain) gebunden werden. Fuer privilegierte Konten ist diese Migration in 2026 nicht mehr Kuer, sondern Pflicht – auch im Hinblick auf die NIS2-konforme Identitaetsarchitektur, die das BSI im Cybersicherheitsmonitor 2026 fuer schutzbeduerftige Institutionen ausdruecklich einfordert.

Was die Schwachstelle uns ueber Vertrauen in Authentifizierungs-Stacks lehrt

CVE-2026-41615 ist keine Einzelpanne. Sie reiht sich in eine Folge von Schwachstellen ein, die im Jahr 2026 das Vertrauen in MFA-Apps als alleinigen zweiten Faktor systematisch unterminieren: der Sentry-SAML-Vorfall im Mai, die Token-Replay-Welle ueber den AiTM-Phishing-Kit "Mamba2FA" Ende April, die GTIG-Recherche zum ersten KI-generierten 2FA-Bypass. Das Muster ist immer dasselbe – Angreifer attackieren nicht das Passwort, sondern den Token-Lebenszyklus hinter der MFA-Bestaetigung.

Fuer die Sicherheitsarchitektur des Mittelstands bedeutet das zweierlei. Erstens: Ein Mehr-Faktor-Authentifizierungssystem ist nicht "fertig", weil es einmal eingefuehrt wurde. Token-Binding, Continuous-Access-Evaluation und Phishing-Resistenz sind die Bausteine, die heute zur Baseline gehoeren. Zweitens: Die Identitaet ist heute der eigentliche Perimeter. Wer seine Conditional-Access-Policies, sein Privileged-Access-Management und seinen Logging-Stack noch aus den Jahren 2022/23 herueberzieht, laeuft mit veralteten Annahmen gegen eine Bedrohungslandschaft, die sich seit Anfang 2025 erkennbar verschoben hat.

Fazit

CVE-2026-41615 ist ein lautstarkes Argument dafuer, dass eine "MFA aktiv" – Haekchen-Antwort im Audit nicht ausreicht. Wer als IT-Verantwortlicher im Mittelstand in den naechsten Tagen die fuenf oben skizzierten Schritte abarbeitet, hat die unmittelbare Angriffsflaeche zu CVE-2026-41615 weitgehend geschlossen. Wer parallel die Wende zu phishing-resistenter Authentifizierung einleitet, ist beim naechsten Token-Disclosure-Vorfall – und der kommt – strukturell nicht mehr verwundbar.

Wenn Sie Unterstuetzung bei der Conditional-Access-Anpassung, der Migration zu FIDO2-Schluesseln oder der Sentinel-Korrelationsregel fuer Token-Anomalien benoetigen, koennen Sie unser Team ueber das Kontaktformular erreichen. Eine Uebersicht ueber unsere Identitaets- und Sicherheitsleistungen finden Sie auf der Seite Leistungen.