Накратко: Виртуалното пачване за PHP преодолява времето до внасянето на истинската актуализация. За целта комбинираме правила на Web Application Firewall с временните мерки, които php.net публикува за PHP2Shell, и веднага определяме пътя към редовния пач. Пълна защита това не дава, но намалява риска през преходния период.
Кога виртуалното пачване за PHP е разумно
BSI препоръчва при PHP2Shell незабавна актуализация, а ако това не е възможно, уеб сървърите да се изключат временно от мрежата. За много фирми нито едното не е осъществимо веднага: магазинът трябва да остане достъпен, собствена разработка се нуждае от тест преди актуализацията или сървърът работи с PHP 8.1 и по-стар, за който вече няма официални актуализации.
В тези случаи виртуалното пачване е мост. То не заменя решението дали не би било по-уместно да се работи офлайн. Тази преценка правите Вие, ние предоставяме техническата оценка.
Защо една WAF сама не стига
Cloudflare съобщи за наблюдавани опити за атака и внедри защитни правила, но предупреждава, че правила само по данните от заявките не са достатъчни. Причината е в естеството на уязвимостите. При CVE-2026-109618 състояние на недостиг на памет (Out-of-Memory) може да прекъсне PHP, докато данните от заявката са инициализирани само частично. При CVE-2026-109619 вътрешно състояние може да остане след освобождаването на паметта и да бъде използвано от по-късна заявка в същия worker. Такива грешки зависят от състоянието на сървъра, а не само от съдържанието на отделна заявка.
Затова залагаме на няколко слоя: WAF правила пред сървъра, временни мерки в самия PHP и засилено наблюдение на сървъра. Всеки слой спира част от атаките, никой сам не стига. Заедно те Ви осигуряват времето, за да внесете актуализацията подредено.
Временните мерки според php.net
php.net назовава няколко настройки, които намаляват риска, изрично без пълна защита. Важно е приложенията да не могат да презаписват тези стойности. Пример за PHP-FPM пул с качвания:
; Временни мерки за PHP2Shell (не са пълна защита), след това рестартирайте всички worker процеси
php_admin_value[memory_limit] = -1
php_admin_value[post_max_size] = 32M
php_admin_value[upload_max_filesize] = 30M
php_admin_flag[session.upload_progress.enabled] = off
; само за PHP 8.5:
php_admin_flag[fatal_error_backtraces] = off
Без качвания php.net препоръчва post_max_size = 8M. Тъй като memory_limit се премахва, към това спада ограничение на паметта на ниво контейнер или cgroup, а не чрез RLIMIT_AS или RLIMIT_DATA. Настройката session.upload_progress.enabled=0 принадлежи в php.ini, в FPM пула или в конфигурацията на сървъра, а не в ini_set() или .user.ini. Тя е същевременно и мярката за бележката относно CVE-2026-115560. Всички мерки накратко има на страницата Незабавни мерки, когато още не можете да пачнете.
Временните мерки действат едва след рестартиране на всички PHP worker процеси. И те защитават само от бъдещи атаки: дали някой е проникнал преди това, не казват.
Кога работата офлайн е по-добрият избор
Виртуалното пачване не е правилният отговор във всяка ситуация. При някои конфигурации съветваме да се следва BSI и уеб сървърът да се изключи временно от мрежата, докато не бъде пачнат:
- сървърът работи с Apache и mod_php, където екипът на PHP оценява риска като най-висок и е показан експлойт още преди да започне да се изпълнява какъвто и да е код на приложението
- на сървъра има особено защитими данни, например здравни данни, данни на клиенти на кантори или платежни данни
- няма възможност временните мерки да се зададат твърдо в конфигурацията на сървъра, например при определени пакети със споделен хостинг
- вече има признаци, че сървърът е бил атакуван
Временната работа офлайн не означава, че уебсайтът Ви е хакнат. Някои доставчици са изключили уебсайтове от предпазливост. Кратка, делова страница с обяснение за посетителите е тогава обикновено по-добро решение от необяснима недостъпност.
Как помага PHP SOS конкретно?
- Проверка на положението: Събираме PHP версиите, режимите на работа и наличните защитни слоеве като CDN, WAF или reverse proxy. При mod_php посочваме повишения риск, който екипът на PHP вижда там.
- Изграждане на слоеве: Активираме или допълваме WAF правила, задаваме твърдо временните мерки в конфигурацията на сървъра и ограничаваме паметта чрез контейнер или cgroup. За Nginx конфигурации се ориентираме по Защита на Nginx с PHP-FPM.
- Рестартиране и тест: Всички PHP процеси се рестартират, след това проверяваме качванията, формулярите, входа и касата.
- Наблюдение: През преходния период обръщаме засилено внимание на сривове на worker процеси, пикове в паметта и необичайни процеси.
- Планиране на пача: Определяме кога и как ще дойде редовната актуализация и я изпълняваме чрез услугата за пач на PHP.
Какво получавате, какво ни е нужно и какво не обещаваме
Получавате документация на всички зададени правила и настройки с обосновка, резултатите от тестовете и план със срокове и мерки за истинския пач. От Вас ни е нужен достъп до сървъра или панела, достъп до CDN или WAF, ако има такива, технически човек за контакт и информация за функциите за качване на Вашите приложения.
Не обещаваме, че виртуалното пачване предотвратява атака. То намалява риска за ограничено време. При PHP 8.1 и по-стари то не е постоянно състояние; тук в плана влиза преминаването към поддържана версия.
Често задавани въпроси
Какво е виртуално пачване?
Виртуалното пачване означава позната уязвимост да се екранира пред приложението, вместо да се променя самият код. Това става най-често чрез Web Application Firewall или промени в конфигурацията. То е преодоляване на периода, а не заместител на актуализацията.
Достатъчна ли е WAF на моя CDN доставчик срещу PHP2Shell?
Сама по себе си по правило не. Cloudflare внедри защитни правила, но сама предупреждава, че правила само по данните от заявките не са достатъчни. WAF е допълнителен слой до временните мерки и пача.
Колко дълго мога да разчитам на виртуално пачване?
Колкото се може по-кратко. То трябва да преодолее времето до редовната актуализация, например докато се освободи прозорец за поддръжка или се тества дадено приложение. При PHP 8.1 и по-стари към това спада и план за миграция.
Могат ли временните мерки да нарушат уебсайта ми?
Да, възможно е. По-малките ограничения за качване могат да попречат на качването на големи файлове, а изключването на session upload progress засяга индикаторите за напредък при качване. След всяка промяна тестваме най-важните функции.