КРИТИЧНИ УЯЗВИМОСТИ В PHP: Необходима е незабавна проверка на интернет сайтовете и информационните системи в администрациите

Извънреден технически бюлетин на „Съвет БГ“

На 22 октомври 2026 г. CERT България – Националният екип за реагиране при инциденти с компютърната сигурност – публикува извънредно предупреждение за две критични уязвимости в програмната платформа PHP, използвана от огромен брой интернет сайтове, портали и информационни системи по света.

Предупреждението е разпространено и до административните структури, за които е необходимо предприемането на незабавни защитни мерки.

Уязвимостите са идентифицирани като CVE-2026-109618 и CVE-2026-109619 и са оценени с критичност 9,2 от максимални 10 точки по международната скала CVSS.

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

Това е известно като Remote Code Execution (RCE) и представлява една от най-сериозните категории уязвимости.

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

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

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

1. Кои версии на PHP са защитени?

На 21 октомври 2026 г. разработчиците на PHP публикуваха извънредни актуализации, които отстраняват двете критични уязвимости.

Клон на PHP	Минимална коригирана версия
PHP 8.5	8.5.12
PHP 8.4	8.4.27
PHP 8.3	8.3.36
PHP 8.2	8.2.35
PHP 8.1 и по-стари	Извън официалната поддръжка

Важно уточнение: използването на PHP 8.5 или PHP 8.4 само по себе си не означава, че системата е защитена. Необходимо е да бъде инсталирана конкретната коригирана подверсия или по-нова версия, съдържаща съответните поправки.

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

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

2. Първата стъпка: изясняване кои системи в администрацията използват PHP

Според нас това е най-важната организационна задача.

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

Често е известно кой поддържа даден софтуер, но не и каква програмна платформа използва той.

Препоръчваме да бъде извършена спешна инвентаризация, която да обхване:

Основния интернет сайт на администрацията;
Всички допълнителни домейни и поддомейни;
Сайтовете на общински съвети, общински предприятия, детски градини, социални услуги и други второстепенни структури;
Публичните справки за местни данъци и такси;
Деловодните системи и справките за движението на документи;
Счетоводни, финансови, кадрови и други информационни системи с уеб достъп;
Електронни услуги, регистри, интеграционни интерфейси и API;
Самостоятелни приложения, разработени по индивидуални проекти.

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

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

3. Втората стъпка: незабавна проверка на общинския сайт и контакт с хостинг доставчика

Ако интернет страницата на администрацията се намира на външен хостинг, препоръчваме незабавно да бъде изпратено писмено искане за техническа проверка.

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

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

Затова е необходимо да се изиска приоритетен технически съпорт, който да потвърди:

Коя е реално активната PHP версия за всеки домейн и поддомейн?
Приложени ли са корекциите за двете критични уязвимости?
Има ли останали сайтове, използващи неподдържани или уязвими версии?
Проверена ли е съвместимостта на приложенията след актуализациите?
Прилагат ли се допълнителни мерки за защита на хостинг ниво?
Налице ли са индикации в журналите за подозрителни заявки или опити за експлоатиране на уязвимостите?

Препоръчваме отговорът да бъде писмен, с конкретно посочени версии, предприети действия и установени рискове.

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

4. Защо актуализацията само на основния сайт не е достатъчна?

В много общини върху една хостинг инфраструктура функционират множество интернет ресурси.

Възможно е основният сайт вече да използва защитена PHP версия, но отделни поддомейни да продължават да работят с PHP 5.6, 7.4, 8.0 или други остарели версии.

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

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

Поради това е необходимо да бъдат проверени всички сайтове, а не само основният портал.

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

5. Третата стъпка: старите WordPress или други CMS сайтове може да изискват допълнителна разработка

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

При много стари интернет сайтове не е достатъчно просто да се избере нова PHP версия.

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

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

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

Тук следва да направим ясно разграничение:

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

Актуализирането и преработването на остарели интернет приложения представлява отделна дейност по уеб разработка и софтуерна поддръжка.

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

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

6. Четвъртата стъпка: проверка на федеративно предоставените портали

Не всички администрации използват самостоятелно хоствани интернет сайтове.

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

В тези случаи препоръчваме да бъде изпратено официално запитване до компетентното звено на Министерството на иновациите и дигиталната трансформация (МИДТ) и съответния оператор на инфраструктурата.

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

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

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

7. Петата стъпка: публичните справки и връзките към вътрешни информационни системи

Това е един от най-важните въпроси, на които искаме да обърнем внимание.

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

Типични примери са:

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

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

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

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

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

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

Следва ли публичните справки временно да бъдат спрени?

Нашата препоръка е да се прилага подход, основан на реалния риск.

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

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

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

Не препоръчваме обаче автоматично спиране на всички електронни справки само поради липса на отговор от доставчика.

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

8. Примерно писмо до разработчиците на информационни системи

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

Относно: Спешна проверка на информационни системи във връзка с предупреждение на CERT България за критични уязвимости в PHP

Уважаеми колеги,

Във връзка с официалното предупреждение на CERT България от 22.10.2026 г. относно критични уязвимости в програмната платформа PHP – CVE-2026-109618 и CVE-2026-109619, молим да извършите приоритетна техническа проверка на разработваните и поддържаните от Вас информационни системи, внедрени в нашата администрация.

Уязвимостите са с оценка 9,2 по международната скала CVSS и при определени условия позволяват дистанционно изпълнение на злонамерен код върху засегнатите системи.

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

В тази връзка молим да ни предоставите информация по следните въпроси:

Използват ли поддържаните от Вас системи PHP, включително в допълнителни модули и публични интерфейси?

Приложими ли са посочените уязвимости към внедрените информационни системи?

Ако се използват засегнати версии, извършени ли са необходимите актуализации?

Проверени ли са публично достъпните компоненти и връзките им с вътрешните информационни системи?

Необходимо ли е временно ограничаване на достъпа до определени публични справки или функционалности?

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

Молим да ни предоставите кратко писмено техническо становище, съдържащо обхвата на извършената проверка, резултатите, предприетите мерки и заключение относно приложимостта на уязвимостите.

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

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

Предвид критичността на предупреждението молим за приоритетно разглеждане и своевременен писмен отговор.

Официално предупреждение на CERT България:

https://www.govcert.bg/warnings/critical-vunerabilities-php/

С уважение,

[Наименование на администрацията]

9. Допълнително предупреждение от 23 октомври 2026 г.

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

Проблемът, идентифициран като CVE-2026-115560, се проявява при специфична комбинация от настройки и поведение на приложението.

Като временна превантивна мярка разработчиците препоръчват:

session.upload_progress.enabled=0

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

Тази мярка не замества актуализациите, публикувани на 21 октомври, а адресира отделен потенциален риск.

10. Нашите препоръки към ръководствата на администрациите

Считаме, че настоящата ситуация изисква както техническа, така и организационна реакция.

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

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

След приключване на първоначалните проверки е целесъобразно да бъде изготвен кратък доклад до ръководството, съдържащ:

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

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

В обобщение: киберсигурността започва с познаването на собствената инфраструктура

Случаят с критичните PHP уязвимости показва колко важно е всяка администрация да разполага с актуална информация за технологиите, които използва.

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

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

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

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

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

„Съвет БГ“ ЕООД

Извънреден технически бюлетин
24 октомври 2026 г.

Официални източници

CERT България – Критични уязвимости в PHP:
https://www.govcert.bg/warnings/critical-vunerabilities-php/

CERT-EU – Security Advisory 2026-018:
https://cert.europa.eu/publications/security-advisories/2026-018

Официални съобщения на PHP:
https://www.php.net/archive/2026.php

Министерство на иновациите и дигиталната трансформация:
https://midt.gov.bg