Що оновити після жовтневих RCE-вразливостей PHP, ми вже розповіли. Тепер з'явилося дві розповіді про те, як усе відбувалося: Фолькер Душ (Tideways, AI Security Engineer in Residence в Ecosystem Security Team PHP Foundation) поговорив з Еріком Барнсом в інтерв'ю для Laravel News, а моніторинговий сервіс Oh Dear опублікував графіки того, що бачив у ті дні. Разом вони добре пояснюють, як працює розкриття вразливостей у PHP і чому воно таке повільне й крихке.
Від одного листа до двох CVE
PHP Foundation домоглася, щоб PHP потрапив до програми OpenAI Patch the Planet, і в її межах безпекова компанія Calif почала аудит мови. Невдовзі Calif написала Фолькеру з проханням терміново зустрітися: у них був мінімальний експлойт, що працював у Docker-контейнері. Щойно команда безпеки PHP його побачила, сумнівів, що загроза реальна, не лишилося. Згодом OpenAI і Wiz повідомили про інші вектори атаки з тим самим корінням.
Так з'явилися CVE-2026-109618 (RCE через пошкодження при нестачі пам'яті) і CVE-2026-109619 (RCE через застарілий глобальний стан), обидві з оцінкою 9.2 за CVSS v4.0. Технічну суть ми розбирали в попередньому матеріалі, тут важливіше інше: вада повторювалася в коді в багатьох місцях. Як сказав Фолькер, "треба виправити кожне місце, де це трапляється. Пропустиш одне - і це проблема", тобто ще один випуск.
Чому патч іде довше, ніж оновлення браузера
Браузер оновлюється сам, і виробник контролює весь шлях до користувача. З PHP так не виходить. Проєкт PHP випускає вихідний код, а не той PHP, який стоїть у вас на сервері. Виправлення має пройти через Debian, Ubuntu, Red Hat, офіційні образи Docker Hub і всі образи, збудовані поверх них. Тому дистрибутиви отримали патч заздалегідь: щоб оновлені пакети були готові тієї ж хвилини, коли вразливості стануть публічними.
Через серйозність ситуації команда допомогла підготувати бекпорти і для версій, які PHP офіційно вже не підтримує. До великих хмарних хостингів, з якими в команди не було прямих контактів, звернулися OpenAI і Wiz. А з вендорами WAF, зокрема Cloudflare, працювали окремо, щоб правила з'явилися до дня випуску і захистили сайти, які не оновляться одразу.
20 жовтня php.net оголосив випуск на 21 жовтня, 14:00 UTC, без жодних деталей, і застеріг, що може випустити його раніше, якщо подробиці стануть публічними або з'являться ознаки атак.
Ембарго, яке не втрималося
Уся схема з раннім доступом тримається на тому, що ніхто не публікує виправлення до узгодженого часу. Chainguard це ембарго порушив: опублікував виправлені образи більш ніж на шість годин раніше. Фолькер пояснює, чому це небезпечно саме зараз: перетворити патч, а то й бінарник, на експлойт сьогодні можна значно швидше, ніж раніше. Його оцінка: "Важко стверджувати, що ти займаєшся безпекою, якщо лишаєш більшість людей беззахисними".
Окрема історія - "доказові" скриншоти експлойтів, що розходилися соцмережами. Кілька з тих, які Фолькер перевіряв, працювали лише проти спеціально модифікованого Docker-контейнера і нічого не робили зі стандартним образом із Docker Hub. Тож скриншот із терміналом ще не означає, що вразливий саме ваш сервер, хоча й не скасовує потреби оновитися.
Як це виглядало з боку моніторингу
Більшість сайтів, які моніторить Oh Dear, написані на PHP, тож його дані - це не весь інтернет, а саме PHP-світ. І в ньому 21 жовтня сталося те, чого сервіс раніше не бачив:
- Частка недоступних сайтів зросла з звичних 0,9-1% до 18,8% о 14:30 UTC, тобто якраз у півгодини виходу патчів. Сайтом "що лежить" Oh Dear вважає той, що провалив щонайменше половину перевірок за півгодини.
- Down-алертів на піку було в 25 разів більше, ніж у звичайні півгодини.
- Код 503 серед недоступних сайтів давали 7,7% до початку подій і 43,4% на піку. Тобто власники свідомо ставили сторінку обслуговування: зупиняли php-fpm і лишали Nginx чи Apache віддавати заглушку або гасили вебсервер цілком. Так зробив і сам Oh Dear, віддаючи статичну HTML-сторінку з зупиненим php-fpm.
- Хто віддавав 503: найчастіше Cloudflare (27,8%), далі відповіді без заголовка
Server (25%), nginx (23,6%) і Apache (12%). Cloudflare, за спостереженням Oh Dear, ще й швидко додав WAF-правило для всіх клієнтів.
- Тривалість: відключення на 4-12 годин мали 11,3% сайтів проти 0,1% тижнем раніше, на 1-4 години - 6,8% проти 0,6%. Станом на ранок 23 жовтня 1,4% сайтів досі лежали.
Інакше кажучи, значна частина PHP-спільноти обрала простоювати кілька годин, аби не ризикувати даними клієнтів. Це наслідок і серйозності вразливостей, і того, що до виходу патча повного обхідного шляху не було.
Що прийшло вже після випуску
Історія не закінчилася 21 жовтня, але обидва продовження невеликі. 23 жовтня PHP опублікував інформаційне попередження: до наступного планового bugfix-випуску вимкнути session.upload_progress.enabled, щоб закрити ще один малоймовірний шлях до RCE. Це налаштування вже було серед заходів в advisory від 21 жовтня, тож якщо ви його застосували, більше нічого робити не треба. Фолькер називає умови для цього випадку "дуже специфічними" і проблему - незначною на тлі основних. 26 жовтня вийшли оновлені Windows-збірки з виправленням у Brotli. Подробиці обох - у нашому попередньому матеріалі.
Хто це полагодив
Поки Фолькер займався комунікацією, у C-коді PHP вдень і вночі сиділи Ілія Товіло, Арно Ле Блан і Якуб Зеленка. Усі троє працюють на PHP Foundation повний робочий день, і саме тому команда змогла кинути все інше й займатися лише цим. Коли ядро підтримують лише у вільний час, такий темп і пошук кожного місця з тією самою вадою дається значно важче.
Звідси й прохання Фолькера до бізнесу: "Якщо ви заробляєте купу грошей на застосунках поверх PHP, віддати навіть крихітну частку цього - дуже корисно".
Що з цього взяти
- Знайте свій ланцюжок постачання PHP. Ваш PHP приходить від дистрибутива, образу Docker, хмари чи хостингу, і швидкість оновлення визначає найповільніша ланка. Варто заздалегідь знати, звідки беруться пакети на кожному сервері і хто відповідає за їх оновлення.
- Майте план на випадок вимкнення. Oh Dear показав, як багато команд за лічені години піднімали сторінку обслуговування. Якщо у вас для цього немає готового сценарію (
php artisan down, статична сторінка на рівні Nginx, правило на CDN), його краще підготувати зараз, а не в день наступного advisory.
- Стежте за першоджерелом. Попередження про випуск з'явилося на php.net за добу до нього. Підписка на новини php.net і advisory репозиторію
php/php-src дає цю добу на підготовку.
- Не вірте скриншотам. Перевіряйте вразливість за офіційним advisory і своєю конфігурацією, а не за відео в соцмережах.
- Підтримайте PHP Foundation. Якщо ваша компанія заробляє на PHP, спонсорство фонду - це внесок у ту саму роботу, яка цього разу закрила вразливості.
