Пробивът в PHP застрашава онлайн магазини, общини и държавни институции

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

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

„Сайтът може да изглежда напълно нормално, да приема поръчки и да зарежда бързо, но средата, в която работи, да има опасен пропуск“, обяснява пред Economic.bg Васил Митев от MasterWeb.

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

Българските сайтове: къде е рискът?

Уязвимостите в PHP засягат популярни платформи като WordPress, WooCommerce, Joomla, Drupal, Magento, OpenCart и PrestaShop, както и приложения, разработени с Laravel и Symfony.

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

Васил Митев подчертава, че рискът зависи от версията на PHP, конфигурацията на сървъра и приложените защитни механизми. Според него, една от най-честите заблуди е, че редовното актуализиране на системата за управление на съдържанието е достатъчна защита.

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

Проблемът се усложнява от факта, че значителна част от сайтовете продължават да използват остарели версии на PHP. Според данни на W3Techs, към 22 октомври 2026 г. почти 35% от сайтовете, използващи PHP, работят с версии, по-стари от PHP 8. Това означава, че над една трета разчитат на поколения PHP, за които официалната поддръжка отдавна е прекратена.

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

Когато една уязвимост се превърне в бизнес загуба

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

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

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

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

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

Затова поддръжката трябва да се оценява и според цената на престоя. Полезният въпрос за един управител е: „Колко ще ни струва, ако утре тази система не работи?“, коментира експертът.

Защо държавните и общинските сайтове изискват специално внимание?

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

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

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

Представете си, че човек следва указания от официален адрес, на който има доверие, а информацията вече е променена от нападател. Именно затова защитата на публичните сайтове е част от отговорността към гражданите“, посочва Митев.

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

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

„Бих попитал всяка от тях: знаете ли кои системи поддържате, кой ги обновява и кой реагира при инцидент? Липсата на ясен отговор вече е проблем.“

Атаките вече са факт. Какво следва?

Междувременно последните данни показват, че заплахата не е останала само теоретична. В четвъртък Amazon Threat Intelligence публикува подробности за засечен опит за експлоатиране на PHP2Shell още на 17 октомври – четири дни преди официалното оповестяване на уязвимостите. Активността е установена чрез MadPot – мрежа от специално изградени системи, които привличат и регистрират опити за атаки.

Впоследствие са засечени нови опити от различни източници, а след публикуването на поправките атакуващите започват почти незабавно да използват появилите се демонстрационни експлойти. Според Amazon, все още не е ясно дали конкретните ранни опити биха били успешни срещу реални системи. Компанията обаче вече определя експлоатирането на уязвимостите като широко разпространено.

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

Това обаче не отменя необходимостта от поправка на PHP.

„Не бих приел „имаме Cloudflare“ като достатъчен отговор. Трябва да има и приложена корекция, ограничени права, наблюдение и надеждни резервни копия“, предупреждава Васил Митев.

Според него наличието на архиви само по себе си също не е гаранция за защита. Важно е предварително да е проверено дали системите действително могат да бъдат възстановени от тях.

Кой всъщност отговаря за сигурността?

За собствениците на бизнес, които нямат технически познания, Митев препоръчва конкретно действие – да се свържат с фирмата или специалиста, който поддържа сайта, и да поискат отговор на три въпроса: използва ли се засегната PHP среда, приложена ли е необходимата корекция и как е проверено това?

Официалните поправки са включени във версиите PHP 8.5.12, 8.4.27, 8.3.36 и 8.2.35. При някои доставчици защитата може да е добавена и чрез актуализация на техен собствен пакет, поради което само номерът на версията невинаги е достатъчен за оценка. За по-стари клонове на PHP са предоставени и корекции на изходния код, предназначени за доставчици, които поддържат такива среди.

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

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

„Опасно е всеки да предполага, че другият се е погрижил“, подчертава Митев.

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

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

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

Според Васил Митев обаче отговорът за компаниите не е непременно незабавното внедряване на AI решения за киберсигурност.

„Първо трябва да са подредени основните неща: кои системи има, кой ги поддържа, как се наблюдават и как се реагира при проблем. AI може да помогне на този процес, но не може да замести липсващата отговорност.“