23 листопада 2025 року частина користувачів Exchange Online, які працюють з новим клієнтом Outlook, зіткнулася з некоректною роботою вкладень: насамперед звернули увагу на файли Excel, які перестали відкриватися з повідомленням «Try opening the file again later». Microsoft зареєструвала інцидент під ідентифікатором EX1189359 і розпочала розгортання виправлення, але проблема має ширший технічний та безпековий контекст.
Ключова причина проблеми: кодування імен вкладень та не-ASCII символи
За інформацією Microsoft, збій спричинений помилкою в обробці кодування імен файлів у новому клієнті Outlook. Йдеться не лише про документи Excel: будь-який тип вкладень може виявитися недоступним, якщо в його назві присутні символи поза базовим набором ASCII — наприклад, кирилиця, літери з діакритикою, окремі спеціальні символи.
Технічно це означає, що новий Outlook формує запит на відкриття вкладення без коректного зазначення кодування, через що ім’я файлу інтерпретується неправильно. У результаті клієнт не може зв’язати відображувану назву з реальним об’єктом у хмарному сховищі, і користувач отримує помилку замість доступу до документа.
Microsoft вказує, що ризику піддається будь-який користувач нового Outlook, якщо він отримує вкладення з «нелатинськими» назвами. Масштаб впливу офіційно не розкривається, однак, з огляду на глобальне використання кирилиці, азійських і інших алфавітів, інцидент потенційно торкається великої кількості організацій.
Статус виправлення Outlook від Microsoft станом на грудень 2025 року
Станом на 1 грудня 2025 року Microsoft повідомила про підготовку оновлення, яке усуває «відсутнє кодування в запитах» на відкриття вкладень у новому Outlook. Компанія розгортає виправлення поетапно в інфраструктурі Microsoft 365, паралельно аналізуючи першопричину інциденту, щоб мінімізувати ризик повторення подібних помилок.
Важливий момент: оновлення поки що отримали не всі тенанти. Як і у більшості великих хмарних сервісів, оновлення розповсюджується «хвилями», аби знизити ймовірність побічних ефектів. До завершення повномасштабного розгортання Microsoft рекомендує використовувати тимчасові обхідні рішення.
Обхідні рішення: як отримати доступ до вкладень, поки виправлення не застосоване
Практичні варіанти для користувачів
Поки інцидент EX1189359 остаточно не закрито, Microsoft пропонує два основних способи роботи з проблемними вкладеннями:
1. Перехід на веб-версію Outlook (Outlook on the web). Веб-клієнт не страждає від поточного дефекту кодування і коректно відкриває вкладення з не-ASCII символами в назві. Для більшості організацій це найшвидший і найменш витратний спосіб відновити доступ до документів без змін в інфраструктурі.
2. Завантаження вкладення на локальний диск і відкриття напряму. Навіть якщо новий Outlook не здатен відкрити файл з інтерфейсу листа, у більшості випадків його можна зберегти локально та відкрити штатними настільними застосунками (Excel чи іншим ПЗ, асоційованим з типом файлу).
Організаційні кроки для ІТ та ІБ-підрозділів
З точки зору управління ІТ- та кіберризиками організаціям доцільно вжити додаткових заходів:
- проінформувати співробітників про інцидент EX1189359, пояснити тимчасові обхідні шляхи та зменшити кількість звернень у службу підтримки через «зниклі» або недоступні файли;
- тимчасово уникати використання нестандартних символів в іменах особливо критичних файлів, що надсилаються електронною поштою (наприклад, фінансові звіти, юридичні документи);
- забезпечити моніторинг панелі стану Microsoft 365 щодо інциденту EX1189359 та оперативно інформувати бізнес-підрозділи про зміну статусу;
- перевірити, чи не впливає збій на DLP-системи, поштові шлюзи, рішення для архівації та eDiscovery, які також працюють з вкладеннями та можуть залежати від коректної обробки імен файлів.
Чому помилка кодування — це питання кібербезпеки та безперервності бізнесу
На перший погляд інцидент із кодуванням назв вкладень у новому Outlook може виглядати як суто технічний дефект. Однак у практиці кібербезпеки подібні збої безпосередньо впливають на доступність даних — один з трьох базових принципів інформаційної безпеки поряд з конфіденційністю та цілісністю.
Якщо співробітники не можуть оперативно відкрити договори, фінансові моделі, інженерну документацію чи інші критичні файли, це призводить до затримок процесів, зриву дедлайнів і зростання операційних ризиків. Для фінансового сектору, критичної інфраструктури та регульованих галузей такі затримки можуть мати й регуляторні наслідки, коли дотримання строків подання звітності або реагування на інциденти прямо закріплене в нормативних актах.
Ця ситуація також підсвічує важливість безпечної розробки та тестування оновлень великими вендорами. Помилки на стику локалізації, різних кодувань та багатомовних сценаріїв використання регулярно проявляються саме у глобальних організаціях з розподіленими командами. Для служб ІБ та ІТ-операцій це аргумент на користь:
- постійного моніторингу стану хмарних сервісів (Microsoft 365, Google Workspace тощо);
- наявності резервних каналів доступу до пошти та файлів — веб-інтерфейси, альтернативні клієнти, локальні копії критичних документів;
- оновлених планів реагування на інциденти, які охоплюють не лише кібератаки, а й технічні збої на боці постачальників SaaS.
Інцидент з неможливістю відкрити вкладення в новому Outlook через помилку кодування — наочний приклад того, як «дрібний» технічний дефект здатен вплинути на роботу цілих компаній. Організаціям варто використати EX1189359 як привід посилити контроль за хмарними сервісами, перевірити готовність до відмов, навчити співробітників альтернативним сценаріям доступу до пошти та документів і закласти ці уроки в стратегію кіберстійкості бізнесу.
