--- title: "Як розкривали критичні вразливості PHP: погляд зсередини і в цифрах" url: https://laravelukraine.com/blog/iak-rozkrivali-kriticni-vrazlivosti-php-pogliad-zseredini-i-v-cifrax date: 2026-10-28 --- # Як розкривали критичні вразливості PHP: погляд зсередини і в цифрах Що оновити після жовтневих RCE-вразливостей PHP, ми [вже розповіли](https://laravelukraine.com/blog/kriticni-rce-vrazlivosti-v-php-shho-stalosia-i-shho-zrobiti-zaraz). Тепер з'явилося дві розповіді про те, як усе відбувалося: Фолькер Душ (Tideways, AI Security Engineer in Residence в Ecosystem Security Team PHP Foundation) поговорив з Еріком Барнсом в [інтерв'ю для Laravel News](https://laravel-news.com/volker-dusch-php-rce-disclosure), а моніторинговий сервіс Oh Dear [опублікував графіки](https://ohdear.app/news-and-updates/the-last-24-hours-in-php-land-as-observed-by-a-monitoring-service) того, що бачив у ті дні. Разом вони добре пояснюють, як працює розкриття вразливостей у PHP і чому воно таке повільне й крихке. ### Від одного листа до двох CVE PHP Foundation домоглася, щоб PHP потрапив до програми OpenAI Patch the Planet, і в її межах безпекова компанія Calif почала аудит мови. Невдовзі Calif написала Фолькеру з проханням терміново зустрітися: у них був мінімальний експлойт, що працював у Docker-контейнері. Щойно команда безпеки PHP його побачила, сумнівів, що загроза реальна, не лишилося. Згодом OpenAI і Wiz повідомили про інші вектори атаки з тим самим корінням. Так з'явилися [CVE-2026-109618](https://github.com/php/php-src/security/advisories/GHSA-w8hw-w9fx-j79w) (RCE через пошкодження при нестачі пам'яті) і [CVE-2026-109619](https://github.com/php/php-src/security/advisories/GHSA-6wmf-4rv5-p3rp) (RCE через застарілий глобальний стан), обидві з оцінкою 9.2 за CVSS v4.0. Технічну суть ми розбирали в попередньому матеріалі, тут важливіше інше: вада повторювалася в коді в багатьох місцях. Як сказав Фолькер, "треба виправити кожне місце, де це трапляється. Пропустиш одне - і це проблема", тобто ще один випуск. ### Чому патч іде довше, ніж оновлення браузера Браузер оновлюється сам, і виробник контролює весь шлях до користувача. З PHP так не виходить. Проєкт PHP випускає вихідний код, а не той PHP, який стоїть у вас на сервері. Виправлення має пройти через Debian, Ubuntu, Red Hat, офіційні образи Docker Hub і всі образи, збудовані поверх них. Тому дистрибутиви отримали патч заздалегідь: щоб оновлені пакети були готові тієї ж хвилини, коли вразливості стануть публічними. Через серйозність ситуації команда допомогла підготувати бекпорти і для версій, які PHP офіційно вже не підтримує. До великих хмарних хостингів, з якими в команди не було прямих контактів, звернулися OpenAI і Wiz. А з вендорами WAF, зокрема Cloudflare, працювали окремо, щоб правила з'явилися до дня випуску і захистили сайти, які не оновляться одразу. 20 жовтня php.net [оголосив](https://www.php.net/archive/2026.php) випуск на 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. Подробиці обох - у [нашому попередньому матеріалі](https://laravelukraine.com/blog/kriticni-rce-vrazlivosti-v-php-shho-stalosia-i-shho-zrobiti-zaraz). ### Хто це полагодив Поки Фолькер займався комунікацією, у 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, [спонсорство фонду](https://thephp.foundation/) - це внесок у ту саму роботу, яка цього разу закрила вразливості.