Уязвимостта в PHP от 21 октомври: какво се случи и какво е текущото състояние

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

Какво се случи?

Пробивите (CVE-2026-109618 и CVE-2026-109619) правеха възможно за неоторизирани лица да изпълняват код на уеб сървър. Това е почти най-лошият вид пробив, който съществува: за него атакуващият не се нуждае от парола и засяга практически целия интернет.

Как реагирахме

1. Временна мяркасряда, 21 октомври, 10:00

   В този момент беше известно само, че във всички версии на PHP има два сериозни пробива с CVE оценка 9,2. Все още нямаше подробности и не бяха известни успешни хакове, въпреки че например Cloudflare забелязваше все повече опити. Тъй като подробностите за пробива не бяха известни, никой не знаеше точно какво е положението и какво може да се направи, за да се ограничи рискът. Постепенно ставаха известни все повече мерки и възможни действия за ограничаване на риска. Тях прилагахме веднага, например изключването на определени PHP функции и многократното актуализиране на защитната стена (firewall).
   От 10:00 ч. непрекъснато пускахме и много строги сканирания за злонамерен софтуер, за да забележим веднага, ако някъде на нашите сървъри или в акаунтите на нашите клиенти бъде поставен скрипт. Това не се случи.

2. Уебсайтовете офлайнсряда, 21 октомври, 15:15

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

3. Официално решениесряда, 21 октомври, 16:00

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

4. Временно решениесряда, 21 октомври, 19:00

   За съжаление отне доста по-дълго, отколкото се надявахме и очаквахме, докато CloudLinux подготви актуализациите. От контактите ни с други доставчици стана ясно, че не сме единствените, които бяха изненадани. Тъй като видяхме, че те вече няколко пъти не бяха спазили собствените си определени крайни срокове, работихме по временно решение.
   Сами инсталирахме версия PHP 8.3.36 на всички наши сървъри и временно прехвърлихме всички наши клиенти на тази версия. 90% от уебсайтовете отново бяха онлайн между 19:00 и 20:30 ч. Единствените уебсайтове, които не станаха отново достъпни, бяха остарели и не можеха да работят със съвременна версия на PHP.

5. Актуализиранечетвъртък, 22 октомври, 00:30

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

6. Решеночетвъртък, 22 октомври, 02:30

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

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

Какво е положението сега?

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

Моят уебсайт отделен ли е от тези на другите?

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