Как да защитите WordPress сайта си през 2026: Пълно ръководство + Чеклист

Накратко: какво се промени през 2026 г.

Ако сте чели ръководство за WordPress сигурност отпреди 2026 г., то вече е непълно. Три неща се промениха фундаментално:

1. Уязвимостта вече е в самото ядро на WordPress. До юли 2026 г. правилото беше просто: атакуващите търсят уязвим плъгин. С wp2shell (CVE-2026-63030 + CVE-2026-60137) вече не е нужен уязвим плъгин – достатъчно е да не сте обновили ядрото.

2. Изкуственият интелект намери тази уязвимост. Точно така. Не човек. Изследовател от Searchlight Cyber насочи GPT-5.6 Sol Ultra към изходния код на WordPress, който е стандартен при вся. След около 10 часа машинно време и приблизително 25 долара по-късно моделът излезе с работеща верига до отдалечени слаби места

3. Времето за реакция вече се мери в часове, а не в седмици. Според доклада на Patchstack за 2026 г. средното време до масова експлоатация при най-силно атакуваните уязвимости е само 5 часа. Приблизително половината от уязвимостите с висок impact започват да бъдат експлоатирани в рамките на 24 часа след публичното им оповестяване. Казано просто: ако проверявате за обновявания веднъж на две седмици, при новите уязвимости реакцията ви вероятно идва твърде късно. 

От нашата практика в SiteFix.BG: в момента преобладаващата част от инцидентите, които обслужваме, идват от автоматизирани сканирания за уязвимости в ядрото. Това са ботове, които обхождат интернет и търсят сайтове, останали на необновена версия. Останалото си е класическото търсене на уязвими плъгини. Истината е, че с навлизането на AI и двете станаха значително по-евтини за атакуващия.

Това ръководство е структурирано, както за собственици на бизнес, маркетинг специалисти така и за технически лица, които могат да предприемат конкретни действия! 

Блоковете за техническия екип, съдържат конкретни команди, заявки и правила за филтъра. Ако сте собственик на бизнес или маркетолог, прескочете ги ако не са ви нужни.

В края на ръководството сме ви приготвили чеклист, който можете да свалите като Word документ или да си го пренесете в Google Sheets с отметки.

Новата картина на заплахите

Колко голям е реално проблемът

Да започнем с числата, които са проверими, защото около WordPress статистиката се върти много фолклор.

Според W3Techs към август 2026 г. WordPress работи на 40.8% от всички сайтове и държи 59.0% от пазара на системи за управление на съдържание.

За България няма официална статистика по CMS. Националният статистически институт измерва дали предприятията имат уеб присъствие, но не води регистър коя платформа използват. Всеки, който ви цитира точен процент за българския пазар го прави без официален източник. 

От нашата практика WordPress е най-честата платформа при корпоративните сайтове, каталозите и блоговете на български МСБ, а при малките онлайн магазини WooCommerce се конкурира с платформи като OpenCart, CloudCart и Shopify. Това е наблюдение, не измерване — и няма да се преструваме на друго.

По-важни са числата за уязвимостите. Годишният доклад State of WordPress Security in 2026 отчита 11 334 нови уязвимости, открити през 2025 г., ръст от 42% спрямо предходната година. От тях 91% идват от плъгини, 9% от теми, а в самото ядро на WordPress са били само шест. Почти половината (46%) са били оповестени публично, преди да съществува пач. И най-неприятното: типичните защити на хостинг ниво блокират около 12% от реално експлоатираните WordPress-специфични атаки — при по-широко тестване 26%. Изводът е прост: „хостингът ми има защитна стена” не е стратегия за сигурност.

И още нещо от същия доклад, което изненадва почти всички: платените плъгини са по-опасни от безплатните.

Логиката подсказва обратното. Щом плащате, значи получавате по-добра поддръжка. Данните казват друго. Платените и freemium плъгините са само около 29% от всички съобщени пропуски, но при тях три от всеки четири са такива, които нападател реално може да използва. Пропуските с доказани атаки при платените са три пъти повече, отколкото при безплатните. Само през 2025 г. в платени компоненти са открити 33 критични дупки, за които в момента на откриването им още не е имало поправка срещу само 12 при безплатните.

Причината е структурна, не морална. Плъгините в хранилището на WordPress.org минават през преглед и имат единен канал за автоматично обновяване. Премиум плъгините се разпространяват директно от разработчика, обновяват се само при активен лиценз и често се озовават в темите като вграден компонент, който собственикът на сайта дори не знае, че съществува.

WP2SHELL: уязвимостта, която промени правилата

Това е събитието на годината за WordPress и заслужава да го разберете, дори ако не сте технически човек.

Хронология:

• 17 юли 2026 г. — WordPress пуска версия 7.0.2 и обявява две уязвимости: една критична и една с висока степен. Едновременно с това екипът принудително включва автоматични обновявания за засегнатите версии — ход, който се използва изключително рядко и е сам по себе си индикатор колко сериозно се е приемал случаят.
• Същия ден — Adam Kues от Searchlight Cyber/Assetnote публикува как е открил веригата с помощта на AI.
• До събота сутринта — публичен експлойт код е наличен. watchTowr отчитат десетки хиляди опити за експлоатация в своите honeypot системи.
• 21 юли 2026 г. — CISA добавя и двете уязвимости в каталога Known Exploited Vulnerabilities. Това е официално потвърждение за активна експлоатация в реални условия.
• Wiz измерват мащаба в първите часове: към момента на оповестяването около 60% от организациите с WordPress имат поне една уязвима инсталация, а 25% я излагат публично. За 24 часа тези стойности падат до 50% и 10% — тоест половината от засегнатите реагираха в рамките на ден, а другата половина не.

Какви версии са засегнати:

Версия	Статус
По-стари от 6.8	Незасегнати
6.8.0 – 6.8.5	Уязвими на SQL инжекцията (CVE-2026-60137) — поправено в 6.8.6
6.9.0 – 6.9.4	Уязвими на пълната RCE верига — поправено в 6.9.5
7.0.0 – 7.0.1	Уязвими на пълната RCE верига — поправено в 7.0.2

Какво означава на човешки език: нападателят изпраща заявка към вашия сайт от интернет, без да има акаунт, без да знае парола и без потребителят да прави нищо. Резултатът е изпълнение на негов код на вашия сървър и постига пълен контрол.

Защо е по-опасно от обичайното: повечето сериозни уязвимости изискват съвпадение на условия — конкретен плъгин, конкретна конфигурация, потребител с определени права. Тук единственото условие е да работите на неактуална версия на ядрото. Затова автоматизираните сканирания са толкова ефективни: ботът не търси „кой плъгин има този сайт”, а само „каква е версията”. Един бот може да провери милиони сайтове с една и съща заявка.

За техническия екип: как работи веригата

Комбинация от два дефекта:

CVE-2026-63030 (CVSS 9.8) — route confusion в batch процесора на REST API. Крайната точка /wp-json/batch/v1 валидира заявките по един кодов път, а ги изпълнява по друг. Префикс с три наклонени черти (///) заобикаля проверката на автентикация и позволява диспечиране на неоторизирани под-заявки.

CVE-2026-60137 (CVSS 5.9) — SQL инжекция през параметъра author__not_in в /wp/v2/posts.

Свързани, двата дефекта позволяват четене на базата без автентикация. Веригата продължава през манипулация на oEmbed кеша и злоупотреба с customizer changeset до създаване на администраторски акаунт, а оттам — качване на плъгин през /wp-admin/update.php?action=upload-plugin и разполагане на webshell.

Индикатори за компрометиране (IoC):

Мрежови:

• HTTP 207 Multi-Status отговори от /wp-json/batch/v1 — сигнатура с висока достоверност
• Вложени batch заявки с /// в пътя
• Под-заявки, верижно свързани към /wp/v2/posts и /wp/v2/block-renderer/
• User-Agent низове, съдържащи wp2shell или rezwp2shell
• Изброяване на потребители през /wp-json/wp/v2/users?context=edit

На ниво хост:

• Администраторски акаунти с префикс w2s_ (стойността по подразбиране в публичния PoC)
• Непознати директории в wp-content/plugins/
• PHP файлове на случайни пътища в поддиректории на wp-content/
• Wiz документират три различни варианта на зловреден код, включително 150 KB webshell, маскиран като легитимен плъгин за сигурност, с модули за достъп до базата, сканиране на портове и повишаване на привилегиите

Защо AI промени икономиката на атаките

Тази част често се пропуска в ръководствата, а е най-важната за разбиране на 2026 г.

Adam Kues е адаптирал prompt за многоагентно изследване, първоначално създаден за решаване на математически задачи, и е насочил модела към чистия изходен код на WordPress — с изрична инструкция да не гледа changelog-ове и сравнения на пачове. Тоест моделът е трябвало да намери дефекта от нулата, както би направил истински “изследовател”. Първо е открил SQL инжекцията, а след това самостоятелно е изградил многостъпковия експлойт, който превръща достъпа до базата в администраторски права и оттам в изпълнение на код.

Цената: около 10 часа машинно време, приблизително 25 долара.

Извадете следствията:

• Откриването на уязвимости вече не е ограничено от наличието на експерти. Досега сложните вериги от няколко дефекта изискваха рядък талант и седмици работа. Това беше естествен ограничител на броя такива открития.
• Същият инструмент работи и за атакуващите. Няма причина един изследовател с добри намерения да има монопол върху метода. Разликата между двете страни е само дали резултатът отива към разработчика или към пазара за експлойти.
• Времето между откриване и масова експлоатация се свива. Анализаторите отбелязват, че AI помощта е направила възпроизвеждането на публикуваните детайли „тривиално”. Това, което преди отнемаше на средно способен нападател седмица, сега отнема часове.

Практическият извод за вас е един: стратегия „ще обновя, като имам време” вече не работи. При медиана от 5 часа до първа експлоатация, ръчното обновяване веднъж на две седмици ви оставя незащитени за по-голямата част от периода на опасност.

Какво всъщност инсталират нападателите

Полезно е да знаете, че почти никой не хаква сайта ви, за да ви навреди. Хакват го, за да го използват. Данните за преобладаващите семейства зловреден код през 2025 г., както и тези, които сме срещали най-много на практика:

• Parrot TDS — 64% от всички инжектирани зловредни последователности код. TDS означава Traffic Direction System: вашият сайт става звено в мрежа, която пренасочва посетители към измамни страници, фалшиви обновявания на браузъри и фишинг. Ключова характеристика — показва се избирателно. Посетител от Google вижда пренасочването; вие, влезли като администратор от офиса, не виждате нищо.
• Lock360 — два варианта, отговорни съответно за 38% и 32% от откритите заразени файлове.
• Uploader скриптове — забелязваме рязък ръст през втората половина на 2025 г. Това не е крайна цел, а инфраструктура: малък скрипт, чиято единствена задача е да позволи качването на нови файлове по-късно. Тоест нападателят си оставя вход, преди да реши какво ще прави със сайта. Интересно, нали?

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

• SEO спам — скрити страници и връзки към хазартни, фармацевтични или крипто сайтове, вградени в съдържанието ви. Често с отделен sitemap, който Google индексира. Понякога стоят месеци, преди някой да забележи.
• Изпращане на спам имейли от вашия сървър, с вашия домейн.
• Фишинг страници — папка с копие на страницата за вход на банка или куриерска фирма, хоствана на вашия домейн.
• Кражба на платежни данни при онлайн магазини (виж Част 5).
• Криптомайнинг — най-безобидният вариант; сайтът просто става бавен.

Изводът, който собствениците подценяват: зловредният код често е проектиран да не се вижда. Ако критерият ви за „всичко е наред” е „сайтът се отваря нормално”, вие нямате критерий.

Кои типове уязвимости реално се експлоатират

Открити уязвимости и експлоатирани уязвимости са две различни неща. От 11 334 открити през 2025 г. само част са реално използвани в атаки. Класацията по това кои типове действително се експлоатират:

1. Broken access control (нарушен контрол на достъпа) — първо място. Функция, която е трябвало да бъде достъпна само за администратор, е достъпна за всеки. Причината почти винаги е пропусната проверка на права в кода на плъгина. Резултатът варира от четене на чужди данни до пълно превземане. Тази категория е първа не защото е най-опасна, а защото е най-лесна за откриване автоматично, a с AI това стана още по-лесно.
2. Неавтентикиран stored XSS. Нападателят вкарва JavaScript в базата ви — през незащитена форма, коментар или поле на плъгин, този код после се изпълнява в браузъра на всеки посетител или администратор. Оттам се краде сесия, създава се администратор или се пренасочва трафик. Тук помагат security headers (Пласт 4).
3. Повишаване на привилегии. Потребител с ниска роля, понякога просто регистриран абонат, намира начин да стане администратор. Оттук идва и правилото за минималните права: колкото по-малко акаунти имате, толкова по-малко отправни точки съществуват.
4. Произволно качване на файлове. Механизъм за качване, който не проверява какво качвате. Крайният резултат е PHP файл на сървъра ви, тоест webshell. Точно затова блокирането на изпълнението на PHP в uploads е толкова ефективно — то обезсмисля цялата категория.

Полезното в тази класация е, че мерките в Част 4 по-надолу не са произволни.. Всяка от тях затваря конкретна категория от този списък уязвимости.

Какво губи един бизнес, когато сайтът му е хакнат

Тази част липсва в техническите ръководства. Ето реалната верига от последствия, подредена по това колко бързо настъпва.

Часове: предприемане на действия от Google. Google Safe Browsing маркира сайта. Посетителите получават червен интерстициален екран „Този сайт може да е опасен”. Chrome, Firefox и Safari го показват. Трафикът пада почти до нула в рамките на часове. Премахването на маркировката става след заявка за преглед в Search Console и отнема от няколко часа до няколко дни, но само след като сайтът е реално чист.

Часове до дни: спиране от хостинга. При споделен хостинг българските доставчици реагират бързо, ако от вашия акаунт се разпраща спам или се хостват фишинг страници. Спирането е нормална практика и е в защита на останалите клиенти на същия сървър. Ако сайтът ви е и вашият канал за продажби, спирането е загуба на приход веднага.

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

Дни до седмици: рекламните акаунти. Google Ads спира обявите, водещи към маркиран сайт. Meta прави същото. Ако имате активни кампании, спирането е незабавно, а възстановяването изисква ръчна проверка. По-опасно би било ако се сдобият със сесия във вашите рекламите акаунти, което би им позволило да използват вашите платежни методи за собствени реклами към други източници, но това е за отделна тема за друг път.

Седмици до месеци: органичните позиции. SEO спамът, който е стоял незабелязано, си остава в индекса. Google е видял сайта ви да сочи към хазартни страници. Възстановяването на позициите след почистване не е автоматично и не е бързо.

Най-важното: доверието. За малък български бизнес, който работи с препоръки, посетител, видял червения екран на Google, е загубен клиент и вероятно ще го спомене на други.

Плюс: правните задължения. Ако в базата има лични данни на клиенти — а почти сигурно има, хубаво е да сте наясно, че при пробив възникват законови задължения със срокове. Подробно в Част 8.

Сборът от изброеното обикновено надхвърля многократно цената на превенцията. Това не е търговски аргумент. Това е причината това ръководство и SiteFix.BG да съществуват.

Спешната проверка — 15 минути

Преди да четете нататък, направете това. Ако сте на уязвима версия, всичко останало е второстепенно.

Стъпка 1: Проверете версията си (30 секунди)

Влезте в администраторския панел → Табло → Обновявания. Версията е изписана най-горе.

Обърнете внимание, че само през август,2026 излязоха два поредни пача:

7.0.3 (6 август) — 12 уязвимости, включително pre-auth reflected XSS на екрана за вход (CVE-2026-64638), повишаване на привилегии при Multisite, SSRF при валидацията на URL адреси и заобикаляне на потвърждението по имейл.

7.0.4 (12 август) — authenticated RCE през качване на файл, обработван от Imagick/Ghostscript (CVE-2026-65640, CVSS 8.8). Дефектът е бил в кода почти 10 години. Експлоатира се от роля Автор и нагоре и само ако сървърът използва Imagick заедно с Ghostscript.

Ритъмът е показателен сам по себе си: три пача за сигурност в рамките на един месец. Това не е нормалният ритъм на WordPress и е още един аргумент за автоматичните обновявания.

Стъпка 2: Разпознайте симптомите (3 минути)

Преди техническата проверка — ето признаците, които собствениците забелязват първи, но обикновено обясняват с нещо друго:

• Сайтът се отваря бавно без ясна причина и без промени по него
• Google Search Console показва страници, които не сте създавали — често с имена на чужд език
• Клиенти съобщават, че сайтът ги пренасочва, а при вас всичко е наред
• В резултатите на Google под вашия домейн се появяват описания, които нямат нищо общо с бизнеса ви
• Имейлите ви масово започват да отиват в спам
• Хостингът пише за необичайно потребление на ресурси
• Не можете да влезете с паролата си, макар да сте сигурни в нея
• В сайта се появява съдържание или изображение, което никой от екипа не е качвал

Един от тези признаци не доказва нищо. Два или повече заедно заслужават проверка.

Стъпка 3: Проверете дали вече не са влезли (5 минути)

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

Минимална проверка:

1. Потребители → Всички потребители. Филтрирайте по роля „Администратор”. Познавате ли всеки един акаунт? Има ли акаунти с префикс w2s_? Сортирайте по дата на регистрация — нещо ново и неочаквано?
2. Плъгини → Инсталирани плъгини. Има ли плъгин, който не сте инсталирали вие? Особено такъв с име, звучащо като инструмент за сигурност.
3. Настройки → Потребители. Проверете „Имейл адрес на администратора” — типична промяна след превземане, защото пренасочва писмата за възстановяване на парола.
4. Google Search Console → Проблеми със сигурността. Google често забелязва преди вас. Проверете и Индексиране → Страници за неочаквано голям брой индексирани адреси.
5. Отворете сайта си в режим инкогнито от мобилен телефон. Голяма част от зловредния код се показва само на посетители от търсачки или мобилни устройства и е невидим за влезлия администратор.
6. Бърза проверка. Потърсете в Google site:вашиятдомейн.bg и прегледайте резултатите. Инжектираните страници се виждат моментално.

Стъпка 4: Обновете (2 минути)

Ако намерите нещо съмнително — не обновявайте още и не изтривайте нищо. Първо запазете логовете. Обновяването презаписва файлове и може да унищожи доказателствата, които ще ви трябват, за да разберете докъде е стигнал нападателят и дали са изтекли лични данни. Ако възникнат задължения за уведомяване (виж Част 8), точно тази информация ви е нужна.

Шестте пласта на защитата

Подредено по съотношение ефект/усилие. Ако направите само първите два пласта, покривате мнозинството от реалните атаки.

Пласт 1: Обновяване — най-важното нещо в целия документ

1.1. Включете автоматичните обновявания на ядрото.

WordPress по подразбиране обновява автоматично само минорните версии, и то невинаги надеждно — през юли 2026 г. екипът прибегна до принудително обновяване именно защото твърде много сайтове бяха останали назад.

Добавете в wp-config.php:

define( ‘WP_AUTO_UPDATE_CORE’, ‘minor’ );

Ако управлявате прост сайт без сложна кастомизация, true вместо ‘minor’ включва и мажорните версии. За сайт с много кастомизации оставете ‘minor’ и планирайте мажорните ръчно, но в срок от дни, не месеци.

1.2. Включете автоматичните обновявания на плъгините — избирателно.

В Плъгини → Инсталирани плъгини има колона „Автоматични обновявания”. Включете я за:

• Плъгини за сигурност
• Плъгини от WordPress.org с активна поддръжка и голяма база инсталации
• Всичко, което не е критично за визуализацията или бизнес логиката

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

1.3. Направете обновяването процес, не настроение.

Определете кой отговаря. Определете колко често се проверява — седмично като минимум, при критично оповестяване веднага. Определете къде се тества преди продукция. Запишете го. Ако е в нечия глава, няма да се случва.

Забележка от практиката ни: обновяването на плъгин може да счупи сайт. Това е реален риск и не го омаловажаваме. Но рискът от счупен сайт е обратим за 15 минути от бекъп. Рискът от превзет сайт е обратим, но е възможно да нанесе сериозни щети по репутацията, имиджа, а и с това продажбите в дългосрочен план. Добра практиката е винаги извършването на бекъп преди актуализация!

Пласт 2: Контрол на достъпа

Broken access control води класацията на реално експлоатираните типове уязвимости, следвана от неавтентикиран stored XSS, повишаване на привилегии и произволно качване на файлове. Този пласт адресира и уязвимостите, и класическите атаки с познати пароли.

2.1. Двуфакторна автентикация за всеки администратор. Без изключения.

Това е единствената мярка, която обезсмисля кражбата на парола. Какво казваме на нашите клиенти от SiteFix.BG, ако имате трима администратори и двама използват 2FA, нямате 2FA.

2.2. Одит на потребителите на всяко тримесечие.

Отворете списъка. За всеки акаунт отговорете на два въпроса: този човек работи ли още с нас, и трябва ли му точно тази роля? Например, Гошо – бившият фрийлансър с администраторски достъп отпреди две години, какво прави още тук?

2.3. Принципът на минималните права.

Никой не се нуждае от „Администратор”, за да пише публикации.

Роля	За кого
Администратор	2 души максимум
Редактор	Управлява чуждо съдържание
Автор	Публикува собствено съдържание
Сътрудник	Пише, но не публикува

Отделно: CVE-2026-65640 (поправена в 7.0.4) се експлоатира от роля Автор и нагоре. Всеки излишен акаунт с права за качване на файлове разширява атакуваната повърхност.

2.4. Премахнете потребителското име admin.

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

2.5. Ограничете опитите за вход и скрийте страницата за вход.

Ограничаването на опитите спира груба сила. Преместването на /wp-login.php на нестандартен адрес не е сериозна защита срещу целенасочен нападател, но премахва огромен обем от шума на автоматизираните ботове, а именно шумът замъглява логовете ви и прави реалната атака невидима.

2.6. Уникални пароли, съхранявани в мениджър на пароли.

Не в браузъра. Не в Excel файл в Google Drive. Не в чат. Ако една и съща парола се използва за хостинга, WordPress и фирмения имейл, вие имате една точка, от където могат да проникнат абсолютно навсякъде!

За техническия екип

Забранете редактирането на файлове от админ панела — при превзет администраторски акаунт това е най-краткият път до webshell:

define( ‘DISALLOW_FILE_EDIT’, true );
define( ‘DISALLOW_FILE_MODS’, true ); // блокира и инсталация на плъгини

Регенерирайте salt ключовете — обезсилва всички активни сесии, задължително след инцидент. Вземете нови от https://api.wordpress.org/secret-key/1.1/salt/ и ги заменете в wp-config.php.

Пласт 3: Плъгини и теми — 91% от проблема

3.1. Направете инвентар.

Отворете списъка с плъгини и помислете отделно за всеки: за какво служи, кога е обновяван за последно, безплатен или платен, и лицензът активен ли е. Ако не можете да отговорите за какво служи даден плъгин – става кандидат за изтриване.

3.2. Изтрийте, не само деактивация.

Деактивираният плъгин остава на диска и остава уязвим. Кодът му е достъпен през браузър и много уязвимости не изискват плъгинът да е активен. Ако не ви трябва, изтрийте го.

3.3. Проверете за изоставени плъгини.

На страницата на всеки плъгин в WordPress.org пише „Последно обновен преди X”. Над 12 месеца без обновяване при активно развиващ се WordPress е предупредителен знак. Може спокойно да планирате замяната на плъгин, който не е обновяван над 16 месеца.. Изоставеният плъгин няма да получи пач, когато в него бъде намерена уязвимост, а фактът, че е изоставен, го прави по-привлекателна цел.

3.4. Проверете лицензите на платените плъгини.

Изтеклият лиценз означава спрени обновявания. Като имате предвид, че при премиум продуктите 76% от уязвимостите са реално експлоатируеми и известните експлоатирани уязвимости са три пъти повече, изтеклият лиценз на премиум плъгин е един от най-подценяваните рискове в WordPress екосистемата. Проверете датите на изтичане и си сложете напомняне месец предварително.

Отделен случай: премиум плъгини, вградени в купена тема (типично Slider Revolution, WPBakery и подобни). Те се обновяват само когато авторът на темата пусне ново издание. Ако темата е изоставена, плъгинът остава на стара версия завинаги.

3.5. Никакви nulled плъгини и теми.

„Безплатната” пиратска версия на премиум плъгин е бизнес модел и приходът не идва от вас, а от потенциален риск за присвояване на чувствителни данни и бекдор вътре. Виждаме това достатъчно често, за да го поставим като отделна точка. Ако бюджетът не стига за лиценз, използвайте безплатната алтернатива. Тя е по-малко функционална, но намалява риска да е нечий вход във вашия сървър.

3.6. Правило преди инсталация.

Преди да добавите нов плъгин: колко активни инсталации, кога е обновен за последно, отговаря ли авторът в форума за поддръжка, има ли история на уязвимости и как е реагирал при тях. Пет минути проверка спестяват главоболия на клиентите ни.

3.7. Как да проверите конкретен плъгин за известни уязвимости.

Не е нужно да чакате някой да ви каже. Публичните бази данни за WordPress уязвимости са безплатни за търсене:

Wordfence Intelligence Vulnerability Database и WPScan Vulnerability Database — търсите по име на плъгин и виждате историята: какви уязвимости е имал, в коя версия са поправени, колко бързо е реагирал авторът.

CVE търсачките — за уязвимости с присвоен идентификатор.

Какво да гледате освен броя: колко време е минало между докладването и пача. Плъгин с пет уязвимости, всяка поправена за 48 часа, е по-безопасен избор от плъгин с една уязвимост, която е стояла отворена шест месеца. Първото говори за отговорен разработчик, а второто за изоставен проект.

Ако имате повече от 15–20 плъгина, ръчното следене става непрактично. Тогава има смисъл от услуга, която следи вашия конкретен списък и ви известява.

Пласт 4: Сървър и конфигурация

4.1. Права на файловете.

Стандартът към август,2026: директории 755, файлове 644, wp-config.php — 600 или 440. Ако нещо е 777, коригирайте го веднага; това означава, че всеки процес на сървъра може да пише в него.

4.2. Забранете изпълнението на PHP в директорията за качвания.

wp-content/uploads/ е мястото, където се озовават качените файлове. Няма легитимна причина PHP файл там да се изпълнява. Това е една от най-ефективните единични мерки срещу разполагане на webshell.

За Apache — файл .htaccess в wp-content/uploads/:

<Files *.php>
    deny from all
</Files>

4.3. Изключете индексирането на директории.

Ако отваряйки testexample.bg/wp-content/uploads/2026/ виждате списък с файлове вместо грешка, всеки може да разглежда съдържанието ви, включително документи, които сте качили, но не сте свързали от никоя страница.

4.4. Скрийте версията на WordPress.

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

4.5. HTTPS навсякъде, с валиден сертификат.

Безплатните Let’s Encrypt сертификати с автоматично подновяване са стандарт при българските хостинг доставчици. Проверете, че всички ресурси на страницата се зареждат по HTTPS. Смесеното съдържание чупи защитата и предупреждава посетителите.

4.6. Заявки за сигурност (security headers).

Content-Security-Policy, X-Frame-Options, X-Content-Type-Options, Referrer-Policy, Strict-Transport-Security. Проверете текущото си състояние на securityheaders.com. Няма да спрат RCE, но ограничават щетата при XSS, а неавтентикираният stored XSS е втори в класацията на реално експлоатираните типове.

4.7. Внимание, ако имате няколко сайта на един хостинг акаунт.

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

Следствието: старата забравена инсталация компрометира новата. Нападателят влиза през WordPress 5.8, който никой не е обновявал от четири години, и оттам стига до файловете на основния ви сайт. Виждаме този сценарий редовно и той е особено неприятен, защото собственикът е сигурен, че е обновявал „сайта си”… просто е забравил, че има още три.

Какво да направите:

• Направете списък на всичко, което е инсталирано в акаунта ви. Включително поддомейни и поддиректории.
• Изтрийте изцяло това, което не се използва. Не го оставяйте „за всеки случай”, старата инсталация няма стойност, а носи риск.
• Ако наистина ви трябва, обновявайте я със същата дисциплина като основния сайт.
• Ако имате критично важен сайт, помислете за отделен хостинг акаунт за него, а не поддиректория до останалите.

Същото важи и за WordPress Multisite: една уязвимост в общ плъгин важи за всички сайтове в мрежата едновременно. Междудругото, WordPress 7.0.3 поправи именно уязвимост за повишаване на привилегии, специфична за Multisite.

Пласт 5: Бекъпи — вашият план Б, ако всичко останало се провали

Ако имате чист, тестван, външен бекъп, най-лошият сценарий става неприятен вместо катастрофален.

5.1. Правилото 3-2-1.

Три копия, на два различни носителя, едно от които извън обекта.

5.2. Бекъпът на същия сървър не е бекъп.

Ако нападателят има достъп до файловата система, той има достъп и до архивите ви. Виждали сме криптиране на сайт заедно с всичките му локални бекъпи. Съхранявайте копие извън хостинга — S3, Google Drive, локален диск, каквото и да е, но другаде.

5.3. Ротация и период на съхранение.

Заразата често се открива седмици след като е започнала. Ако пазите само последните 7 дни, всичките ви бекъпи може вече да са заразени и „възстановяването” ще върне бекдора обратно. Дръжте поне един месечен архив назад в рамките на 6 месеца.

5.4. Тествайте възстановяването. Наистина.

Това е точката, която почти всички пропускат. Бекъп, който никога не е бил възстановяван, е предположение, а не застраховка. Веднъж на тримесечие възстановете на staging среда и проверете, че сайтът работи. Ще откриете проблеми – липсваща база, непълни файлове, счупени пътища. По-добре сега, отколкото в кризата.

5.5. Бекъп преди всяка значима промяна.

Преди обновяване на core версия, преди нов плъгин, преди редакция на код.

Пласт 6: Мониторинг – да разберете преди клиентите си

6.1. Мониторинг на целостта на файловете.

Известява ви, когато PHP файл се промени неочаквано. Това е най-бързият сигнал за компрометиране, който съществува и работи дори когато зловредният код е нов и никой сканер още не го разпознава.

6.2. Мониторинг на достъпността.

Външна услуга, която проверява сайта на всеки 5 минути. Безплатните варианти вършат работа.

6.3. Google Search Console.

Настройте имейл известия. Google често вижда SEO спам инжекция преди вас. Проверявайте „Проблеми със сигурността” в рутината си, а не само когато нещо се обърка.

6.4. Известия за нови администраторски акаунти.

Създаването на администратор трябва да генерира имейл до вас. При юлската вълна от превземания през 2026 г. точно това беше видимият признак — Wiz документират над 100 бекдор администраторски акаунта, създадени в атакувани сайтове.

6.5. Планирайте тримесечен преглед на сигурността.

Един час на тримесечие: инвентар на плъгините, одит на потребителите, тест на бекъп, преглед на логовете. Сложете си го в календара, иначе няма да се случи.

Кой инструмент за какво служи

Въпросът „кой е най-добрият плъгин за сигурност” е грешно зададен, защото различните инструменти решават различни задачи, а някои от най-важните задачи не се решават с плъгин изобщо. Ето картата:

Задача	Какво я решава	Плъгин ли е?
Обновяване на ядрото навреме	Автоматични обновявания + процес	Не — конфигурация
Проследяване на уязвими плъгини	База данни за уязвимости или услуга за мониторинг	Частично
Блокиране на атака в движение	WAF — на ниво хостинг или облачен	Обикновено не
Откриване на променени файлове	Мониторинг на целостта	Да
Сканиране за зловреден код	Скенер (на ниво плъгин или сървър)	Да
Ограничаване на опитите за вход	Плъгин за сигурност	Да
Двуфакторна автентикация	Плъгин за 2FA	Да
Възстановяване след инцидент	Външен бекъп	Да, но не „за сигурност”
Почистване на зараза	Ръчна работа от човек	Не е плъгин

Практическите изводи:

Плъгин за сигурност покрива средната част на таблицата. Той е полезен и си заслужава — но обърнете внимание, че първият ред, който е и най-важният, не се решава от плъгин.

Не инсталирайте два скенера едновременно. Ще се засичат взаимно, ще натоварят сървъра и ще генерират фалшиви тревоги, които бързо ще се научите да игнорирате, а игнорираната тревога е по-лоша от липсваща.

Скенерът, който работи на ниво сървър, е по-надежден от този на ниво плъгин. Ако зловредният код е компрометирал WordPress, той може да скрие себе си от плъгин, който работи вътре в същия WordPress. Затова решения като Imunify360 при хостинга допълват, а не дублират плъгина.

Нито един скенер не гарантира пълно откриване. Скенерите работят по сигнатури и евристики. Прясно написан webshell, особено такъв с малък размер, редовно минава незабелязано. Затова мониторингът на целостта на файловете е по-надежден сигнал от сканирането — той не пита „познавам ли този код”, а „този файл променен ли е”.

Специфики за онлайн магазини

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

5.1. Скимери на платежни данни.

Ако приемате картови данни на собствената си страница, инжектиран JavaScript може да ги прихваща и изпраща навън, без нищо да се промени визуално. Клиентът плаща, поръчката минава, всичко изглежда нормално и данните вече са у нападателя. Най-надеждната защита е структурна: използвайте платежен доставчик, при който картовите данни никога не минават през вашия сървър (пренасочване към страницата на доставчика или изолиран iframe). Ако картовите данни не минават през вас, няма какво да бъде откраднато от вас.

5.2. Базата ви е ценна дори без карти.

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

5.3. Разширенията на WooCommerce са отделна атакувана повърхност.

Типичният български магазин има доставка до Еконт или Спиди, платежен модул, интеграция със счетоводен софтуер, синхронизация на склад, плъгин за фактури. Всеки от тях е код с достъп до поръчките. Приложете правилото за инвентар от Пласт 3 особено стриктно тук и проверете лицензите – платените разширения са норма при магазините.

5.4. Тестова поръчка след всяко обновяване.

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

5.5. Наблюдавайте поръчките за аномалии.

Внезапна серия дребни поръчки с различни карти обикновено означава, че някой тества откраднати карти през вашия магазин (card testing). Това не е кражба от вас, но води до chargeback-и, санкции от платежния доставчик и в тежки случаи прекратяване на договора.

5.6. Ограничете достъпа до данните за поръчките.

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

Петте грешки, които виждаме най-често

1. „Сайтът ми е малък, на никого не му трябва.”

Атаките не са насочени. Ботът не знае, че сте счетоводна кантора в Пловдив с 300 посетителя месечно. Той сканира диапазони от адреси и търси версия. Малкият сайт е дори по-привлекателен — обикновено няма кой да го наблюдава, така че става стабилна база за изпращане на спам, хостване на фишинг страници или пренасочване на трафик. Точно ниската видимост е предимството от гледна точка на нападателя.

2. „Хостингът се грижи за сигурността.”

Хостингът се грижи за сървъра. Не се грижи за вашия изтекъл лиценз на плъгин, за администратора с парола Firma2020, нито за темата, която не е обновявана от 2023 г. Данните на Patchstack са категорични: типичните хостинг защити блокират около 12% от WordPress-специфичните атаки. Това е допълнение, не заместител.

3. „Обновихме, значи е чисто.”

Най-скъпата грешка в списъка. Обновяването затваря входа, но не премахва бекдора, поставен преди пача. Ако сайтът ви е бил уязвим на wp2shell между 17 юли и момента, в който сте обновили, и през този период е имало активно сканиране — обновяването само по себе си не ви казва нищо за това дали някой вече е влязъл. Нужна е отделна проверка.

4. „Имаме бекъп”

Питаме всеки клиент: кога за последно възстановихте бекъп успешно? Отговорът почти винаги е „не сме пробвали”. Тогава при инцидент откриваме, че архивите са частични, повредени или вече заразени.

5. Няма отговорник.

При малките фирми сайтът е ничия земя между маркетинга, външния фрийлансър и „момчето, което го направи преди три години”. Никой не проверява версията. Никой не следи за оповестени уязвимости. Определете човек, дори това да сте вие, и му дайте 30 минути месечно.

Ако сте сте сигурни, че сайтът вече е хакнат

Какво да НЕ правите

• Не изтривайте файловете веднага. Ще унищожите доказателствата, които са ви нужни, за да разберете обхвата и дали са изтекли лични данни.
• Не възстановявайте „последния” бекъп рефлексивно. Ако не знаете кога е започнала заразата, е напълно възможно да възстановите вече заразена версия. Така има рис да презапишете текущото състояние и да загубите следите.
• Не обновявайте, преди да сте документирали. Обновяването презаписва файловете на ядрото заедно със следите в тях.
• Не сменяйте паролите, преди да сте затворили входа. Ако бекдорът е още активен, новите пароли изтичат моментално и създавате у себе си фалшиво усещане за решен проблем.
• Не пишете публично, че сте хакнати в социалните медии, преди да сте оправили. Това е покана за другите ботове.

Правилният ред

1. Запазете доказателствата. Пълно копие на файловете и базата, плюс логовете на уеб сървъра, FTP/SSH и панела за хостинг. Логовете обикновено се ротират в рамките на дни — извадете ги първи, преди да са изчезнали.
2. Изолирайте. Режим на поддръжка или ограничаване на достъпа по IP. Ако се разпраща спам или има фишинг съдържание, спрете сайта. Зашо? Репутационната щета расте всяка минута.
3. Установете входа. Каква версия работеше? Какви уязвими плъгини имаше? Какво показват логовете за момента на първата промяна? Без този отговор ще почистите и ще се заразите пак — и това е най-честата причина за повторно обаждане.
4. Почистете. Замяна на файловете на ядрото с оригинали, преинсталиране на плъгините от чисти източници, ръчна проверка на темата (тя е единственото място, което не може да се замени с оригинал, ако е персонализирана), почистване на инжекциите в базата, премахване на неоторизираните акаунти, преглед на планираните задачи.
5. Затворете входа. Обновете всичко. Пачнете или премахнете уязвимия компонент.
6. Ротирайте всички тайни. Пароли на всички потребители, парола на базата, salt ключове в wp-config.php, FTP/SSH достъпи, API ключове на всички интеграции.
7. Проверете правните си задължения. Виж Част 8 — ако има засегнати лични данни, часовникът тече.
8. Заявете преглед в Google. Search Console → Проблеми със сигурността → Заявка за преглед. Направете това, след като сте чисти, не преди — отхвърлената заявка забавя следващата.
9. Наблюдавайте 30 дни. Повторното заразяване обикновено идва от пропуснат бекдор и се проявява в първите седмици.

Кога да се обадите на професионалист

Обадете се, ако: не намирате входа; почистили сте и заразата се върна; имате данни на клиенти в базата; сайтът е блокиран от Google; изчезва ви трафик и не знаете защо; или просто нямате увереност, че сте направили всичко необходимо.

SiteFix.BG прави точно това — намираме входа, почистваме, затваряме дупката и оставаме да наблюдаваме, за да не се повтори. Работим с български бизнес и говорим на разбираем език, а не на жаргон.

Правната страна в България

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

Ако при пробива са засегнати лични данни

Няма да навлизаме в правни детайли. Все пак, това е работа на юрист, а не на хора, които чистят сайтове. Но едно нещо трябва да знаете, преди да ви се случи.

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

Практическото следствие е в реда на действията, а не в правото. Ако изтриете файловете и логовете в първите двайсет минути от паниката, няма да можете да установите какво точно е изтекло, а точно това ще ви бъде поискано. Именно затова стъпка 1 в раздела по-горе е „запазете доказателствата”, а не „почистете”.

Ако имате съмнение, че са засегнати данни на клиенти, направете две неща веднага: запазете всичко и се консултирайте с юрист. Актуалните изисквания и редът за уведомяване са публикувани на сайта на Комисията за защита на личните данни.

Закон за киберсигурност (NIS2): вероятно не се отнася за вас

Тук ще бъдем по-точни, отколкото е модерно.

Законът за изменение и допълнение на Закона за киберсигурност, който въвежда Директива NIS2, е обнародван в ДВ, бр. 17 от 13 февруари 2026 г. Той въвежда сериозни задължения: четиристепенно докладване на инциденти (ранно предупреждение до 24 часа, пълно уведомление до 72 часа, междинен доклад при поискване, окончателен доклад до 1 месец), лична отговорност на управителите и глоби до 20 млн. лв. или 2% от оборота за съществените субекти. Докладването минава през CERT България към Министерството на електронното управление.

Но обхватът е ограничен. Законът покрива средни и големи предприятия в определени сектори — енергетика, транспорт, банково дело, здравеопазване, питейна вода, управление на отпадъци, химикали, цифрови доставчици и др. Праговете са 50+ служители или 10+ млн. евро оборот за важните субекти, и 250+ служители или 50+ млн. евро за съществените.

Ако сте фирма с 8 души и корпоративен сайт, най-вероятно НЕ сте в обхвата на NIS2. Ще срещнете доста маркетингови текстове, които твърдят обратното — не се плашете, а проверете актуалния закон, сектора и размера си.

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

Практическа препоръка

Направете си еднократно два документа и ги сложете някъде достъпно:

1. Каква лична информация събира сайтът ми и къде се съхранява. Една страница. Ще ви е нужна в първия час на инцидента.
2. План за реакция при инцидент. Кой се обажда на кого, къде са бекъпите, кой има достъп до хостинга, кой уведомява отговорните институции. Половин страница.

Отнема час. В кризата струва много повече.

Пълният чеклист

Свалете пълния чеклист и го добавете във вашия Google Drive, за да използвате отметките.

Изтеглете пълния чеклист.

A. Спешно (днес)

• ☐ Проверена версия на WordPress в Табло → Обновявания
• ☐ Обновено до 7.0.4 / 6.9.7 / 6.8.8 или съответния актуален бекпорт
• ☐ Проверен списъкът с администратори за непознати акаунти (и за префикс w2s_)
• ☐ Проверен списъкът с плъгини за непознати инсталации
• ☐ Проверен имейлът на администратора в Настройки → Общи
• ☐ Проверени Проблеми със сигурността в Google Search Console
• ☐ Сайтът отворен в инкогнито от мобилен телефон
• ☐ Проверено site:вашиятдомейн.bg в Google за чужди страници

Б. Обновяване

• ☐ Включени автоматични обновявания на ядрото (WP_AUTO_UPDATE_CORE)
• ☐ Включени автоматични обновявания за безопасните плъгини
• ☐ PHP на текущо поддържана версия
• ☐ Определен отговорник за обновяванията
• ☐ Записан ритъм на проверка (минимум седмично)
• ☐ Налична staging среда за тестване

В. Достъп

• ☐ 2FA включена за всеки администратор без изключение
• ☐ Извършен одит на потребителите; премахнати неактивните
• ☐ Ролите сведени до минимално необходимите
• ☐ Няма потребител с име admin
• ☐ Ограничени опити за вход
• ☐ Страницата за вход преместена на нестандартен адрес
• ☐ Всички пароли уникални и в мениджър на пароли
• ☐ DISALLOW_FILE_EDIT активирано

Г. Плъгини и теми

• ☐ Направен пълен инвентар с предназначение на всеки плъгин
• ☐ Изтриване на неизползваните (не само деактивиране)
• ☐ Проверени за изоставени плъгини (над 12 месеца без обновяване)
• ☐ Проверени и валидни лицензи на платените плъгини
• ☐ Нула nulled плъгини и теми
• ☐ Изтрити неизползваните теми (остава активната + една резервна)
• ☐ Въведено правило за проверка преди инсталация

Д. Сървър и конфигурация

• ☐ Права: директории 755, файлове 644, wp-config.php 600/440
• ☐ Блокирано изпълнение на PHP в wp-content/uploads/
• ☐ Изключено индексиране на директории
• ☐ Скрита версията на WordPress
• ☐ HTTPS навсякъде, валиден сертификат, без смесено съдържание
• ☐ Настроени заявки за сигурност (security headers)
• ☐ XML-RPC изключен, ако не е нужен

Е. Бекъпи

• ☐ Автоматични ежедневни бекъпи
• ☐ Поне едно копие извън хостинг сървъра
• ☐ Период на съхранение минимум 30 дни; един месечен архив назад
• ☐ Възстановяването е тествано през последните 3 месеца
• ☐ Бекъп преди всяка значима промяна

Ж. Мониторинг

• ☐ Мониторинг на целостта на файловете
• ☐ Външен мониторинг на достъпността
• ☐ Google Search Console свързан с имейл известия
• ☐ Известие при създаване на нов администратор
• ☐ Тримесечен преглед на сигурността в календара

З. Правна готовност

• ☐ Документирано какви лични данни събира сайтът и къде се съхраняват
• ☐ Изготвен план за реакция при инцидент с посочени отговорници
• ☐ Известни каналът и срокът за уведомяване при изтичане на лични данни
• ☐ Проверено дали фирмата попада в обхвата на Закона за киберсигурност
• ☐ Записани контактите за спешна помощ, включително CERT България

И. Само за онлайн магазини

• ☐ Картовите данни не минават през вашия сървър
• ☐ Инвентар и проверени лицензи на всички разширения на магазина
• ☐ Тестова поръчка след всяко значимо обновяване
• ☐ Наблюдение за серии от дребни поръчки (card testing)
• ☐ Ограничен достъп до данните за поръчките по роли

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

Достатъчен ли е един плъгин за сигурност?

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

Автоматичните обновявания няма ли да счупят сайта ми?

Може, и това е реален риск. Но сравнете двете страни: счупен дизайн след обновяване се оправя от бекъп за минути; превзет сайт означава дни възстановяване, вероятно блокиране от Google, вероятни правни задължения и загубено доверие. Компромисът е автоматично за ядрото и безопасните плъгини, ръчно и бързо за критичните.

Обнових след wp2shell. В безопасност ли съм?

От тази конкретна уязвимост — да. Но обновяването не премахва бекдор, поставен преди пача. Ако сайтът е бил на уязвима версия след 17 юли 2026 г., направете проверката от Част 3.

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

Поискайте ги от поддръжката. Всички сериозни български доставчици пазят access логове и ще ви ги предоставят при запитване. Кажете конкретно какво търсите: заявки към /wp-json/batch/v1 и ?rest_route=/batch/v1 след 17 юли 2026 г.

Колко струва почистването на хакнат сайт?

Еднократното почистване на SiteFix.BG струва €49 — включва пълен security audit, премахване на зловреден код, проверка за backdoors и отчет с препоръки. Без абонамент, без скрити такси.

Мога ли да го почистя сам?

Ако имате достъп до SSH, работите уверено с командния ред и знаете какво правите — да. Ако сте почиствали веднъж и заразата се е върнала, значи има пропуснат бекдор; тогава повторният опит със същия метод рядко помага.

Речник на термините

RCE (Remote Code Execution) — отдалечено изпълнение на код. Най-тежкият тип уязвимост: нападателят изпълнява свои команди на вашия сървър.

Pre-auth / неавтентикиран — не изисква вход в системата. Всеки от интернет може да опита.

CVE — уникален идентификатор на публично известна уязвимост.

CVSS — стандартна оценка на тежестта от 0 до 10. Над 9.0 се смята за критично.

Webshell / бекдор — файл, оставен от нападателя, който му дава постоянен достъп дори след като първоначалната уязвимост бъде поправена.

WAF (Web Application Firewall) — филтър пред сайта, който блокира заявки по определени правила.

IoC (Indicators of Compromise) — следи, по които се разпознава, че е имало пробив.

Staging — копие на сайта, идентично на живото, но недостъпно публично. За тестове преди промени.

Nulled — пиратска версия на платен плъгин или тема, с премахната проверка на лиценз.

Salt ключове — низове в wp-config.php, с които се подписват сесиите. Смяната им изхвърля всички влезли потребители.

За SiteFix.BG

Възстановяваме хакнати сайтове и премахваме зловреден код за българския бизнес. Работим с WordPress ежедневно — намираме входа, почистваме, затваряме дупката и оставаме да наблюдаваме, за да не се повтори.

Ако имате съмнение, че нещо не е наред със сайта ви, най-евтиният момент да го проверите е сега.

Данните за версиите на WordPress и статуса на уязвимостите отразяват състоянието към 19 август 2026 г. Сигурността е процес — преглеждайте чеклиста на всяко тримесечие.

Източници

• SiteFix.BG
• W3Techs — Usage statistics of WordPress
• Patchstack — State of WordPress Security in 2026
• Wordfence Intelligence Vulnerability Database
• WordPress.org — WordPress 7.0.2 Release
• WordPress.org — Version 7.0.4
• Rapid7 — CVE-2026-63030: wp2shell, a Critical RCE in WordPress Core
• Bitdefender — Technical Advisory: wp2shell
• Wiz — Exploitation in the Wild of wp2shell
• The Hacker News — WordPress wp2shell Exploitation Grows
• CyberInsider — AI helped uncover WordPress wp2shell RCE
• Strobes — wp2shell: Pre-Auth RCE in WordPress
• Wordify — WordPress 7.0.4 security release
• CERT България — Национален екип за реагиране при инциденти с компютърната сигурност, Министерство на електронното управление
• Правко — NIS2 в България: Закон за киберсигурност 2026