Накратко: Веригата на доставките на един уебсайт започва от PHP проекта и през дистрибуцията и хостинг доставчика стига до CMS, добавките, агенцията и вградените услуги. За ИТ сигурността има значение всяко звено, защото един пач стига до Вашия уебсайт едва когато всички са го предали нататък. Който запише веригата, определи за всяко звено отговорно лице и доказателство и ограничи достъпите, я прави надеждна.
Един пач и дългото му пътешествие
На 21.10.2026 г. в 14:00 UTC PHP проектът публикува корекциите за PHP2Shell. С това уязвимостта не беше затворена за нито един уебсайт. Първо дистрибуции като Debian, Ubuntu или семейството на RHEL трябваше да включат корекциите в своите пакети; според съобщенията backport-ове частично бяха доставени още същия ден. След това хостинг доставчиците и администраторите трябваше да инсталират тези пакети и да рестартират всички PHP процеси. Едва тогава съответният уебсайт беше защитен.
Всяко звено от тази верига може да забави. И на всяко е окачена друга организация със собствени приоритети. Който не знае как изглежда неговата верига, не може да каже къде в момента е пачът.
Някои вериги имат допълнителни звена, които почти никой не познава. Много сървъри с Debian и Ubuntu получават PHP не от дистрибуцията, а от хранилището на Ondřej Surý на sury.org, разпространен трети източник. Според съобщенията то е предоставяло билдове за всички клонове от 5.6 до 8.5. Това е полезно, но не е архивът за сигурност на Debian: който ползва този източник, зависи от друго звено, със собствен ритъм и собствена отговорност. Дали един сървър е настроен така, показва списъкът с източниците на пакети, и точно тази информация принадлежи в документацията на веригата.
Звената на веригата накратко
Следната таблица показва типичните звена на един PHP уебсайт и какво можете да изисквате от всяко.
| Звено | Типичен риск | Какво трябва да определите |
|---|---|---|
| PHP проект | уязвимост в интерпретатора, край на поддръжката | поддържана версия в употреба, план за края на поддръжката |
| Дистрибуция или трети източник | липсва backport или идва късно | познат източник на пакети, абонирани съобщения за сигурност |
| Хостинг доставчик или платформена услуга | ъпдейт без рестарт, липса на информация | задължение за ъпдейт, рестарт, доказателство и известяване |
| Производител на CMS | уязвимост в ядрото | канал за ъпдейти, отговорно лице |
| Доставчик на добавки и теми | изоставени или несигурни разширения | само поддържани добавки от официални източници |
| Агенция или разработчик | широки достъпи, неясна отговорност | лични достъпи, писмени задачи |
| Външни скриптове и услуги | чужд код в браузъра, изтичане на данни | списък, фиксирани версии, проверена цел |
Два примера от седмицата на PHP2Shell показват колко лесно едно звено се пропуска. Vercel посочва, че ъпдейт на локалната среда за разработка, на кода на приложението или на добавките не е достатъчен; решаваща е PHP средата, която действително обслужва. Coolify съветва да се актуализира PHP средата на всяко приложение поотделно, дори зад Cloudflare. А според съобщенията WordPress.org не планира собствен ъпдейт срещу PHP2Shell, защото уязвимостта е в интерпретатора. Който чака CMS, чака напразно.
Как да направите веригата видима: пет стъпки
Така внасяте ред в зависимостите на Вашите уебсайтове:
- Запишете веригата за всеки уебсайт: от PHP средата до външните скриптове, с името на доставчика или лицето.
- Определете отговорност за всяко звено: Кой инсталира ъпдейтите, кой проверява, кой кого информира?
- Договорете доказателства: Какво се счита за свършено? При PHP средата например състояние на пакета и рестарт, както е описано в Как да попитате Вашия хостинг доставчик за състоянието на пача.
- Ограничете достъпите: Всяка агенция и всеки доставчик получава само правата, от които се нуждае, с лични акаунти.
- Планирайте обходни пътища: Какво да се прави, ако едно звено отпадне, например доставчик на добавка се откаже или доставчик не е достижим?
Попитайте всеки доставчик как ви информира за критични уязвимости. Който отговаря само при запитване, в ситуация като PHP2Shell е риск за Вашия график. Запишете отговора писмено.
Добавки и разширения: най-неясното място
При много уебсайтове най-голямата част от веригата е невидима: добавки и теми, добавени през годините. Всяка идва от друг доставчик, със собствено темпо при ъпдейтите за сигурност. Някои доставчици изоставят продукта си, без да го обявят. Други разширения се получават от неофициални източници и никога не получават ъпдейти.
Тук помага просто правило: всяка добавка се нуждае от цел, поддържан доставчик и официален източник. Ако липсва едно от трите, тя влиза в списъка за замяна. Подобно важи за вградените услуги като платежни доставчици, системи за резервации, чат прозорци или аналитични инструменти. Те внасят собствен код на Вашата страница или получават данни на Вашите посетители. Запишете кои услуги са вградени, кой ги е поръчал и дали още са нужни. Забравен скрипт на доставчик, с когото отдавна няма договор, е звено без отговорник.
Как да поддържате добавките и пакетите постоянно актуални, описва Как да поддържате зависимостите актуални: Composer, npm и добавки.
Верига на доставките, договори и NIS2
За фирмите, които попадат под NIS2, сигурността на веригата на доставките изрично е част от управлението на риска, значи и отношенията с доставчици и производители. Подробности има в NIS2 и сигурност на уеб сървърите. Но и без законово задължение важи: възложените задачи остават Ваш риск. Затова резултатите от петте стъпки принадлежат в договорите с агенцията, хостинг доставчика и доставчиците; кои точки трябва да се уредят там, описва Договори с ИТ доставчици: ясно уреждане на задълженията за сигурност. Тази страница е обща информация и не е правен съвет.
Как помага PHP SOS конкретно?
- Начертаваме с Вас веригата на всеки уебсайт, от PHP средата до външните скриптове.
- Проверяваме добавки, теми и пакети за състояние на поддръжката и произход и препоръчваме замяна, където е нужно.
- Съгласуваме с хостинг доставчика и агенцията кой за кои звена отговаря и какви доказателства се предоставят.
- Където едно звено е незаето, поемаме го постоянно чрез договор за поддръжка на сигурността.
Извод: Сигурността на един уебсайт е толкова силна, колкото е най-бавното звено на неговата верига на доставките. Който познава веригата и свързва всяко звено с отговорно лице и доказателство, знае в критичен момент къде е пачът.
Често задавани въпроси
Какво означава верига на доставките при един уебсайт?
Всички участници, от чиято работа зависи сигурността на Вашия уебсайт: PHP проектът, Linux дистрибуцията, хостинг доставчикът или платформената услуга, производителят на CMS, доставчиците на добавки и теми, агенцията и вградените услуги като платежни доставчици или външни скриптове.
Отговарям ли аз, ако един доставчик не пачва?
Отговорността за собствения уебсайт и данните на него по правило остава у Вас, дори задачите да са възложени навън. Затова отговорностите трябва да са ясни по договор и да се проверяват. За правната оценка са компетентни адвокатът и длъжностното лице по защита на данните.
Достатъчно ли е хостинг доставчикът да актуализира PHP?
За PHP средата при хостинг доставчика да, при условие че той рестартира и всички процеси и го доказва. Ако части от Вашето приложение работят другаде, например в контейнери, на платформени услуги или на втори сървър, там всяка среда трябва да се актуализира поотделно.
Как да разпозная рискови добавки?
Предупредителни знаци са дълго липсващи актуализации, доставчик без разпознаваем контакт за сигурност, получаване от неофициални източници и функции, които никой вече не използва. Такива добавки трябва да се заменят или премахнат.