[English]Microsoft hat zum 9. August 2022 (Patchday) das Sicherheitsupdate KB5002242 für Excel 2013 freigegeben. Der Patch soll sowohl eine Schwachstelle als auch einen Bug in dieser Excel-Version beseitigen. Im Blog gibt es aber Rückmeldungen der Leserschaft, dass dieses Update zu Problemen führt. Zudem dümpelt noch ein anderes Excel-Problem hier bei mir, welches ich mal dazu packe. Ergänzungen: Es gibt die Bestätigung durch Microsoft sowie einen Workaround.
Anzeige
Excel 2013 Update KB5002242
Das Excel 2013 Update KB5002242 schließt die Schwachstelle CVE-2022-336 (Microsoft Excel Security Feature Bypass Vulnerability). Zur Ausnutzung der Sicherheitslücke muss ein Angreifer eine speziell gestaltete Datei an einen Benutzer mit einer betroffenen Version von Microsoft Excel senden und diesen dazu bringen, diese zu öffnen. Die Übermittlung der Datei könnte per E-Mail oder per Download von einer kompromittierten Website erfolgen. Ein Angreifer, der diese Schwachstelle erfolgreich ausnutzt, könnte die Funktion "Packager Object Filters" aushebeln.
Das Update behebt weiterhin ein Problem, bei dem gemeinsam genutzte Arbeitsmappen im .xls-Format möglicherweise nicht korrekt zusammengeführt werden.
Update löst xlsx-Fehler aus
Hier im Blog hat sich Sebastian gemeldet und berichtet von Problemen bei Microsoft Excel 2013 in Verbindung mit den August 2022-Updates. Sebastian schreibt:
kurze Rückmeldung – ich weiß nicht an welchem Patch es liegt aber bei Excel 2013 bekommen wir nun beim Öffnen immer diesen Fehler:
Das Dateiformat und die Dateierweiterung von "….xlsx" passen nicht zueinander. Möglicherweise ist die Datei beschädigt oder nicht sicher. Sie sollten sie nicht öffnen, wenn sie ihrer Quelle nicht vertrauen. Möchten Sie die Datei trotzdem öffnen?"
Blog-Leser Stefan bestätigt den Fehler auf einem Terminalserver mit Excel 2013 und benennt das Update KB5002242 als Ursache.
Anzeige
Hatte das selbe Problem mit Excel 2013 auf einem TS.
Nach entfernen des kb5002242, ist alles wieder gut.
Das Phänomen trat nur bei langen Verzeichnispfaden bzw. Dateinamen auf.
Habe ich den Dateinamen gekürzt, lies sich die Datei ohne Fehlermeldung öffnen.
Und in diesem Kommentar meldet Hauten Ärger mit KB5002242, wenn eine XLSX auf einem DFS Server per UNC geöffnet wird. Es kommt die Meldung:
Das Dateiformat und die Dateierweiterung passen nicht zueinander.
Setzt er ein Laufwerk als Dateipfad, lässt sich die XLS-Datei ohne Probleme öffnen. Deinstallation des Updates behebt den Fehler. Falls der Fehler also bei euch auftritt, wisst ihr, wo nachzuschauen ist.
Hilft diese Maßnahme?
Ergänzung: Im englischen Blog hat sich ein Benutzer gemeldet und schreibt, dass der das Ganze per Registry-Eintrag beheben konnte.
Create a new DWORD32 Key
HKEY_CURRENT_USER\Software\Microsoft\Office\*X*\Excel\Security\ExtensionHardening=0x00000000(0)
In seinem Fall war *X* 15.0 für Excel 2013. Nach einem Neustart war das Problem bei ihm weg. Das Problem ist im Beitrag Force file extension to match file type beschrieben. Allerdings unterdrückt das die Fehlermeldung nur – der Bug ist nicht behoben. Ich habe das Ganze jetzt mal per Twitter an Microsoft Helps gemeldet und auch diesen MS Answers-Forenbeitrag erstellt.
Microsoft bestätigt den Bug
Im Support-Beitrag zu Update KB5002242 wird der Fehler nun bestätigt, und es finden sich folgende Informationen.
-
Symptom
After you install this update, you might encounter the following warning when you open Excel files from a network location if the file extension is correct:The file format and extension of %FILENAME% don't match. The file could be corrupted or unsafe. Unless you trust its source, don't open it. Do you want to open it anyways?
Status
Microsoft is researching this issue and will update this article when a fix is available.Workaround
Copy the affected files to the desktop, and then open them in Excel.
Excel 2016: Makros gehen beim Speichern kaputt
Es gibt noch ein zweites Problem, welches mit dem Patchday aber nichts zu tun hat, sondern bereits im Juni 2022 von Jeannette Hügli im Diskussionsbereich berichtet wurde. Das das Thema versandet ist und ich die Diskussionsbereichseinträge zyklisch lösche, ziehe ich den Sachverhalt mal hier heraus – vielleicht kann das jemand bestätigen. Jeanette schreibt:
Hallo zusammen.
Ich entwickle Excel-Anwendungen und verwende dazu eine Office Version 16. Lange Zeit hatte ich die Option zur automatischen Installation der Updates aktiviert. Doch am 4. Oktober 2021 bemerkte ich, dass die Excel-Anwendungen nach dem Speichern kaputt gingen. Verursacht wurde das erstmals in der Version 2109 (Build 14430.20234), seither habe ich das noch zwei weitere Male bemerkt (allenfalls kam es öfters vor, aber ich habe ja nun die automatische Installation deaktiviert).
Normalerweise passiert ja Folgendes: Beim Speichern werden Formeln, die nicht auf Englisch vorliegen, auf Englisch umgestellt und so gespeichert. Beim Öffnen der Datei werden diese wieder in die Office-Sprache übersetzt (bei mir Deutsch).
Und das passiert dann eben manchmal nicht mehr. In der oben angegebenen Version wurden die Formeln auf Deutsch gespeichert, was Excel dann beim Öffnen nicht versteht und die Datei nicht öffnen kann. Die vorgeschlagene Reparatur bewirkt, dass alle Teile, die Formeln enthalten (Formeln auf dem Arbeitsblatt, Bedingte Formatierungen usw.) gelöscht werden.
Die einzige Rettung, die ich bisher gefunden habe, ist auf eine Datei-Version zurückzugehen, die unter einer früheren Version gespeichert wurde.
Recherchen zu diesem Thema haben mir keinen Hinweis gebracht, wodurch dieses Verhalten ausgelöst werden könnte. Hat jemand schon mal davon gehört? Hat jemand eine Idee, wie ich das verhindern könnte?
Mit herzlichem Dank
Jeannette
Ich habe bisher im Internet auch noch nichts zu diesem Fehler gefunden. Vielleicht kann jemand das bestätigen.
Ähnliche Artikel:
Microsoft 365 Version 2206: Neuer Absturz-Bug in Apps im Monthly Channel (August 2022)
Microsoft: Workaround für Outlook-Absturz; Rollback von Microsoft 365 auf Version 2205
Anzeige
Wir haben den gleichen Fehler, eine Lösung scheint noch nicht in Sicht zu sein. Auch ein Abspeichern der Datei in .xlsx oder .xlsm hilft dabei nicht.
Yes, wir können das Problem auch nachstellen mit Excel 2013 unter Win10. Auffälligerweise betrifft das nur Dateien, die eine gewisse Pfadlänge mitbringen (kurze Stichprobe ergab 110+). Leider konnten wir den betroffenen Patch beim ersten Versuch nicht deinstallieren. Er taucht zwar in der Liste der Historie auf, aber nicht unter "Updates deinstallieren". Deinstallation mittels WUSA klappte ebenfalls nicht.
ich kann das nicht nachstellen. Ich habe "MS Office Professional Plus 2013" mit der "klick & los" ("click & run") -Version.
Ich habe Excel geöffnet und eine neue Datei als "test.xlsx" abgespeichert. Das geht problemlos und auch das öffnen wieder.
Das mit Länge über 110-Zeichen ist interessant. Es ist ein leidiges Thema mit MS.
Es gab mal eine Änderung, dass MS wohl 256 Zeichen kann verarbeiten. Leerzeichen zählen mit und Verzeichnisse und Unterverzeichnisse! Das kann schnell passieren. Das hineinkopieren in Verzeichnisse geht. Das Bearbeiten und kürzen des Daeinames dann nicht mehr. Im Extremfall kann man den Dateinamen auch nicht mehr mit den Explorer wie üblich kürzen und dann verschieben oder löschen. Ich nutze in solchen Fällen das Programm "Speedcommander" von Sven Ritter. Damit geht es problemlos.
Macht man eine Datensicherung und spielt sie wieder ein geht es. Also es ist ein MS-Problem. Da ssind meine Erfahrungen seit Jahren. Ich habe mich daran gewöhnt und weiß wie ich das Ganze dann ändern und bearbeiten kann für meine Zufriedenheit. Es gibt auch bestimmt andere Varianten.
In dem Fall scheint es je eben nicht die typische 256 -Zeichen Problematik zu sein, zumindest auf den ersten Blick nicht.
Der gesamte Pfad mit Dateinamen (Datei im Netzlaufwerk) war knapp über 100 Zeichen, wobei in der Fehlermeldung selber der Dateiname auch teilweise falsch stand. In der Form, dass ein Teil des Dateinamens doppelt vorkam bzw. ich bilde mir sogar ein da ganz andre Buchstaben drinnen vorkamen. Der in der Meldung angezeigte Dateiname war um ein paar Zeichen länger als der eigentliche Dateiname ¯\_(ツ )_/¯
Die Nutzer hatten auch Ordner mit vorangestellten "!" benutzt, damit Windows diese ganz oben anzeigt und im Dateiname waren auch Punkte für Datumsangaben. Was ich jetzt nicht so toll fand, evtl. zum Problem beigetragen haben könnte, aber hat dann auch keine Rolle gespielt.
Danke, ich habe es schon sehr ernst genommen und deshalb auch bei mir versucht es nachzustellen. Ich brauche Excel unbedingt. Es betrifft wohl nicht alle Versionen von Excel 2013. Ich muss es mal auf meinen "alten" HP-Notebook machen. Dort ist zwar die gleiche Version drauf (Office pro click to run 2013). Es verhält sich aber komischerweise etwas anders.
Am Anfang ist es immer schwierig die eigentliche Ursache herauszufiltern. Günter wird schon sammeln und recherchieren.
Dass es nicht an den 110-zeichen (256-Zeichen im Ergebnis) liegen kann ist mir bewusst. In der Not muss man jedoch alles hinterfragen und testen. Ich habe das Problem nur ergänzend auch erwähnt. Denn wird die Zeichenzahl in der Summe über 256-zeichen betragen, so kann man diese (abgespeicherte) Datei im Programm bearbeiten und auch neu speichern. Es geht aber das andere alles nicht.
Grüße
Im englischen Blog hat jemand etwas von 90 Zeichen geschrieben … die Meldungen gehen aber bis runter auf 13 Zeichen …
Also bei mir funtioniert es zum Glück. Ich habe jetzt mal das mit der Zeichenanzahl bis zum Äußerste getrieben mit diversen Unterverzeichnissen. Dann kann die Meldung, dass der Dateiname maximal 218 Zeichen sein darf (also nicht 256 Zeichen). Das ist alles auf internen
Festplatten.
So wie ich das hier alles lese, auch im englischen Blog, ist es wohl ein Serverproblem wo die Festplatten dann liegen. Ich könnte ja mal meine Netzfestplatten anschalten.
Wir bekommen auch die Meldung "Möglicherweise ist die Datei beschädigt oder nicht sicher. Sie sollten sie nicht öffnen, wenn sie ihrer Quelle nicht vertrauen. Möchten Sie die Datei trotzdem öffnen?"
Es handelt sich um .xlsx die im Netzlaufwerk gespeichert sind, ein Einkürzen des Dateinamens bzw. verschieben "behebt" den Fehler. Der Pfad ist aber nicht mal wirklich lang bzw. weit von den kritischen 250 Zeichen entfernt, dürfte nicht mal die Hälfte sein.
In der Fehlermeldung selber wird der Dateiname erwähnt, aber komischerweise "falsch". Ein Teil des Dateinamens doppelt sich irgendwie.
Wie viel Minuten jetzt für den Scheiß wieder draufgegangen sind… Ich hab jetzt nicht mal unbedingt an irgendwelche Updates gedacht, sondern den Beitrag hier wieder durch Zufall gefunden (Danke BornIT Blog!). Ich dachte erst, es wäre eine separate Beschränkung die mir nicht bekannt war.
Mag ja nicht auf Schulterklopfen machen. Aber ich versuche hier zeitnah solche Bugs, speziell wenn diese von Lesern gemeldet werden, hier zu einem Beitrag zusammen zu fassen. Und mit dem englischen Pendant wird das oft über meine Kanäle an die MS Produktgruppe gemeldet. Muss ich im aktuellen Fall noch machen.
Ich habe gerade einen Test mit einem Terminalserver und 2013 gemacht, auch wenn der Pfad z. B. nur G:\Öffentlich\Test.xls ist, funktioniert es nicht. Es scheint wohl mit dem DFS etwas zu tun zu haben.
Hallo
Ich kann es bestätigen. Der Dateiname in der Fehlermeldung ist Falsch/ teillweise gedoppelt nicht komplett verdoppelt.
Kopiert man die Datei 1:1 auf die lokale platte läst sich diese Kopie fehlerfrei öffnen.
DFS haben wir bei den Shares nicht im Einsatz.
irgendwie wird der Dateiname (server\share\Pfadvomeinstiegspunkt\Dateiname) verfälscht und daraus resultiert der Fehler.
Das mit dem "verfälschten Pfad" hat mich ja am meisten gewundert. Man hat eine Datei mit Namen "…..Verbrauchsdaten (SD).csv" und in der Fehlermeldung wird dann sowas wie "…..Verbrauchsdaten (SD) (SD).csv" angezeigt.
Wie sowas geht und vor allem warum ist mir schleierhaft. Ich gehe mal davon aus oder hoffe, dass Problem ist "in Excel". Wenn da im Hintergrund irgendwie falsche Pfadangaben erzeugt/gespeichert werden.
Guten Morgen,
ich kann den Excel Bug ebenfalls bestätigen.
Das KB deinstalliert, ausgeblendet und weiter geht`s.
Vielen Dank für die stets topaktuellen News hier! Was würden wir nur ohne Günter Born machen. :-)
Hallo,
ich kann bestätigen, dass der Workaround mit dem DWORD "HKEY_CURRENT_USER\Software\Microsoft\Office\*X*\Excel\Security\ExtensionHardening =0x00000000(0)" funktioniert.
Allerdings hat sich wohl ein Leerzeichen in den Registry Key eingeschlichen
Viele Grüße
Matthias
Bei uns im Unternehmen hat es einen positiven Nebeneffekt. Die Kollegen sind nun wieder etwas mehr gezwungen, kurze Verzeichnis- und Dateinamen zu verwenden. :-)
Trotzdem vielen Dank für die ganzen Infos und das du Microsoft zur Klärung kontaktiert hast!
Grüße
Martin
Bezüglich "Microsoft zur Klärung kontaktiert": Die wollen inzwischen wohl nicht mehr durch Nutzer belästigt werden (dazu passt auch dieser Beitrag von Martin Geuß auf Dr. Windows). Ich kenne es aus mehr als einem Jahrzehnt Tätigkeit als unbezahlter Community-Moderator für Windows im Microsoft Answers-Forum. Dort hatte ich die Möglichkeit, einen Thread an alle Moderatoren zu eskalieren und die Microsoft-Moderatoren zu bitten, das Thema ggf. an die Microsoft Produktgruppe zu eskalieren. Hat bisher auch immer geklappt.
Im englischen Microsoft Answers-Forum hat sich ein "Microsoft Agent" (wurden früher als Microsoft Forenmoderatoren bezeichnet und es waren Dienstleister und Microsoft-Mitarbeiter – inzwischen sind es aber wohl nur noch Dienstleister) mit folgendem Hinweis gemeldet.
Ich kann es nicht final werten – denn ich habe als deutscher "Volunteer Moderator" (früher Communiy-Moderator) nur entsprechende Berechtigungen zum Eskalieren im deutschen Windows-Forum. Entweder hat Microsoft seine Dienstleister erneut ein Stück mehr vom Kontakt mit den Produktgruppen abgeschnitten – oder der Moderator hatte keine Lust, das zu bearbeiten.
Das MS Answers-Forum geht sowieso den Bach runter – wenn ich schon die automatischen Übersetzungen von US-Moderatoren mit "allgemeinem Geschwurbel, wie gerne man hülfe" in deutschen Posts des Answers-Forums lese, stellen sich mir jeweils die Nackenhaare auf. Ich interpretiere es aber so, dass Microsoft kein Interesse mehr an wirklichem Feedback (speziell aus Anwender-Communities hat).
Habe mir jetzt erneut die 3 Minuten Zeit genommen, den Case durch Microsofts (sinnloses) Support-Forumular zu nudeln. Der arme Supporter in Indien war bass erstaunt, ziemlich deutlich den Hinweis zu bekommen, dass ich keine Hilfe von ihm will, sondern dass er das Thema an die Produktgruppe melden solle. Er versprach, das Ganze an seinem Super Visor weiter zu leiten. In deutschen Amtsstuben ist das ein Synomyn für "gelesen, gelacht, gelocht und abgeheftet" …
Von daher lese ich hier immer süffisant die Nutzerkommentare, wenn mir wieder jemand erklären will, wie "alternativlos und toll dieses oder jenes MS-Produkt ist" – und mir schießt dann regelmäßig Eddie Stoiber durchs Hirn. Sorry für den letzten Satz – der Rant musste einfach sein ;-).
Moin,
also in der MS-KB ist es nun als known-issue drin
https://support.microsoft.com/en-us/topic/description-of-the-security-update-for-excel-2013-august-9-2022-kb5002242-ba736c29-885d-4d7c-a3fb-bf61242f4ce0
Symptom
After you install this update, you might encounter the following warning when you open Excel files from a network location if the file extension is correct:
The file format and extension of %FILENAME% don't match. The file could be corrupted or unsafe. Unless you trust its source, don't open it. Do you want to open it anyways?
Status
Microsoft is researching this issue and will update this article when a fix is available.
Workaround
Copy the affected files to the desktop, and then open them in Excel.
Schönes Wochenende
Danke für den Hinweis – dann hat möglicherweise meine Meldung über Twitter an MS Help was gebracht.
Warum ist der Workaround "Copy the affected files to the desktop, and then open them in Excel".
Ich kann die Datei trotz der Meldung öffnen, bearbeiten und speichern. Sollte man das nicht machen? Das ist der offensichtlichste Workaround. Der Workaround ist vielleicht die sicherste Lösung, aber jede Datei aus der Ordnerstruktur rauskopieren….
Bei uns tritt das Problem bei einigen Anwendern auch auf. Öffnen, bearbeiten und speichern funktioniert auch problemlos – der Hinweis beim Öffnen ist natürlich verwirrend….
Moin,
vielen Dank für die Info und die Kommentare hierzu! Ich hatte gestern von einem Kunden eine entsprechende Meldung erhalten, aber noch nichts gefunden. Hatte aber schon die Vermutung, dass es ein Update sein könnte. Der Kunde hat Office 2013 Standard (also Volumen-Lizenz) im Einsatz.
Für solche Themen ist dieser Blog wirklich extrem hilfreich, Danke dafür!
Viele Grüße
yoyobo
Danke für die Ergänzung mit den Reg Eintrag, hat geholfen
Bei Office 2013 hilft dieser Regkey zu 100% und niemand muss den Patch entfernen. Der Key sollte dann aber auch mal wieder entfernt werden, wenn MS das Problem behoben hat.
HKEY_CURRENT_USER\Software\Microsoft\Office\*X*\Excel\Security\ExtensionHardening=0x00000000(0)
Bei Office 2013 Pro Plus unserer Anwender hat der Regkey leider nicht geholfen, aber das Deinstallieren des Updates KB5002242.
Mahlzeit.
Gibt es hierzu neue Erkenntnisse?
Über den Blog-Beitrag hinaus ist mir nichts bekannt.
Hallo,
in unserer Domäne mit importieren Office ADMX Dateien hat diese GPO-Einstellung geholfen:
"Übereinstimmung der Dateierweiterung mit dem Dateityp erzwingen"
Aktivieren und "Andere zulassen" auswählen
Diese Einstellung war bei uns auf "Andere zulassen, aber warnen" gesetzt.
Bei unsern derzeitig 2 Betroffenen Systemen haben wir das Update KB5002242 deinstalliert. Offiziell hatten wir es noch nicht freigegeben über Wsus. Haben an unseren Wsus GPO's Anpassungen vorgenommen und die 2 Systeme hatten gleich die Chance genutzt und aus Internet geladen. Anpassung Optimiert und Firewall komplett für Windows Updates gesperrt. Falls wir mal wieder die Wsus GPO's anpassen können die Systeme nicht online saugen.
Sehr interessant das die GPO's "Zielversion des Funktionsupdates auswählen" und "Zugriff auf alle Windows-Update-Funktionen entfernen" unsere Wsus Vorgabe ausgehebelt hat. Benutzer konnten nicht selbständig installieren aber System hat einfach gezogen und Bios Updates durchgeführt.
Guten Morgen zusammen,
wie es aussieht hat Microsoft heute einen Fix veröffentlicht.
kb5002268
Verbesserungen und Korrekturen
Dieses Update behebt ein Problem, bei dem beim Öffnen einer Datei von einem Netzwerkspeicherort mit einem langen Dateipfad fälschlicherweise eine Warnung wegen eines Dateiformat- und Erweiterungskonflikts angezeigt wird.This update fixes an issue in which opening a file from a network location that has a long file path incorrectly shows a warning about a file format and extension mismatch.
Ich sehe aber nicht, dass es das alte Update ersetzt.
Jetzt die Frage – trotzdem das alte Update im WSUS wieder freigeben oder (weiterhin) ablehnen?`
Schöne Grüße
Sebastian
Danke, ist im Beitrag Microsoft Office Updates mit Fix für Excel-Bug (6. September 2022) angesprochen.
Wir hatten das Problem mit der Fehlermeldung bezgl. des Dateiformats und der Dateiendung auch. Wir hatten das auf einem UNC eingebunden Netzlaufwerk aber auf einem anderen UNC eingebundenen Netzlaufwerk nicht. Der Workaround mit dem Unterdrücken der Fehlermeldung durch den Eintrag in der Registry hat bei uns nicht funktioniert. Das September Update jedoch hat Abhilfe geschaffen, jetzt funktioniert das wieder. Bis zum nächsten Problem…
Hallo,
ich bin auch von dem Problem betroffen aber zum einen, finde ich das verursachende Update KB5002242 nicht in den "installierten Updates" und zum anderen, kann ich weder KB5002268 noch KB5002252 zum fixen installieren. Es heißt immer, dass kein enstprechendes MS Produkt bei mit installiert ist um den fix zu installieren.
Hat jemand eine Idee, was ich sonst noch für Möglichkeiten habe?
VG
Kilian