Для адміністраторів Exchange висновок простий: не варто чекати на CU1, щоб закрити поточні ризики безпеки. Потрібно й надалі встановлювати щомісячні оновлення безпеки Exchange SE, а CU1 планувати окремо — після того, як Microsoft оголосить його готовим.

Чому реліз CU1 затримується

Інструменти безпеки з підтримкою ШІ можуть генерувати потенційні вразливості швидше, ніж інженерні команди встигають їх опрацьовувати. Повідомлена проблема може виявитися справжньою вразливістю, хибним спрацюванням або дефектом, який складно стабільно відтворити.

Якщо проблему підтверджено, розробникам потрібно спроєктувати й реалізувати виправлення, перевірити його на великій кодовій базі Exchange, а також переконатися, що воно не створює нових проблем із надійністю чи сумісністю. Microsoft описує цей процес як послідовність перевірки, відтворення, виправлення, тестування та пошуку регресій — паралельно з підготовкою щомісячних оновлень.

Тому CU1 — це не просто пакет уже завершених змін. Випуск за початковим графіком міг би змусити Microsoft або не включити до накопичувального оновлення щойно підтверджені вразливості, або поспішити з виправленнями, які ще не пройшли достатнє регресійне тестування, або все одно відкласти реліз. Компанія обрала затримку й заявила, що випустить CU1, коли збірка досягне прийнятного стабільного стану та настане місяць без нагального безпекового навантаження.

Як змінювався графік Microsoft

План релізу змінювався поетапно:

• спочатку Microsoft орієнтувався на першу половину календарного 2026 року;
• згодом ціль перенесли на другу половину 2026 року;
• тепер компанія не називає жодної дати й повідомляє, що CU1 все ще перебуває в розробці.

Команда Exchange продовжує додавати щомісячні виправлення безпеки до внутрішньої збірки CU1. Отже, майбутнє накопичувальне оновлення має містити роботу, виконану під час затримки, а не означати зупинку супроводу безпеки Exchange.

Щомісячні оновлення безпеки продовжують виходити

Відсутність дати для CU1 не означає, що користувачі Exchange SE залишилися без виправлень. Microsoft випустив оновлення безпеки Exchange SE у червні, липні та серпні 2026 року.

Травень став винятком: Microsoft повідомив, що регулярного оновлення безпеки того місяця не буде. Пізніше компанія опублікувала рекомендації та інформацію про пом’якшення ризику для CVE-2026-42897, а згодом вказала на липневе оновлення як на реліз, після якого відповідну рекомендацію можна скасувати.

Серпневе оновлення також усунуло CVE-2026-65813 — вразливість підвищення привілеїв, яка зачіпала Exchange Server Subscription Edition та інші підтримувані версії Exchange.

Що робити адміністраторам зараз

Встановлювати кожне щомісячне оновлення Exchange SE

CU1 не слід сприймати як майбутній «дедлайн» для безпеки, якого можна просто дочекатися. Microsoft рекомендує організаціям, що вже використовують Exchange SE, підтримувати систему в актуальному стані, поки CU1 залишається в розробці.

Оновлення варто проводити за звичайною процедурою контролю змін: за можливості спочатку тестувати їх у наближених до робочих умовах непроєктних середовищах, оцінювати терміновість з огляду на ризик і рівень відкритості системи, встановлювати відповідний пакет Exchange та перевіряти успішність інсталяції.

Серпневі рекомендації також наголошують: потрібно перевіряти саме збірку Security Update, а не покладатися лише на базову версію накопичувального оновлення, яку показують інструменти Exchange.

Планувати CU1 як окрему масштабну зміну

Щомісячне SU — це передусім оперативна дія для зниження поточних безпекових ризиків. CU1 слід планувати як ширше оновлення платформи: із перевіркою сумісності, тестуванням бізнес-застосунків, підготовкою резервних копій і плану відкату, а також додатковими регресійними перевірками.

Таке розділення допомагає уникнути типової помилки — сприймати CU1 як заміну регулярному патчінгу. Щомісячні оновлення зменшують актуальну поверхню атаки, тоді як CU1 має об’єднати накопичену роботу та стати першим релізом Exchange Server SE із новими функціями.

Який урок дає ця історія про ШІ та безпеку

Затримка Exchange демонструє структурну суперечність сучасної розробки програмного забезпечення. ШІ може збільшити потік потенційних вразливостей, але виявлення — лише початок процесу. Інженерам усе одно потрібно визначити, чи є проблема реальною, відтворити її, створити безпечне виправлення та довести, що воно не порушує роботу пов’язаних компонентів.

З погляду безпеки це радше позитивна проблема: що більше дефектів знайдено до початку атаки, то краще. Водночас така модель створює додаткове навантаження на аналіз знахідок, виправлення, контроль якості, випуск оновлень і комунікацію з клієнтами. Підписне програмне забезпечення формує очікування передбачуваних релізів, тоді як безпекові роботи не завжди вкладаються в календарний план.

Для користувачів Exchange практична модель залишається двоколійною: щомісяця встановлювати оновлення заради захисту, а CU1 запланувати як окрему подію життєвого циклу та консолідації платформи після появи стабільного релізу. Відсутність дати CU1 змінює плани розгортання, але не скасовує потреби підтримувати Exchange SE в актуальному стані.

Для адміністраторів Exchange висновок простий: не варто чекати на CU1, щоб закрити поточні ризики безпеки. Потрібно й надалі встановлювати щомісячні оновлення безпеки Exchange SE, а CU1 планувати окремо — після того, як Microsoft оголосить його готовим.

Чому реліз CU1 затримується

Інструменти безпеки з підтримкою ШІ можуть генерувати потенційні вразливості швидше, ніж інженерні команди встигають їх опрацьовувати. Повідомлена проблема може виявитися справжньою вразливістю, хибним спрацюванням або дефектом, який складно стабільно відтворити.

Якщо проблему підтверджено, розробникам потрібно спроєктувати й реалізувати виправлення, перевірити його на великій кодовій базі Exchange, а також переконатися, що воно не створює нових проблем із надійністю чи сумісністю. Microsoft описує цей процес як послідовність перевірки, відтворення, виправлення, тестування та пошуку регресій — паралельно з підготовкою щомісячних оновлень.

Тому CU1 — це не просто пакет уже завершених змін. Випуск за початковим графіком міг би змусити Microsoft або не включити до накопичувального оновлення щойно підтверджені вразливості, або поспішити з виправленнями, які ще не пройшли достатнє регресійне тестування, або все одно відкласти реліз. Компанія обрала затримку й заявила, що випустить CU1, коли збірка досягне прийнятного стабільного стану та настане місяць без нагального безпекового навантаження.

Як змінювався графік Microsoft

План релізу змінювався поетапно:

• спочатку Microsoft орієнтувався на першу половину календарного 2026 року;
• згодом ціль перенесли на другу половину 2026 року;
• тепер компанія не називає жодної дати й повідомляє, що CU1 все ще перебуває в розробці.

Команда Exchange продовжує додавати щомісячні виправлення безпеки до внутрішньої збірки CU1. Отже, майбутнє накопичувальне оновлення має містити роботу, виконану під час затримки, а не означати зупинку супроводу безпеки Exchange.

Щомісячні оновлення безпеки продовжують виходити

Відсутність дати для CU1 не означає, що користувачі Exchange SE залишилися без виправлень. Microsoft випустив оновлення безпеки Exchange SE у червні, липні та серпні 2026 року.

Травень став винятком: Microsoft повідомив, що регулярного оновлення безпеки того місяця не буде. Пізніше компанія опублікувала рекомендації та інформацію про пом’якшення ризику для CVE-2026-42897, а згодом вказала на липневе оновлення як на реліз, після якого відповідну рекомендацію можна скасувати.

Серпневе оновлення також усунуло CVE-2026-65813 — вразливість підвищення привілеїв, яка зачіпала Exchange Server Subscription Edition та інші підтримувані версії Exchange.

Що робити адміністраторам зараз

Встановлювати кожне щомісячне оновлення Exchange SE

CU1 не слід сприймати як майбутній «дедлайн» для безпеки, якого можна просто дочекатися. Microsoft рекомендує організаціям, що вже використовують Exchange SE, підтримувати систему в актуальному стані, поки CU1 залишається в розробці.

Оновлення варто проводити за звичайною процедурою контролю змін: за можливості спочатку тестувати їх у наближених до робочих умовах непроєктних середовищах, оцінювати терміновість з огляду на ризик і рівень відкритості системи, встановлювати відповідний пакет Exchange та перевіряти успішність інсталяції.

Серпневі рекомендації також наголошують: потрібно перевіряти саме збірку Security Update, а не покладатися лише на базову версію накопичувального оновлення, яку показують інструменти Exchange.

Планувати CU1 як окрему масштабну зміну

Щомісячне SU — це передусім оперативна дія для зниження поточних безпекових ризиків. CU1 слід планувати як ширше оновлення платформи: із перевіркою сумісності, тестуванням бізнес-застосунків, підготовкою резервних копій і плану відкату, а також додатковими регресійними перевірками.

Таке розділення допомагає уникнути типової помилки — сприймати CU1 як заміну регулярному патчінгу. Щомісячні оновлення зменшують актуальну поверхню атаки, тоді як CU1 має об’єднати накопичену роботу та стати першим релізом Exchange Server SE із новими функціями.

Який урок дає ця історія про ШІ та безпеку

Затримка Exchange демонструє структурну суперечність сучасної розробки програмного забезпечення. ШІ може збільшити потік потенційних вразливостей, але виявлення — лише початок процесу. Інженерам усе одно потрібно визначити, чи є проблема реальною, відтворити її, створити безпечне виправлення та довести, що воно не порушує роботу пов’язаних компонентів.

З погляду безпеки це радше позитивна проблема: що більше дефектів знайдено до початку атаки, то краще. Водночас така модель створює додаткове навантаження на аналіз знахідок, виправлення, контроль якості, випуск оновлень і комунікацію з клієнтами. Підписне програмне забезпечення формує очікування передбачуваних релізів, тоді як безпекові роботи не завжди вкладаються в календарний план.

Для користувачів Exchange практична модель залишається двоколійною: щомісяця встановлювати оновлення заради захисту, а CU1 запланувати як окрему подію життєвого циклу та консолідації платформи після появи стабільного релізу. Відсутність дати CU1 змінює плани розгортання, але не скасовує потреби підтримувати Exchange SE в актуальному стані.