Сайтът ви е хакнат, но никой още не знае
Представете си следната ситуация. Отваряте фирмения си сайт сутринта. Всичко изглежда наред. Началната страница се зарежда, продуктите са на мястото си, формата за контакт работи, а поръчките продължават да пристигат. Няма предупредителни съобщения, няма повредени страници, няма нищо необичайно.
Само че някъде в директориите на сайта вече има файл, който не принадлежи там. Той не е част от системата, не е качен от програмистите и няма никаква легитимна функция. Поставен е от външен човек, който е открил уязвимост и си е осигурил начин да изпълнява команди на сървъра.
Сайтът продължава да работи. Именно това прави ситуацията толкова опасна.
Защо един хакнат сайт невинаги изглежда хакнат?
Популярната представа за хакерска атака включва заменена начална страница, заплашително съобщение или напълно недостъпен сайт. В действителност нападателите често нямат никакъв интерес да привличат внимание.
Компрометираният сайт може да бъде използван за изпращане на спам, създаване на фалшиви страници, пренасочване на посетители, кражба на информация или като междинна точка за други злонамерени действия. В някои случаи се инсталира така нареченият web shell — скрипт, който позволява отдалечен достъп до определени функции на сървъра.
Колкото по-дълго подобен достъп остава незабелязан, толкова повече възможности има нападателят. А собственикът на сайта може да разбере за проблема едва когато Google започне да показва непознати страници в резултатите от търсенето или хостинг доставчикът изпрати предупреждение.
Това не са хипотетични сценарии. Google документира случаи, при които компрометирани сайтове се използват за разпространение на злонамерен код, фишинг съдържание и SEO спам.
Понякога всичко започва от един забравен модул
Една от най-често подценяваните опасности са старите разширения и библиотеки. Някога те са били инсталирани с конкретна цел — галерия, форма за контакт, файлов мениджър, редактор на съдържание или система за резервни копия. Години по-късно функционалността може вече да не се използва, но кодът продължава да стои на сървъра.
И точно там се появява рискът.
През 2020 г. сериозна уязвимост в популярния WordPress плъгин File Manager позволява на външни лица да качват и изпълняват PHP файлове на уязвими сайтове. Проблемът е регистриран като CVE-2020-25213 и действително е експлоатиран. Не е било необходимо нападателят да знае администраторската парола — достатъчно е било сайтът да използва засегната версия на разширението.
Шест години по-късно подобни проблеми продължават да се появяват.
През април 2026 г. е оповестена уязвимост в разширението Ninja Forms – File Upload, използвано за качване на файлове през уебформи. При засегнатите версии проблемът позволява качване на опасни файлове и потенциално изпълнение на код на сървъра. Пълната корекция е публикувана във версия 3.3.27.
Интересното е, че това не са непременно неизвестни или съмнителни програми. Става дума за легитимни разширения, които имат реално приложение. Опасността възниква, когато дадена версия съдържа уязвимост, а сайтът не бъде актуализиран навреме.
И проблемът не се ограничава до WordPress. Подобни слабости могат да бъдат открити и в самостоятелно разработени сайтове, стари административни панели, PHP библиотеки и всяка друга система, която обработва файлове, заявки и потребителски данни.
През октомври 2026 г. самият PHP напомни колко сериозен може да бъде рискът
На 21 октомври 2026 г. екипът на PHP публикува извънредно важни актуализации за поддържаните версии на езика. Причината са две критични уязвимости — CVE-2026-109618 и CVE-2026-109619 — които при определени условия могат да позволят отдалечено изпълнение на код без удостоверяване на потребителя.
Това означава, че потенциалният проблем не е непременно в самия уебсайт. Дори приложението да е разработено правилно, уязвимост на ниво PHP може да изложи сървъра на риск.
Коригираните версии включват PHP 8.2.35, 8.3.36, 8.4.27 и 8.5.12.
Тук има още една важна подробност: „използваме PHP 8“ не е достатъчен отговор на въпроса дали системата е защитена. От значение е точната версия, включително последната цифра, както и дали съответните поправки са приложени от доставчика на операционната система.
Освен това поддръжката на PHP не е безкрайна. Например PHP 8.2 достига края на официалната си поддръжка на 31 декември 2026 г. След тази дата проектът PHP няма да публикува нови корекции за този клон. Някои Linux дистрибуции могат да продължат да предоставят собствени пачове, но това трябва да се проверява за конкретната система.
Това е причината поддръжката на един сайт да не приключва с неговото публикуване.
Как всъщност се открива, че нещо не е наред?
Понякога първата следа е необичайно име на файл в директорията за изображения. Например PHP скрипт сред стотици снимки, където по принцип не би трябвало да има изпълним код. Друг път се появява непознат администраторски профил, променен системен файл или нова задача за автоматично изпълнение.
Друга възможна следа е поведението на сайта. Ако посетителите понякога биват пренасочвани към непознати адреси, ако Google индексира страници, които никой не е създавал, или ако сървърът започне да изпраща неочаквано голямо количество изходящ трафик, това заслужава проверка.
Особено коварни са атаките, при които злонамереното съдържание се показва само при определени условия — например на посетители от търсачки или от конкретни устройства. Така собственикът може многократно да отваря сайта от своя компютър и да не забелязва нищо подозрително.
Разбира се, нито един от тези признаци сам по себе си не доказва хакерска атака. Необичайният трафик може да има напълно легитимно обяснение, а непознат файл може да е част от актуализация. Затова диагностиката трябва да се извършва внимателно.
Един от полезните инструменти за собствениците на сайтове е Google Search Console. В секцията Security issues могат да се появят известни на Google проблеми, свързани със злонамерено или измамно съдържание. Липсата на предупреждение обаче не е гаранция, че сайтът е чист.
По-надеждната проверка включва анализ на файловете, сравнение с доверени версии, преглед на системните логове, проверка на административните профили и наблюдение на необичайни заявки към сървъра.
Има и нещо, което често се пропуска: самото премахване на подозрителния файл невинаги решава проблема. Ако първоначалната уязвимост остава отворена, нападателят може да се върне. Ако са откраднати пароли или ключове за достъп, те също трябва да бъдат подменени. При установен пробив е важно да се запазят необходимите доказателства и логове, преди да се предприемат действия, които могат да ги унищожат.
А резервното копие?
Много собственици на сайтове приемат, че щом разполагат с архив, са защитени. Архивът действително е важна част от възстановяването, но не е универсално решение.
Ако даден сайт е компрометиран преди няколко седмици, част от последните резервни копия може вече да съдържат злонамерените файлове. Възстановяването на такъв архив би върнало и проблема.
Затова е важно да се съхраняват архиви от различни моменти, да има защитени копия извън основния сървър и периодично да се проверява дали възстановяването действително работи.
Най-същественият въпрос не е само дали можем да върнем сайта назад, а дали знаем кога е започнал проблемът и как е възникнал.
Сигурността не е еднократна услуга
Може би най-голямото заблуждение е, че един добре разработен сайт остава сигурен завинаги.
Софтуерът се променя непрекъснато. Откриват се нови уязвимости, излизат корекции, версии достигат края на поддръжката си. Това, което е било защитено преди година, може днес да изисква спешна актуализация.
Добрата поддръжка не означава безразборно обновяване на всичко. Тя включва инвентаризация на използвания софтуер, проследяване на критичните уязвимости, контролирано инсталиране на актуализации, тестове за съвместимост, резервни копия и наблюдение на поведението на сайта.
Защото най-опасният пробив невинаги е онзи, който спира бизнеса ви за няколко часа.
Понякога е този, който не пречи на сайта да работи, не предизвиква оплаквания и не се забелязва с месеци.
Докато някой друг вече използва част от инфраструктурата ви.