CVE-2026-87886 в Acronis Backup експлуатують

Коротка відповідь: CVE-2026-87886 — це вразливість, яку активно експлуатують у модулях Acronis Backup для cPanel & WHM і Plesk. Перевірте наявність і версію модуля на кожному сервері, установіть виправлену версію та окремо з’ясуйте, чи не відбулося до оновлення підвищення привілеїв або зміни резервних копій.

Що сталося 16 вересня 2026 року

Американське агентство CISA 16 вересня 2026 року внесло вразливість CVE-2026-87886 до каталогу Known Exploited Vulnerabilities. Причиною стали докази її активного використання. Помилка стосується модулів Acronis Backup, які використовують на Linux-серверах під керуванням cPanel & WHM або Plesk.

CISA оприлюднила інформацію в попередженні від 16 вересня 2026 року. За даними повідомлення BleepingComputer від 15 вересня 2026 року, вразливість має рівень небезпеки High і оцінку CVSS 7,8. Acronis охарактеризувала зафіксовані атаки як обмежені та цілеспрямовані; BleepingComputer уточнює, що виробник спирається на повідомлення одного «потенційно постраждалого» клієнта й поки не оприлюднив індикатори компрометації. У каталозі CISA помилку класифіковано як неправильно налаштовані дозволи за замовчуванням (Incorrect Default Permissions).

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

Яких серверів стосується вразливість

CVE-2026-87886 не поширюється автоматично на кожен сервер із cPanel чи Plesk або на всі продукти Acronis. Визначальним є те, чи встановлено на конкретному Linux-сервері відповідний модуль резервного копіювання та яку саме його версію використано.

Згідно з оприлюдненою інформацією, виправлення містять такі версії:

Перевіряйте кожен сервер окремо. Версія, виявлена на одному сервері cPanel, нічого не говорить про інші вузли чи окремі інсталяції Plesk.

Якщо модуля на сервері немає, сама наявність cPanel або Plesk не означає, що ця конкретна вразливість його стосується.

Чому недостатньо сказати «резервне копіювання працює»

CVE-2026-87886 дає змогу локальному користувачеві з обмеженими правами підвищити свої привілеї на сервері. З наведених описів не випливає, що ця помилка сама по собі дозволяє анонімно ввійти віддалено. Зловмисник повинен спочатку отримати локальний доступ через обліковий запис із нижчими привілеями.

Однак це серйозна проблема. Після підвищення привілеїв під загрозою може опинитися весь сервер, а не лише одне завдання резервного копіювання. Тому необхідно також перевірити облікові записи, SSH-ключі, правила sudo, системні служби та конфігурацію резервного копіювання.

Успішне завершення резервного копіювання не підтверджує, що:

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

Оновлення усуває відому вразливість. Воно не скасовує автоматично зміни, зроблені до його встановлення, і не доводить, що вразливістю не скористалися.

Що зробити негайно

Розділіть роботу на два окремі завдання: установлення виправлення та перевірку на можливу компрометацію. Результат «оновлено» не означає «сервер перевірено».

1. Знайдіть усі інсталяції модуля

Перевірте всі Linux-сервери з cPanel & WHM і Plesk. Не обмежуйтеся головним продуктивним сервером. Модуль може працювати також на старішому вузлі, резервному сервері або системі, якою керує зовнішній постачальник.

Для кожного сервера запишіть:

• назву або унікальний ідентифікатор сервера;
• використовувану панель адміністрування;
• наявність модуля Acronis Backup;
• виявлену версію модуля;
• дату й час перевірки;
• особу, яка перевірила стан.

2. Зафіксуйте стан до внесення змін

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

Не покладайтеся лише на екран панелі адміністрування. Результатом має бути запис, який можна знайти й повторно використати під час перевірки безпеки.

3. Установіть виправлену версію

Для cPanel & WHM виправленою вказано версію 1.9.3 HF3, для Plesk — версію 1.8.11. Після оновлення ще раз перевірте фактично встановлену версію.

Одного повідомлення інсталятора про успішне завершення недостатньо. Перевірте стан компонента безпосередньо на кожному контрольованому сервері та зафіксуйте час установлення.

4. Збережіть доступні журнали

Збережіть відповідні записи до того, як ротація журналів перезапише або видалить їх. Залежно від дистрибутива й конфігурації це можуть бути, наприклад, журнал systemd, /var/log/auth.log, /var/log/secure, записи панелі адміністрування та журнали модуля Acronis.

Для кожного джерела запишіть:

• за який період доступні записи;
• чи правильно синхронізовано час на сервері;
• чи немає пропусків у відповідному періоді;
• чи було збережено журнали поза межами перевірюваного сервера.

Відсутність журналу не є доказом атаки. Водночас вона не дає змоги надійно підтвердити, що відбувалося протягом непокритого періоду.

5. Визначте період перевірки

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

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

Що перевірити після встановлення виправлення

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

Насамперед перевірте:

• новостворені, розблоковані або змінені локальні облікові записи;
• зміни членства у привілейованих групах;
• зміни в sudoers та інших правилах підвищення привілеїв;
• нові або змінені SSH-ключі;
• незвичні входи в систему та використання привілейованих команд;
• нові завдання cron;
• нові або змінені служби й таймери systemd;
• зміни конфігурації cPanel, Plesk і модуля Acronis;
• зміни цільового сховища та правил зберігання;
• зміни облікових даних, які використовують для резервного копіювання.

Якщо ви виявили несподіваний обліковий запис адміністратора, новий SSH-ключ або невідому службу, не вважайте інцидент закритим лише після видалення відповідного елемента. Необхідно з’ясувати, коли виникла зміна, з якого облікового запису її внесли та чи не використовували такий самий доступ деінде.

Якщо виявлені ознаки вказують на активну атаку, дійте відповідно до підготовленого плану реагування на інциденти. Практичний огляд перших кроків наведено у статті Програма-вимагач у компанії: перші 24 години.

Перевірте також придатність резервних копій

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

Тест має документально підтвердити:

• з якої дати та з якого завдання було вибрано резервну копію;
• куди її відновили;
• чи вдалося відкрити дані;
• чи відповідають вони очікуваній точці відновлення;
• чи не використовували під час тесту облікові дані, надійність яких викликає сумніви.

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

Який звіт вимагати від адміністратора

Попросіть внутрішнього адміністратора або зовнішнього постачальника надати конкретний підсумковий звіт. Він має містити:

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

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

Коли залучати фахівців з управління IT

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

Якщо доручити цю перевірку нікому, в ITHOPE ми виконуємо оновлення сервера, перевірку на можливе проникнення та тест відновлення як окремі документально підтверджені роботи. Що має охоплювати така співпраця, описано в огляді Що передбачає щомісячне управління IT.

Вимагайте три окремі результати:

1. вразливий компонент оновлено, а нову версію перевірено;
2. доступні сліди перевірено за точно вказаний період;
3. вибрана резервна копія пройшла фактичний тест відновлення.

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

Поширені запитання

Чи вразливий кожен сервер із cPanel або Plesk?

Ні. Вразливість стосується відповідного модуля Acronis Backup. Тому на кожному сервері перевірте його наявність і конкретну версію.

Які версії містять виправлення?

За даними BleepingComputer, виправлення містять модуль Acronis Backup для cPanel & WHM версії 1.9.3 HF3 і розширення для Plesk версії 1.8.11.

Чи достатньо встановити оновлення?

Ні. Оновлення виправляє вразливий компонент, але не доводить, що до його встановлення вразливість не було використано або систему не було змінено.

Чи означає внесення до каталогу CISA, що вразливість справді експлуатують?

Так. CISA повідомила, що внесла CVE-2026-87886 до каталогу Known Exploited Vulnerabilities на підставі доказів активного використання.

Що робити, якщо журнали за період до оновлення відсутні?

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

Де нас знайти

ITHOPE — компанія з Брно, Чехія: ми робимо відновлення даних з дисків, RAID і NAS, сервіс ПК та ноутбуків та IT для бізнесу, усе у власній лабораторії за адресою Viniční 3587/216, 615 00 Brno.

Телефон +420 775 556 063 (цілодобово). Пристрій можна привезти особисто або надіслати курʼєром (Zásilkovna, PPL).