In Microsoft Office 2016 bis 2024 sowie Office 365-Apps gibt es eine 0-day-Schwachstelle CVE-2026-21509, die in Angriffen aktiv ausgenutzt wird. Microsoft hat zum 26. Januar 2026 erste Informationen und serverseitig Notfall-Updates für Microsoft Office 2021 und höher veröffentlicht. Für Microsoft Office 2016 und 2019 gibt es (inzwischen) Updates. Administratoren und Nutzer sollten dringend patchen, sobald die Updates verfügbar sind, und vorher einen Registrierungseintrag setzen, um sich vor der Schwachstelle zu schützen. Ergänzung: Update für Office 2026 und neue Build für Office 2019 verfügbar.
Seit einigen Stunden überschlagen sich die Meldungen auf meinen Social Media-Kanälen. Ich stelle mal nachfolgenden Tweet mit den Informationen zum Sachverhalt hier ein.
Microsoft Office 0-day-Schwachstelle CVE-2026-21509
In Microsoft Office gibt es die 0-day-Schwachstelle CVE-2026-21509, die in Angriffen aktiv ausgenutzt wird. Es handelt sich um eine Security Feature Bypass-Schwachstelle, die mit einem CVSS 3.1-Scrore von 7.8 als Important eingestuft wurde.
Microsoft umschreibt es so, dass nicht vertrauenswürdige Eingaben bei einer Sicherheitsentscheidung in Microsoft Office zugelassen sind. Konkret sind wohl Prüfungen von OLE-Aufrufen in Microsoft 365 und Microsoft Office, die Benutzer vor anfälligen COM/OLE-Steuerelementen schützen sollen, unzureichend.
Sicherheitsforscher HaifeiLi vermutet, dass hier der alte Internet Explorer-Browser über OLE/COM-Aufrufe als Angriffsvektor missbraucht wird.
Dies ermöglicht es einem unbefugten Angreifer, eine Sicherheitsfunktion lokal zu umgehen. Ein Angreifer muss einem Benutzer allerdings eine bösartige Office-Datei senden und ihn dazu bringen, diese zu öffnen. Das ist schon mal gut, die reine Anzeige in der Vorschau reicht nicht zur Ausnutzung.
Welche Office-Versionen sind betroffen?
Die Schwachstelle ist öffentlich bekannt geworden und bereits durch Angreifer ausgenutzt worden. Betroffen sind faktisch alle Office-Versionen ab Microsoft Office 2016 aus folgender Auflistung:
- Microsoft Office 2016 (64 Bit)
- Microsoft Office 2016 (32-Bit)
- Microsoft Office 2019 (64 Bit)
- Microsoft Office 2019 (32-Bit)
- Microsoft Office LTSC 2021 (32-Bit)
- Microsoft Office LTSC 2021 (64 Bit)
- Microsoft Office LTSC 2024 (64 Bit)
- Microsoft Office LTSC 2024 (32-Bit)
- Microsoft 365 Apps for Enterprise (64 Bit)
- Microsoft 365 Apps for Enterprise (32-Bit)
Nutzern und Administratoren bleibt nur noch, Gegenmaßnahmen einzuleiten, um einen Schutz vor der Schwachstelle zu haben.
Updates (noch) nicht für alle Office-Versionen
Bezüglich des Schutzes der Nutzer vor der Ausnutzung der Schwachstelle fährt Microsoft einen unterschiedlichen Ansatz. Anwender von Microsoft Office 2021 und höher werden laut Microsoft automatisch durch eine serverseitige Änderung geschützt. Die Nutzer müssen jedoch ihre Microsoft Office-Anwendungen neu starten, damit diese Änderung wirksam wird.
Update für Office 2016 (MSI-Version)
Ergänzung: Microsoft ist schnell – wie ich nachfolgendem Kommentar entnehmen kann. Microsoft hat für Office 2016 (MSI-Version) das Out-of-Band-Update KB5002713 zum 26. Januar 2026 freigegeben. Dieses Update ist über Microsoft Update verfügbar, kann aber auch über den Microsoft Update-Katalog manuell heruntergeladen und installiert werden.
Noch keine C2R-Updates für Office 2016/2019?
Für die Click-2-Run-Versionen von Microsoft Office 2016 und Microsoft Office 2019 stehen derzeit noch keine Sicherheitsupdate zur Verfügung. Für Office 2019 habe ich im Microsoft Update Catalog bisher nur zwei Dateien für den Systemcenter-Manager gefunden (ob die das C2R-Update für die Build 10417.20095 ziehen, weiß ich nicht).
Laut dieser Microsoft-Seite ist am 26. Januar 2026 Microsoft Office 2019 Version 1808 (Build 10417.20095) veröffentlicht worden. Für Microsoft Office 2016 C2R habe ich keine neueren Builds gefunden (die Version ist ja im Oktober 2025 aus dem Support gefallen). Diese Nutzer bzw. deren Administratoren müssen nachfolgenden Schutzmaßnahmen ergreifen.
Ergänzung: Auf der Microsoft Seite zur Schwachstelle CVE-2026-21509 heißt es, dass Microsoft zum 26. Januar 2026 Updates für die C2R-Versionen von Office 2016 Build 16.0.5539.1001 und Office 2019 Build 16.0.10417.20095 zum Schließen der Schwachstelle freigegeben habe.
Workaround zum sofortigen Schutz
Microsoft hat auf der Supportseite zu CVE-2026-21509 Workarounds angegeben, um auch Microsoft Office 2016 und Microsoft Office 2019 sofort gegen diese Schwachstelle zu schützen.
Zuerst sollten alle Microsoft Office-Anwendungen geschlossen werden. Für die zu schützende Office-Version ist ein neuer Unterschlüssel mit dem Namen {EAB22AC3-30C1-11CF-A7EB-0000C05BAE0B} in der Registrierung einzufügen. Ab Microsoft Office 2016 gilt folgender Schlüssel:
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Office\16.0\Common\COM Compatibility\{EAB22AC3-30C1-11CF-A7EB-0000C05BAE0B}
Im betreffenden Schlüssel ist der 32-Bit-DWORD-Wert Compatibility Flags hinzuzufügen und auf 400 zu setzen. Microsoft sagt nichts dazu, aber im Anschluss an das Hinzufügen der Registrierungsschlüssel und -Werts würde ich Windows neu starten.
Anmerkung: Die Kollegen von Bleeping Computer geben in diesem Beitrag weitere Registrierungszweige (WOW6432Node, ClickToRun) an, die um den CLSID-Eintrag und den REG_DWORD-Wert zu erweitern (aber nicht ganz korrekt) sind. Beachtet daher die Hinweise von Bolko hier im Kommentar, der die korrekten Registrierungseinträge benennt.
Ergänzung: Die Sicherheitsexperten von ACROS Security sichern Office mit 0patch Micropatches gegen die obige Schwachstelle ab (siehe 0patch Micropatch für Microsoft Office-Schwachstelle CVE-2026-21509).
Ähnliche Artikel:
Microsoft Security Update Summary (13. Januar 2026)
Patchday: Windows 10/11 Updates (13. Januar 2026)
Patchday: Windows Server-Updates (13. Januar 2026)
Patchday: Microsoft Office Updates (13. Januar 2026)
Windows SQLite DLL-Problem mit Januar 2026 Updates behoben
Windows Januar 2026 Update tauscht Secure Boot Zertifikate
Windows 11 23H2: Januar 2026-Update KB5073455 macht Shutdown-/Sleep-Problem
Windows Januar 2026-Updates verursachen Verbindungs- und Authentifizierungsfehler
Windows 11 24H2/25H2: Citrix Director / Remote Assist funktioniert mit KB5074109 nicht mehr
Windows 11 24H2/25H2: Outlook Classic POP3-Abrufe hängen nach Update KB5074109
Windows: Out-of-Band-Update KB5077744 korrigiert Verbindungs- und Authentifizierungsfehler nach Jan. 2026-Updates
Windows 11 23H2: Out-of-Band-Update KB5077797 korrigiert Shutdown-/Sleep-Problem
Windows Telefonie-Server nach Januar 2026-Update nicht mehr erreichbar?
Januar 2026 Patchday-Nachlese: Probleme mit Windows, Office etc.
Windows: Out-of-Band-Updates sollen Outlook-Hänger beseitigen (24.1.2026)
Windows 11 24H2-25H2 Update KB5074109: Deinstallation wirft Error 0x800f0905
Windows 11 24H2/25H2: Januar 2026-Update KB5074109 verursacht Boot-BSOD-Problem
MVP: 2013 – 2016
Es gibt bereits ein Update für Office (Word) 2016
https://support.microsoft.com/de-de/topic/beschreibung-des-sicherheitsupdates-f%C3%BCr-office-2016-26-januar-2026-kb5002713-32ec881d-a3b5-470c-b9a5-513cc46bc77e
https://www.catalog.update.microsoft.com/Search.aspx?q=office%202016
Zitat:
"werden laut Microsoft automatisch durch eine serverseitige Änderung geschützt"
—
"serverseitige Änderung"?
Im Microsoft-Artikel steht:
"service-side change"
"Service" ist nicht das selbe wie "Server".
"Server" ist auch falsch, denn Office ist auch ohne einen Server lauffähig und wenn es keinen Server gibt, kann der Server auch nicht diesen Fehler beseitigen.
Mit diesem "Service" ist folgendes gemeint:
"Enhanced Configuration Service (ECS)":
ECS provides Microsoft the ability to reconfigure Office installations without the need for you to redeploy Office.
It's used to control the gradual rollout of features or updates, […].
It's also used to mitigate security or performance issues with a feature or update.
learn. microsoft. com/en-us/microsoft-365-apps/privacy/essential-services
2.
Die CLSID {EAB22AC3-30C1-11CF-A7EB-0000C05BAE0B}
steht für "Shell.Explorer.1" = WebBrowser_V1 = "Microsoft Web Browser Version 1" = ieframe.dll = Internet Explorer
Damit ist die Vermutung des Sicherheitsforschers HaifeiLi korrekt.
3.
"Compatibility Flags"=dword:00000400
ist das Kill-Bit ("COMPAT_EVIL_DONT_LOAD").
Im Registry-Editor darauf achten, dass man es hexadezimal eingibt und nicht dezimal.
learn. microsoft. com/en-us/previous-versions/windows/internet-explorer/ie-developer/platform-apis/aa768234(v=vs.85)?redirectedfrom=MSDN
In der CVE-Meldung von Microsoft ist "Compatibility Flags" leider nicht hervorgehoben (Anführungszeichen oder Fettschrift).
Wie kann man sich eigentlich sicher seinm, dass diese "Enhanced Configuration Service (ECS)" Daten auch wirklich angekommen sind?
Bei der falschen EOS-Meldung von Win10 LTSC 2021 hatte Microsoft auch versucht, per Konfigurationsnachricht das Problem zu fixen, aber diese Nachricht kam nicht überall durch, etwa weil die Telemetrie gesperrt war oder ein Port in der Firewall nicht offen war.
Es ist also ratsam, auf jeden Fall diese Registry-Änderungen vorzunehmen, solange man die von Microsoft geplante bzw behauptete ECS-Konfigurationsänderung nicht selber irgendwie verifizieren konnte.
***************************************
Ein Angreifer muss einem Benutzer allerdings eine bösartige Office-Datei senden und ihn dazu bringen, diese zu öffnen.
***************************************
Das Wichtigste an der Ganzen Meldung! Damit ist die "Zielgruppe" auch wieder eindeutig definiert.
Interessant wäre noch: seit wann weis MS davon und haben sie erst jetzt wo es öffentlich bekannt ist gepatcht? oder sind sie tatsächlich mal schnell unterwegs?
"Damit ist die "Zielgruppe" auch wieder eindeutig definiert."
Oh jeh… Ich hoffe du bist nirgendwo für die IT-Sicherheit zuständig.
Die Attributierung "Zielgruppe" hilft im Kontext nicht weiter – habe daher die Folgekommentare gelöscht.
Erklärung für die Leserschaft: Erstens hilft es Administratoren nicht, wenn etwas durch einen Nutzer passiert ist. Und zweitens springt die Attributierung wieder zu kurz. Abseits dessen, dass es Vorgänge geben kann, wo für das Opfer nicht oder kaum erkennbar ist, dass das bösartig ist, hat sich die Erkenntnis noch nicht durchgesetzt, dass gerade eine Welle von KI-Bots mit eigenständigen Funktionen von Marketing-Menschen, Managern und extrem Fortschrittsgläubigen losgetreten bzw. losgelassen wird. Da dürften künftig noch Überraschungen lauern.
Nur als gedankliche Anregung – ich hatte vorgestern den Artikel Clawdbot: Ein OpenSource KI-Assistent – cool und ein Sicherheitsdesaster hier im Blog. Da sitzen Tausende Enthusiasten in ihren Büros und setzen Testinstallationen von Moltbot (wie es nun heißt) auf, ohne einen Blick in die Dokumentation zu werfen und die VPS-Instanzen abzusichern. Es liegen Tausende "Geheimnisse" auf angreifbaren VPS-Instanzen offen im Internet herum.
Den Vogel schießt aber der vom US-Präsidenten Trump eingesetzte Interimsdirektor der US-Cybersicherheitsbehörde CISA ab. Der gibt einfach mal vertraulich-sensitives Material in die öffentlichen Instanz von ChatGPT zum Verwursteln. Hab es die Nacht im Text nachgetragen. Wenn bereits die "Köpfe" spektakulär scheitern, brauchen wir uns in obigem Kontext nicht mehr um "Zielgruppe" gedanklich zu kümmern, sondern sollten pronto zu "könnte jeden treffen" kommen. Meine 2 Cent.
@Günter
2019 gibt es afaik nur als C2R. Daher wird es über den Katalog wohl nichts geben.
Du hast Recht – Asche auf mein Haupt.
????
ich habe auf meinem rechner (windows 10) office 2019 in der version 1808 (aus fernost) und auf einem anderen rechner (windows 11) gibt es office 2019 in der version 2508 (eigentlich auch aus fernost, weiß nicht, was da schief lief. insofern, auf dem ersten Rechner gab es einen Patch, auf dem zweiten rechner einen registry eintrag siehe meinen Kommentar unten.
Und jetzt die Frage aller Fragen: wie kann ich sicherstellen dass meine C2R Installationen auch den "Patch" von Microsoft automatisch erhalten haben?
Da verlangt jemand nachvollziehbare Änderungen durch den (US)-Hersteller!!! AUF DEN PODEN MIT DEM PURSCHEN!!! Nein, ernsthaft. Das würde mich auch brennend interessieren.
Wie sieht denn eure Konfiguration (config.office.com) aus?
Das würde mich auch interessieren.
Über Datei > Konto erfahre ich nur, dass ich auf dem Build bin
Office 2024 LTSC: Version 2408 (Build 17932.20638 C2R)
Update-Optionen > Jetzt aktualisieren: "Sie sind auf dem neuesten Stand"
Gemäß dieser Seite stimmt das ja auch:
https://learn.microsoft.com/de-de/officeupdates/update-history-office-2024
Veröffentlichungsdatum Versionsnummer
Dienstag, 13. Januar 2026 Version 2408 (Build 17932.20638)
Aber wie weiß ich ich ob die per "Enhanced Configuration Service (ECS)" vorgenommenen Änderungen angekommen sind?
hinter dem Link oben zu Bleeping Computer sind mehrere Registry-Einträge dokumentiert. Die meisten werden den für 32bit ClickToRun brauchen und da sind bei mir schon eine ganze Menge anderer eingetragen.
Wenn Office nach Hause telefonieren darf, kann es auch diesen Hotfix holen und den passenden Regkey setzen.
Und wenn man nachsieht ob er schon da ist, kann man ihn notfalls auch gleich eintragen.
Und außerdem sollte man sowieso keine Office-Dateien aus unbekannten Quellen öffnen…
So lange hier nichts steht, gibts auch kein C2R Update:
https://learn.microsoft.com/de-de/officeupdates/update-history-office-2024
https://learn.microsoft.com/de-de/officeupdates/update-history-office-2021
https://learn.microsoft.com/de-de/officeupdates/update-history-office-2019
2019 hat gestern ein Update erhalten.
Danke für die Links
Habe für unser Office 2021 nun den Reg-Key gesetzt per GPO
Sorry, aber ich "glaube" das ist nur die halbe Wahrheit. 2021/2024 haben diesen seltsam / geheimnisvollen "ECS"-Dienst (siehe weiter oben). Meine Vermutung: wir werden kein Update bis zum nächsten Patchday von 2021/2024 sehen und ob der Dienst das gefixt hat kann man mangels Informationen nur raten/hoffen. Wir werden hier (spätestens morgen) den Reg-Key ausrollen, der "frisst kein Brot".
Mögen alle eure Neustarts geschmeidig ablaufen!
Beachtet die Microsoft-Aussage, dass Office 2021 und höher serverseitig einen Fix erhalten hat.
Ich kann jetzt irgendwie aktuell nicht nachvollziehen ob es schon einen Patch für 0365 Apps gibt und wenn ja welche Version das Problem fixt.
Hallo Zusammen,
Für alle mit WSUS on-premise hier die Import GUID vom Horror Patchday 01-2026. Ihr braucht dazu das ImportUpdateToWSUS.ps1 von MS um diese direkt in den WSUS zu importieren. Funktioniert aber sauber.
Mit dabei die GUID für die anderen Sachen wie Outlook.exe und POP3 Konten oder Outlook.exe und PST auf OneDrive bug.
Gruss aus der Schweiz ;-)
# https://www.butsch.ch, 01-2026 Patch manual import for Enterprise
#OFFICE 0day from 27.01.2026
.\ImportUpdateToWSUS.ps1 -WsusServer 127.0.0.1 -PortNumber 8530 -UpdateId aa0b784a-0e0a-406b-b7c3-dbcfacb7afae
.\ImportUpdateToWSUS.ps1 -WsusServer 127.0.0.1 -PortNumber 8530 -UpdateId 58b398fd-2b6c-4086-8756-e97edf4797ff
# Windows 11 25H2 and 24H2 from 24.01.2026
.\ImportUpdateToWSUS.ps1 -WsusServer 127.0.0.1 -PortNumber 8530 -UpdateId c969c652-75b3-4ea9-a314-c69ebb26483d
.\ImportUpdateToWSUS.ps1 -WsusServer 127.0.0.1 -PortNumber 8530 -UpdateId add5ed3b-b9ce-4cb0-8b14-1e25a01e8ed7
.\ImportUpdateToWSUS.ps1 -WsusServer 127.0.0.1 -PortNumber 8530 -UpdateId 3f6df217-5070-4c9c-ae37-9878fd2bc56f
.\ImportUpdateToWSUS.ps1 -WsusServer 127.0.0.1 -PortNumber 8530 -UpdateId 7f978d98-864d-4812-a25f-e2ab8a5f2c54
# 23H2 from 24.01.2026
.\ImportUpdateToWSUS.ps1 -WsusServer 127.0.0.1 -PortNumber 8530 -UpdateId 4b9efbc3-c039-4199-9808-d60142fd6990
.\ImportUpdateToWSUS.ps1 -WsusServer 127.0.0.1 -PortNumber 8530 -UpdateId dae2527f-1cb7-4573-b759-8c9a38ba4646
# Windows 10 23H2 and 22H2 from 24.01.2026
.\ImportUpdateToWSUS.ps1 -WsusServer 127.0.0.1 -PortNumber 8530 -UpdateId eb6cb55e-9d00-455c-8e00-0a4be69d0cf7
.\ImportUpdateToWSUS.ps1 -WsusServer 127.0.0.1 -PortNumber 8530 -UpdateId 8995ef56-ca21-4c6c-8d36-1c3669c8912d
.\ImportUpdateToWSUS.ps1 -WsusServer 127.0.0.1 -PortNumber 8530 -UpdateId f73ff6ca-9fcf-4470-9c5f-4dffcfa9ac37
.\ImportUpdateToWSUS.ps1 -WsusServer 127.0.0.1 -PortNumber 8530 -UpdateId 371ca48a-4183-4956-9c18-9da50a762ffe
.\ImportUpdateToWSUS.ps1 -WsusServer 127.0.0.1 -PortNumber 8530 -UpdateId e283195c-1c50-4c55-a599-118a7b06537e
.\ImportUpdateToWSUS.ps1 -WsusServer 127.0.0.1 -PortNumber 8530 -UpdateId b304618e-79b5-4dfc-9803-2fe0b7e8829a
# SRV2022 from 24.01.2026
.\ImportUpdateToWSUS.ps1 -WsusServer 127.0.0.1 -PortNumber 8530 -UpdateId f0bc13c2-2bf2-42d0-a7a8-80fbd2ffe9ea
# SRV2025 from 24.01.2026
.\ImportUpdateToWSUS.ps1 -WsusServer 127.0.0.1 -PortNumber 8530 -UpdateId 3f0d033a-9785-4e68-99ef-8c07baeaf9be
# SRV2019 from 24.01.2026
.\ImportUpdateToWSUS.ps1 -WsusServer 127.0.0.1 -PortNumber 8530 -UpdateId b4286606-2da0-4870-b285-20b545dc1993
.\ImportUpdateToWSUS.ps1 -WsusServer 127.0.0.1 -PortNumber 8530 -UpdateId 8688338a-3c23-4991-9868-41c4b32dcc60
.\ImportUpdateToWSUS.ps1 -WsusServer 127.0.0.1 -PortNumber 8530 -UpdateId 58a7d237-7c6b-4b1c-8e6d-05b32004b6b6
Hier unsere komplette Anleitung:
https://www.butsch.ch/post/cve-2026-21509-office-all-version-0-day-exploit/
365 Apps for Business sind demnach nicht betroffen?
Möglicherweise schon. Es ist noch ein Rätsel warum 365 Apps for Enterprise im CVE-2026-21509 aufgeführt sind und 365 Apps for Business nicht. Gemäss folgender Übersicht basieren beide Produkte auf dem gleichen Build. Der letzte Build mit Security Updates für Current Channel ist Version 2512 Build 19530.20184 vom 21. Januar 2026. Etwas neueres kommt auch nicht wenn man die Update-Funktion in der App manuell anstösst.
https://learn.microsoft.com/en-us/officeupdates/update-history-microsoft365-apps-by-date
Ich tippe auf ein Dokumentationsproblem – wäre nicht das erste Mal. Bei Microsoft 365 gehe ich nach meiner Lesart des Microsoft-Beitrags eh davon aus, dass es serverseitig durch eine bessere Prüfung der Links zum OLE-Aufruf gefixt ist.
| Etwas neueres kommt auch nicht wenn man die Update-Funktion in
| der App manuell anstösst.
Hier schon. Ich habe vor ein paar Minuten manuell die Update-Installation in Word gestartet. Es wurden Updates gefunden und installiert, aktueller Stand ist jetzt 2601 (19628.20150), so wie auf der verlinkten Seite in der Tabelle gelistet.
Ja, habe ich heute am späteren Vormittag auch gesehen und einen Kommentar hier im Artikel eingestellt. Dieser steckt aber in der Moderation oder dem Papierkorb fest. In den Release-Notes findet sich aber kein Hinweis auf die Schwachstelle CVE-2026-21509.
Ich verstehs nicht in Bezug auf Office 365 Apps for Enterprise. Es gibt keine neuere Version als 19426.20260 im Enterprise Channel. Und die Regkeys sind ja nur für 2016/2019.
Zitat:
"Und die Regkeys sind ja nur für 2016/2019."
—
Nein, die Registry-Keys gelten generell für alle Office Versionen ab einschließlich 2016, weil sich ab dann er Registry-Zweig "\Software\Office\16.0" nicht mehr verändert hat.
Da muss ich mich leider selber verbessern.
Der erste Teil meines Satzes stimmt, der zweite Teil stimmt nicht, wegen C2R.
Man bbeachte den Plural "Keys" und ich meinte die Keys aus dem CVE-Artikel von Microsoft.
Office 2016 hat den internen Codenamen "Office 16" und deswegen die erweiterte Build-Nummer "16.0".xxxx.yyyy
Deswegen schaut es in der Registry im Zweig \SOFTWARE\Microsoft\Office\16.0\
bzw bei einem 32-Bit Office auf einem 64-Bit Windows schaut es in den Zweig:
SOFTWARE\WOW6432Node\Microsoft\Office\16.0
Office 2019 war intern die zweite Version von "Office 16" und hat auch dieselben 4 Zeichen "16.0" am Anfang der erweiterten Build-Nummer und schaut auch in den selben Registry-Zweig mit der "16.0".
en. wikipedia. org/wiki/Microsoft_Office_2019
Bei vorherigen Office-Versionen hatten sich die ersten 4 Zeichen der erweiterten Build-Nummer immer geändert, aber ab 2016 blieb es bei "16.0", allerdings wurde dieses "16.0" dann auch an anderen Stellen in der Registry eingetragen, etwa unterhalb von "ClickToRun".
Ab Office 2019 wurde neben und später statt des MSI-Installers auch die Click-To-Run Methode eingeführt und deswegen schaut Office dann in den anderen Registry-Zweig
SOFTWARE\Microsoft\Office\ClickToRun\REGISTRY\MACHINE\Software\Microsoft\Office\16.0
bzw bei einem 32-Bit C2R Office auf einem 64-Bit Windows schaut es dort:
SOFTWARE\Microsoft\Office\ClickToRun\REGISTRY\MACHINE\Software\WOW6432Node\Microsoft\Office\16.0\
Also der eine Registry-Key, der hier im Artikel steht und der bei Bleeping Computer steht (dort nur als ein! Beispiel), der gilt tatsächlich nicht für die Click-To-Run-Varianten und auch nicht für 32-Bit MSI-Office auf 64-Bit Windows.
Man muss alle 4 Möglichkeiten beachten:
msrc. microsoft. com/update-guide/vulnerability/CVE-2026-21509
Also diese Reg-Datei benutzen:
borncity. com/blog/2026/01/27/microsoft-office-0-day-schwachstelle-cve-2026-21509-notfall-updates-teilweise-verfuegbar/#comment-245326
Deshalb schrieb ich, dass die "Keys" (plural) für alle Office-Versionen ab 2016 gelten, aber der eine Key hier aus dem Artiikel, der reicht nicht aus.
Mich würde ja mal interessieren warum MS so ein "Geschiss" daraus macht und OOB Updates raushaut. Macht es ja sonst auch nicht so fleissig. Da muss ja schon einiges im Busch sein, z.B. ein grösserer Anbieter der lauter verseuchte Dokumente hat.
Für Office 2019 sollte der Task "Office Automatic Updates 2.0" regelmäßig auf dem Microsoft "Office CDN" nach Updates schauen und diese automatisch holen und installieren.
learn. microsoft. com/de-de/office/2019/update
Falls Microsoft also auf ihren CDN-Servern die Updates abgelegt hat, dann kann man in diesem Fall doch von "serverseitig" gefixt sprechen.
Das wird allerdings differenziert nach Lizenz (Firma vs Privatkunde).
Für die Volumenlizenz (Firmenkunde) gilt das Soll:
Version 1808 (Build 10417.20095) vom 26.Januar 2026
Der Support für Office 2016 und 2019 lief aber am 14.Oktober 2025 aus.
Deswegen erhalten die "Retail versions of Office 2016 C2R and Office 2019" (Privatkunde) dieses Update nicht und bleiben auf "Version 2508 (Build 19127.20302)" vom 14.Oktober 2025 stehen.
learn. microsoft. com/en-us/officeupdates/update-history-office-2019
Ob ECS Konfigurations-Updates auch differenziert werden nach Lizenz (Firma vs Privatkunde) weiß ich nicht.
Die Blockierung des "Shell.Explorer.1" über die Registry sollte man auf jeden Fall machen.
Dieser Registry-Fix schützt dann allerdings nur Office ab einschließlich Version 2016, aber es gibt theoretisch auch noch andere Programme und Dateiformate, die für diese Angriffsmethode benutzt werden könnten, denn OLE ist nicht auf Office beschränkt, nur halt im aktuellen Fall gerade akut dort aufgefallen.
Office kleiner als 2016 benutzt einen anderen Registry-Schlüssel als "16.0", daher wird diese Angreiffsmethode dort weiterhin funktionieren, auch wenn man den Registry-Fix gesetzt hat.
Aber auch jenseits irgend einer Office-Version ist diese OLE-Angriffsmethode über die Internet Explorer Datei ieframe.dll möglich.
Daher sollte man vielleicht besser auch die Datei ieframe.dll im System32- und im SysWOW64-Ordner umbenennen oder deren Rechte sperren, um diese Angriffsmethoden generell zu blockieren.
Sonst müsste man für jedes erdenkliche Programm einen separaten Registry-Key setzen, der dort jeweils das Kill-Bit setzt, um für dieses Programm dann OLE über diese ieframe-Datei zu verhindern.
Das wäre recht aufwändig.
Für Office 2016 und 2019 (EOS) müsste 0Patch in den nächsten Tagen oder Wochen ein Micropatch veröffentlichen. Mit der Pro- und Enterprise-Lizenz wird das so versprochen: Microsoft Office 2016 post-EOS patches und Microsoft Office 2019 post-EOS patches.
Wer noch Office 2016 und 2019 und älter einsetzt, schert sich eh nicht um Sicherheit. Die müssen halt ihre Lektion erst noch lernen. Kein Backup, kein Mitleid.
Hatte schon den Finger auf der Delete-Taste, da arg themenfremd. Wie ChristopH ausführt, ist es problemlos möglich, ältere Office-Versionen durch 0patch abzusichern. Zudem bietet Microsoft Patches für die beiden genannten Office-Versionen.
Und was das Thema Backup mit dem Artikel zu tun hat, erschließt sich mir nicht. Bitte beim nächsten Kommentar etwas auf Fokussierung zum Thema achten, sonst lösche ich.
ist 1984 auch themenfremd?
Danke für die Zusammenfassung. Mir war gar nicht klar, dass wir noch IE Reste auf den Geräten haben – ich dachte diesese Problem wäre durch die Deinstalltion des IE ein für alle mal gelöst. Wieder so ein unnötige Lücke durch Unterstützung von unsicherer, toter Technik. Eine Software-Komponente die sich noch auf IE stützt muss beerdigt werden.
Dazu scheinen auch Intel Grafitreiber zu gehören. Zumindest wird im Intel Forum von einem Intel Moderator zur Problemlösung eines Users unter anderem
sfc /scanfile=c:\windows\system32\ieframe.dll
und
sfc /verifyfile=c:\windows\system32\ieframe.dll
empfohlen.
Bei einer Stichprobe finden sich übrigens noch diverse Versionen unter C:\\Windows\\WinSxS\\amd64_microsoft-windows-ieframe_[…]
Zitat:
"finden sich übrigens noch diverse Versionen unter C:\Windows\WinSxS\"
—
In diesem WinSXS-Ordner (Komponentenstore) darf man auf keinen Fall manuell Dateien löschen oder sonstwie manipulieren.
Microsoft schreibt dazu folgendes:
Warnung
Das Löschen von Dateien aus dem Ordner "WinSxS" oder das Löschen des gesamten WinSxS-Ordners kann ihr System erheblich beschädigen, sodass Ihr PC möglicherweise nicht gestartet wird und es unmöglich ist, die Aktualisierung vorzunehmen.
learn. microsoft. com/de-de/windows-hardware/manufacture/desktop/clean-up-the-winsxs-folder?view=windows-11
Kennt jemand die Registry-Schlüssel, um LibreOffice, Softmaker Office und OpenOffice gegen diese OLE-Angriffsmethode zu schützen?
Wie kommst du darauf, dass die auch betroffen sind? Hast du da einen Link?
Erkläre mal, warum die nicht betroffen sein sollten, wenn die ein Microsoft Office Dokument mit eingebettetem OLE-Schädling öffnen, der das "Shell.Explorer.1" OLE-Objekt benutzt. Der schickt seinen Schadcode an die ieframe.dll und ist drin im System.
Die OLE-Funktionalität ist kein exklusiver Bestandteil von Microsoft Office, sondern eine Funktionalität von Windows, um Daten zwischen Programmen austauschen zu können, zum Beispiel eine Tabelle aus Excel oder Planmaker oder eine Grafik aus Paint in einen Text in Word oder Textmaker etc und andersum.
Beispiel für LibreOffice:
"OLE-Objekt einfügen"
help. libreoffice. org/latest/de/text/shared/01/04150100.html
Beispiel für Softmaker Office:
"OLE-Objekte"
help. softmaker. com/textmaker2021/de/index.html?ole-objekte.html
Es könnte sein, dass ich bezüglich LibreOffice total falsch liege: Aber dort werden Zugriffe auf OLE-Objekte über JAVA-Aufrufe realisiert und es scheint keine Registry-Einträge wie bei Microsoft Office zu geben. Ähnlich dürfte es bei Softmaker Office ausschauen. CVE-2026-21509 ist eine Microsoft-spezifische Schwachstelle in dessen Office-Modulen.
In LibreOffice kann man Java abschalten:
Extras,
Optionen,
Erweitert,
Java-Optionen:
[_] Eine Java Laufzeitumgebung verwenden (Haken entfernen)
OK
Jetzt zum OLE-Test den Planmaker von Softmaker Office starten und dort eine Tabelle erstellen.
Mit den Daten aus dieser Tabelle erstellt man ein Diagramm.
Dieses Diagramm kann man mit Copy und Paste in den LibreOffice Writer einfügen als OLE Objekt.
Das funktioniert normal und problemlos, obwohl Java vorher deaktiviert wurde.
Der umgekehrte Weg von LibreOffice Calc zu Softmaker Textmaker funktioniert ebenfalls problemlos ohne Java.
LibreOffice benutzt also für OLE kein Java, sondern ganz normal die Windows-Funtionalität, so wie es auch Microsoft-Office macht.
LibreOffice braucht Java für diese Funktionen:
wiki. documentfoundation. org/Faq/General/015
und für die "Base"-Datenbank:
de. libreoffice. org/get-help/system-requirements/
Also wird Java nicht für OLE gebraucht.
OLE kann man in Libreoffice bei
Dialog Optionen
Reiter Sicherheit
Button Optionen …
[X] Aktive Inhalte für OLE-Objekte, DDE und OLE-Automatisierung deaktivieren
deaktivieren. Auch wenn Libreoffice unter Linux läuft.
Was das genau bewirkt? Einfach "kurz" im Sourcecode suchen ;)
Java wird mittlerweile für das meiste nicht mehr benötigt und genutzt.
Für Windows OLE wurde Java noch nie genutzt. Deshalb war man wie auch OpenOffice von allen früheren Problemen im Prinzip genauso betroffen.
Auch wenn viele Exploits für MS Office nicht direkt laufen dürften.
danke
Also bei mir hat (anscheinend) das Ganze bei Office 365 Business zugeschlagen, nachdem ich das Trust-Center unter Optionen geöffnet und mit OK gespeichert hatte, denn ich hatte gestern diesen Fall und heute auf einem anderen PC, dass ein langjähriges Outlook AddIn, welches wir verwenden, plötzlich den Dienst verweigerte. Selbst nach den Updates hat das AddIn noch perfekt funktioniert, erst als ich das Trust-Center offen und wieder geschlossen hatte, ging es urplötzlich (und seitdem) nicht mehr :(
Neuerdings kommt jetzt durch das AddIn: "Ein oder mehrere Objekte dieses Formulars enthalten möglicherweise böswilligen Code, der ein Sicherheitsrisiko darstellt. Aus diesem Grund wurden die Objekte nicht geladen. Für weitere Informationen wenden Sie sich bitte an Ihren Administrator"
Konnte den Fall bisher nicht lösen, also AddIn deaktiviert (was mir nicht gefällt!)
Das hört sich mehr nach Smart App Control an. Würde ich jedenfalls mal prüfen in die Richtung.
Glaube auch das ist nur eine zufällige zeitliche Koinzidenz.
Diese Meldung hatten wir auch gerade im Current Channel unerwarteterweise bei einem Outlook Kontakt-Form. Es waren die strengeren ActiveX Regeln.
https://support.microsoft.com/de-de/office/aktivieren-oder-deaktivieren-von-activex-einstellungen-in-office-dateien-f1303e08-a3f8-41c5-a17e-b0b8898743ed#__toc311697501
https://m365admin.handsontek.net/activex-will-be-disabled-by-default-in-microsoft-office-2024/
@Bolko: Danke für Deine Erläuterung "Server" vs "Service"!
Da ich mindestens nicht sicher bin, das ECS bei mir greift, würde ich gerne per GPO die RegKeys setzen. Hier vor Ort kommt Office LTSC 2024 (64Bit) auf Windows 11 Enterprise (64Bit) zum Einsatz. Diese Konstellation, also 64Bit C2R-Office auf 64Bit Windows kommt in den verschiedenen Beschreibungen der zu setzenden RegKeys gar nicht vor (Microsoft, Bleeping Computer).
Ich frage mich also: Welche Keys muss ich denn setzen?
Ist dazu evtl. jemand auskunftsfähig?
DANKE!
"for 64-bit Click2Run Office":
[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Office\ClickToRun\REGISTRY\MACHINE\Software\Microsoft\Office\16.0\Common\COM Compatibility\{EAB22AC3-30C1-11CF-A7EB-0000C05BAE0B}]
"Compatibility Flags"=dword:00000400
Nicht ganz richtig. Laut Bleeping Computer ist der Registry Wert von Günter oben schon fix und fertig benutzbar.
"If one of the above keys does not exist, create a new "COM Compatibility" key under this Registry:
HKEY_LOCAL_MACHINE-SOFTWARE-Microsoft-Office-16.0-Common"
Daraus ergibt sich dann:
HKEY_LOCAL_MACHINE-SOFTWARE-Microsoft-Office-16.0-Common-COM Compatibility-{EAB22AC3-30C1-11CF-A7EB-0000C05BAE0B}
DWORD (32-bit) Value -> Compatibility Flags
Hexadezimal 400
Aus irgendeinem Grund wird Blackslash vom Editor geschluckt.
Die Primär-Quelle ist der CVE-Artikel von Microsoft:
msrc. microsoft. com/update-guide/vulnerability/CVE-2026-21509
Dort wird differenziert zwischen MSI-Installer und Click-To-Run und jeweils zwischen 32-Bit und 64-Bit.
Du hast also die MSI-Variante benutzt, die für die Click-To-Run-Variante aber nicht greift.
Der Bleeping-Computer-Artikel ist in diesem Punkt falsch, weil er vom Microsoft-Artikel abweicht.
Bei Microsoft steht:
"Note: The COM Compatibility node may not be present by default. If you don't see it, add it by right-clicking the Common node and choosing Add Key."
Falls also der Registry-Key (aus der Liste der 4-Keys) fehlt, Dann soll man ihn manuell erstellen.
Als "BEISPIEL" zeigt Microsoft dann, wie man das macht anhand einer der 4 Möglichkeiten.
Zwei Zeilen vor deinem Registry-Key (und dem selben Key bei Bleeping Computer) steht im Microsoft-Artikel:
"Example"
(Beispiel)
Bleeping Computer hat dieses eine Beispiel als die alleine gültige Lösung missverstanden bzw nur anhand der ersten Möglichkeit erläutert und die anderen 3 Möglichkeiten nicht erläutert.
Man muss aber die richtige der 4 Möglichkeiten auswählen, passend zum Installer (MSI oder Click-To-Run und passend zu 32-Bit oder 64-Bit jeweils).
2.
Der Backslash bleibt bestehen, wenn man ihn als HTML-Code einfügt:
& # 9 2 ;
(ohne die Leerzeichen, also ganz enbg zusammen geschrieben):
\
Tatsächlich!
Dann ist dein Registry Key korrekt. Habs gleich in der GPO geändert. Danke!
Es schadet aber auch nichts, wenn du alle 4 Registry-Keys einträgst, denn jede Office-Variante schaut in seinen eigenen Registry-Key und dann passt es immer.
Microsoft ist einfach nur zu bräsig, um das als allgemeingültige Reg-Datei zu veröffentlichen.
OLE-Blocker.Reg
— Schnipp —
Windows Registry Editor Version 5.00
[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Office\16.0\Common\COM Compatibility\{EAB22AC3-30C1-11CF-A7EB-0000C05BAE0B}]
"Compatibility Flags"=dword:00000400
[HKEY_LOCAL_MACHINE\SOFTWARE\WOW6432Node\Microsoft\Office\16.0\Common\COM Compatibility\{EAB22AC3-30C1-11CF-A7EB-0000C05BAE0B}]
"Compatibility Flags"=dword:00000400
[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Office\ClickToRun\REGISTRY\MACHINE\Software\Microsoft\Office\16.0\Common\COM Compatibility\{EAB22AC3-30C1-11CF-A7EB-0000C05BAE0B}]
"Compatibility Flags"=dword:00000400
[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Office\ClickToRun\REGISTRY\MACHINE\Software\WOW6432Node\Microsoft\Office\16.0\Common\COM Compatibility\{EAB22AC3-30C1-11CF-A7EB-0000C05BAE0B}]
"Compatibility Flags"=dword:00000400
— Schnapp —
Hallo Balko
[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Office\ClickToRun\REGISTRY\MACHINE\Software\Microsoft\Office\16.0\Common\COM Compatibility\
Ich finde in diesem Pfad etliche Schlüssel die Reg_DWORD Compatibility Flags Einträge haben.
Ist das nicht eine Bestätigung, dass dieser Pfad die richtige ist für meine Installation?
Ja, das ist der normale Registry-Zweig für neuere 64-Bit Click-To-Run Office-Versionen.
Dort bist du richtig.
Bei einem 32-Bit Office auf einem 64-Bit Windows oder bei einem per MSI installierten Office wäre der Key falsch.
Moin Bolko!
Thx für die Zusammenfassung in einer OLE-Blocker Reg-Datei!
Danke Bolko
Wobei der Dateiname "OLE-Blocker.reg" nicht optimal ist, denn es wird nicht OLE im Allgemeinen geblockt, sondern nur das hier relevante "Shell.Explorer.1"-OLE-Objekt (ieframe.dll) und das auch nur in Verbindung mit Microsoft Office ab 2016.
Andere OLE-Objekte funktionieren weiterhin und das "Shell.Explorer.1"-OLE-Objekt funktioniert auch außerhalb von Microsoft Office weiterhin.
Die Sperre ist also recht selektiv.
Die Angriffsmethode ist meiner Meinung nach damit noch nicht vollständig blockiert, denn die Datei mit dem OLE-Schädling könnte man auch mit einem anderen Programm starten, das OLE benutzen kann, zum Beispiel Softmaker Office oder LibreOffice oder Paint.
Die Reparatur-Methode von Microsoft finde ich fahrlässig lückenhaft und zu selektiv.
Es wäre besser, wenn man diese ieframe.dll komplett aus dem System schmeißt oder wenn Microsoft diese Datei wasserdicht absichert, damit sie nicht mehr exploitbar ist.
Hallo Bolko,
danke ! Kann man per reg query abfragen ob die keys gesetzt sind?
Top – vielen Dank!
@Günter: Evtl den RegKey im Blog-Text verlinken?
—
GB: Ist passiert – ich habe es als Anmerkung am Beitragsende separat hervorgehoben.
Zum Nebenthema "Backslash in den Kommentaren":
Es reicht überall einen doppelten Backslash zu verwenden. Das wird vom System zu einem einzelnen verkürzt.
Deine Methode funktioniert aber nicht mehr, wenn man den Beitrag anschließend nochmal bearbeitet.
Nur der HTML-Code übersteht auch ein mehrfaches Edit.
& # 9 2 ;
\
Ggf. Feedback an den Autor des betreffenden Plugins: https://de.wordpress.org/plugins/simple-comment-editing/
Da wird nicht viel passieren und HTML sollte im Kommentarbereich möglichst aus Sicherheitsgründen auch weitgehend gefiltert werden. Daher blende ich auch keine HTML-Formatierungsschaltflächen ein.
Ohne Rückmeldung weiss ein Autor nicht, dass es die hier beschriebenen Probleme mit mehrfachem Bearbeiten gibt. Das Mindeste, was man bei Nutzung von Open Source Produkten machen kann, ist dem Autor solche Dinge wenigstens mitzuteilen.
@Bolko: „Lesen (mit Verstand!) schadet der Dummheit", hätte ich also vor dem Post machen sollen. Sorry & DANKE!
Ich gehe mal davon aus das bei Office LTSC 2024 das nur funktioniert wenn die Clients sich die Updates über das CDN holen und nicht von einer lokalen Freigabe und alle Telemetry zu MS geblockt wird wie das bei den meisten unserer Kunden der Fall ist.
Muss ich mal schauen was ich da unseren Kunden sagen kann ob sie die Regkeys setzen müssen oder nicht.
Das ist auch meine Konstellation:
Updates für Office NICHT aus dem CDN sondern aus einem lokalen Share und Telemetrie weitestmöglich geblockt.
Ich gehe davon aus, das ECS so NICHT funktioniert und man den (richtigen) Key setzen MUSS, um sich abzusichern.
Selbst wenn Updates aus dem CDN aktiv WÄREN:
Es GIBT ja aktuell auch gar kein Update für Office LTSC 2024, das jüngste ist von Anfang Januar, da dürfte ja noch kein Fix hierfür drin sein…
Ohne Telemetrie funktionieren ECS-Konfigurations-Updates nicht.
Den Inhalt des "Office CDN" kann man sich mit dem "Office Deployment Tool" runterladen und dann lokal synchronisieren bzw installieren.
Man muss nur die passende xml Datei erstellen, je nachdem welche Version und Sprache man haben möchte und welche Lizenz man hat.
Ich halte die 4 Registry-Einträge zusätzlich in jedem Fall für eine Pflichtmaßnahme.
Die aktuelles Release Version im O365 Enterprise Current Channel ist die 2512 (19530.20184) und die scheint diese Lücke nicht zu fixen.
Version 2512: January 21
Version 2512 (Build 19530.20184)
Various fixes to functionality and performance.
Die Updates für diese Lücke stehen für O365 Enterprise definitiv noch nicht zur Verfügung.
Zitat:
"Ab Microsoft Office 2016 gilt folgender Schlüssel:"
—
Das stimmt so nicht, denn es gibt nicht einen einzelnen Registry-Key für alle 4 Möglichkeiten (MSI / C2R , 32-Bit / 64-Bit).
Man braucht einen von den 4 Registry-Keys je nachdem, welche Office-Variante man benutzt.
Wenn man den Key für MSI bei einer C2R-Installation benutzt, dann ist man ungeschützt.
Weil die aktuellen Office-Versionen alle als Click-To-Run oder über das "Office Deployment Tool" installiert werden, ist der Key im Artikel dann immer falsch, denn der gilt nur für die MSI-Installation und
er gilt auch nicht für
(32-Bit Office Version auf einem 64-Bit Windows),
sondern nur
für (32-Bit Office auf 32-Bit Windows)
und
für (64-Bit Office auf 64-Bit Windows).
sehr richtig.
ist doch alles Mist!
M$ MUSS ein Update selber bringen, was das entschärft!
Alles andere ist "Frickelkram" – um mal bei dem "Sprech" der Win-Fanboys und den Linux-Hatern zu bleiben… ;-)
achwas 😉
Wurde zwar in den Kommentaren schon mal angeschnitten, aber bislang aus meiner Sicht nicht beantwortet:
Gibts für "Office 365 Apps for Enterprise" auch einen Fix? Es gibt zwar ein Update vom 27.01.2026 (https://learn.microsoft.com/en-us/officeupdates/current-channel#version-2601-january-27), darin werden aber keine CVEs aufgeführt.
Und in der Liste der Security-Updates (https://learn.microsoft.com/en-us/officeupdates/microsoft365-apps-security-updates) gibt's kein neueres Update als vom 13.01.2026.
—
GB: Die Antwort kann imho nur Microsoft liefern. Wenn die serverseitig fixen, gehe ich davon aus, dass es behoben ist. Warum: Ich tippe darauf, dass die in obigem Text genannten, unzureichenden Prüfungen, ab Office 2021 serverseitig erfolgen und nun gefixt sind. Mag mich aber täuschen. Von daher sollte es in allen Microsoft 365-Builds behoben sein – was auch eine Erklärung ist, dass es keine neue Build-Nummer gibt.
Guten Morgen!
Unsre leider noch vorhandenen Office 2016 Installationen haben brav das Update KB5002713 installiert und neu gestartet. Trotzdem ist die Word Version 16.0.5535.1000
Selbige Version in "Details" Reiter der Winword.exe
Hat jemand ein ähnliches Verhalten?
Hat jemand schon ein brauchbaren Fix für 2019? die noop files im MS Catalog scheinen nicht viel zu bringen.
Danke
Roland
Hallo Roland,
Ist bei uns genauso, Build verändert sich nicht.
Gehört aber wohl so:
MSI (Windows Installer): This is the traditional version (e.g., Office Professional Plus 2016 volume license). For these versions, Microsoft does not update the build number shown in the "About" section when you apply security patches.
C2R (Click-to-Run): This is the modern version (e.g., Microsoft 365, retail Office 2016/2019). These versions do update their build number automatically under "Product Information"
https://learn.microsoft.com/en-us/answers/questions/595528/microsoft-office-2016-version-in-control-panel-doe
"As far as I know, Microsoft no longer releases build numbers for volume licensed versions of Office installed based on MSI. In other words, the version number in the About option has no reference meaning for MSI version Office.
Am 27.1.2026 hat Microsoft den CVE-Artikel aktualisiert und hinzugefügt, wie man die Versionsnummer abfragt.
File, Account, About,
In der ersten Zeile dieses About-Dialogs steht die aktuelle Versionsnummer.
Dort muss 16.0.5539.1001 stehen bei Office 2016, und 16.0.10417.20095 bei Office 2019, sonst ist der Patch nicht drin.
msrc. microsoft. com/update-guide/vulnerability/CVE-2026-21509
Diese Office-Versionsnummer entspricht der Datei-Versionsnummer für folgende Datei (für Office 2016):
MSO30WIN32CLIENT.DLL
Wie man die Buildnummer abfragt ist mir bekannt, sonst hätte ich nicht "ist bei uns genauso" geschrieben.
Geht aber am Problem vorbei das bei Volumenlizenzen der Build (manchmal) nicht angehoben wird obwohl offenkundig Dateien ausgetauscht wurden.
Auch die GLB.exe sagt "wurde bereits installiert".
Abgesehen davon eben das übliche MS-Chaos:
10 Artikel, 20 Meinungen
Das mit der Version anzeigen scheint aber nicht wirklich zu funktionieren, wir haben noch einen Kunden, der noch Office 2016 32-Bit in der MSI-Version auf dem TS installiert hat und der das Upgrade auf Office 2024 bisher nicht durchführen wollte. Dort habe ich gestern das Update für die Office 2016 32-Bit MSI Version installiert und den Terminal Server neu gestartet, angezeigt wird aber nach wie vor die Version 16.0.5535.1000, führe ich das update erneut aus, wird gemeldet, dass dieses bereits installiert ist.
Die Reg-Keys hatte ich übrigens zuvor auch gesetzt.
Es ist ja auch installiert.
Aber sogar die CMD/Powershell Versionsabfragen liefern falsche Werte.
Da hilft nur händisch Dateiversion überprüfen
Ja, wir haben das Update für Office 2016 auch installiert. Es wurde nur die Datei "mso30win32client.dll" upgedated. Die Versionsnummer der Datei bleibt gleich, aber das Änderungsdatum wurde vom 22.3.2025 auf 25.1.2026 geändert. Es wurden keine Registry Keys geschrieben.
Die dll-Datei wurde am 26.1.2026 signiert.
Bei mir ist das Dateidatum allerdings auch der 25.1.2026 (ausgepackt aus dem Update, ohne Installation).
Dateiversion muss 16.0.5539.1001 sein.
Seltsam, dass du bei dir vor dem Update bereits diese Version drauf hattest.
Ich hatte angenommen, Microsoft hätte die Version erhöht.
Nachtrag, habs mir doch selbst erarbeitet/im web gesucht:
OLE:
OLE (Object Linking and Embedding) ist eine Microsoft-Technologie, die es ermöglicht, Inhalte (Objekte wie Excel-Diagramme) zwischen Anwendungen (z. B. Word, Excel) auszutauschen und zu verknüpfen. Es erlaubt das Einbetten von Daten oder das Verknüpfen mit der Quelldatei, wodurch Änderungen dynamisch aktualisiert werden können. OLE wird häufig für die Erstellung komplexer Dokumente genutzt.
Hauptfunktionen und Funktionsweise von OLE:
Einbetten (Embedding): Eine Kopie der Daten wird in das Zieldokument eingefügt, ohne Verbindung zur Quelldatei.
Verknüpfen (Linking): Die eingefügten Daten bleiben mit der Originaldatei verbunden, Änderungen im Original aktualisieren das Dokument.
Typische Objekte: Microsoft Excel-Diagramme, Word-Dokumente, Visio-Zeichnungen oder Bilder.
Anwendung: Über das Menü "Einfügen" -> "Objekt" in Office-Anwendungen.
Fehlerbehebung: OLE-Fehler können auftreten, wenn Programme auf Aktionen warten oder Sicherheitsrichtlinien Makros blockieren.
OLE ermöglicht eine tiefere Integration, indem es Nutzern erlaubt, die Quelldaten direkt aus dem Zieldokument heraus zu bearbeiten.
—
GB: Hab den Kommentar im Papierkorb gefunden – kann aber nicht erkennen, ob vom Schreiber oder einem Filter gelöscht. Falls irrtümlich wiederhergestellt, bitte kurze Rückmeldung.
Habe erst gefragt ob jemand die Auswirkungen im Betrieb weiss, war aber dann doch nicht zu faul selbst zu suchen.
Vlt hilfts wem anderen
Danke!
Der Patch für Microsoft Office 2016 enthält im Wesentlichen nur 2 Dateien:
MSO30WIN32CLIENT.DLL
Version: 16.0.5539.1001
Diese Versionsnsummer steht jetzt auch im CVE-Artikel von Microsoft drin.
Abfragen in Office kann man diese Soll-Versionsnummer so:
File, Account, About,
In der ersten Zeile dieses About-Dialogs steht die aktuelle Versionsnummer.
Wenn diese Nummer dort nicht stimmt, dann war der Patch nicht erfolgreich.
msrc. microsoft. com/update-guide/vulnerability/CVE-2026-21509
MSOINTL30.DLL
Version: 16.0.5409.1000
Dazu noch einige tausende Dateien mit Sprachanpassungen und Patch-Meta-Infos.
Hier wäre eine Prüfsumme/Hashwert hilfreich.
Die Aussage "Patch war nicht erfolgreich" kann man imho so erst mal nicht stehen lassen.
sha256 Checksummen für Version 16.0.5539.1001 aus dem Update msodll302016-kb5002713 für Office 2016:
MSO30WIN32CLIENT.DLL (x64):
ad0454a2421c3854d6407bc4e3b68b2881fcf8d1e270db456abcb9b7526e4f85
MSO30WIN32CLIENT.DLL (x32):
c712fb905175208277ccd52b7c98adfb6a04d82adfca1bdf5687a5e000afe609
Digitale Signatur jeweils vom 26.Januar 2026.
Ausgepackt aus dem cab, das in dem msp, welches in der exe steckt.
Übrigens enthalten die x86 und die x64 Varianten des Updates jeweils beide Varianten 32-Bit und 64-Bit der dll.
Normalerweise sollten doch die x86 nur die 32-Bit und die x64 nur die 64-Bit Dateien enthalten.
Es wird ja noch konfuser:
Bei Kollege funktionierte der CAB Installer nicht.
Also alter Trick CAB auspacken und msp starten.
Fragt 100x nach Adminrechten , macht irgendwas und verabschiedet sich dann kommentarlos.
Also den hier…..der dann sagt das Update sei bereits installiert.
MSP Update deinstalliert , Rebootarien und nochmal installiert.
https://www.microsoft.com/en-us/download/details.aspx?id=108535
So langsam kann man wieder auf Typenrad , Kugelkopf und Abakus downgraden, das macht alles keinen Spass mehr.
Wir verwenden die C2R Version 2502 aus dem Semi-Annual Enterprise Channel: Version 2502 (Build 18526.20696). Auch heute morgen, stand 10:18 hat microsoft noch keine neuere Version dei den Channel 2502 gelistet.
Wir deployen unsere Updates über eine eigene interne Share, welche vorher mit dem Deployment tool vom MS CDN heuntergeladen werden.
Ich frage mich, wie ich unsere Office Installationen härten soll. Bis her gibt es keine Updates auf den Seiten https://learn.microsoft.com/en-us/officeupdates/update-history-microsoft365-apps-by-date und https://learn.microsoft.com/en-us/officeupdates/microsoft365-apps-security-updates.
Und der genannte Workaround via Registry wird nicht ffür die C2R Installationen genannt. Hat jemand nen Tipp?
Zitat:
"Und der genannte Workaround via Registry wird nicht ffür die C2R Installationen genannt."
—
Doch wird er.
Siehe Punkt 2 und dort der dritte und vierte Registry-Zweig:
3.: "(for 64-bit Click2Run Office, or 32-bit Click2Run Office on 32-bit Windows)"
4: "(for 32-bit Click2Run Office on 64-bit Windows)"
msrc. microsoft. com/update-guide/vulnerability/CVE-2026-21509
Am besten nimmst du alle 4 Registry-Einträge, denn die passen in jedem Fall und stören sich nicht gegenseitig.
borncity. com/blog/2026/01/27/microsoft-office-0-day-schwachstelle-cve-2026-21509-notfall-updates-teilweise-verfuegbar/#comment-245326
2.
Dein Link zeigt Updates vom 27.Januar 2026.
für "Current Channel":
Version 2601 (Build 19628.20150)
Als ich diese Seite gestern aufrief, stand das noch nicht drin, denn da war der Stand noch 21.1. und 13.1.
Das hilft dir aber auch nichts, wenn "Monthly", oder "Semi-Annual" Channel benutzt wird.
Du solltest die Registry-Workaround benutzen und darauf hoffen, dass Microsoft tatsächlich irgendwie serverseitig oder per Service (ECS) das Problem gefixt hat, obwohl man das bisher nicht nachvollziehen (verifizieren) kann.
Es fehlt ein Test-Exploit.docx mit einem OLE zum Nachweis des erfolgreichen Schutzes.
Also wir haben Office 2024 LTSC Build 17932.20638, angeblich Click to Run, aber wir bekommen kein Update angeboten.
es bleibt Beim 13.1.2026, egal ob Neustart oder reboot, es ändert sich nicht.
Bei Microsoft finden wir auch keine Updates.
Frage an alle, Hat Jemand eine neuere Version gefunden oder bekommen?
Angeblich wird das ja Serverseitig eingespielt davon merken wir aber nix.
Wie machst Du das "Angeblich wird das ja Serverseitig eingespielt davon merken wir aber nix" denn fest? Wenn deine Office-Module bei jedem OLE-Link einen Prüfauftrag an ein serverseitiges Script senden und dieses Script um eine erweiterte Prüfung ergänzt wurde, bekommt der Endnutzer nichts davon mir.
Naja ich bekomme halt kein neues Build angezeigt, solange das nicht der Fall ist, gehe ich davon aus das wir nichts erhalten haben.
Folglich sind wir nicht geschützt.
die build wird nicht angehoben. check die registry per powershell oder cmd, dann weißt du ob es serverside aufgespielt wurde.
Workaround:
Prüfe die erwähnte Mso30win32client.dll auf Version und Signaturzeitpunkt und du weisst ob du gepatcht wurdest und soweit Safe bist
Zitat:
"Prüfauftrag an ein serverseitiges Script senden und dieses Script um eine erweiterte Prüfung ergänzt wurde"
—
Wenn nur eine Anfrage an den Server geschickt würde, dann müsste Office auch sofort ohne Neustart geschützt sein.
Microsoft schreibt aber von einem notwendigen Neustart.
Demnach wäre es möglich, dass so ein Script mit einer Blacklist von Microsoft-Servern auf den lokalen Computer runtergeladen wird.
Diese Blacklist könnte und sollte Microsoft dann aber am besten auch als einfach installierbaren Download mitsamt Versionsnummer anbieten, genauso wie auch Defender-Updates für den separaten Download angeboten werden, für den Fall, dass eine automatische Installation nicht funktioniert.
Damit man das lokal irgendwie verifizieren kann.
Version 2408 (Build 17932.20638) vom 13.Januar 2026 ist das aktuelle in der Liste:
learn. microsoft. com/en-us/officeupdates/update-history-office-2024
Bisher gibt es kein neues Update.
Microsoft scheint das Problem irgendwie (nicht verifizierbar) gelöst zu haben, ohne die Programmdateien zu verändern.
Das könnte man glauben, muss man aber nicht glauben.
Microsoft hat schon zu viel Vertrauen verspielt, als dass man denen einfach so irgend eine Behauptung einfach glauben sollte.
Was ist, wenn die einfach gar nichts gemacht haben oder ihre magische mystische "Lösung" gar nicht funktioniert?
Was ist mit den Computern, auf denen eine OLE-Abfrage zum Microsoft-Server nicht durchkommt, aus irgend einem Grund, etwa weil Telemetrie abgestellt ist?
Stehen alle OLE-Objekte auf eine Black-List bis zur Freigabe durch Microsoft oder stehen alle OLE-Objekte auf einer White-List bis zur Sperre durch Microsoft?
Das weiß man alles nicht.
Ein Office sollte auch offline sicher funktionieren, ohne Standleitung zu Microsoft.
Bei Office 2016 wurden zwei Dateien lokal geändert, also sollte das auch bei den höheren Office Versionen möglich sein.
Absolut! Ich habe einen Supportfall bei MS eröffnet, genau mit den gleichen Fragestellungen. Wir verteilen unsere Updates über eine bei uns im Netz für die Clients verfügbare Share. Solange es keine neue Version auf den Seiten https://learn.microsoft.com/en-us/officeupdates/microsoft365-apps-security-updates und https://learn.microsoft.com/en-us/officeupdates/update-history-microsoft365-apps-by-date gibt, sehe ich uns auch als "ungeschützt".
Mal gespannt wann und was MS uns zur Info gibt.
Office 2016
So sieht das dann hier aus:
MSO30WIN32CLIENT.DLL
Version: 16.0.5539.1001
Signaturzeitpunkt:Montag, 26. Januar 2026 00:30:35
Also definitiv auf Stand.
Patch erfolgreich.
Word Info falsch:
16.0.5535.1000
Also in
C:Program Files-Common Files-microsoft shared-OFFICE16
Mso30win32client.dll prüfen
und alles wird gut.
Danke für die Info.
Dann ist der CVE-Artikel von Microsoft falsch ab der Zeile
"To see what version you have installed:"
(folgende 3 Zeilen sind falsch bezüglich erfolgreichem Patch).
msrc. microsoft. com/update-guide/vulnerability/CVE-2026-21509
OK, Office 2016 wäre damit geklärt.
Wir haben "Glauben" durch "Wissen" ersetzt.
So muss das sein.
Wie geht das mit Office 2019 und höher?
Leider keine 2019 im Einsatz….aber vielleicht funktioniert es ja dort genauso.
Ansonsten Gaffa Tape und intensives Beten…
"Genauso" funktioniert es nicht, weil ich noch keinen Patch zum Runterladen gefunden habe.
Office 2019 ist Click-To-Run im Gegensatz zu Office 2016.
Office 2021. heute morgen aus Mitleid Update aktivert und angestoßen.
Neben der wohl obligatorischen KAI haben 230 Dateien Änderungsdatum heute.
Könnte das vielleicht helfen?
https://www.microsoft.com/en-us/download/details.aspx?id=49117
angeblich kannst du dir damit auch updates aus deren Fingern saugen….
"Ansonsten Gaffa Tape und intensives Beten…"
was bedeutet das? lerne gerne dazu. webcam mit tape abkleben? sich selbst die hände zukleben und ab mit sich selbst in den kleiderschrank.
O365 Enterprise x64 in Nutzung, bei mir findet sich diese DLL Datei vier mal, Änderungsdatum gestern als ich auf die Version 20184 um Current Channel aktualisiert habe.
Die DLL Datei selbst hat die v16.0.19530.20184.
Nachtrag bezüglich meiner O365 Enterprise x64 Installation.
Die Digitale Signatur stammte noch vom 21.01.
Jetzt nachdem ich auf 2601 Build 19628.20150 im Current Channel aktualisiert habe, hat sich wie gestern auch das Änderungsdatum der DLL Datei selbst auf das heutige Datum geändert, aber zusätzlich hat sich der Zeit Stempel der digitalen Signatur auf den 26.01.2025 kurz vor 22 Uhr geändert.
Die Versionsnummer der MSO30WIN32CLIENT.DLL ändert nicht mit dem Update, nur das Datum der Signierung und das Änderungsdatum. Bei der alten Version war das vom 22.3.2025, jetzt vom 26.1.2026.
doch tut sie (zum Glück!)
https://imgur.com/a/Zs0hdCN
@robi
selbiges bei mir Word Version alt , File Mso30win32client.dll wurde aktualisiert
bei mir steht da immer noch :
MSO30WIN32CLIENT.DLL 20638, also noch nix
Was ist 20638?
So muss es aussehen:
https://imgur.com/a/Zs0hdCN
Oder bist du bei Office 2019 und aufwärts?
"20638" ist der Patchlevel von:
Office 2024 LTSC Version 2408 (Build 17932.20638 C2R vom 13.Januar 2016 (ohne Update gegen OLE-Exploit).
Im Current-Channel gibt es eine neue Version der Microsoft 365 Apps
Version 2601: January 27 Version 2601 (Build 19628.20150):
*****
Feature updates
OneNote
Improved proofing language control: OneNote now applies your chosen proofing language more consistently, so you don't have to reset it for every paragraph when writing in multiple languages.
Resolved issues
Excel
We fixed an issue that caused Office applications to become unresponsive when profile card-related activities are performed.
PowerPoint
– We fixed an issue that caused Office applications to become unresponsive when profile card-related activities are performed.
– Fixed an issue where opening a PowerPoint document from OneDrive sometimes opened a new presentation with a prompt to add a first slide, even if the presentation already contained slides.
Word
We fixed an issue that caused Office applications to become unresponsive when profile card-related activities are performed.
*****
CVE-2026-21509 wird mit keinem Wort erwähnt.
https://learn.microsoft.com/en-us/officeupdates/update-history-microsoft365-apps-by-date
https://learn.microsoft.com/en-us/officeupdates/current-channel
Hab noch die selbe Info wie Bolko
Was ist mit Office 2019?
Bei den beiden Patches scheint nicht viel zu passieren
https://www.catalog.update.microsoft.com/Search.aspx?q=10417.20095
Keine Ahnung von was ich hier spreche aber für Office 2019 kann ich folgendes beitragen:
Auf einem Server 2019 mit Office 2019 x86 habe ich ein Ordner C:\Program Files\Common Files\microsoft shared\ClickToRun\Updates\16.0.10417.20095 mit einer ApiClient.dll Version 16.0.10417.20095
Im Ordner C:\Program Files\Common Files\microsoft shared\ClickToRun gibts die ApiClient.dll ebenfalls mit Version 16.0.10417.20083
Schaut aus als wäre das Update irgendwie auf dem Server gekommen konnte aber noch nicht aktiviert werden weil vermutlich Officeprogramme dauernd geöffnet waren.
Auf einem anderen Server 2019 mit Office 2019 x86 existiert der Ordner C:\Program Files\Common Files\microsoft shared\ClickToRun\Updates\16.0.10417.20095 nicht
JEDOCH!!!
Hat die C:\Program Files\Common Files\microsoft shared\ClickToRun\ApiClient.dll die Version 16.0.10417.20095
Beide Server haben zuletzt am 21.1.26 aufgrund des CU 2026-01 neu gestartet
Bei letzterem Server scheint das Update 16.0.10417.20095 irgendwie von Geisterhand durchgeführt worden zu sein.
Mir ist noch nicht ganz klar was zu tun ist wenn das eingesetzte Office 2024 C2R nicht nach Hause telefonieren darf.
Nur den erwähnten Registry Key setzen und alles ist gepatcht? (Und Office-Programme müssen neu gestartet werden)
[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Office\ClickToRun\REGISTRY\MACHINE\Software\Microsoft\Office\16.0\Common\COM Compatibility\{EAB22AC3-30C1-11CF-A7EB-0000C05BAE0B}]
"Compatibility Flags"=dword:00000400
möchglicherweise (?) wird man mich jetzt belächeln, aber ich finde diese mso30win32client.dll nicht. keine einziges mal.
kann mir jemand helfen, unter welchem pfad diese datei zu finden sein müßte?
O2021. fehlermeldungen dazu gibt es keine.
C:\Program Files\Common Files\Microsoft shared\OFFICE16\Mso30win32client.dll
Die Prüfung dieser Datei auf Versionsnummer und Signatur zum Nachweis des erfolgreichen Updates gilt aber nur für Office 2016.
Danke, bei 2021 ist da nichts. Weiter beobachten. Oder weiter wundern.
Nachtrag, laut der Produktinformation ist es ein 64bit C2R-Office 2021. Version 2601 Build 16.0.19628.20132
Ich finde weder die o.g. dll noch Infos genau dazu im Neuland.
Gefunden! Händische Suche.
Unter C:\Program Files\Microsoft Office\root\vfs\ProgramFilesCommonX64\Microsoft Shared\OFFICE16 ist die Mso30win32client.dll .
Aktuellster Stand.
Ebenso unter C:\Program Files\Microsoft Office\root\vfs\ProgramFilesCommonX86\Microsoft Shared\OFFICE16
Danke, die Pfade passen auch für Microsoft 365 Apps für Business. Mit der Version 2601 (Build 19628.20150) vom 27.01.2026 im Current Channel hat auch da das Signaturdatum der Datei Mso30win32client.dll auf 26.01.2026 geändert.
diese seite half mir sehr:
https://www.reddit.com/r/sysadmin/comments/1qo7mgo/psa_cve202621509_microsoft_office_security/
anscheinend nutze ich eine Volume licensed versions of Office 2019 (version 1808) und jemand anderes eine Retail versions of Office 2019 (version 2508). nur bei letzterem musste ich an der registry arbeiten, erstere bekam ein patch. ich habe, wie viele das auch haben sollten, for 64-bit Click2Run Office (der Begriff 6
-bit Windows wurde weggelassen, es gibt kein 64-bit Programm auf einem 32-bit OS)
Danke für den Link auf den Reddit-Post. Dort ist in den Kommentaren auch beschrieben wie man die Microsoft 365 Office Apps prüfen kann ob das COM-Objekt mit der GUID {EAB22AC3-30C1-11CF-A7EB-0000C05BAE0B} auch geblockt wird. @All bei Interesse bitte dort nachlesen wie es genau funktioniert, will das jetzt nicht im Detail hier rein kopieren.
Auf meinen PC (Microsoft 365 Apps for Business, Current Channel) lässt sich nachvollziehen das bereits am 25.01.2026 um 10:41 der Eintrag innerhalb von <o:token o:name="ActivationFilterGUIDs# (…) |FFDF;b;{EAB22AC3-30C1-11CF-A7EB-0000C05BAE0B}|FFFF (…) in einer der Dateien im Pfad C:\Users\MYUSERNAME\AppData\Local\Microsoft\Office\16.0\WebServiceCache\AllUsers\officeclient.microsoft.com vorhanden ist. Also noch bevor der CVE-Artikel veröffentlich wurde. Diese Dateien werden, wie es ausschaut, jeweils beim Programmstart (oder beim triggern der Update-Funktion?) einer Microsoft 365 App von einem Server heruntergeladen und aktiviert. Nun verstehe ich auch was Serverseitig heisst. Ob das auch für die Enterprise-Channel gilt kann ich nicht verifizieren.
# durch "grösser als Zeichen" ersetzen, musste tricksen damit das nicht als HTML-Tag weggefiltert wird.
Diese aktuelle Config-Datei vom 29.Januar 2026 (GenerationTime=2026-01-29T09:38:03)
für Office kann man dort sehen bzw runterladen:
officeclient.microsoft.com/config16
Dort ist die GUID {EAB22AC3-30C1-11CF-A7EB-0000C05BAE0B} bei "ActivationFilterGUIDs" enthalten.
Danke Euch beiden für den Hinweis, hier meine Hinweise für "Microsoft 365 Apps for Enterprise – de-de 16.0.18526.20696 – SemiAnnual DCEXT"
Dort war das Killbit teilweise schon in Files vom am 21.01.2026 14:20Uhr , aber in manchen Rechnern erst am 29.01. (obwohl Neustart… früher erfolgte).
Also vielleicht lohnt sich ein zusätzlicher "Compatibility Flags"-Regkey via GPO doch im 0-day Fall erstmal????
https://www.heise.de/forum/heise-online/Kommentare/Notfall-Update-gegen-Zeroday-in-Microsoft-Office/Serverseitig-eingespielt/thread-7900752/page-2/#posting_45948603
Ein "Microsoft Technical Account Manager" (MS TAM) hat folgende Anleitung zum Test veröffentlicht, ob die aktuelle Config-Datei runtergeladen wurde, in der die GUID des zu blockenden OLE-Objekts enthalten ist.
Zitat:
our MS TAM got back to us on how to validate a patched/updated M365 instance:
1. Navigate to
%localappdata%\Microsoft\Office\16.0\WebServiceCache\AllUsers\officeclient.microsoft.com
2. Close all instances of Office (Word, Outlook, etc.)
3. Delete the most recent file(s) in that directory (i.e., looking for files dated 1/24/26 ~12pm PST). If you don't have that, delete the past few days of files
4. Restart Word
5. Open the file (GUID format file name) with today's date in Notepad/text editor of your choice
6. Search for ActivationFilter and you should see this in the token list: FFDF;b;{EAB22AC3-30C1-11CF-A7EB-0000C05BAE0B}
—
Der Kunde konnte den Empfang dieser aktuellen Config-Datei validieren, auch auf Office Versionen mit Build vom November 2025.
"We were able to validate that both our November build (19231.20246) and January build (19426.20260) are showing patched using the above method, so this CVE certainly does not require any updated client for O365,"
www. reddit. com/r/sysadmin/comments/1qo7mgo/comment/o236k5f/
Danke, Bolko!
Warum kann MS das nicht irgendwo offiziell dokumentieren? Seufz
Kann ich bei unserer Office 365 Enterprise Installation bestätigen.
Ich habe dafür jetzt den Schritt 3 nicht gemacht, sondern mir die aktuellsten 3 Dateien geschaut, die älteste vom 14.01 und auch da ist dieser Eintrag schon vorhanden.
In Dateien aus Dezember oder älter wiederum nicht.
sorry aber ist office 2010 sicher? keine zero-days? kein patch von nöten?
Wie kommst Du drauf?
Diese Version ist ja nun bereits einige Weile aus dem Support raus. 🤷♂️
ein betriebsinhaber eines KMU (gesundheitsbranche) weigert sich für einen schmalen taler office 2024 standard zu kaufen und nutzt, auch weil er kein neues GUI lernen will, office 2010.
ich bin solche spaßvögel Leid. es geht nicht ums geld es geht um "das ist mein betrieb, ich entscheide, will mit viel PS gegen die mauer fahren, Ahoi!"
unfassbar, dass die praxis sogar 32-bit office auf 64-bit windows 10 nutzt. die welt ist verloren.
Ja das ist schon erschreckend, was da mit den Menschen gemacht wird.
In meiner Straße da gibts so Typen,
die fahren noch Autos mit 4Zylindern!
Ich mein so, wirklich und in echt!
Da hilft nur: Hubschraubereinsatz!
Recht hat der KMU Inhaber, Office 2010 kann bereits alles, was er jemals brauchen wird.
Für Office 2010 und 2013 (32 Bit Office auf 32-Bit Windows oder 64-Bit Office):
[HKEY_LOCAL_MACHINE\Software\Microsoft\Office\Common\COM Compatibility\{EAB22AC3-30C1-11CF-A7EB-0000C05BAE0B}]
"Compatibility Flags"=dword:00000400
Für 32-Bit Office 2010 oder 2013 auf einem 64-Bit Windows:
HKEY_LOCAL_MACHINE\Software\Wow6432Node\Microsoft\Office\Common\COM Compatibility\{EAB22AC3-30C1-11CF-A7EB-0000C05BAE0B}]
"Compatibility Flags"=dword:00000400
Die Quelle für die Registry-Pfade der Kill-Bits für die alten Office-Versionen habe ich von dort genommen:
support. microsoft. com/en-us/topic/security-settings-for-com-objects-in-office-b08a031c-0ab8-3796-b8ec-a89f9dbb443d
Microsoft erwähnt in dem COM KillBit Artikel auch:
support. microsoft. com/en-us/topic/security-settings-for-com-objects-in-office-b08a031c-0ab8-3796-b8ec-a89f9dbb443d
HKEY_LOCAL_MACHINE\Software\Wow6432Node\Microsoft\Office\Common\COM Compatibility\{EAB22AC3-30C1-11CF-A7EB-0000C05BAE0B}
ActivationFilterOverride=dword:0x00000001.
Ist das nicht mehr notwendig und der Wert 1 mittlerweile der Standard, falls nicht gesetzt?
danke für
HKEY_LOCAL_MACHINE\Software\Wow6432Node\Microsoft\Office\Common\COM Compatibility\{EAB22AC3-30C1-11CF-A7EB-0000C05BAE0B}]
"Compatibility Flags"=dword:00000400
wobei es mir wumpe ist, wenn der betrieb den bach runterläuft, wegen eines verseuchten word-dokuments.
Da die "Fixes" von Microsoft wohl nur Office schützen, würde ich gerne die DLL überall deaktiveren (umbennen). Damit wären auch andere OLE-Anwendungen geschützt. Nur: Es scheint doch noch Software zu geben, die immer noch auf die IE-Komponente setzt. So ist mir bei der Recherche ein Thread aus jüngere Zeit in den Intel Hilfeforen untergekommen, in dem der Support zur Problemlösung beim Grafiktreiber direkt auf eine Repatur der DLL verwiesen hat.
Hat von euch noch jemand ein Idee, wie man die DLL auch in anderem Kontext (andere Office-Pakete etc) entschärfen kann?
Jemand mit Praxissoftware Probleme, die mit Outlook verknüpft ist? Zeitlicher zusammenhang sind die Sicherheitsupdates.