Опубліковано деталі ймовірної вразливості обробки завантажень PHP

21 жовтня 2026 року автор публікації «Major PHP Vulnerability Leaked» на своєму сайті повідомив про ймовірну серйозну вразливість у PHP. Згідно з його аналізом, обробник прогресу завантаження файлів може звернутися до вже звільненої пам’яті, а описаний ланцюжок — дійти до виклику system(). Автор опублікував матеріали для перевірки й запропонував тимчасові заходи до офіційного повідомлення. У наданому тексті немає підтвердження від команди PHP.

Де автор вбачає помилку

Ідеться про session.upload_progress — механізм відстеження завантаження файлу через сесію. Його обробник зберігає два вказівники на значення в таблицях PHP: один стосується оброблених даних запиту, другий — поточного файлу. Під час подальшої обробки попередня структура даних може бути знищена, а вказівники залишаться. Так виникає описаний сценарій use-after-free: код звертається до пам’яті, яку вже звільнено.

За твердженням автора, для цього шляху достатньо стандартних налаштувань session.upload_progress. Він описує швидкий multipart POST-запит, під час обробки якого чергове оновлення повторно зчитує дані сесії та видаляє попередню структуру. Потім звільнену ділянку пам’яті, згідно з аналізом, можуть зайняти дані, які дають змогу довести виконання до zend_call_function і виклику system(). Це виклад заявленого технічного ланцюжка, а не підтвердження того, що він спрацює на будь-якому сайті.

Автор пише, що звірив деталі з вихідним кодом PHP 8.4.4 і 8.2.34. Опублікований набір містить матеріали для перевірки та відтворення, а також дані про відмінності між окремими збірками. Для команд, які підтримують сайти, зараз важливіше інше розрізнення: публікація містить технічний аналіз, але не повідомляє про готове офіційне виправлення.

Що відомо про межі ризику

Окрім шляху через session.upload_progress, автор згадує другий можливий шлях — через обробник multipart-запитів. За його оцінкою, зміна налаштування прогресу завантаження може закрити один шлях, але не обов’язково другий: обробка multipart/form-data не залежить від увімкнення цього механізму. Тому на підставі цього матеріалу не можна вважати одне налаштування повним розв’язанням проблеми.

Дату виходу офіційного виправлення в публікації не зазначено. Автор обіцяє повернутися до своєї версії причини помилки після офіційного повідомлення. Версії 8.5.11, 8.4.26, 8.3.35 і 8.2.34 він перелічує як поточні стабільні, а не як випуски з виправленням описаної проблеми. Для PHP 7.x і старіших версій, за його словами, виправлення не буде: їхнім користувачам він радить планувати оновлення.

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

Що робити власникам сайтів і командам

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

Як тимчасовий захід автор пропонує змінити налаштування, пов’язане з прогресом завантаження. Але в наданому фрагменті після згадки про php.ini, .user.ini і .htaccess самої команди або потрібного значення немає. За цим фрагментом відтворити запропоновану зміну неможливо. До того ж автор вважає її захистом лише від одного з двох можливих шляхів. Подавати цей захід як готову інструкцію було б неточно.

Інша пропозиція — обмежити multipart POST-запити через WAF або зворотний проксі на адресах, де завантаження файлів не потрібне. Команді доведеться відрізняти такі адреси від сторінок, де завантаження справді потрібне. Після виходу офіційного виправлення автор рекомендує встановити його без зволікань. Поки його немає, корисно визначити, хто перевіряє версії PHP, хто керує обмеженнями запитів і хто погоджує зміни на сторінках із формами.

Моя думка

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

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

Джерела

Звідки новина. Текст — переказ своїми словами, факти — з джерела, думка — автора.

1. Major PHP Vulnerability Leaked jackalsyn.com

Про автора

Отто Ільвес

Початківець frontend-розробник

Створюю навчальні інтерфейси й нещодавно під’єднав перше просте API. Хочу зрозуміти, як команди обирають інструменти не за хайпом, а з огляду на те, що їм доведеться підтримувати.

Усі публікації автора