# Да сменим ли CMS след хака? Кога помага и кога не

> Смяна на CMS след хакване? Кога нова система наистина помага, кога само премества усилията и как да преместите съдържанието без зловреден код.

Източник: https://phpsos.de/bg/blog/cms-wechsel-nach-hack/  
Актуалност: 25.10.2026  
Доставчик: PHP SOS, Спешна помощ за PHP и сигурност на сървъри. Незабавна помощ по WhatsApp: https://wa.me/491736494914?text=%D0%97%D0%B4%D1%80%D0%B0%D0%B2%D0%B5%D0%B9%D1%82%D0%B5%2C%20PHP%20SOS%2C%20%D0%B8%D0%BC%D0%B0%D0%BC%D0%B5%20%D0%BD%D1%83%D0%B6%D0%B4%D0%B0%20%D0%BE%D1%82%20%D0%BF%D0%BE%D0%BC%D0%BE%D1%89%20%D1%81%20%D0%BD%D0%B0%D1%88%D0%B8%D1%8F%20PHP%20%D1%81%D1%8A%D1%80%D0%B2%D1%8A%D1%80.%20%D0%A4%D0%B8%D1%80%D0%BC%D0%B0%3A%20%E2%80%A6%20%D0%A3%D0%B5%D0%B1%D1%81%D0%B0%D0%B9%D1%82%3A%20%E2%80%A6

**Накратко:** Смяната на CMS след хак помага само ако старата система самата е била причината, например защото производителят не доставя вече ъпдейти за сигурност или важни разширения не се поддържат. Ако причината е била в остарели добавки, слаби достъпи или уязвимост като PHP2Shell в подлежащия PHP, смяната само премества усилията. Във всеки случай важи: първо проверете съдържанието, после го преместете, иначе зловредният код се премества с него.

## Когато доверието е изчезнало

След проникване настроението често е недвусмислено: „С тази система никога повече.“ Това е разбираемо. Уебсайтът е пренасочвал посетители към чужди страници, Google е предупредил, клиенти са питали. Ново CMS се усеща като ново начало.

Положението около PHP2Shell обаче показва защо този рефлекс може да подведе. Уязвимостта е в интерпретатора на PHP, а не в WordPress, TYPO3, Shopware или друга система. WordPress.org според drweb.de затова не планира собствен ъпдейт срещу нея. Който сега смени едно PHP CMS с друго PHP CMS, накрая има същата зависимост, само с друго лого. Кои системи работят на PHP, показва прегледът [Кои CMS и магазинни системи работят на PHP](https://phpsos.de/bg/php/cms-und-shops-auf-php/).

## Решава причината

Преди да мислите за смяна, причината за проникването трябва да е изяснена. Типични входни врати са остарели разширения, многократно използвани или слаби пароли, липсващо двуфакторно удостоверяване, непачнат сървър или забравени тестови инсталации. Никоя от тези причини не е свързана с определено CMS.

Който не познава причината, рискува да я пренесе в новата система. Екип, който досега е отлагал ъпдейтите, ще го прави и в новото CMS. Агенция, която е ползвала общи администраторски акаунти, ще го повтори, ако никой не промени реда. Въпросът затова е по-малко „кое CMS?“, а „кой процес?“.

## Смяна на CMS след хака: преценката

| Критерий | Оставате при съществуващото CMS и го заздравявате | Преминавате към друго CMS |
|---|---|---|
| Причина за проникването | Позната и отстранима, например остаряла добавка | Лежи в самата система, например липсващи ъпдейти на производителя |
| Поддръжка от производителя | Ъпдейтите за сигурност се доставят | Производителят е прекратил поддръжката |
| Зависимост от разширения | Малко, поддържани разширения | Много разширения без активна поддръжка |
| Усилия | Почистване, заздравяване, промяна на процеса | Ново изграждане, миграция, обучение, често нов дизайн |
| Време до сигурен уебсайт | По-кратко | По-дълго, нужно е преходно решение |
| Защита от уязвимости в PHP | Без промяна, PHP трябва да се пачне | Без промяна, докато новата система ползва PHP |
| Дългосрочна полза | Висока, ако процесите се подобрят | Висока, ако старата система така или иначе е била в края си |

Ако повечето редове във Вашата ситуация попадат вляво, смяната едва ли си струва. Оставане, почистване, заздравяване и подобряване на реда на поддръжка носи повече сигурност за по-малко пари. За операторите на WordPress [WordPress и PHP2Shell](https://phpsos.de/bg/plattformen/wordpress/) обобщава най-важните стъпки.

За това решение не Ви трябва винаги доставчик. Ако причината е била еднозначна, например известна добавка с публикувана уязвимост, и Вашата агенция или администратор е инсталирал уебсайта чисто наново, можете да решите сами. Външна помощ си струва, когато причината остава неясна или може да са засегнати лични данни.

## Ако сменяте: не пренасяйте зловредния код

Ако решението е за смяна, самата миграция е риск за сигурността. Нападателите оставят следи не само във файловете, но и в базата данни. Тези стъпки помагат да се премести чисто:

1. **Обезопасете и изолирайте старата система:** Пълно резервно копие като доказателство, след това старата система се изключва от мрежата или остава достъпна само вътрешно.
2. **Експортирайте съдържанието целенасочено:** Текстове, структура на страниците и медии, а не цялата база данни. Потребителските акаунти не се прехвърлят, а се създават наново.
3. **Проверете съдържанието:** Прегледайте текстовете за внесени скриптове, скрити връзки и чужди пренасочвания. Как става това, описва [Как да проверите базата данни за внесен код](https://phpsos.de/bg/blog/datenbank-auf-schadcode-pruefen/).
4. **Филтрирайте медиите:** Прехвърляйте само очаквани видове файлове, отстранете файлове с двойно разширение или със скриптово съдържание.
5. **Настройте новата система чисто:** От оригиналния източник на производителя, на сървър с пачнат PHP, с нови данни за достъп и двуфакторно удостоверяване.
6. **Планирайте пренасочвания:** Старите адреси се пренасочват към новите, за да стигнат търсачките и посетителите, без старите пътища да остават отворени.

> **Важно:**
> Смяната на CMS не замества почистването на стария сървър. Ако старата система продължава да работи, например като забравено копие на поддомейн, задната врата остава отворена.

## Алтернативата, която често се пропуска

Някои фирми след хак установяват, че изобщо не се нуждаят от функциите на голямо CMS. Фирмен уебсайт с малко страници, които рядко се променят, може да се справи и без PHP на сървъра. Генераторът на статични страници създава готови HTML файлове, които не изискват сървърна програмна логика. Какви са предимствата и недостатъците, описва [Статични уебсайтове: по-малко PHP, по-малка повърхност за атака](https://phpsos.de/bg/blog/statische-website-alternative/).

Обратно, за магазини, портали или уебсайтове с много редактори това обикновено не е вариант. Тук динамичната система остава разумна, а сигурността се получава чрез поддръжка, заздравяване и наблюдение.

Който е несигурен дали в стария WordPress не дебнат още скрити достъпи, ще намери в [Как да намерите задни врати в WordPress](https://phpsos.de/bg/ratgeber/backdoor-wordpress-finden/) типичните места за откриване. Това помага и при решението дали почистването е реалистично.

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

- Първо изясняваме причината за проникването и Ви казваме дали е в CMS или в процеса и сървъра.
- Почистваме съществуващата система в рамките на [премахването на зловреден софтуер](https://phpsos.de/bg/leistungen/malware-entfernung/) или я подготвяме като доказателство за ново изграждане.
- При смяна проверяваме съдържанията и медиите за прехвърляне за зловреден код, преди да стигнат до новата система.
- Настройваме новия сървър с пачнат PHP и заздравена конфигурация.

## Извод

Смяната на CMS след хак рядко е решението, но понякога е правилният повод. Ако старата система вече не се поддържа, новото начало си струва. Ако причината е била в процесите или в сървъра, работата по процеса носи повече от ново лого. И в двата случая важи: първо проверете, после преместете.


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

**Помага ли смяната на CMS срещу PHP2Shell?**  
Не, докато новото CMS също работи на PHP. PHP2Shell е в интерпретатора на PHP, а не в CMS. Решаващо е състоянието на пача на PHP на сървъра, а не системата над него.

**WordPress по-несигурен ли е от други CMS?**  
Не може да се каже общо. Много прониквания възникват от остарели разширения, слаби достъпи или липсващи ъпдейти, а тези причини съществуват във всяка система. Разпространението обаче прави едно CMS по-често цел на автоматизирани сканирания.

**Мога ли просто да експортирам съдържанието от хакнатото CMS?**  
Само след проверка. Базата данни може да съдържа внесени скриптове, скрити връзки или чужди администраторски акаунти. Качените файлове могат да маскират зловреден код. Експортирайте съдържанието целенасочено и го проверете преди импортиране.

**Кога смяната на CMS наистина има смисъл?**  
Когато производителят вече не доставя ъпдейти за сигурност, когато уебсайтът зависи от разширения, които вече не се поддържат, или когато системата просто вече не пасва на днешните изисквания. Хакът тогава е поводът, а не причината.

## Източници

- [WordPress.org](https://wordpress.org/)
- [TYPO3](https://typo3.org/)
- [OWASP Top 10](https://owasp.org/www-project-top-ten/)
- [Dr. Web: PHP2Shell и WordPress](https://www.drweb.de/php2shell-update-php-versionen/)