21 жовтня 2026 | PHP | ІТ-безпека
21 жовтня 2026 року команда безпеки PHP опублікувала оновлення для усіх досі підтримуваних версій PHP. Вони закривають дві критичні вразливості, відомі як PHP2Shell. BSI видав щодо цього попередження та вимагає негайно встановити патчі на уражені системи. Хто керує вебсервером із PHP, має діяти ще сьогодні. Це стосується й усіх, хто керує «лише» WordPress, Nextcloud або Joomla, бо ці застосунки працюють на PHP.
Ця стаття підсумовує, що сталося, які версії PHP уражені, яка версія вам потрібна зараз і як за кілька хвилин перевірити, чи ваш сервер захищений.
Що сталося? Хронологія подій
Команда безпеки PHP завчасно оголосила про випуск виправлень, щоб хостинг-провайдери й адміністратори мали час підготуватися. Сам випуск відбувся 21 жовтня 2026 року. BSI оприлюднив своє попередження (версія 1.1) того ж дня.
- 20 жовтня 2026: попередження від команди безпеки PHP про те, що наступного дня вийдуть оновлення безпеки.
- 21 жовтня 2026, 14:00 UTC (16:00 за CEST): публікуються патчі для PHP 8.5, 8.4, 8.3 і 8.2.
- 21 жовтня 2026: BSI попереджає про «критичні вразливості, що загрожують вебзастосункам у всьому світі», і рекомендує негайно встановити патчі. За даними BSI, великі хостинг-провайдери подекуди превентивно вимкнули сервери.
Дві вразливості PHP коротко
Йдеться про дві окремі помилки в ядрі PHP: CVE-2026-109618 і CVE-2026-109619. Обидві, за даними команди безпеки PHP, можуть призвести до того, що зловмисник зможе виконувати програмний код на сервері без входу в систему (unauthenticated Remote Code Execution). Вразливості оцінено як CVSS v4.0: 9,2 (критична).
| Ознака | Значення |
|---|---|
| Ідентифікатори | CVE-2026-109618 і CVE-2026-109619 |
| Оцінка | CVSS v4.0: 9,2 — критична |
| Наслідок | Виконання коду на сервері (Remote Code Execution) без входу в систему |
| Причина 1 | Пошкоджена пам’ять, коли PHP під час обробки не отримує більше оперативної пам’яті (Out-of-Memory) |
| Причина 2 | Застарілий глобальний стан, що залишається в пам’яті між запитами |
| Особливо під загрозою | Apache з mod_php |
За оцінкою BSI, на момент публікації підтверджених атак не було, але були непідтверджені ознаки спроб експлуатації. Для критичних вразливостей у такому поширеному програмному забезпеченні, за досвідом, слід очікувати, що зловмисники проаналізують виправлення й підготують автоматизовані атаки. Часове вікно для встановлення патчів тому коротке.
Кого це стосується?
Уражений загалом кожен сервер, на якому працює PHP, незалежно від того, як PHP підключено: PHP-FPM, mod_php в Apache, php-cgi, FrankenPHP або LiteSpeed. Найвищий ризик, за даними команди безпеки PHP, — в Apache з mod_php.
BSI прямо називає застосунки, які побудовані на PHP й тому можуть бути вражені:
- Системи керування вмістом: WordPress, Drupal, TYPO3, Joomla
- Системи інтернет-магазинів: Magento
- Хмарне сховище та файлові сховища: Nextcloud
- Інтерфейси міжмережевих екранів: pfSense, OPNsense
Сам застосунок для цього не мусить бути несправним. Вразливість — у PHP, тому одного оновлення WordPress, Nextcloud & Co. недостатньо. Потрібно оновити версію PHP на сервері. Для міжмережевих екранів, як-от pfSense та OPNsense, виправлену версію PHP надає відповідне оновлення прошивки від виробника.
Ці версії PHP безпечні
Вразливості виправлено в наведених нижче версіях. Усе, що нижче, вважається вразливим.
| Гілка PHP | Мінімально потрібна | Примітка |
|---|---|---|
| PHP 8.5 | 8.5.12 | поточна гілка |
| PHP 8.4 | 8.4.27 | |
| PHP 8.3 | 8.3.36 | |
| PHP 8.2 | 8.2.35 | Підтримка закінчується 31 грудня 2026 року |
| PHP 8.1 і старіші | офіційного оновлення немає, див. унизу | |
Як перевірити й оновити свій сервер
1. З’ясувати встановлену версію PHP
У командному рядку сервера php -v показує версію PHP командного рядка. Вебсервер може використовувати іншу версію PHP. Тому перевірте також версію PHP-FPM або модуля Apache, наприклад за допомогою php-fpm8.3 -v або через сторінку, що виводить phpinfo() (потім її одразу видаліть).
2. Встановити оновлення через менеджер пакетів
У Debian, Ubuntu, RHEL і споріднених системах виправлена версія надходить через звичайний менеджер пакетів, наприклад apt update && apt upgrade або dnf upgrade. У сторонніх джерелах, як-от Sury PPA чи репозиторій Remi, нові пакети зазвичай з’являються оперативно.
apt changelog php8.3-fpm або rpm -q --changelog php | grep CVE-2026-1096).
3. Перезапустити службу PHP
Одного оновлення пакета недостатньо: запущені процеси PHP зберігають старий код у пам’яті. Перезапустіть PHP-FPM (systemctl restart php8.3-fpm) або Apache (systemctl restart apache2) і потім перевірте, чи процеси були запущені після оновлення.
4. Вебсайти на хостингу
На спільному хостингу оновлює, як правило, провайдер. У меню клієнта зазвичай можна налаштувати версію PHP для кожного вебсайту. Виберіть там одну з наведених вище безпечних версій або запитайте провайдера про стан патчів. За даними BSI, окремі провайдери превентивно відключили сервери від мережі. Якщо ваш сайт ненадовго недоступний, це може бути причиною.
PHP 8.1 і старіші: офіційного оновлення немає
Для PHP 8.1 і старіших офіційних оновлень безпеки більше немає. Власники таких систем мають дві можливості:
- Перейти на підтримувану версію (рекомендовано). Чим старіша версія, тим більший обсяг адаптації застосунку й розширень, тому перехід слід попередньо протестувати.
- Перенести виправлення назад. Команда безпеки PHP надала виправлення в гілках розробки на GitHub. Хто компілює PHP самостійно, може перенести ці зміни в старіші версії. Це тимчасове рішення, що потребує фахових знань.
PHP 8.2 також підтримується лише до 31 грудня 2026 року. Тому плануйте перехід на PHP 8.4 або 8.5 уже зараз і не відкладайте його на зміну року.
Тимчасові заходи та питання «вимкнути сервер?»
Команда безпеки PHP разом з оголошенням описала також тимчасові заходи захисту. Вони зменшують ризик, але не закривають вразливості повністю. Вони не замінюють оновлення й призначені лише для того, щоб подолати час до оновлення.
Чи слід відключати сервер від мережі до оновлення, залежить від його значення та доступності. BSI зазначає, що великі провайдери зробили цей крок. Практичне правило таке:
- Публічно доступний сервер, оновлення можливе зараз: негайно встановіть патч, вимикати не потрібно.
- Публічно доступний сервер, оновлення найближчим часом неможливе: обмежте доступ (наприклад, міжмережевим екраном лише для відомих адрес) або тимчасово вимкніть службу, особливо за
mod_php. - Сервер, доступний лише всередині мережі: встановіть патч найближчим часом, терміновість нижча.
Поширені запитання
Чи потрібно мені оновлювати WordPress, Joomla або Nextcloud?
Не через цю вразливість. Вона міститься в PHP, а не в самому застосунку. Оновіть версію PHP на сервері. Оновлення застосунку, втім, доцільне й саме по собі.
Як зрозуміти, що вразливість уже хтось використав?
Однозначно відповісти важко. Насторожувати мають невідомі PHP-файли у веброзділі сервера, незвичні процеси від імені користувача вебсервера, нові облікові записи або завдання cron, а також незвичний вихідний трафік. У разі конкретної підозри систему слід піддати криміналістичній перевірці, а за потреби розгорнути заново.
Чи достатньо Web Application Firewall?
Брандмауер може перехоплювати відомі шаблони атак, але не замінює оновлення. Докладніше про взаємодію кількох рівнів захисту читайте в нашій статті Захист Odoo 19: брандмауер, 2FA & Web RBL. Ці принципи стосуються будь-якого вебзастосунку.
Чи стосується це Odoo?
Ні. Odoo написано мовою Python, і він не працює на PHP. Під загрозою можуть бути лише PHP-застосунки, що працюють на тому самому сервері.
Де знайти офіційну інформацію?
Оголошення команди безпеки PHP ви знайдете в архівах новин на php.net (запис від 20 жовтня 2026 року), а версії — на php.net/downloads. Попередження BSI має номер 2026-297981-1032 і розміщене на bsi.bund.de .
Підтримка від Biricon IT Services
Якщо ви не впевнені, яка версія PHP працює на вашому сервері, або вам потрібна допомога з виправленням, ми охоче вам допоможемо: з інвентаризацією усіх PHP-систем, встановленням оновлень, переходом на підтримувану версію PHP та перевіркою на компрометацію. Як ІТ-постачальник ми обслуговуємо сервери, брандмауери та вебзастосунки для малого й середнього бізнесу.
Станом на 21 жовтня 2026 року. Ситуація може швидко змінитися; визначальними є публікації команди безпеки PHP та BSI.