Накратко: Основният риск за един WordPress сайт не е самият WordPress, а плъгините (plugins). Според доклада на Patchstack за 2026 г. 91% от новите уязвимости през 2025 г. са в плъгини, а при масово атакуваните уязвимости медианното време до първата атака е около 5 часа след публикуването им. Хостингът сам не спира повечето такива атаки. Сигурността идва от редовна поддръжка: обновяване, премахване на излишното, резервни копия с тест за възстановяване, защитен достъп и наблюдение.
Откъде идва рискът за WordPress сайтовете?
Patchstack, компания, която събира данни за уязвимости и предлага защита за WordPress, публикува на 25 февруари 2026 г. годишния си доклад. Числата са от доклад на доставчик на защита, затова ги четете като такива, но картината е ясна:
- Обем: през 2025 г. са открити 11 334 нови уязвимости в екосистемата на WordPress, с 42% повече от 2024 г.
- Плъгини: 91% от новите уязвимости са в плъгини, а 9% в теми.
- Ядрото на WordPress: само 6 уязвимости, и то с нисък приоритет.
- Без поправка: за 46% от уязвимостите разработчикът не е пуснал поправка до момента на публичното им оповестяване.
- Платени плъгини: докладът отбелязва висок дял сериозни уязвимости и в платените компоненти, затова «платен» не означава «безопасен».
Какво означава това за Вашия бизнес? Всеки плъгин е чужд код, който работи с пълен достъп до сайта. Сайт с 40 плъгина има 40 отделни източника на риск, всеки със свой разработчик и свой темп на поправки.
Колко бързо се използват уязвимостите?
Често по-бързо, отколкото сайтът се обновява. Според Patchstack около половината от уязвимостите с голямо въздействие се използват в атаки в рамките на 24 часа след оповестяването. Когато се отчете колко интензивни са атаките, медианното време до първата атака при масово атакуваните уязвимости е 5 часа.
Старите уязвимости също не изчезват. В списъка на Patchstack с уязвимостите, срещу които през 2025 г. е имало много атаки, има и уязвимости, публикувани през 2023 г. и 2024 г., които продължават да се използват, защото на много сайтове все още стоят старите версии на плъгините.
Точно тук е разликата. Обновяване «веднъж месечно, когато има време» оставя сайта уязвим седмици наред, а автоматизираните атаки не чакат.
Защо хостингът сам не е достатъчен?
Добрият хостинг е важен, но той защитава сървъра, не приложението. В официалното ръководство на WordPress за защита е посочено, че хостинг компаниите обикновено отговарят за инфраструктурата, но не и за приложението, което сте инсталирали.
Patchstack е тествал колко атаки срещу уязвимости в WordPress спират обичайни защити като защитни стени (WAF) при хостинга и услуги от типа на Cloudflare. В първия тест, насочен към уязвимости, които реално се използват в атаки, са спрени само 12% от атаките. Във втория, по-широк тест, са спрени 26%.
Причината е, че много атаки срещу плъгини изглеждат като нормален трафик. Категорията уязвимости, използвана в атаки по-често от всички други през 2025 г., е свързана с контрола на достъпа, при която заявката на нападателя прилича на обикновено действие на влязъл потребител.
Съвет от ScaleLab: Попитайте хостинг компанията си писмено какво точно покрива: обновява ли плъгините, пази ли резервни копия извън същия сървър и кой възстановява сайта при пробив. Така ще знаете кои задачи остават за Вас.
Какъв режим на поддръжка пази сайта?
Няма една мярка, която решава всичко. Работи комбинацията от няколко прости навика, изпълнявани редовно.
1. Определете политика за обновяване
От WordPress 5.5 насам администраторът може да включи автоматично обновяване за всеки плъгин и тема поотделно. WordPress проверява за автоматични обновявания два пъти дневно и по подразбиране изпраща имейл при успешно или неуспешно обновяване.
Препоръчваме да разделите плъгините на две групи. За простите и широко използвани включете автоматично обновяване. За тези, от които зависи поръчката или формата за запитване, тествайте обновяването първо на тестово копие (staging), но в рамките на часове или дни, не седмици. При публикувана сериозна уязвимост обновявайте веднага.
2. Премахнете неизползваните плъгини и теми
Официалното ръководство на WordPress е категорично: ако не използвате даден плъгин, изтрийте го. Изключеният, но неизтрит плъгин остава на сървъра. Премахнете и темите, които не са активни, освен една резервна, и плъгините, чиито разработчици отдавна не пускат обновявания.
3. Правете резервни копия и тествайте възстановяването
Пазете редовни копия на целия сайт, файловете и базата данни, на надеждно място извън същия сървър. Копие, от което никой не е възстановявал, е само надежда. Поне веднъж на тримесечие възстановете сайта на тестова среда и проверете дали формите и поръчките работят.
4. Защитете достъпа
- Пароли: дълги, генерирани пароли за всеки администратор, без повтаряне в други системи.
- Двуфакторно удостоверяване (2FA): ръководството на WordPress го препоръчва като допълнителна защита. Включете го поне за всички администратори.
- Минимални права: всеки получава само ролята, от която има нужда. Бившите служители и агенции се премахват в деня, в който приключи работата с тях.
5. Наблюдавайте сайта
Следете дали сайтът е достъпен, дали има нови администратори или непознати файлове и дали Google Search Console не показва проблеми със сигурността. Абонирайте се за известия за уязвимости в плъгините, които използвате, за да знаете за проблема преди нападателите.
6. Добавете виртуално закърпване или защитна стена (WAF)
Защитна стена за уеб приложения (WAF) филтрира трафика преди да стигне до сайта. Виртуалното закърпване (virtual patching) добавя правило, което блокира конкретна уязвимост, докато разработчикът пусне поправка. Това е полезен допълнителен слой, особено за уязвимостите без поправка, но не заменя обновяването и резервните копия.
7. Подгответе план за инцидент
Решете предварително какво се случва, ако сайтът бъде пробит. Кой е първият човек, когото търсите, и как се свързвате с него извън работно време. От кое резервно копие възстановявате и как проверявате, че то е отпреди пробива. Кои пароли се сменят веднага, как се откриват новите администратори и непознатите файлове и кой уведомява клиентите, ако са засегнати лични данни. Запишете отговорите на една страница. В момента на инцидента никой няма време да ги измисля.
Кой отговаря за сигурността на сайта?
Често проблемът не е технически, а организационен: всеки смята, че друг се грижи. Подредете отговорностите писмено.
| Роля | За какво отговаря |
|---|---|
| Хостинг компания | Сървър, мрежа, наличност на инфраструктурата |
| Разработчик на сайта | Качество на кода и подбор на плъгините при изработката |
| Поддръжка на сайта | Обновявания, резервни копия, наблюдение, реакция при инцидент |
| Собственик на бизнеса | Кой има достъп, одобрение на рисковете, бюджет за поддръжка |
Ако фирмата Ви попада в обхвата на новите правила за киберсигурност, отговорността на ръководството става и правна. Повече ще намерите в статията за изискванията на NIS2. Ако не сте сигурни в какво състояние е сайтът Ви днес, започнете с безплатния одит.
Съвет от ScaleLab: Направете списък на всички плъгини с три колони: за какво служи, кой го е инсталирал и кога е обновен за последно. Плъгините, за които никой не знае отговора на първия въпрос, са първите кандидати за изтриване.
Така е подредена работата по поддръжка на сайт и хостинг: софтуерът и добавките се обновяват, поправките за сигурност се прилагат навреме, пазят се резервни копия, а сайтът се наблюдава денонощно, за да се разбере за проблем преди клиентите.
Често задавани въпроси
Сигурен ли е WordPress?
Ядрото на WordPress има много малко уязвимости: според Patchstack само 6 през 2025 г., и то с нисък приоритет. Рискът идва основно от плъгините и темите, затова сигурността на сайта зависи от това кои плъгини използвате и колко бързо ги обновявате.
Достатъчно ли е да включим автоматичното обновяване?
Автоматичното обновяване намалява времето, през което сайтът е уязвим, но не решава всичко. За почти половината от уязвимостите няма поправка към момента на оповестяването им, затова са нужни и резервни копия, наблюдение и допълнителна защита.
Нашият хостинг има защитна стена. Защо ни трябва още нещо?
Защитите на ниво хостинг спират само част от атаките срещу плъгини: в тестовете на Patchstack между 12% и 26%. Хостингът отговаря за сървъра, а приложението и плъгините остават Ваша отговорност.
Колко често да правим резервни копия?
Честотата зависи от това колко често се променя сайтът: онлайн магазин с ежедневни поръчки има нужда от по-чести копия от представителен сайт. По-важно от честотата е копието да е извън същия сървър и възстановяването да е тествано.