Текуща ситуация: PHP2Shell. Две критични уязвимости в PHP (CVSS 9,2) позволяват злонамерен код без вход. Корекции от 21.10.2026 г.Какво да направите сега →

Как да обезопасите PHP под Windows и IIS

Под IIS PHP работи най-често като php-cgi.exe през FastCGI. Така откривате всички инсталации, сменяте PHP безопасно, рециклирате пуловете на приложенията и проверявате резултата.

Актуалност 5 мин. четенеСървър и хостинг

Накратко: Под Windows с IIS PHP работи най-често като php-cgi.exe през FastCGI, режим на работа, засегнат изрично от PHP2Shell. Актуализацията на PHP в IIS се състои от три стъпки: да се открият всички инсталации на PHP, да се заменят с коригирана версия и да се рециклират пуловете на приложенията. Управление на пакети и бекпортове като под Linux тук по правило няма.

Как PHP работи под IIS

На Windows сървърите IIS свързва PHP чрез модула FastCGI. За всяка версия на PHP има FastCGI запис, който сочи към php-cgi.exe, и съответствие на манипулатор, което насочва файловете с разширение .php натам. IIS стартира при нужда няколко php-cgi процеса и ги държи активни за следващи заявки.

За разлика от Linux PHP тук най-често не идва от управление на пакети, а като ZIP архив на Windows изгражданията на проекта PHP, като част от специализирано приложение или чрез по-стари инсталатори. Това означава: актуализациите не стават автоматично и няма бекпортове от дистрибутор. Решаващ е номерът на версията на инсталираните файлове.

Какво означава PHP2Shell за Windows сървърите

PHP2Shell обхваща CVE-2026-109618 и CVE-2026-109619 в самия PHP, и двете с CVSS v4.0 9,2. И двете позволяват изпълнение на код без вход в системата. Проектът PHP изрично посочва php-cgi сред засегнатите режими на работа. Коригирани са PHP 8.5.12, 8.4.27, 8.3.36 и 8.2.35.

За PHP 8.1 и по-стари вече няма официални актуализации. Windows сървърите със специализирани приложения според опита често работят на такива състояния, защото приложението изисква определена версия. Тук освен временните мерки е нужно изясняване с производителя на приложението. Контекст за този режим на работа има в php-cgi: наследство с риск.

Актуализация на PHP в IIS: откриване на инсталациите

Следващите PowerShell команди само четат. Те показват кои инсталации на PHP ползва IIS и коя версия имат. Пътищата са примери.

# FastCGI записи в IIS: коя php-cgi.exe се ползва?
& "$env:windir\system32\inetsrv\appcmd.exe" list config -section:system.webServer/fastCgi

# Версия на всяка намерена инсталация (пътят е пример)
& "C:\PHP\8.3\php.exe" -v

# Работещи php-cgi процеси с време на стартиране
Get-Process php-cgi -ErrorAction SilentlyContinue | Select-Object Id, StartTime, Path

Потърсете допълнително на всички дялове други php-cgi.exe, защото специализираните приложения понякога носят собствени копия. За всяка инсталация отбележете версия, вариант (Thread Safe или Non Thread Safe) и архитектура.

Внасяне на актуализацията и рециклиране на пуловете на приложенията

Изтеглете коригираната версия от официалните Windows изграждания на проекта PHP, към които води php.net, в същия вариант и същата архитектура. Доказало се е новата версия да се разархивира в нова папка, да се вземат съществуващият php.ini и нужните разширения и после FastCGI записът да се премине към новия път. Така старото състояние остава за връщане назад.

# Рециклиране на пул на приложение (името е пример)
Import-Module WebAdministration
Restart-WebAppPool -Name "Intranet"

# Алтернативно рестартиране на всички услуги на IIS
iisreset

# Проверка: всички php-cgi процеси ли са стартирани след актуализацията?
Get-Process php-cgi -ErrorAction SilentlyContinue | Select-Object Id, StartTime, Path

Всеки php-cgi процес трябва да има време на стартиране след актуализацията и да сочи към новия път. После тествайте уебсайтовете. Премахнете старата папка на PHP, щом новото състояние работи стабилно, за да не бъде включена отново по погрешка.

Важно

Новите файлове в папката на PHP не са достатъчни, докато стари php-cgi процеси работят. Едва след рециклирането на пуловете или рестарт на IIS пачът е в сила.

Временни мерки в php.ini

Ако инсталацията не може да се актуализира веднага, php.net препоръчва временни мерки без пълна защита. Под IIS задавате стойностите в централния php.ini на съответната инсталация. Файловете .user.ini и ini_set() според php.net не са достатъчни.

; php.ini на засегнатата инсталация
session.upload_progress.enabled = 0
post_max_size = 8M
upload_max_filesize = 6M

При функция за качване php.net посочва post_max_size = 32M. При PHP 8.5 се добавя fatal_error_backtraces=0. За да не могат уебсайтовете да променят стойностите чрез собствени файлове .user.ini, user_ini.filename може да се остави празен в централния php.ini; преди това проверете дали приложенията не зависят от това. След това рециклирайте пуловете. BSI (Федерална служба за информационна сигурност на Германия) препоръчва уеб сървърите да се изключат временно от мрежата, ако актуализацията не е възможна веднага. Допълнителни настройки обяснява Сигурна конфигурация на php.ini.

След актуализацията

Пачът не премахва зловреден софтуер, внесен преди това. Запазете протоколите на IIS от 20.10.2026 г. нататък, проверете уеб директориите за нови файлове със скриптове и прегледайте планираните задачи и локалните потребителски акаунти за нещо непознато. Ако сървърът работи в домейн, към това спада и поглед към входовете в системата.

Обърнете внимание допълнително на правата на идентичностите на пуловете на приложенията. Ако пул работи с акаунт, който има права за запис върху цялата уеб директория или дори административни права, нападател след успешно проникване може да причини значително повече. Смисъл има отделна, ограничена идентичност за всеки пул с права за запис само там, където приложението действително ги изисква, например в папката за качване или за кеш. В тези папки IIS не бива да изпълнява PHP файлове; това може да се уреди чрез съответствията на манипулаторите на съответната папка. Проверете и дали в уеб директорията не стоят стари тестови и инсталационни файлове като изходи на phpinfo, и ги премахнете.

Как помага PHP SOS конкретно?

  • Откриваме всички инсталации на PHP на Вашите Windows сървъри, включително копия в специализирани приложения.
  • Чрез услугата за PHP пач сменяме PHP, рециклираме пуловете и документираме версията и времената на процесите.
  • При стари версии изясняваме с Вас и с производителя на приложението пътя към миграция към поддържана версия на PHP.
  • Проверяваме сървърите за следи от атака и запазваме протоколите.

Често задавани въпроси

Какъв вариант на PHP ми трябва за IIS?

За IIS с FastCGI обикновено се ползва вариантът Non-Thread-Safe (NTS). При актуализацията внимавайте отново да изберете същия вариант и същата архитектура, за да продължат да пасват разширенията.

Достатъчно ли е да разархивирам новата папка на PHP?

Не. IIS държи процесите php-cgi.exe активни известно време. Рециклирайте пуловете на приложенията или рестартирайте IIS и проверете дали не работят стари процеси.

Мога ли да ползвам няколко версии на PHP на един IIS?

Да, чрез няколко FastCGI записа и съответствия на манипулатори за всеки уебсайт. Това обаче увеличава усилията за поддръжка. Всяка инсталация се нуждае от собствена актуализация и собствена проверка.

Засегнат ли е PHP под Windows от PHP2Shell?

Уязвимостите са в самия PHP. Под IIS PHP по правило работи като php-cgi, който проектът PHP изрично причислява към засегнатите режими на работа. Затова третирайте Windows сървърите със същата спешност като Linux сървърите.

Източници

Незабавен контакт

Всеки час има значение. Пишете ни сега.

Опишете накратко системата, версията на PHP и какво сте забелязали. Ние се свързваме с Вас, уточняваме ситуацията и работим отдалечено, докато инцидентът бъде приключен и документиран.

Незабавна помощ