Атака на Zero-Day CVE-2026-42897 у Exchange: патч відсутній
Уявіть середньовічне місто, яке витратило цілий статок на кам'яні стіни, залізні ворота та рів, але залишило бічні двері поштаря відчиненими, підпертими цеглиною. Приблизно так само почувалися клієнти Exchange OWA минулого четверга. Стіни витримали. Поштовий лаз — ні.
Microsoft розкрила інформацію про CVE-2026-42897 у четвер, 18 травня: активно експлуатована вразливість нульового дня в Outlook Web Access, і через чотири дні патч досі відсутній. Виправлення, за словами самої Microsoft, з'явиться «у майбутньому».
Що сталося
Коротко: вразливість типу міжсайтовий скриптинг (XSS) в OWA дозволяє неавторизованому зловмиснику здійснювати атаки з підробкою через мережу. Як повідомило Dark Reading, реальна експлуатація вже зафіксована в дикій природі. CISA додала CVE до свого каталогу KEV у п'ятницю, що є федеральним еквівалентом оголошення пожежної тривоги.
Момент вибору майже комічний. Баг з'явився через два дні після масштабного випуску Patch Tuesday, який, за іронією долі, не містив жодного zero-day. Захисники ледве встигли закрити тікети попереднього місяця, як цей вже опинився в черзі — без будь-якого виправлення.
Вразливі продукти — локальне тріо: Exchange Server 2016, Exchange Server 2019 та Exchange Server Subscription Edition. Microsoft присвоїла вразливості показник CVSS 8.1. Національна база даних вразливостей NIST не погодилась і оцінила її як середню — 6.1. Ця розбіжність важлива: кожен, хто використовує автоматичне пріоритизування патчів за рівнем критичності, отримає різні відповіді залежно від того, якому джерелу довіряє.
Центр кібербезпеки Бельгії опублікував власне попередження в понеділок, і бельгійці не добирали слів. Успішна експлуатація, попередив CCB, може надати зловмиснику доступ до поштової скриньки Outlook жертви та токенів сесії, а також можливість несанкціоновано змінювати налаштування поштової скриньки або вміст електронних листів. Іншими словами, поштовий лаз не просто відчинений. Зловмисник ще й може залізти в нього та переставити листи.
Технічна анатомія
Якщо відкинути брендинг, це класичний XSS-ланцюжок. Власний опис Microsoft говорить прямо: «Зловмисник може скористатися цією проблемою, надіславши жертві спеціально сформований лист. Якщо користувач відкриє лист в Outlook Web Access і будуть виконані певні умови взаємодії, довільний JavaScript може бути виконаний у контексті браузера». Ось і все. Лист-пастка, жертва відкриває його в OWA — і JavaScript зловмисника вже працює в сесії користувача.
XSS, якщо хтось забув, є одним із найпоширеніших класів вразливостей у світі та постійним гостем у OWASP Top 10. Богдан Тірон, засновник компанії з пентестингу Fortbridge, зауважив у LinkedIn, що XSS «досі панує в корпоративній пошті у 2026 році» і що «нудні вразливості — це ті, що продовжують працювати». Він має рацію, і кожен, хто хоч раз тріажував вебпоштовий продукт, розуміє суть: насичений рендеринг HTML, десятиліття сумісності зі застарілою розміткою та санітайзер, який має бути бездоганним кожного разу, тоді як зловмиснику достатньо перемогти лише один раз.
Оцінка наслідків від Тірона варта того, щоб викарбувати її на стіні. Ризик, написав він, «полягає не в компрометації сервера. Це компрометація поштової скриньки: читання пошти, відправлення листів від імені жертви, крадіжка токенів сесії, встановлення правил переадресації, які виживають після скидання паролів». Саме останній момент — нудна деталь, яка руйнує квартальні показники. Правило переадресації, що тихо сидить у поштовій скриньці фінансового директора, не перейматиметься тим, що IT щойно змінило пароль. Воно продовжуватиме зливати рахунки-фактури.
Звідти шлях до компрометації ділової пошти або підготовки до атаки з вимогою викупу короткий і добре вихожений. Вам не потрібен RCE на хості Exchange, щоб обманом змусити відділ закупівель переказати гроші або запустити внутрішню фішингову кампанію, яка обходить усі зовнішні поштові фільтри організації. Достатньо одного переконливого повідомлення зсередини.
Хто постраждає
Очевидними жертвами є компанії з локальним Exchange, і це далеко не мала аудиторія. Регульовані галузі, суверенні хмари та ті, чиї комплаєнс-команди злякалися ідеї переносити поштові скриньки до M365, досі тримають Exchange 2016, 2019 або SE десь у серверній. Сюди відноситься чимала частина бек-офісів фінтех-компаній, платіжних процесорів із жорсткими вимогами щодо резидентності даних та iGaming-операторів, яким подобається тримати операційні комунікації на інфраструктурі під фізичним контролем.
Галузі, за які я найбільше переживатиму впродовж наступних 90 днів, — це ті, де компрометація поштової скриньки безпосередньо означає рух грошей. Операційні команди в платежах підтверджують зміни постачальників електронною поштою. Казначейські підрозділи підтверджують деталі переказів електронною поштою. Оператори букмекерських контор координуються з платіжними провайдерами та KYC-вендорами електронною поштою. Правило переадресації на правильній поштовій скриньці коштує більше, ніж будь-яке вимагацьке програмне забезпечення.
Крипто- та DeFi-компанії з будь-яким корпоративним Exchange-середовищем мають бути особливо насторожі. Кожен, хто спостерігав за розгортанням атаки на міст, знає: зловмисник рідко зламує криптографію. Вони соціально інжинерять оператора. Стійке закріплення в поштовій скриньці — це саме той вид передпозиціонування, який через шість тижнів перетворюється на постмортем зі словами «як вони дізналися розклад наших multisig-підписантів».
Компанії у сфері рекламних технологій та корпоративної інфраструктури, які вже перейшли на Exchange Online, також не можуть розслабитися. Чимало придбаних дочірніх підприємств досі тримають власний локальний Exchange, бо проєкт інтеграції переносили на наступний квартал три роки поспіль. Ці забуті сервери тепер є зафіксованими CISA зобов'язаннями, що лежать у вашій CMDB під рубрикою «legacy, не чіпати».
Покроковий план для команд безпеки
По-перше, зробіть ту нескромну річ, про яку Microsoft благає клієнтів. Переконайтеся, що Exchange Emergency Mitigation Service увімкнена. Її випустили у 2021 році, вона увімкнена за замовчуванням, і Redmond автоматично розгорнув через неї пом'якшення для версій 2016, 2019 і SE. Цитата Microsoft варта уваги: «Використання EM Service — найкращий спосіб негайно усунути цю вразливість. Якщо EM Service наразі вимкнена, рекомендуємо ввімкнути її прямо зараз». Повірте їм.
Якщо EM Service вимкнена, резервний варіант — оновлений Exchange On-premises Mitigation Tool (EOMT), який застосовується на кожен сервер окремо або запускається через підвищену Exchange Management Shell. Майте на увазі: відомі методи пом'якшення порушують функції OWA Print Calendar та спрощеного OWA. Це штормовий потік тікетів для служби підтримки, але краще так.
Крім офіційних заходів пом'якшення, шукайте патерни персистентності, на які вказав Тірон. Перевірте кожну поштову скриньку на наявність правил вхідних повідомлень, особливо правил переадресації та перенаправлення, створених за останні два тижні. Масово анулюйте токени сесій OWA, якщо ваш орендар це підтримує. Перегляньте відправлені елементи на наявність повідомлень, що схожі на внутрішній фішинг або спроби переспрямування рахунків-фактур. Зіставте активність із відповідними техніками ATT&CK щодо збору електронної пошти та маніпуляцій із правилами, щоб ваші засоби виявлення витримали наступний варіант цього бага.
І оновіть регламент управління патчами вже зараз, поки спокійно, бо Microsoft не назвала жодних термінів для реального виправлення. Заздалегідь заброньте вікно обслуговування на той момент, коли воно з'явиться.
Ключові висновки
- Патча немає, експлуатація активна, внесено до KEV. CVE-2026-42897 використовується в дикій природі, а ETA від Microsoft — «у майбутньому».
- Увімкніть Exchange EM Service сьогодні. Це рекомендований захід пом'якшення, увімкнений за замовчуванням із 2021 року, і автоматично розгортає виправлення для версій 2016, 2019 та SE.
- Ризик — компрометація поштової скриньки, а не захоплення сервера. Очікуйте BEC, персистентності через правила переадресації та крадіжки токенів сесій, а не вимагацьке ПЗ на хості Exchange.
- CVSS 8.1 проти NIST 6.1. Автоматична пріоритизація за рівнем критичності дасть суперечливі відповіді. Перевизначте вручну та ставтеся до цього як до критичної вразливості.
- Нудні баги продовжують перемагати. XSS у вебпошті у 2026 році — це не жарт. Це цеглина, що тримає відкритими двері поштаря, поки вежа гордо стоїть позаду.
Часті запитання
Q: Що таке CVE-2026-42897 і чому це серйозно?
Це вразливість типу міжсайтовий скриптинг (XSS) в Microsoft Exchange Outlook Web Access, яка дозволяє неавторизованому зловмиснику виконувати JavaScript у браузерній сесії жертви після того, як та відкриє спеціально сформований лист в OWA. Це серйозно, оскільки вразливість активно експлуатується, CISA додала її до каталогу KEV, а Microsoft ще не випустила патч.
Q: Які версії Exchange вразливі до CVE-2026-42897?
Вразливість стосується локальних Exchange Server 2016, Exchange Server 2019 та Exchange Server Subscription Edition. Microsoft присвоїла їй показник CVSS 8.1, тоді як Національна база даних вразливостей NIST оцінила її в 6.1.
Q: Як організації можуть пом'якшити zero-day у Exchange до виходу патча?
Microsoft рекомендує ввімкнути Exchange Emergency Mitigation Service, яка активована за замовчуванням із 2021 року та автоматично розгортає пом'якшення. Як альтернативу клієнти можуть завантажити оновлений Exchange On-premises Mitigation Tool і застосувати його на кожен сервер. Обидва варіанти частково порушують функції OWA Print Calendar та спрощеного OWA.
Claude Mythos Знаходить 10 000 Zero-Day Вразливостей, Конвеєр Патчів Зламано
Claude Mythos Preview від Anthropic знайшов понад 10 000 zero-day за місяць. Виправлено лише 97. 90-денне вікно координованого розкриття втратило сенс.
$20 за Zero-Day: Плагіни WordPress стали мисливськими угіддями для ШІ
За три дні ШІ-пайплайн знайшов 300+ zero-day у плагінах WordPress по $20 кожен. Інфраструктура розкриття вразливостей не готова, а зловмисники вже діють за тією самою схемою.
Злам GitHub через Розширення Nx Console: 3 800 Репозиторіїв Скомпрометовано
TeamPCP викрав 3 800 внутрішніх репозиторіїв GitHub через отруєне розширення Nx Console за 18 хвилин. Головне — як команди платформ оцінюють ризики developer tooling.




