21 октомври 2026, сряда
БизнесТехнология

Две критични уязвимости в PHP застрашават сървъри по целия свят – администраторите очакват спешни корекции

Две критични уязвимости в PHP застрашават сървъри по целия свят – администраторите очакват спешни корекции

Уязвимостите CVE-2026-109618 и CVE-2026-109619 са оценени с 9,2 от 10 по CVSS v4.0 и потенциално позволяват дистанционно изпълнение на код. След изтичане на информацията преди планираното разкриване екипът по сигурността на PHP насрочи извънредно издание с корекции за 21 октомври. Междувременно администраторите трябва да проверят всички PHP инсталации в Linux и Windows средите и да подготвят системите си за незабавна актуализация.

Две критични уязвимости в PHP, идентифицирани като CVE-2026-109618 и CVE-2026-109619, станаха публично известни на 20 октомври 2026 г., преди планираното координирано разкриване и публикуването на официални корекции. Според предварителната информация недостатъците могат да позволят дистанционно изпълнение на код (Remote Code Execution — RCE), което потенциално дава възможност на атакуващ да изпълнява команди върху уязвим сървър.

Екипът по сигурността на PHP определи и двете уязвимости като критични, с оценка 9,2 по системата CVSS v4.0. В отговор на изтичането беше обявено извънредно издание с корекции за 21 октомври 2026 г. от 14:00 UTC, или 17:00 ч. българско време.

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

Временно решение за защита е достъпно в GitHub

Докато се очакват официалните корекции, българската IT компания РЕВОННЕТ ЕООД публикува проект с временно решение за защита, достъпен в GitHub.

Хранилището е достъпно на адрес: github.com/revonnet/php-fix.

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

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

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

Изследователи от компанията за киберсигурност watchTowr потвърдиха достоверността на информацията за уязвимостите и съобщиха, че са успели да възпроизведат CVE-2026-109618.

Според публикацията на Huntress от 20 октомври към момента на нейното изготвяне не са били установени случаи на експлоатация на двете уязвимости в реална среда сред наблюдаваните партньорски системи на компанията. Това обаче не доказва, че няма засегнати организации извън наблюдаваната среда.

Виж и това  Колко космически отпадъци има в земната орбита и как можем да ги почистим?

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

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

Защо проблемът засяга толкова много системи?

PHP е широко използван език за разработка и поддръжка на уебсайтове и онлайн услуги. Той стои зад популярни платформи като WordPress, Drupal, Joomla и Magento, както и зад множество хостинг среди, контролни панели и корпоративни приложения.

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

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

Къде да търсим PHP инсталации?

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

Linux сървъри

При Linux системите проверките трябва да обхванат PHP CLI, PHP-FPM, PHP-CGI и интеграциите с уеб сървъри като Apache и Nginx.

Често срещани имена на изпълними файлове и процеси са:

  • php — команден интерфейс на PHP;
  • php-fpm — FastCGI Process Manager;
  • php-cgi — CGI/FastCGI изпълнение на PHP.

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

Windows сървъри

При Windows трябва да се проверят инсталациите на PHP, включително изпълнимите файлове:

  • php.exe — командният интерфейс на PHP;
  • php-cgi.exe — CGI/FastCGI изпълнение на PHP.
Виж и това  Заради кризата: По-скромни коледни бонуси в съдебната власт

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

Важно разграничение: файловете php.exe и php-cgi.exe са характерни за Windows PHP инсталации. При Linux обичайно се използват изпълними файлове като php, php-fpm и php-cgi, без разширението .exe.

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

Какви признаци могат да издадат атака?

Един от основните индикатори за евентуална експлоатация е необичайното стартиране на процеси от PHP работници или свързани уеб сървърни процеси.

Сред подозрителните действия са:

  • Стартиране на командни интерпретатори като sh и bash в Linux или cmd.exe и powershell.exe в Windows.
  • Изпълнение на скриптове чрез Python или Perl.
  • Използване на инструменти за изтегляне и мрежова комуникация като curl, wget и nc.
  • Изпълнение на команди за събиране на информация за системата, като whoami, id, uname -a и ipconfig, от процеси, свързани с уеб сървъра.
  • Необичайни опити за създаване и изтриване на файлове в директории, достъпни за PHP процесите.

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

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

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

Какво трябва да направят администраторите?

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

1. Инвентаризация на всички PHP инсталации

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

Виж и това  Цената на петрола Брент падна до под 80 долара за барел преди срещата на ОПЕК+

2. Подготовка за незабавно инсталиране на корекциите

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

3. Ограничаване на риска при неподдържани версии

Системите с PHP версии без активна поддръжка трябва да бъдат надградени или изолирани от интернет. Когато това не е възможно незабавно, достъпът може временно да бъде ограничен чрез VPN, защитна стена за уеб приложения (WAF) и други подходящи мерки.

4. Наблюдение на поведението на PHP процесите

При Linux следете за необичайно стартиране на sh, bash, python, perl, curl и wget. При Windows обръщайте внимание на подозрителни стартирания на cmd.exe, powershell.exe и други неочаквани процеси от PHP или уеб сървърни компоненти.

За Linux системи може да бъде разгледан и инструментът с отворен код process-watcher, предназначен за наблюдение на процеси и откриване на подозрително поведение.

5. Внимателна оценка на временните защитни решения

Инструменти като публикувания проект в github.com/revonnet/php-fix могат да бъдат оценени като част от плана за временно ограничаване на риска. Преди внедряване трябва да се прегледат инструкциите, ограниченията и съвместимостта им, без да се приема, че автоматично премахват уязвимостта.

6. Реакция при съмнение за компрометиране

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

Какво следва?

Ключовият момент е публикуването на официалното издание на PHP на 21 октомври 2026 г. То се очаква да предостави потвърдените засегнати версии, наличните корекции и технически подробности за CVE-2026-109618 и CVE-2026-109619.

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

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

Официален източник: PHP — предварително съобщение за изданието от 20 октомври 2026 г.

Допълнителен ресурс: Временно решение за PHP в GitHub