PHP: PHP2Shell – CVE-2026-109618 та CVE-2026-109619, тимчасовий фікс
0 (0)

Автор |  21/10/2026
0 коментарів
Click to rate this post!
[Total: 0 Average: 0]

UPD: вже є офіційний патч, див. PHP 8.5.12 Release Announcement. Але для Amazon Linux repos поки не вийшло.

Не встиг я трохи заспокоїтись після позавчорашньої проблеми з Updraft і зламом RTFM – як “доброго дня, ми знову тута”. Але цього разу хочу без проблем на RTFM.

Див. RTFM: злам TeamUpdraft (UpdraftPlus) та WordPress з блогом RTFM.

Мабуть, вже всі чули про нові критичні вразливості в PHP – CVE-2026-109618 та CVE-2026-109619, які потенційно дозволяють виконувати довільний код на сервері без аутентифікації.

Нова атака використовує обробку multipart-запитів і механізм відстеження прогресу завантаження файлів session.upload_progress.

А головна проблема в тому, що код виконується ще до запуску самого application PHP code – тому вразливими можуть бути навіть сайти, які безпосередньо не використовують завантаження файлів або PHP-сесії.

До виходу і встановлення патчу тимчасовий захист полягає у вимкненні session.upload_progress.enabled та блокуванні multipart-запитів на рівні вебсервера. Останній захід тимчасово ламає завантаження файлів, але перекриває відомі вектори атаки.

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

В ролі веб-сервера в мене NGINX, тому приклад на ньому.

Див:

PHP-FPM та відключення upload_progress

Поточна версія – остання, але ще офіційного патчу нема, тобто вразлива:

root@ip-10-0-3-146:~ # php -v
PHP 8.5.11 (cli) (built: Sep 22 2026 13:32:06) (NTS gcc x86_64)
Copyright (c) The PHP Group
Built by Amazon Linux
Zend Engine v4.5.11, Copyright (c) Zend Technologies
    with Zend OPcache v8.5.11, Copyright (c), by Zend Technologies

Перевіряємо які конфіги використовуються і яке значення session.upload_progress задано зараз:

root@ip-10-0-3-146:~ # php-fpm -i | grep -E 'Loaded Configuration File|Scan this dir for additional .ini files|session.upload_progress.enabled'
Loaded Configuration File => /etc/php.ini
Scan this dir for additional .ini files => /etc/php.d
session.upload_progress.enabled => On => On

Створюємо файл /etc/php.d/99-disable-session-upload-progress.ini, в ньому перевизначаємо параметр session.upload_progress.enabled зі значенням off:

; Temporary mitigation for CVE-2026-109618/CVE-2026-109619
session.upload_progress.enabled = Off

Перевіряємо, чи бачить PHP-FPM ці зміни:

root@ip-10-0-3-146:~ # php-fpm -i | grep -E 'Additional .ini files parsed|99-disable-session-upload-progress|session.upload_progress.enabled'
Additional .ini files parsed => /etc/php.d/10-opcache.ini,
/etc/php.d/99-disable-session-upload-progress.ini
session.upload_progress.enabled => Off => Off

Перевіряємо синтаксис:

root@ip-10-0-3-146:~ # php-fpm -t
[21-Oct-2026 14:36:12] NOTICE: configuration file /etc/php-fpm.conf test is successful

Перечитуємо конфіги PHP-FPM:

root@ip-10-0-3-146:~ # systemctl reload php-fpm

І друга невелика зміна – з NGINX.

NGINX та блок multipart uploads

Редагуємо /etc/nginx/conf.d/rtfm.co.ua.conf, на початку файла додаємо:

map $http_content_type $block_multipart {
    default       0;
    "~*multipart" 1;
}

Тут map перевіряє заголовок Content-Type кожного запиту, якщо він містить слово “multipart”, наприклад – “multipart/form-data” під час завантаження файлу – то змінна $block_multipart отримує значення 1, для запитів задається дефолт в 0.

Потім в блок server {...} додаємо перевірку, яка повертає 403, якщо $block_multipart == 1:

server {
    listen 80;
    server_name rtfm.co.ua;

    root /var/www/rtfm/rtfm.co.ua;

    ...

    if ($block_multipart) {
        return 403;
    }
   
    ...

Може зламати завантаження файлів – але поки хоч так.

Перевіряємо синтаксис:

root@ip-10-0-3-146:~ # nginx -t
nginx: the configuration file /etc/nginx/nginx.conf syntax is ok
nginx: configuration file /etc/nginx/nginx.conf test is successful

Перечитуємо конфіг:

root@ip-10-0-3-146:~ # systemctl reload nginx

Перевіряємо – спочатку нормальний запит, потім з multipart:

root@ip-10-0-3-146:~ # curl -sS -o /dev/null -w 'GET: %{http_code}\n' https://rtfm.co.ua/
GET: 200
root@ip-10-0-3-146:~ # curl -sS -o /dev/null -w 'multipart POST: %{http_code}\n' -F 'a=b' https://rtfm.co.ua/
multipart POST: 403

Готово.

Ну і чекаємо офіційного патчу.

Як вийде – обновимось з dnf (в мене Amazon Linux):

root@ip-10-0-3-146:~ # dnf upgrade 'php8.5*' --releasever=2023.12.20261016 -y

“Готово” – але готово тимчасово.

Loading