Накратко: При облачни и PaaS доставчици пач не се прави автоматично от доставчика. Ако той управлява PHP средата за изпълнение, той я актуализира, но често едва със следващия deployment. Ако изграждате образи или build-ове сами или сами управлявате платформата, трябва да изградите наново и да разположите наново. Меродавна е винаги средата за изпълнение, която Вашият уебсайт обслужва в момента.
PHP актуализация при PaaS: на кого принадлежи средата за изпълнение?
Платформените услуги, на професионален жаргон PaaS (Platform as a Service), освобождават фирмите от експлоатацията на сървъри. Качвате код, платформата го изгражда и го управлява. При PHP2Shell оттук възниква типична несигурност: кой всъщност трябва да актуализира PHP?
Vercel го казва ясно в бюлетина си за PHP2Shell: актуализация на локалната среда за разработка, на кода на приложението или на добавките не стига. Решаваща е PHP средата за изпълнение на deployment-а, който наистина отговаря на заявките. Дали тази среда е пачната, зависи от това кой я осигурява и кога последно е била изградена.
Четири модела на работа в сравнение
Названията на доставчиците се различават. За въпроса за пача повечето предложения могат да се причислят към един от тези модели:
| Модел | Кой актуализира PHP? | Какво трябва да направите |
|---|---|---|
| Среда за изпълнение, управлявана от доставчика | Доставчик | Поискайте потвърждение, при нужда направете нов deployment, за да влезе в сила новата среда |
| Среда за изпълнение, базирана на build (buildpack) | Доставчикът предоставя нова версия, Вашият build я фиксира | Задействайте нов build, проверете версията в протокола на build-а |
| Собствен контейнерен образ | Вие | Изградете наново образа с отстранения PHP и го разположете |
| Платформа, управлявана от Вас | Вие, за платформата и за приложенията | Пачнете платформата и всяко приложение поотделно |
Много фирми ползват няколко модела едновременно, например управлявана среда за изпълнение за уебсайта и собствени контейнери за вътрешни инструменти. Затова всяко приложение изисква собствен отговор.
Клопка се крие в думата „управлявана“. Дори доставчикът да поддържа средата за изпълнение, вече разположено приложение често продължава да работи със състоянието, с което е било изградено. Новата версия влиза в сила едва при следващия build или deployment. Някои платформи освен това държат по-стари deployment-и или среди за преглед достъпни под собствени адреси. Затова не питайте само дали доставчикът е пачнал, а и от кога Вашите работещи инстанции ползват пача и какво се случва със старите deployment-и.
Какво казват Vercel и Coolify за PHP2Shell
Двама доставчици направиха указанията си публични. Те са поучителни, защото ясно назовават границите на собствените си защитни мерки.
Vercel според собствения си бюлетин е активирал преди публикуването защитни правила в своя Web Application Firewall (WAF), филтър за уеб заявки. Те важат автоматично за PHP функции на Vercel и за заявки, които Vercel препраща към външни PHP сървъри. Същевременно Vercel изисква PHP средата за изпълнение да се актуализира незабавно до отстранена версия. Контейнерните deployment-и трябва да се изградят наново с актуализиран базов образ на PHP и да се разположат. Заявки, които заобикалят Vercel и отиват директно към външен PHP сървър, WAF не покрива.
Coolify, платформа, която може да се управлява самостоятелно, според собственото си съобщение за сигурност сама е била засегната: всички клонове на версия 4. Като първи отстранени състояния Coolify посочва 4.0.1, 4.1.3, 4.2.1, 4.3.24 и 4.4.7 и препоръчва 4.4.7. Важна е добавката: актуализацията на Coolify не актуализира PHP приложенията, които управлявате през нея. Техните среди за изпълнение или образи трябва да актуализирате отделно и да изградите наново или да разположите. Според Coolify това важи и за клиентите на Coolify Cloud, и за приложенията зад Cloudflare, защото правилата на Cloudflare проверяват само трафик, минаващ през Cloudflare.
Какво постигат правилата на Cloudflare, класифицира статията Защитни правила на Cloudflare срещу PHP2Shell.
Как да проверите обслужващата среда за изпълнение
Следните стъпки работят независимо от доставчика. Те са насочени към доказателство, не към усещане.
- Изброете всички среди: продукция, staging, deployment-и за преглед и фонови услуги като queue worker-и. Всяка среда може да има различна среда за изпълнение.
- Прочетете версията на средата за всяка среда: в конзолата на доставчика, в протокола на build-а или в конфигурационния файл на проекта.
- Проверете датата на последния deployment: Ако е преди 21.10.2026 г., с голяма вероятност още работи старата среда, освен ако доставчикът не потвърди изрично друго.
- Погледнете в работещата инстанция: Ако платформата предлага конзола, следната команда показва версията на инстанцията.
- Включете външните PHP сървъри: Сървърите, към които платформата препраща заявки, се нуждаят от собствена актуализация и не бива да са достъпни директно от интернет.
# В конзолата на работещата инстанция (ако е предложена от доставчика)
php -v
php -r 'echo PHP_VERSION, " ", PHP_SAPI, PHP_EOL;'
Очакват се 8.5.12, 8.4.27, 8.3.36 или 8.2.35 или backport, потвърден от доставчика. Имайте предвид, че командният ред на инстанцията не ползва винаги същата среда като уеб процеса. Не създавайте за проверката публично достъпен phpinfo файл. Как да тълкувате правилно номера на версията и състоянието на backport-а, описва Проверка на версията на PHP и състоянието на пача.
Нов deployment не премахва злонамерен софтуер, който преди това е попаднал в трайни хранилища като томове за качване или базата данни. Тези области проверявате отделно.
Фиксирайте отговорността писмено
PHP2Shell показва колко неясна често е границата между платформата и клиента. Отбележете за всяко приложение кой осигурява средата за изпълнение, кой изгражда наново при съобщения за сигурност и как доставчикът обявява пачовете. Към това спада и кой има достъп до конзолата на платформата, когато е спешно, и кой може да задейства нов build извън работно време.
За собствената документация е достатъчна кратка таблица за всяко приложение: платформа, модел на работа, клон на PHP, дата на последния build, отговорно лице. Който има този списък под ръка при следващото съобщение, спестява дните, които много екипи прекараха в търсене след 21 октомври. При контейнерните приложения към това спада кой поддържа базовия образ; контекста обяснява PHP в контейнери.
За управлявани сървъри без характер на PaaS важат сходни въпроси, които сме обобщили в Managed сървър: изяснете отговорността.
Как помага PHP SOS конкретно?
- Причисляване: Причисляваме всяко Ваше приложение към модел на работа и изясняваме кой осигурява PHP средата за изпълнение.
- Доказване: Проверяваме среда за изпълнение, дата на build и deployment за всяка среда и документираме резултата.
- Ново изграждане и разполагане: Чрез PHP Patch Service актуализираме образи и build-ове и ги разполагаме контролирано.
- Затваряне на пропуските: Проверяваме дали външни PHP сървъри са директно достъпни и ограничаваме достъпа.
Често задавани въпроси
Пачва ли моят PaaS доставчик PHP автоматично?
Зависи от модела. Ако доставчикът управлява средата за изпълнение, той я актуализира, но често едва за нови deployment-и. Ако изграждате образи или build-ове сами, трябва да изградите наново и да разположите наново. Поискайте потвърждение за състоянието за Вашето приложение.
Стига ли WAF на моя доставчик на платформа срещу PHP2Shell?
Не. Vercel и Coolify пишат изрично, че защитните правила не заместват актуализацията на PHP средата за изпълнение. Освен това те действат само върху трафик, минаващ през платформата.
Трябва ли след пача да направя нов deployment?
Често да. Vercel за контейнерните deployment-и посочва ново изграждане с актуализиран базов образ на PHP и нов deployment. При платформи, базирани на build, средата за изпълнение се фиксира при build-а; едва нов build поема пача.
Ползвам Coolify. Стига ли актуализацията на Coolify?
Не. Според съобщението за сигурност на Coolify актуализацията обновява само самия Coolify. Средите за изпълнение на PHP или контейнерните образи на Вашите приложения трябва да актуализирате отделно и да изградите наново или да разположите наново.